Establishing the system architecture, allocating system requirements to elements, and defining interfaces — with traceability back to SYS.2 and down to software (SWE.1).
ASPICE SYS.3 System Architectural Design establishes a system architecture that identifies the system elements, allocates the system requirements to those elements, defines their interfaces and dynamic behaviour, and establishes bidirectional traceability and consistency between the system requirements (SYS.2) and the system architecture.
SYS.3 splits the system into elements (hardware, software, mechanics) and hands the software-relevant parts down to SWE.1/SWE.2. The failure mode is the same as SWE.2: an architecture in slides, requirements not allocated.
Purpose (per the ASPICE PAM): establish a system architectural design and identify which system requirements are to be allocated to which elements of the system, and evaluate the architecture against defined criteria.
The process is achieved when these outcomes hold:
Define the system elements/structure.
Allocate each requirement to elements.
Specify element interfaces.
Timing, interactions, resource use.
Against defined criteria.
SYS.2 ↔ SYS.3.
Architecture consistent with requirements.
Baseline and communicate.
The output work products SYS.3 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 element / component | Component / Epic (weak — not a model) | Architecture work item linked to model | Architecture tracker item | architecture module object | Block / Component + diagrams (native) | architecture page + diagram |
| WP: interface specification | linked interface issue | Interface work item | Interface tracker item | interface object | Interface / Port / connector | interface table |
| Outcome: requirement → element allocation | issue link req → component | 'is allocated to' | allocation ref | link module | «allocate» / «satisfy» | allocation matrix |
| WP: traceability (SYS.2 ↔ SYS.3) | issue links + suspect | Linked Work Items + suspect | trace links | link modules | «trace» matrix | — |
| Outcome: dynamic behaviour | — | linked model/diagram | linked diagram | — | sequence / activity / state diagrams | diagram 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.3 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.3 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.3 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SYS.3 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 keep the system architecture, its allocations and interfaces traced to the system requirements above and the software elements below — turning a stale architecture back into consistent evidence. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SYS.3'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.3 System Architectural Design establishes the system architecture, allocates system requirements to elements, defines interfaces and dynamic behaviour, and maintains bidirectional traceability and consistency with the system requirements (SYS.2).
The system architectural design, interface specifications, traceability records (SYS.2 ↔ SYS.3), and review records.
SYS.3 allocates the software-relevant system requirements and interfaces to the software element(s); SWE.1 then derives the software requirements and SWE.2 the software architecture, tracing back to SYS.3.
Typically in Enterprise Architect (or another modelling tool) as blocks/components with diagrams, linked to the system requirements in Polarion, Codebeamer, DOORS or Jira via allocation and trace links.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SYS.2 System Requirements · SYS.4 Integration · SWE.2 SW Architecture