SYS.2 – System Requirements Analysis

---

Welcome back!
I´m NotDenis and I will give you my thoughts on the A-SPICE SYS.2 process. In the last blogs we have covered the structure and concept of A-SPICE where as now I want to explain each process of the HIS/VDA Scope.

Structure

But before we start maybe we should check how the processes are documented.
If you investigate such a A-SPICE related process you will find following structure.

• Process ID:
  Mainly showing the ID like in our example it would be SYS.2
• Process Name:
  I don´t think I need to explain this :D. In our case it would be „System Requirement Analysis“
• Process purpose:
  This is a summary of what you want to achieve with this process.
• Process outcomes:
  This is a indicator if you have succeeded with your implementation. If you´re able to answer every outcome with „yes“, then you should be fine.
• Base practices:
  They describe the process steps you need to fulfill the A-SPICE process. It is structured with the Process ID in the beginning and its BP ID (e.g. SYS.2.BP1 Specify system requirements). At the end they also display which work product you need to gather your results of the process.
• Output work products:
  This helps you identify relevant work products mentioned within the base practices. They show you the A-SPICE ID + Name + Outcome definition. So e.g. if your process has outcome 8 at the end. So for our example we would need 13-04 Communication record. And if I need more input on how this Communication record is defined, then I can look it up within the norm describing relevant information.

Lets get started

So we will start today with SYS.2 System Requirements Analysis
ID: SYS.2
Process name: System Requirements Analysis
Process purpose: Based on the identified stakeholder requirements we want to define our system requirements which also will have impact on the systems design.
Process outcomes: This process is successful if:

• a set of system requirements is generated.
• the system requirements are categorized and analyzed for verifiability and correctness.
• the impact on the operating environment from the system requirements is being analyzed/checked.
• for the implementation of the system requirements a prioritization is being used.
• the system requirements are up to date.
• stakeholder & system requirements are consistent and have bidirectional traceability to each other.
• the system requirements have been checked for financial aspects, schedule and technical impact.
• all relevant parties have agreed on the communicated system requirements

Base practices:

Let´s start with our first Sub-process

SYS.2-BP.1 Specify System Requirements
So, in a few words explained. We take our Stakeholder Requirements and identify based on that our functions and capabilities within System Requirements. After that we cluster them into functional and Non-functional and store them in a System Requirements Specification. Let´s try to draw it

We can also see that we need to deliver a set of Work Products. In this process it is:

• 13-21 Change Control Record
• 17-08 Interface requirements specification
• 17-12 System requirements specification
• 15-01 Analysis report

Those are defined more granular within the norm. They show you what each Work Product contains. I would recommend to look it up.

SYS.2-BP.2 Structure System Requirements
Now that we have our System Requirements, we now structure them within the specification by e.g.

• grouped by project relevant clusters
• sorted for logical order within project
• categorization based on relevant criteria for project
• priotization due to stakeholder needs

After that we will have gained a structured System Requirement Specification
It could something like this

So even if the System Requirement Specification is not mentioned as WP, I think its still some kind of result due to the structuring. So officially we need to produce following WP´s

• 17-50 Verification criteria
• 15-01 Analysis Report

SYS.2-BP.3 Analyze System Requirements
In this process we need to (as the name says) analyze our system requirements and their interdependencies to check their correctness, technical feasibility and verifiability, and to support risk identification. This analysis includes also the impact on cost, schedule and technical impact.

So this process impacts following WP´s

• 13-21 Change control record
• 15-01 Analysis report
• 17-08 Interface requirements specification
• 17-12 System requirements specification
• 17-50 Verification criteria

SYS.2-BP.4 Analyze the impact on the operating environment
Identify relevant interfaces between your system and other elements in terms of the operating environment. Check the influence of your system requirements on those interfaces and operating environment.

Our WP´s for this process are:

• 15-01 Analysis report
• 17-08 Interface requirements specification

SYS.2-BP.5 Develop verification criteria
Now we need to develop/identify verification criteria for every system requirement we have defined so far. They should measure qualitative and quantitative values for the verification of the requirement.

• 15-01 Analysis report
• 17-50 Verification criteria

SYS.2-BP.6 Establish bidirectional traceability
Now that we have provided a certain quality into our information packages we now need to set our content into a relation. Therefore we need to connect our stakeholder requirements with the system requirements.

So this one was easy. If you use a Lifecycle solution. If not this can be a challenge (e.g. Word or Excel) Our WP´s in this process are

• 13-22 Traceability record
• 13-19 Review Record

SYS.2-BP.7 Ensure consistency
This is very dependent on the BP.6 which now checks if the right versions of the content are connected to each other.

This one was easy to draw :).
Our WP´s are

• 13-22 Traceability record
• 13-19 Review record

SYS.2-BP.8 Communicate agreed system requirements
Yes we almost did it! Now we only need to communicate the agreed system requirements and updates of the system requirements to all relevant parties.

This will result in a

• 13-04 Communication record

You did it!!

We´ve fulfilled our first A-SPICE process. How do you feel? Amazing right? 15 more to go 😀

If we now put everything together it looks like this:

Not very good looking, right? But this enables us to now see everything (on process level) related to the SYS.2 process and understand it a little bit better.

Thank you

for reading this post. I hope that it made the SYS.2 process a little bit clearer for you. If you have some questions, use the comment section. I´ll answer it ASAP.

NEXT UP

• Deep Dive SYS.3 System Architectural Design