Make Automotive SPICE demonstrable - from SYS.2 to the assessment
WORKSPACE.PM gives your ASPICE projects a backbone: process groups as a container structure, the V of phases, milestones and quality gates, versioned and released work products, plus an audit trail that evidences every decision - in the same system your teams already work in.
Where Automotive SPICE sits on the spectrum
And which methods are its neighbours
Automotive SPICE: process-driven, evidence-oriented
Automotive SPICE sits firmly on the process-driven side - defined process groups, the V of specification and verification, evidenced releases. In WORKSPACE.PM that stays combinable: through the container concept every sub-project runs its own way of working, so the ASPICE governance holds while individual software streams work agile in sprints and on boards.
Process defined - evidence scattered
What ASPICE adoption actually hinges on in many development teams
The process lives in the slide deck
Your process landscape is described and assessed - but the project tool knows neither process groups nor work products. So what the model demands is maintained on the side, in spreadsheets, folders and emails.
Traceability patched together in tables
Which work package hangs off which document, which risk, which change? The answer lives in scattered lists - and no back-reference survives the next rename.
Approvals without a solid trail
Who released which version, and when? Right up to the customer audit the team hunts for evidence in mailboxes and file shares instead of in the project.
Gates and baselines only on paper
Phase transitions, release criteria and frozen plan states are meant to be documented - yet without a shared system every piece of evidence stays a manual chore.
Seven ASPICE core elements - and the tool that carries each one
From the process reference model to assessment preparation: each element with its concrete implementation. No re-labelling, no side track.
Process reference model (VDA scope: SYS · SWE · MAN · SUP)
Automotive SPICE describes development as defined process groups - system and software engineering, management and supporting processes.
Process groups as a container structure - built once as a reusable block
Every process step becomes a structure node in three types - container, milestone and quality gate. Per container you switch on exactly what the step needs from 13 functional areas. A SYS/SWE/MAN/SUP skeleton built once is saved as a reusable block and inserted into every project.
The V - specification and verification
In the V, every specification level on the left has a verification or validation level facing it on the right - from system requirements to system test.
Phases, milestones and gates - wired via typed dependencies
You model the left and right side of the V from phases, milestones and quality gates and connect corresponding levels via dependencies in four types with an offset. The network computation delivers earliest and latest positions, critical path and float; a cycle check warns of circular dependencies.
Requirements and verification as first-class objects
ASPICE carries requirements across all levels - stakeholder, system and software - with verifiable acceptance criteria and their verification.
Requirement and verification objects with levels, criteria and results
Every requirement is a versioned object of its own, with level, attributes and acceptance criteria - from which the verification case derives directly. Verification runs record result, tester and evidence; a failed run creates the linked defect.
Bidirectional traceability, coverage and consistency
ASPICE requires requirements, design and verification to be linked both ways, fully covered and kept consistent.
Trace matrix with coverage analysis and suspect links
Requirements, verification cases and results are connected through typed, two-way links; the trace matrix shows coverage per level and flags requirements without verification. When a requirement changes, dependent verifications are marked “to re-check” automatically until confirmed again.
Work products - versioned and released
Through its base practices, every process produces defined work products with a traceable maturity and release state.
Automatic versioning, three-stage release, documents from templates
Documentation is versioned automatically on every content change and can be restored version by version. Status reports run the release draft → submitted → released and freeze their values afterwards. From your own templates in seven categories, a project charter, status report or closure report is generated straight from the project data.
Configuration, change and problem management (SUP.8 · SUP.9 · SUP.10)
The supporting processes keep changes controlled, findings traceable and plan states fixed as a baseline.
From finding to change request to a new baseline
Findings are typed as incident work packages, from which a change request with an approver and impact dimensions arises - linked in substance to the affected risk. Released plan states are frozen as a baseline and browsed read-only across the entire planning history.
Capability levels and assessment preparation
Automotive SPICE rates processes on maturity levels 0 to 5 - preparation needs complete, demonstrable evidence.
Maturity as your own fields, evidence from the audit trail
You model process attributes and maturity as your own, even calculated fields with role-based visibility. The evidence comes from a system-wide audit trail of date, user and action, plus the voting history of every quality gate and three-stage locked releases. A full-text search reaches 32 entity types.
ASPICE assessment: process and preparation
How an Automotive SPICE assessment typically runs - and where the evidence for it is created
- 1
Define the scope
The sponsor and the lead assessor decide which processes are rated up to which capability level - often the processes of the VDA scope up to level 2 or 3.
Evidence in WORKSPACE.PMThe process groups sit in the project as a container structure and make the scope visible.
- 2
Review the evidence
The assessors examine work products such as requirements, architecture, verification evidence, plans and status reports. What counts is what the project actually produced.
Evidence in WORKSPACE.PMVersioned documentation, approved status reports, requirements and verification runs in one place.
- 3
Conduct interviews
Project management and engineering explain how they work. Their statements are checked against the evidence.
Evidence in WORKSPACE.PMGate votes with verdict and comment show who decided what and when.
- 4
Rate the process attributes
Each process attribute is rated N, P, L or F (not, partially, largely, fully achieved). This yields the capability level reached per process.
Evidence in WORKSPACE.PMCapability levels per process as custom fields, rolled up in KPIs and dashboards.
- 5
Report and improve
The assessment report lists strengths and weaknesses per process. The weaknesses become the improvement plan up to the next assessment.
Evidence in WORKSPACE.PMTrack actions as work packages with owners and due dates.
An assessment rates your organisation’s processes and is carried out by qualified assessors, usually intacs certified. WORKSPACE.PM does not replace that - it makes sure the required evidence is created in the project and can be found.
MAN.3, SWE.5 and MLE: what the processes require
Three frequently searched processes - briefly explained, with how the tool supports them
MAN.3Project Management
The process requires
MAN.3 requires a project to define, monitor and adjust its scope, life cycle, feasibility, activities, estimates and resources, interfaces and schedule - and to report progress regularly.
How WORKSPACE.PM supports it
Project structure with phases, milestones and quality gates, network schedule with critical path and float, baselines for approved plans, resource planning and status reports with three-stage approval.
SWE.5Integration and integration verification
The process requires
SWE.5 covers how software components are integrated and how the integration is verified: strategy, verification specification, execution and recorded results. Automotive SPICE 3.1 calls the process “Software Integration and Integration Test”, 4.0 calls it “Software Component Verification and Integration Verification”.
How WORKSPACE.PM supports it
Verification items carry a verification level such as integration, are linked to the requirements and record every run with its result. A failed run is kept as evidence.
MLEMachine Learning Engineering (ASPICE 4.0)
The process requires
Automotive SPICE 4.0 added processes for AI components: MLE.1 to MLE.4 for requirements, architecture, training and testing of ML models, plus SUP.11 for managing the training data.
How WORKSPACE.PM supports it
You set up the ML processes as containers like any other process group. The AI assistant helps with the project work itself: drafting the project structure and milestones from a document and proposing risk lists - write actions only after your confirmation.
Tailoring lives in the container - the right depth per sub-project
ASPICE projects are rarely monolithic: the system side strictly by gates, software streams iterative. That is exactly what container blocks deliver - each sub-project activates only the functions it needs: quality gates and reporting at the overall level, board and sprints in the development stream. One structure, several worlds of work, one trail of evidence.
Where Automotive SPICE counts
Project worlds and teams that benefit most from process-safe execution
Frequently asked questions about Automotive SPICE in WORKSPACE.PM
Which concrete tools carry ASPICE adoption day to day
Through the container structure: every process step is created as a container, milestone or quality gate, and per container you switch on exactly what the step needs from 13 functional areas. A complete SYS/SWE/MAN/SUP skeleton is saved as a reusable block and inserted into every new project - including a phase pipeline with quality gates.
Requirements, verification cases and results are versioned objects of their own, connected through typed, two-way links. The trace matrix shows coverage per level and lists requirements without verification. When a requirement changes, the system automatically marks dependent verifications as “to re-check” until confirmed again - views and status reports consolidate the state.
Documentation is versioned automatically on every content change and can be restored version by version. A verification state records who checked it and when, and expires automatically after a configurable interval. Status reports run the three-stage release draft → submitted → released and freeze their values afterwards.
Change requests carry a category, impact dimensions and an approver and link in substance to the affected risk - including the originating problem and risk assessment. Recurring check and release steps are triggered automatically as a workflow.
A system-wide audit trail logs date, user and action across 32 entity types, every quality-gate vote is preserved with a verdict and comment, and releases are locked in three stages. KPIs and portfolio reporting consolidate maturity per process in dashboards.
Yes: you model the V structure from phases, milestones and quality gates and connect corresponding levels via dependencies in four types. The network computation delivers critical path and float; for purely sequential system development, the V-Model is additionally available as its own method.
The customer decides. In the automotive industry, capability level 2 is often required for the processes of the VDA scope, sometimes level 3. Level 2 means the process is planned, monitored and adjusted, and its work products are managed. In WORKSPACE.PM you keep the capability level per process as custom fields and roll it up in KPIs and dashboards.
Version 4.0 from the VDA adds, among other things, the process groups Hardware Engineering (HWE) and Machine Learning Engineering (MLE), validation (VAL.1) and ML data management (SUP.11), and reframes the test processes as verification processes. Moving from 3.1 means remapping processes such as SWE.5 and SWE.6 - in WORKSPACE.PM you adjust the container structure of your building block accordingly.
No. An assessment rates your organisation’s processes, not a tool, and is carried out by qualified assessors. WORKSPACE.PM makes sure the required evidence is created in the project, versioned and traceable through the audit trail.
Requirements management in WORKSPACE.PM
The part of this method that needs the most tooling - as an area of its own.
Related methods
When your development runs several standards
Bring your ASPICE processes into the system - auditable from the first phase
Start for free and set up process groups, gates and evidence in minutes.