Recording change requests, assessing their impact, approving them before implementation, and tracing them to every affected work product — the control loop that keeps the V consistent.
ASPICE SUP.10 Change Request Management ensures that change requests are recorded and identified, their dependencies and impact assessed, approved before implementation (typically by a change control board), tracked to closure with a known status, and bidirectionally traceable to the affected work products.
SUP.10 is the gate that keeps the whole V-model honest as things change. Without controlled, impact-assessed, approved changes traced to affected items, traceability everywhere else silently rots.
Purpose (per the ASPICE PAM): ensure that change requests are managed, tracked and controlled.
The process is achieved when these outcomes hold:
Classification, CCB, workflow.
Uniquely record each request.
Track status through the workflow.
Impact and dependency analysis.
CCB / defined approval.
Confirm the change was implemented as approved.
Manage to closed.
CR ↔ affected work products.
The output work products SUP.10 asks for (named per the standard):
This is where the standard meets reality. Each work product and outcome has a concrete home — an issue type, work-item type, or model element — in the tools you already run. Types are configurable, so treat this as the typical ASPICE setup:
| Work product / outcome | Jira | Polarion | Codebeamer | DOORS Next | Enterprise Architect | Confluence |
|---|---|---|---|---|---|---|
| WP: change management strategy | workflow + CCB scheme (documented) | change-mgmt plan LiveDoc | plan item | — | — | change-mgmt / CCB page |
| WP: change request record | 'Change Request' issue type | Change Request work item | Change Request tracker item | — | — | CR log (only if no tracker) |
| Outcome: impact assessment | 'impacts' links to config items + analysis field | Linked Work Items (impacted) + suspect | impact links | link module | — | impact-analysis page |
| Outcome: approval before implementation (CCB) | workflow approval status / transition | workflow approval state + e-sig | workflow approval | — | — | CCB minutes |
| WP: bidirectional traceability (CR ↔ work products) | issue links CR ↔ req/design/test/commit | Linked Work Items | trace links | link module | «trace» | — |
The trap isn't the tools — it's that the links between them are maintained by hand and decay the moment a requirement changes. (See best ASPICE tools.)
Here is the part almost everyone misses. SUP.10 can never reach a mature capability level (CL2+) on its own — it can only be as mature as the configuration-management data model underneath it. SUP.8 Configuration Management is the secret enabling layer: the shared data model of items, versions, baselines and links that is the basis on which every other process group becomes provable. Scatter that data model across a Jira project, a Polarion space, a DOORS module, an EA model and a Confluence tree, and the model is fragmented by construction — the traceability that SUP.10 depends on decays the moment anything changes, and no amount of process ceremony fixes it.
What actually unlocks maturity is a headless ALM — an API-first, tool-agnostic configuration-management data model that is the single source of truth for every work product and every link, readable and writable by both humans and agents — plus an agent/human workflow definition, coordination and traceability platform on top of it, so every change is planned, assigned (to a human or an agent), executed and traced against that one model. That is the layer that lets SUP.10 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SUP.10 guide is part of The Blueprint — our free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools and grounded in one configuration-management data model. Take it, use it, no cost.
On every pull request, agents raise or link the change request, compute the impact across the V (requirements → architecture → design → test), and maintain the CR ↔ work-product traceability — so change control is continuous, not a gate people route around. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SUP.10's work products and traceability as a byproduct of the build, each with a confidence score and audit trail) running on a partner headless ALM — the API-first configuration-management data model that makes the whole thing provable.
SUP.10 Change Request Management ensures change requests are recorded, impact-assessed, approved before implementation, tracked to closure, and bidirectionally traceable to the affected work products.
A change management plan/strategy, change request records (with impact, approval and status), and CR traceability/status records.
As a 'Change Request' issue/work-item type with an approval workflow (CCB), 'impacts' links to the affected configuration items, and a status tracked to closure — the impact and approval evidenced on the record.
By making every change go through impact assessment against the affected requirements, architecture, design and tests, with suspect-aware links — so traceability is refreshed on change instead of decaying.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SUP.9 Problem Resolution · SUP.8 CM · SYS.1 Elicitation