Automotive SPICE 3.1 in the summary


What is ASPICE?

Automotive SPICE® (ASPICE) is an initiative of the Automotive Special Interest Group and the Quality Management Center in the German Association of Automotive Industry (VDA QMC) Today automotive SPICE® is a standard used as a framework for improving and evaluating processes popular in the automotive domain. It applies to the engineering processes (inc. software development, hardware, and mechanical engineering). Historically it’s an adaption of ISO 15504 to specific characteristics of the automotive domain.

In the framework, all processes have been organized according to the “V model” principle in such a way that each process on the left side is corresponding to exactly one process on the right side. Thereby, this approach includes few levels of quality control which allows reducing costs of returning not enough quality products. Because automotive SPICE process results take the key position, processes are dramatically essential in itself and include different steps, and refers to sequential development model. It means we can’t speak here about flexible methodology and should speak more about V model in general.

What is the V-Model?

The V-model summarizes the main steps to be taken in conjunction with the corresponding deliverables within project life cycle development. It describes the activities to be performed and the results that have to be produced during product development.

With some reservations, the left side of the “V” represents the decomposition of requirements and creation of system specifications. The right side of the “V” represents the integration of parts and their validation.

However, because V refers to sequential design approach, requirements need to be validated first against the higher level requirements or user needs. So will be better to say, that verification is always against the technical terms and validation always against the real world or the user needs.

What does ASPICE define?

By ASPICE we can define the sequence of processes, their outcomes, artifacts, and gives base practices.

Processes are grouped by process category and at a second level into process groups according to the type of activity they address.

Life Cycles

There are three substantial process categories in the initiative: Primary Life Cycle Processes, Organizational Life Cycle Processes and Supporting Life Cycle Processes.

The primary life cycle processes category consists of:

  • the Acquisition process group;
  • the Supply process group;
  • the System Engineering process group;
  • the Software Engineering process group.

Organizational Life Cycle Processes Category

The organizational life cycle processes category consists of processes that development process, product, and resource assets which, when used by projects in the organization, will help the organization achieve its business goals.

The organizational life cycle processes category consists of the following groups:

  • the Management process group;
  • the Process Improvement process group;
  • the Reuse process group

Supporting Life Cycle Processes Category

The supporting life cycle processes category consists of processes that may be employed by any of the other processes at various points in the life cycle.

Let’s speak shortly about all of the groups.

Process Groups

Acquisition Process Group (ACQ)

# Process name Process description
ACQ.3 Contract Agreement negotiation and approving a contract/agreement with the supplier
ACQ.4 Supplier Monitoring Tracking and assessing the performance of the supplier against agreed requirements
ACQ.11 Technical Requirements This involves the elicitation of
functional and non-functional requirement
ACQ.12 Legal and Administrative Requirements
ACQ.13 Project Requirements Specifying the requirements to ensure the acquisition project is performed with adequate
ACQ.14 Request for Proposals Preparing a contract, project, finance, and technical requirements to be provided for use in the Call For Proposals (CFP) /Invitation To Tender (ITT).
ACQ.15 Supplier Qualification To determine if the potential supplier(s) have the required qualification

It was hard to remember Acquisition Process Group, so I defined for myself three subgroups:
1) Contract and supplier choosing relevant: ACQ.3, ACQ.15
2) Business requirements: ACQ.11, ACQ.12, ACQ.13, ACQ.14
3) Track of supplier’s performance: ACQ.4

Supply Process Group (SPL)

# Process name Process description
SPL.1 Supplier Tendering
SPL.2 Product Release

System Engineering Process Group (SYS)

# Process name Process description
SYS.1 Requirements Elicitation Gathering, processing and tracking evolving stakeholder needs and requirements as to establish a requirements baseline for the work products
SYS.2 System Requirements Analysis Transformation of the defined stakeholder requirements into a set of system
SYS.3 System Architectural Design Identifying which system requirements are to be allocated to which elements of the system, and to evaluate the system-architectural design against defined criteria
SYS.4 System Integration and Integration Test Integration of the system items to produce an integrated system consistent with the system-architectural design and to ensure that the system items are tested to provide evidence for compliance of the built-in system items with the system-architectural design, including the interfaces between system items
SYS.5 System Qualification Test Evidence providing for compliance with the system requirements and that the system is ready for delivery

Software Engineering Process Group (SWE)

# Process name Process description
SWE.1 Software Requirements Analysis Transforming parts of the system requirements into a set of software requirements
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction Providing a detailed evaluated design for the software units and to produce the software units
SWE.4 Software Unit Verification Providing evidence for compliance of the software units with the detailed software design and with the non-functional software requirements
SWE.5 Software Integration and Integration Test Providing evidence for compliance with the integrated software items with the software-architectural design, including the interfaces between the software units and items
SWE.6 Software Qualification Test Providing evidence for compliance with the software requirements

Supporting Process Group (SUP)

# Process name Process description
SUP.1 Quality Assurance Checking work products and processes with predefined provisions and plans
SUP.2 Verification Getting confirmations that each work product of a process or project accurately reflects the specified requirements
SUP.4 Joint Review Maintain a common understanding with the stakeholders of the progress
SUP.7 Documentation
SUP.8 Configuration Management Establish and maintain the integrity of all work products of a process or project
SUP.9 Problem Resolution Management
SUP.10 Change Request Management Ensure that change requests are managed, tracked and implemented

Management Process Group (MAN)

# Process name Process description
MAN.3 Project Management To identify, establish, and control the activities and resources necessary for a project to produce a product, in the context of the project’s requirements and constraints
MAN.5 Risk Management
MAN.6 Measurement Collect and analyze data relating to the products developed

Process Improvement Process Group (PIM)

# Process name Process description
PIM.3 Process Improvement Continuously improving the organization’s effectiveness and efficiency through the processes used and aligned with the business need

Reuse Process Group (REU)

# Process name Process description
REU.2 Reuse Program Management Planning, establishing, managing, controlling, and monitoring an organization’s reuse program and to systematically exploit reuse opportunities.

Terms “Element”, “Component”, “Unit”, and “Item”

Verification criteria

Verification criteria are used as input for the development of the test cases or other verification measures that ensure compliance with the requirements. Evaluation of alternative (design) solutions is required for system and software architectures. Agreement with an architectural design implies that the specified integration tests are capable of proving that interfaces and relevant interactions fulfill the architectural design.

Where can I get detailed information?

if you want to receive more information you can read the original document from VDA QMC or the pocket guide from KUGLER MAAG CIE GmbH
The pocket guide looks more presentable than the original pdf. But KUGLER uses bus-wording like, the slogan in the pocket guide “We integrate these standards into an agile development process.” But the motto is nonsense if we speak about Automotive Spice. I foresee that direct implementation of this idea can lead any company to losses, deterioration of quality improvement and the overworking. If you are ok with bus-wording ad some kind of interpretation, you probably can use it.

Used materials

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.


  1. In “SYS.1 BP.3 Agree on requirements”, if these are requirements SW will be working, reviewing and approving on SWE.1 and reviewing and approving on SYS.2, do they also need to review and approve them in SYS.1?
    This question comes up because our team members consider that since SYS.1 is something for the systems area, they should not be required to approve the software related requirements at Stakeholders level.
    What is the correct way to do this? SW approves in all three levels (SYS.1, SYS.2 and SWE.1)?
    If you could please clarify this it would be of great help.


Please enter your comment!
Please enter your name here