Why should you document the software requirements? As a rule, you already have system or customer requirements, so why invest time and effort to document additional software requirements? In a project, you want to deliver the agreed results on time, within budget and in the quality required by the customer. If you do not document your software requirements, you may overlook the functionality or completely misinterpret your customers' expectations. This causes additional effort, costs and delays. You can also overlook aspects of your software that are essential to the functionality or nonfunctional aspects of your software. This can lead to false starts or even additional development cycles.
This process has strong links upstream to System Requirements Analysis (SYS.2), System Architectural Design (SYS.3), and downstream to Software Architecture (SWE.2) and Software Qualification Test (SWE.6). Other processes with strong dependencies are Project Management (MAN.3) and Configuration Management (SUP.8), for instance, because of release management, and Defect Management (SUP.9) and Change Request Management (SUP.10). The connection here is that defects identified in tests have to be addressed and bug fixes and change requests have to be addressed in regression tests.
The following are the most important aspects of Software Requirements Analysis in Automotive SPICE®:
- Consider more than just your customer’s requirements. An important reason for documenting software requirements is that you need to consider more than your customer's expectations. The software has to meet standards, norms and other regulations that increase the number of requirements. For documentation purposes, map the system requirements or in case of software development only, the customer and other stakeholder requirements to your software requirements that reflect your internal view of the software. The software requirements in turn form the basis for the Software Qualification Test and all downstream processes, such as Software Architecture.
The software requirements describe the software as a black box, the "what" — what should the software does, not "how" should it do something. So, we identify the following: the software requirements describe what are the signals that the pins of the microcontroller reach, what the software should do with these signals and what output signals we expect at the pins of the microcontroller.
The software requirements describe the software as a black box, the "what" — what should the software does, not "how" should it do something. So, we identify the following: the software requirements describe what are the signals that the pins of the microcontroller reach, what the software should do with these signals and what output signals we expect at the pins of the microcontroller.
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 of the requirements to different areas of interest so that each organizational unit knows which requirements are relevant to it. These may be attributes (e.g., to classify requirements according to ISO 26262), a functional structure to support distribution to function groups, etc.
Typically, requirements management is supported by appropriate tools such as a requirements database.
- Analyze and understand the implications of your 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 you are not really sure about the feasibility of a requirement, there is an inherent risk, because it may take time to find a way to address it, or there may be no way to address it at all. Obviously, here is a strong link to the estimates that we have to perform in Project Management — specifically MAN.3.BP5. Another topic to analyze is testability. Of course, the support of the testers can analyze this and review the requirements. Additionally, the analysis should cover the technical implications. This includes the assessment of dependencies between requirements.
I included an example in the video on System Requirements Analysis (SYS.2).
Finally, the analysis should also cover business aspects of the requirements. It should therefore be determined how the implementation of the various requirements affects costs and timeline. Now, you can say that you cannot document all this in the requirements database. Remember that Automotive SPICE® does not say where you 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.
- Demonstrating traceability and consistency are required. This process also requires you to demonstrate traceability between your software requirements, the system requirements and the system architecture.
However, Automotive SPICE® explicitly states that a redundancy is not required. You can decide whether you prefer a traceability to the system requirements, to the system architecture or a combination of the two. It depends which approach supports your development in the best way, not on which approach is easier for you.
Traceability can be established through hyperlinks such as DOORS, through specific traceability tools such as Rectify, through traceability matrices or through other manageable means which are supported your company's tool landscape.
The purpose of traceability is to:
- Support consistency checks — i.e., to verify the completeness and accuracy of the software requirements.
- Support the impact assessment in case of change requests or deficiencies.
- Support the reporting of implementation status.
The other part of this point is consistency.
Consistency means that you prove completeness and correctness of your software requirements against the system requirements respectively your system architecture.
This can only be established by a review.
If you skip this review, you may have incomplete or faulty software requirements. The worst part is that you may not even notice the defects in the software qualification test because this test is performed against your software requirements. If these are faulty your test may not show false behavior. Do not skip this review.
Advanced tutorial about software requirements analysis
What is the benefit of software requirements analysis?
The software requirements for the software related elements and their interfaces of the system architecture are fully analyzed and documented. These provide the basis for the actual software development.
What is the content of the Software Requirements Analysis process?
- Functional and nonfunctional requirements for the software are determined, taking into account the system requirements and the system architecture (BP1).
- All software 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 for each requirement 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 software requirements and system requirements and architecture (BP6, BP7).
- Software requirements and their updates are agreed upon and communicated to all stakeholders (BP8).
Sources for the determination of software requirements
Experiences, problems and hints
- In many cases, customer requirements are so detailed that they can be used as they are or with little modifications as software requirements. However, an analysis has to be performed to determine if there is any system impact. Also, full coverage of and traceability to the customer requirements need to be demonstrated.
- In the case of a software-only product the customer requirements are linked directly to the software requirements, as there is no need for System Requirements in this case.
- Regarding traceability between software requirements and system requirements and between software requirements and system architecture: redundancy is not required. The project can decide whether they implement it one way or the other.
- If the project is based on a platform, the software requirements of the platform can be carried over. However, these platform requirements should be carefully analyzed for relevance and accuracy for the new project requirements.
- Traceability is not enough by itself; consistency has to be demonstrated. Consistency checks (through reviews) have to verify that software requirements are correct interpretations of system requirements, and that traceability and links are correct and complete.
- In some systems, functions may involve two or more disciplines — e.g., hardware and software. It must be clear which portion of the function is covered by the software requirements.
- In software-heavy systems, the requirements on system and software level may be overlapping, but they should never be the same.
Deepen your knowledge of Automotive SPICE®
If you’re serious about learning Automotive SPICE®, participate in one of our Automotive SPICE® trainings.
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 a principal assessor and trainer for Automotive SPICE® and has performed more than 140 assessments and trained more than 250 assessors.
Read our related content
Software Requirements Analysis (SWE.1) resource guide
Services for Automotive SPICE and Extensions
To access the rest of this engaging content, please fill out the form below:
Please wait…