Software Requirements Analysis (SWE.1)

Process ID: SWE.1
Process group: Software Engineering
Automotive SPICE® is a trademark of VDA QMC.

The Software Requirements Analysis process in Automotive SPICE® (also known as SWE.1) helps your organization transform the software related aspects of the system requirements into a set of software requirements.

There are already system or customer requirements covering a project, but documenting software requirements is also essential. Projects must be delivered on time, within budget, and in the quality required by the customer.

Failure to document software requirements may lead to overlooked functionality or misinterpretation of customer expectations. Overlooking both essential software functionality and nonfunctional requirements (such as performance, reusability and maintenance) can lead to increased effort, added costs and delays along with false starts or even additional development cycles.

The SWE.1 process has links upstream to System Requirements Analysis (SYS.2) and 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), due to release management. Defect Management (SUP.9) and Change Request Management (SUP.10) also have dependencies because defects identified in tests must be addressed and bug fixes and change requests must be addressed, for example, in regression tests.

The following are the most important aspects of Software Requirements Analysis in Automotive SPICE®.

Meeting customer expectations and important regulations

One important reason for documenting software requirements is to establish that all functional and nonfunctional aspects of the system realized by software can be managed, implemented and tested.

The software requirements describe what the software should do, not how it should do something. The software requirements, for example, describe what the signals that the pins of the microcontroller reach should mean, what the software should do with these signals, and what output signals we set 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 establishes that each unit responsible (for example, for a special software function) knows which requirements are relevant to it. These may be attributes, for example, to classify functional safety 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.

Analyze and understand the implications of all requirements

Another aspect of this process, as the name suggests, is the analysis of requirements. The requirements should be analyzed for feasibility or risk, and these two are closely linked. There is an inherent risk to not understanding the feasibility of a requirement as time may be required to find an implementation if one is available. There is also a strong link to the estimates that must be performed in Project Management, MAN.3.BP5.

Testability is also important, and the support of the testers can be used to confirm testability. Testers shall also be asked to review the requirements. Additionally, the analysis should cover the technical implications, including assessment of dependencies between requirements. An example is available in the video dedicated to SYS.2, System Requirements Analysis.

Finally, the analysis should cover business aspects of the requirements. It should therefore be determined how the implementation of the various requirements affects costs and timeline. It is important to remember that Automotive SPICE® does not say where this information should be documented. For example, the first part of the analysis (feasibility and risks) could be documented in the requirements database, the technical implications could be covered in corresponding and linked change requests and the impact on costs and schedule can be recorded in project management tools.

Establish traceability and consistency between requirements

This process also requires maintaining traceability between software requirements, system requirements and the system architecture as well as downwards the V-model to software architecture and detailed design, and to all relevant testing processes.

However, Automotive SPICE® explicitly states that a redundancy is not required. This allows the organization to determine whether to establish traceability to the system requirements, to the system architecture or a combination of the two. The proper approach must support development in the best way, even if that approach is not the easiest option.

Traceability can be established through hyperlinks traceability matrices or other manageable means which are supported by an organization’s tool landscape.

The purpose of traceability is to support:

• Consistency checks, including verifying the completeness and accuracy of the software requirements.
• Impact assessments in case of change requests or deficiencies.
• Reporting of implementation and testing status.

Lastly, it is essential to help establish consistency. Consistency means proving the completeness and correctness of software requirements against the system requirements and system architecture. This can only be established by a review.

Skipping this review may leave incomplete or faulty software requirements undiscovered. Defects in the software qualification test may also go unnoticed as this test is performed against software requirements. If these are faulty, the test may not show false behavior.

Why choose UL Solutions Software Intensive Systems for Automotive SPICE® support? 

UL Solutions Software Intensive Systems can support automotive original equipment manufacturers (OEMs) and suppliers in:

• Achieving the required capability levels within key development processes.
• Systematically improving existing workflows and methods.
• Evaluating the status of process improvements through formal assessments and gap analysis.
• Fulfilling the requirements of Automotive SPICE® in harmony with security, functional safety and agile methods.
• Training staff and assessors.

Read our related content

Software Requirements Analysis (SWE.1) in Automotive SPICE® white paper

Services for Automotive SPICE and Extensions