Verifying the software units against the detailed design — a strategy, criteria, static verification and unit test — with traceability from design to test to result.
ASPICE SWE.4 Software Unit Verification develops a unit verification strategy (including regression) and criteria, verifies the software units against the detailed design and non-functional requirements through static verification and unit testing, records the results, and establishes bidirectional traceability and consistency between the detailed design, the verification criteria and the results.
SWE.4 is the first step back up the right arm of the V. The common gap: unit tests exist, but there's no static-analysis evidence and no trace from a test back to the design it verifies.
Purpose (per the ASPICE PAM): verify software units against the software detailed design and the non-functional requirements.
The process is achieved when these outcomes hold:
Including regression strategy and re-verification.
Static verification and unit-test criteria.
Static analysis / reviews of the units.
Execute unit tests against the criteria and design.
Design ↔ criteria ↔ results.
Keep the three consistent.
Report results to affected parties.
The output work products SWE.4 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 |
|---|---|---|---|---|---|---|
| Unit test case | Xray / Zephyr Test issue | Test Case work item | Test Case tracker item | — | test element | test page |
| Test execution / result | Xray Test Execution + run | Test Run / result | Test Run | — | — | results page |
| Static analysis result | CI check linked to issue | linked CI report | linked CI report | — | — | analysis page |
| Traceability (design ↔ test ↔ result) | issue links (Test ↔ design) + suspect | Linked Work Items + suspect | trace links | — | «verify» | — |
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.4 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.4 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.4 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SWE.4 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 generate unit-verification criteria from the detailed design, wire the test and static-analysis results back to the design and units with traceability, and keep it current on every change in CI. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SWE.4'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.4 Software Unit Verification verifies the software units against the detailed design and non-functional requirements using static verification and unit testing, with a strategy, criteria, recorded results, and bidirectional traceability between design, criteria and results.
A unit verification specification with criteria, unit-test results, static-analysis results, and traceability records linking detailed design ↔ criteria ↔ results.
Unit tests as Xray/Zephyr Test issues (Jira) or Test Cases with Test Runs (Polarion/Codebeamer), static analysis as linked CI reports, and 'verifies' links back to the detailed design kept suspect-aware.
Yes — agents can derive verification criteria from the design and attach test and static-analysis results to the units with traceability, refreshed on every CI run so the evidence stays current.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SWE.3 Detailed Design · SWE.5 Integration · SUP.8 CM