Introduction
Why the necessity to document the system requirements? As a rule, organizations already have customer requirements, so why invest time and effort to document additional system requirements? In a project, the goal is to deliver the agreed results on time, within budget and in the quality required by the customer. If a supplier does not document system requirements, they may overlook the functionality or completely misinterpret customer expectations. This causes additional effort, costs and delays. Sometimes suppliers overlook aspects of the system that are essential to the functionality or non-functional aspects of the system. This can lead to false starts or even additional development cycles.
We regard the following as the most important aspects of System Requirements Analysis in Automotive SPICE:
-
The need for system requirements and structure. An important reason for documenting system requirements is the need to consider more than the customer's expectations. Most systems must meet standards, norms and other regulations that increase the number of requirements. For this reason, the process describes them as stakeholder requirements. For documentation purposes, map the stakeholder requirements to the system requirements that reflect the internal view of the system. The system requirements, in turn, form the basis for the system qualification test and all downstream processes, e.g., system architecture.
The system requirements describe the system as a black box, the "what". What should the system do, not "how" should it do something. As an example, when we develop an electronic control unit (ECU), we identify the following:
- They describe what the signals are that reach the pins of the connector, what the system should do with these signals and what output signals we expect at the pins of the connector.
- Part of this approach is also to structure the requirements in such a way that they are meaningful for the internal organization and support the distribution to different areas.
- This verifies that each organizational unit knows which requirements are relevant to it. These may be attributes, e.g., to classify requirements according to ISO 26262, it could be a functional structure to support distribution to function groups, etc.
Typically, requirements management is supported by appropriate tools such as a requirements database.
- Staffing of this process. A challenge can be how to find employees who can support the definition of system requirements. The reason why this is a challenge is that a systems engineer must be an all-rounder. If you want to develop a mechatronic system such as power steering, this engineer must have a deep understanding of mechanics, electronics and software development. This is almost impossible to combine in one person. If an organization does not have this type of personnel, a workaround would be to put together a cross-domain team responsible for jointly defining system requirements.
- The analysis of requirements. Another aspect of this process, as the name suggests, is the analysis of requirements. The requirements should be analyzed for feasibility or risk. These two are closely linked. If the feasibility of a requirement is in question, there is an inherent risk (because it may take time to find a solution) or there may be no solution at all. Another topic to analyze is testability. Of course, the support of the testers can be used to support this. Often the testers are asked to review the requirements. The analysis should also cover the technical implications. This includes the assessment of dependencies between requirements.
An example of this could be the "close" function of a window regulator ECU. The close function requires the window pane to slide upwards until the window is closed. However, there is a contradicting safety function, the so-called "anti-pinch" function, which is designed to prevent fingers from getting caught when the window is closed. There is an obvious interdependence and mutual technical implication between these requirements. This should be considered in the context of the analysis.
Last but not least, the analysis should also cover business aspects of the requirements. It should therefore be determined how the implementation of the various requirements effects costs and timeline. One can say that it is not possible to document all this in the requirements database.
- Note that Automotive SPICE does not say where to document this.
For example, you could cover the first part of the analysis (feasibility and risks) in the requirements database, the technical implications in corresponding and linked change requests and the impact on costs and schedule in your project management tools.
-
The effort into traceability and consistency. This process also requires the confirmation of traceability and consistency between system requirements and stakeholder requirements.
The purpose of traceability is to support:
- Consistency checks — i.e., to verify the completeness and accuracy of the system requirements.
- The impact assessment in case of change requests or deficiencies.
- The reporting of stakeholder expectations.
The second part of this aspect is consistency.
Consistency means one can prove completeness and correctness of system requirements against the stakeholder requirements. As this process is the entry into development, one will want to confirm that the system requirements are covering the stakeholder requirements correctly. It’s important not to skip this review.
The purpose of Automotive SPICE system requirements analysis, according to Automotive SPICE, is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.
Best practices (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:
- 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.
BP3: Analyze system requirements. Analyze the specified system requirements including their interdependencies to verify 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.
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: Verify 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 requirementand updates to system requirements to all relevant parties.
Output work Products
- Communication record
- Review record
- Change control record
- Traceability record
- Analysis report
- Interface requirements specification
- System requirements specification
- Verification criteria
What is the benefit of system requirements analysis?
System requirements analysis is the basis of the development of the complete product. Problems that arise 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 of the system requirements analysis process?
- 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).
Inputs for the system requirements specification
- Verification criteria are developed which give direction to 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).
Considerations for typical challenges
- 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 confirm 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.
Learn more about Automotive SPICE
If you want to learn more about Automotive SPICE®, check out our ASPICE Training.
About the author
Bhaskar Vanamali has been working on process improvement for nearly 20 years and was secretary of the working group 13 of VDA QMC.
He is Principal Assessor and Trainer for Automotive SPICE®, and has performed more than 140 assessments and trained more than 250 assessors.
Read our related content
Automotive SPICE®: System Requirements Analysis SYS.2 resource guide
To access the rest of this engaging content, please fill out the form below:
Please wait…