Integrating the software units into the complete software and verifying the integration against the architecture — interfaces and interactions. (ASPICE 4.0 reworks this as Software Component & Integration Verification.)
ASPICE SWE.5 Software Integration and Integration Test integrates the software units into larger items up to the complete integrated software consistent with the software architecture, develops an integration test specification that verifies the interfaces and interactions defined in the architecture (SWE.2), tests the integrated software, records results, and establishes bidirectional traceability between architecture, integration test specification and results.
SWE.5 verifies that the pieces fit — interfaces and interactions from SWE.2. In ASPICE 4.0 this area was reworked (Software Component Verification and Integration Verification); the intent is the same: prove the integration against the architecture.
Purpose (per the ASPICE PAM): integrate the software units into larger software items up to a complete integrated software, and verify the integration against the software architectural design.
The process is achieved when these outcomes hold:
Consistent with the architecture.
Including regression.
Verify interfaces and interactions.
Build up the complete software.
Test per the specification.
Architecture ↔ integration test ↔ results.
Keep consistent; summarize results.
The output work products SWE.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 |
|---|---|---|---|---|---|---|
| Integration test case | Xray/Zephyr Test (integration) | Test Case (integration level) | Test Case | — | test element | test page |
| Integration test run / result | Test Execution + CI pipeline | Test Run | Test Run | — | — | results page |
| Interface / interaction under test | linked to architecture component | linked architecture item | linked item | — | Interface / connector under «verify» | — |
| Traceability (architecture ↔ test ↔ result) | issue links + suspect | Linked Work Items + suspect | trace links | — | «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. SWE.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 SWE.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 SWE.5 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SWE.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 integration test specification from the architecture's interfaces and interactions, link the CI results back to the architecture, and keep the traceability current as the architecture evolves. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SWE.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.
SWE.5 Software Integration and Integration Test integrates the software units into the complete software and verifies the integration against the software architecture — its interfaces and interactions — with an integration test specification, recorded results, and bidirectional traceability to the architecture.
Yes. ASPICE 4.0 reworked the integration area (as Software Component Verification and Integration Verification), but the intent is unchanged: verify the integrated software against the architecture's interfaces and interactions with traceable evidence.
A software integration test specification, integration test results, and traceability records linking the architecture ↔ integration test ↔ results.
By deriving the tests from the architecture's interfaces/interactions and linking each test (and its result) back to the architectural element it verifies — «verify» in EA, linked work items in Polarion/Codebeamer, or issue links in Jira.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SWE.2 Architecture · SWE.6 Qualification · SWE.4 Unit Verification