SWE.1 Software Requirements Analysis
Involved in the challenges of Automotive SPICE, particularly software requirements analysis? Read on for a quick overview of key information on SWE.1, a key process from VDA Scope, including a video and our free white paper.
back to Automotive SPICEAutomotive SPICE® is a trademark of VDA QMC.
The Software Requirements Analysis process in Automotive SPICE® (also known as SWE.1) helps your organization to to transform the software related parts of the system requirements into a set of software requirements.
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 non-functional aspects of your software. This can lead to false starts or even additional development cycles.
This process has strong links upstream to SYS.2 System Requirements Analysis, SYS.3 System Architectural Design, and downstream to SWE.2 Software Architecture and SWE.6 Software Qualification Test. 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 must 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®.
Image
The SWE.1 process under VDA Scope
Interested in finding out more about Software Requirements Analysis (SWE.1), the Automotive SPICE® process from VDA Scope? Our free white paper provides you with a summary of all key information, including an extract from our book on Automotive SPICE® Essentials – ideal reading for anyone new to the topic of process improvements.
An important reason for documenting software requirements is that you need to consider more than your customer's expectations. The software must 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, e.g. Software Architecture.
The Software requirements describe the software as a black box, the "what". What should the software do, 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.
This ensures 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.
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
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 sure about the feasibility of a requirement, there is an inherent risk, because it may take time to find a solution, or there may be no solution at all. Obviously here is a strong link to the estimates which we must perform in Project management, specifically MAN.3.BP5. Another topic to analyze is testability. Of course, the support of the testers can be used to ensure this. Often the testers are also asked to 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 SYS.2 System Requirements Analysis.
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.
Over 100 corporate customers on four continents bank on our experience.
Automotive SPICE®? We’re the experts!
We currently have 48 intacs™-certified assessors. These include ten instructors on Provisional and Competent Level.
Automotive SPICE®? We’re the experts!
As a peer reviewer, we have been continually involved in the process of designing standards since 2005. We also co-authored plug-ins for mechanical engineering and hardware engineering with intacs™.
Automotive SPICE®? We’re the experts!
We have written multiple editions of »Automotive SPICE® in Practice«, already an industry classic.
Automotive SPICE®? We’re the experts!
Benefit from over 200 people-years of cumulative project experience, often involving improvement programmes lasting several years.
Automotive SPICE®? We’re the experts!
We have now trained more than 1000 assessors according to intacs™ guidelines.
Automotive SPICE®? We’re the experts!
We have conducted over 200 assessments since 2007, on both a project and an organisational level. That is equivalent to 10,000 assessment-hours.
Automotive SPICE®? We’re the experts!
This process also requires that you ensure 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.
- the impact assessment in case of change requests or deficiencies.
- the reporting of implementation status.
As part of our strategy to systematically improve development processes in the automotive electronics sector, we are also an official licensee of Automotive SPICE® – a trademark of the Association of the German Automotive Industry (VDA QMC).
The other part of this point is to ensure 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. So, do not skip this review!
- Using AUTOMOTIVE SPICE® to achieve the required maturity levels within your key processes in development
- Systematically improving existing workflows and methods
- Evaluating the status of your process improvements through formal assessments and gap analysis
- Fulfilling the requirements of Automotive SPICE® in harmony with SECURITY, FUNCTIONAL SAFETY and AGILE METHODS
- Training your staff and assessors
