Confirming the integrated system meets the system requirements — the top-right of the system V, traced back to SYS.2.
ASPICE SYS.5 System Qualification Test confirms that the integrated system meets the system requirements (SYS.2): it develops a qualification test strategy and a test specification consistent with the system requirements, tests the integrated system, records the results, and establishes bidirectional traceability and consistency between the system requirements and the qualification test specification and results.
SYS.5 closes the top of the V opened at SYS.1/SYS.2: does the finished system meet the system requirements? Again the gap is traceability — qualification tests not linked to the requirements they prove.
Purpose (per the ASPICE PAM): ensure that the integrated system is tested to provide evidence for compliance with the system requirements.
The process is achieved when these outcomes hold:
Including regression.
Consistent with system requirements.
Execute against the specification.
System requirements ↔ qualification test ↔ results.
Keep requirements, spec and results consistent.
Report to affected parties.
The output work products SYS.5 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: qualification test case | Xray/Zephyr Test (system qualification) | Test Case (qualification) | Test Case | — | test element | test page |
| WP: qualification test result | Test Execution + CI/HIL | Test Run | Test Run | — | — | results page |
| Outcome: system requirement under test | linked SYS.2 requirement | linked System Requirement | linked requirement | requirement object | Requirement «verify» | — |
| WP: traceability (SYS.2 ↔ test ↔ result) | 'verifies' links + suspect | Linked Work Items + suspect | trace links | link module | «verify» matrix | — |
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. SYS.5 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 SYS.5 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 SYS.5 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SYS.5 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.
Agents derive the system qualification test specification from the system requirements, tie every test and result back to the requirement it qualifies, and surface coverage gaps — a traceable, current answer to 'does the system meet its requirements?'. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SYS.5'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.
SYS.5 System Qualification Test confirms the integrated system meets the system requirements, with a qualification test strategy and specification consistent with the requirements, recorded results, and bidirectional traceability between requirements, specification and results.
A system qualification test specification, system qualification test results, and traceability records linking system requirements ↔ qualification test ↔ results.
SYS.5 qualifies the whole integrated system against the system requirements (SYS.2); SWE.6 qualifies the integrated software against the software requirements (SWE.1). Both are the top-right of their respective Vs.
Derive the qualification tests from the system requirements and link each test and result back to the requirement it qualifies — 'verifies' links in Jira/Polarion/Codebeamer, a DOORS link module, or «verify» in Enterprise Architect.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SYS.2 System Requirements · SYS.4 Integration · SWE.6 SW Qualification