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.
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.
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.