Automotive SPICE® Software Verification (SWE.6)

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

The Software Verification process in Automotive SPICE® (also known as SWE.6) helps your organization demonstrate integrated software meets the software requirements.

The expectation is that software requirements are already in place, so the goal is to check against these requirements and determine if they are fully met and correctly implemented. This process is carried out shortly before delivery of the software, either directly to the customer or as a basis for the system. There are also close process relationships: Project Management (MAN.3), Configuration Management (SUP.8), Product Release (SPL.2) and Software Requirements Analysis (SWE.1).

If the software verification does not work well, errors can go undetected and customer satisfaction may drop. The verification environment depends on the product. Examples are software-in-the-loop (SIL), processor-in-the-loop (PIL) and hardware-in-the-loop (HIL).

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

Develop a clear specification for software verification measures 

The software verification process requires that the verification measures are specified. A separate specification may exist for each verification level, but it is better to develop and coordinate this specification across all verification levels. This helps establish that all requirements are covered and redundancies are avoided.

The specification for the verification measures should cover the following topics:

• The verification object in question.
• The methods for developing verification measures and verification data (such as development of positive/negative tests, equivalence partitioning).
• Entry and exit criteria and verification interruption criteria.
• The verification environment and infrastructure.
• The necessary sequence of the verification measures.

This process has a strong connection to SUP.9, Problem Resolution Management, allowing synergies in the handling of defects or failed verifications.

When specifying the verification measures, the format is not mandated. Automotive SPICE does not define how and where specifications are documented, meaning they can be distributed over several documents, located in a shared folder or defined in chats, but they must be accessible and known to the team.

These definitions also build a good basis for a complete process strategy, as required in capability level 2 of Automotive SPICE® v4.0 and should be harmonized with it.

Select the right verification measures.

The process expects a selection of verification measures to be performed for the various verifications, depending on the goal of the verification and the required coverage. The aim and expectation are that, for the different deliveries, the software is properly verified against the software requirements on the basis of the aforementioned verification measure specification.

Part of the verification measure selection is also to define coverage targets based on the type of delivery, which strongly links to the project and demand plan.

The idea is that it is possible to have deliveries with different expectations. An example is having complete coverage of all implemented software requirements for the important deliveries.

For minor deliveries, only the delta of implemented requirements since the last delivery is verified.

For this approach, of course, the right verification measures must be selected. 

Another possible situation for verification measure selection would be the regression verification, which covers change requests and/or bug fixes. Here, verification measures are selected that cover the change request or bug and the effects they can have. The latter means that dependencies on requirements that can be affected by the change request or bug fix are also verified.

Establish traceability and consistency.

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

The purpose of traceability is that it:

• Supports consistency checks (such as checking the completeness and accuracy of the coverage of software requirements):
• Supports the impact assessment in case of change requests or bugs:
• Enables the reporting of stakeholder expectations and identifies which requirements have been tested, often referred to as coverage reports:

The second part of this aspect is the consistency, in this case between software requirements and software verification measures. Checks for consistency typically confirm if the coverage is complete and correct. This can only be performed by a review. Failure to prove the software is fully and correctly covered may lead to an insufficiently verified software.

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.

Learn more about the Automotive SPICE® Software Verification process

Interested in deepening your understanding of the Automotive SPICE® Software Verification process (SWE.8) from the Automotive SPICE® v4.0 base scope? Watch our video.