3. The ASPICE-Processes (VDA Scope)
3.1 SYS.2 – System Requirements Analysis
What is the purpose?
The requirements for the system are collected, analyzed and categorized in a system requirements specification.
What is the benefit?
System requirements analysis is the basis of the development of the complete product. Problems injected during this stage may cause unnecessary and unplanned costs as well as schedule deviations later in the development lifecycle. However, if the system requirements are fully described, unambiguous and well structured, this provides a strong foundation for an efficient development and a functioning system test.
What is the content?
- The functional and non-functional requirements for the system are determined, taking into account the input of all internal and external stakeholders. (BP1)
- All system requirements are examined for technical feasibility, testability, risks, effects on the operating environment and interdependencies. They are structured in a logical order according to the needs of the project. (BP2,BP3, BP4)
- Verification criteria are developed which give hints how requirement should be verified. (BP5)
- The requirements are prioritized, structured, and assigned to releases. (BP2)
- Consistent bidirectional traceability is established between the system requirements and the stakeholder requirements. (BP6, BP7)
- System requirements and their updates are agreed upon and communicated to all stakeholders. (BP8)
Experiences, problems and hints
- The system requirements should not be copies of the customer requirements. System requirements should be derived and detailed out from the customer requirements. The number of system requirements is typically significantly larger than the number of corresponding customer requirements.
- A recursive approach when deriving the system requirements is useful because the development of the system architecture often yields additional requirements or restrictions for the system.
- Discussions of the system requirement specification with the customer may be very helpful to obtain a thorough and common understanding. This is often done in joint workshops. The results of these workshops should be documented and traceable to the related requirements.
- In case of an existing product platform the project needs to determine the customer requirements which are already satisfied by the platform and the delta which needs to be covered by the customer project.
- Non-functional requirements (e.g., process requirements, quality requirements) are often neglected.
- There should be also internal system requirements based on own knowledge and experience which have not been derived from the customer requirements.
- Sometimes customers have frequent changes to their requirements and leave it to the supplier to find out what the exact changes are. This leads to large additional cost and delays on the supplier side.
- Traceability is not enough by itself, consistency has to be demonstrated. Consistency checks (through reviews) have to assure that system requirements are correct interpretations of customer requirements and that traceability and links are correct and complete.
- Additional value of the system requirement’s independence from the stakeholder’s is that is shall be voiced in language and context familiar to the supplier. This makes it easier to shift staff between projects.
- Often customers have requirements specs which span many of their products and it is very tedious to find out whether a requirement is relevant for this project. Organizational support teams can do this analysis thereby reducing multiplied effort in projects.
Automotive SPICE text of System Requirements Analysis (SYS.2)
The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.
BP1: Specify system requirements. Use the stakeholder requirements and changes to the stakeholder requirements to identify the required functions and capabilities of the system. Specify functional and non-functional system requirements in a system requirements specification.
NOTE 1: Application parameter influencing functions and capabilities are part of the system requirements.
NOTE 2: For changes to the stakeholder’s requirements SUP.10 applies.
BP2: Structure system requirements. Structure the system requirements in the system requirements specification by e.g.
- grouping to project relevant clusters,
- sorting in a logical order for the project,
- categorizing based on relevant criteria for the project,
- prioritizing according to stakeholder needs.
NOTE 3: Prioritizing typically includes the assignment of functional content to planned releases. Refer to SPL.2.BP1.
BP3: Analyze system requirements. Analyze the specified system requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact.
NOTE 4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to MAN.3.BP5.
BP4: Analyze the impact on the operating environment. Identify the interfaces between the specified system and other elements of the operating environment. Analyze the impact that the system requirements will have on these interfaces and the operating environment.
BP5: Develop verification criteria. Develop the verification criteria for each system requirement that define the qualitative and quantitative measures for the verification of a requirement.
NOTE 5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the system test cases or other verification measures that ensures compliance with the system requirements.
NOTE 6: Verification which cannot be covered by testing is covered by SUP.2.
BP6: Establish bidirectional traceability. Establish bidirectional traceability between stakeholder requirements and system requirements.
NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.
BP7: Ensure consistency. Ensure consistency between stakeholder requirements and system requirements.
NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
BP8: Communicate agreed system requirements. Communicate the agreed system requirements and updates to system requirements to all relevant parties. [OUTCOME 8]
Output Work Products
Communication record, Review record, Change control record, Traceability record, Analysis report, Interface requirements specification, System requirements specification, Verification criteria
If you wish to continue to the next chapter click here: