The detailed design of the software units and the units themselves (the code) — with traceability from architecture to design to code. The richest place for automation.
ASPICE SWE.3 provides an evaluated detailed design for the software components, specifies the interfaces and dynamic behaviour of the software units, produces the software units (source code), and establishes bidirectional traceability and consistency between the software architecture (SWE.2), the detailed design, and the software units.
SWE.3 is the bottom of the V — design and code. It is also where the legacy process hurts most, because teams write the code first and reverse-document the design and traceability afterwards, if at all.
Purpose (per the ASPICE PAM): provide an evaluated detailed design for the software components and to specify and produce the software units.
The process is achieved when these outcomes hold:
Design each software unit from the architecture.
Specify the unit interfaces.
Define the runtime behaviour of the units.
Evaluate against criteria (interoperability, maintainability…).
Trace SWE.2 ↔ design and design ↔ units.
Keep design, architecture and code consistent.
Produce the source code for the units.
The output work products SWE.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 |
|---|---|---|---|---|---|---|
| Detailed design (unit) | linked design issue → repo | design work item + linked model | design tracker item + SCM link | — | Class / sequence / state diagrams (native) | design page |
| Software unit (source code) | commit / PR referenced by issue key | linked SVN/Git revision | linked SCM commit | — | generated / round-tripped code | — |
| Design → code traceability | smart commit / branch → issue | Work Item ↔ revision link | item ↔ commit link | — | model ↔ source association | — |
| Architecture → design traceability | issue links + suspect | Linked Work Items + suspect | trace links | link module | «trace» / «refine» | — |
| Design review | PR review + linked record | review workflow | review item | — | — | 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. SWE.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 SWE.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 SWE.3 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SWE.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.
This is where agents earn their keep: they read the code and its intent (commits, PRs, comments), reconstruct the detailed design and the architecture ↔ design ↔ code traceability, and flag what they can't confirm — instead of a human hand-drawing UML after the fact. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SWE.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.
SWE.3 Software Detailed Design and Unit Construction produces an evaluated detailed design of the software units and the units themselves (source code), with bidirectional traceability from the software architecture to the design and from the design to the code.
The software detailed design, the software units (source code), unit interface specifications, traceability records (architecture ↔ design ↔ units), and review records.
By linking design items to the actual commits/PRs — smart commits and branch naming to issue keys in Jira, Work-Item-to-revision links in Polarion/Codebeamer, or model-to-source associations in Enterprise Architect.
Yes — agents read the code and its intent, reconstruct the detailed design and the architecture ↔ design ↔ code traceability with confidence scores, and flag low-confidence areas for a human, rather than reverse-documenting UML by hand before an audit.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SWE.2 Architecture · SWE.4 Unit Verification · Automate it