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
- VDA QMC
- AUTOMOTIVE SPICE ® v3.1 POCKET GUIDE from KUGLER MAAG CIE
- V-model Wikipedia
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.