Transforming stakeholder requirements into analysed, verifiable system requirements — with verification criteria and bidirectional traceability to SYS.1 and the system architecture.
ASPICE SYS.2 System Requirements Analysis transforms the stakeholder requirements (SYS.1) into a set of system requirements: specifying, structuring and analysing them for correctness and verifiability, developing verification criteria, and establishing bidirectional traceability to the stakeholder requirements and consistency with the system architecture.
SYS.2 is the system-level twin of SWE.1. It is where the customer's needs become engineering requirements the whole V will trace to.
Purpose (per the ASPICE PAM): transform the defined stakeholder requirements into a set of system requirements.
The process is achieved when these outcomes hold:
Derive system requirements from the stakeholder requirements.
Categorize, group and prioritize.
Correctness, feasibility, verifiability.
Interfaces and impact on the environment.
Per requirement.
SYS.1 ↔ SYS.2.
Across the traces.
Baseline and communicate.
The output work products SYS.2 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: system requirement | 'System Requirement' issue type (R4J) | System Requirement work item | System Requirements tracker | system-req module Object | Requirement (system) element | req page (only if no ALM) |
| WP: verification criteria | Acceptance Criteria field (Xray/Gherkin) | field / linked Test Case | field / linked test | attribute | constraint / linked test | criteria table |
| WP: traceability (SYS.1 ↔ SYS.2) | issue links 'derives from' + suspect | Linked Work Items + suspect | upstream/downstream refs | link module | «deriveReqt» | — |
| Outcome: trace SYS.2 → system architecture | link req → component (SYS.3) | 'is allocated to' | allocation ref | link module | «satisfy» / «allocate» | allocation matrix |
| WP: review record | review sub-task / linked page | review workflow + e-sig | Review item | review attributes | — | review page |
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.2 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.2 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.2 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SYS.2 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 system requirements with verification criteria from the stakeholder requirements and the design, and generate the SYS.1 ↔ SYS.2 ↔ architecture traceability, each link with a confidence score. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SYS.2'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.2 System Requirements Analysis transforms the stakeholder requirements into analysed, verifiable system requirements with verification criteria and bidirectional traceability to SYS.1 and consistency with the system architecture.
A system requirements specification, verification criteria per requirement, traceability records (SYS.1 ↔ SYS.2), and review records.
SYS.2 produces the system requirements; SWE.1 takes the software-related system requirements and derives the software requirements, tracing back to SYS.2.
System requirements as a dedicated work-item type in Polarion/Codebeamer or a system-requirements module in DOORS Next, with 'derives from' links to the stakeholder requirements and verification criteria per item, kept suspect-aware.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SYS.1 Elicitation · SYS.3 Architecture · SWE.1 SW Requirements