Requirements Traceability End-to-End in Sparx EA: From Business Goal to Test Case

TL;DR: End-to-end requirements traceability means you can demonstrate — to an auditor, a certification authority, or a project board — that every requirement is accounted for in the design and verified by test. In Sparx EA, that chain runs from Requirements packages through design elements to Test Cases, held together by Derive, Realize, Satisfy, and Verify connectors. The thing that makes it auditable is connector discipline: the right connector type at every link, applied consistently, so the traceability matrix is queryable rather than just present.

Manual traceability — kept in Word documents and disconnected spreadsheets — is expensive to maintain and fragile under change. The risk of a missed link is a certification failure.

Why it matters

For sectors where regulatory compliance, safety certification, or government contract compliance applies — defense (MIL-STD-882, DO-178C, DEF STAN), medical devices (IEC 62304, ISO 13485, FDA 21 CFR Part 11), rail (EN 50128, EN 50657), aerospace (DO-178C, ARP 4754A) — end-to-end traceability is not optional. It is a certification prerequisite.

The practical question these sectors face is not "should we do traceability?" but "can we demonstrate it efficiently?" When a requirement changes, identifying every affected design and test artifact across multiple disconnected documents is a manual trace, and the risk of a missed link — an untested requirement, an unimplemented design element — is real. Sparx EA addresses this by holding the entire chain in one governed repository, with relationship types that carry formal meaning and can be queried automatically.

The traceability chain

The complete chain from business goal to test result looks like this:

Business Goal → Stakeholder Requirement. A stakeholder need (captured as a Stakeholder Requirement in UML requirements notation, or a business objective in ArchiMate) drives the requirement. The «derive» connector links the requirement back to its originating goal — the "why does this exist?" link that matters for change impact analysis.

Stakeholder Requirement → System Requirement. High-level needs are decomposed into system requirements. The «derive» connector formalizes it: System Requirement X is derived from Stakeholder Requirement Y. This is where requirements analysis happens — translating business needs into verifiable specifications.

System Requirement → Design Element. The «realize» or «satisfy» connectors link design elements to the requirements they implement. A component realizes a set of requirements; an interface satisfies a non-functional requirement. This is the allocation a certifier checks when asking "is this requirement implemented?"

Design Element → Test Case. Test Cases (using the UML Testing Profile or custom test stereotypes) link to the design elements they verify via «verify» connectors. Each describes what is tested, the procedure, the expected result, and the actual result.

Test Case → Test Result. Results are recorded as tagged values on Test Case elements or as separate result elements. This lets the query "has this requirement been tested, and what was the result?" be answered from the model.

Picking the right connector

The most common mistake is using Trace for everything — which flattens the model so automated queries can't tell implementation from related context. Four connector types do distinct jobs:

Realize (or Satisfy) is the primary implementation link: "this design element implements this requirement." It has directional meaning — design element on the source end, requirement on the target. When you query "is this requirement implemented?", you traverse Realize connectors.

Trace is supplementary: "this element is related to this one in a traceability sense, without asserting a specific realization." Use it for cross-domain traceability that isn't implementation — a system requirement tracing to a business capability, a test case tracing to a stakeholder requirement. Flexible, but less semantically strong.

Derive is used between requirements: a system requirement derived from a stakeholder requirement, a sub-requirement from a parent. It establishes the inheritance chain.

Verify links test cases to design elements or requirements: "this test case verifies this element." Verification relationships are what make the test coverage matrix possible.

Building the traceability matrix

The matrix is what auditors ask for. It shows, in tabular form, which requirements are covered by which design elements and test cases — and where the gaps are. In Sparx EA, the Relationship Matrix view produces this automatically. Configure it with rows (a Requirements package), columns (a Test Cases package), and a relationship filter (the Verify connector, direct or transitive). Cells fill where a relationship exists; empty cells are gaps. The view exports to CSV or HTML for audit documentation.

Multiple matrix views serve different stages:

• Requirements-to-Design: rows = requirements, columns = components, filter = Realize.
• Requirements-to-Test: rows = requirements, columns = test cases, filter = Verify (transitive through design elements).
• Derived requirements: rows = system requirements, columns = stakeholder requirements, filter = Derive.

The quality of these matrices depends entirely on the consistency with which architects and requirements engineers apply the correct connector types. Apply them inconsistently and the matrix shows false gaps — valid relationships not captured — and the audit evidence becomes unreliable.

Requirements packages and stereotypes

Sparx EA's built-in «Requirement» element is the foundation. Extend it with stereotypes for your taxonomy: «StakeholderRequirement», «SystemRequirement», «FunctionalRequirement», «NonFunctionalRequirement», and «RegulatoryRequirement». Tagged values on each should include RequirementID (for cross-referencing external tools), Status (Draft, Baselined, Verified, Waived), Priority, Origin (the standard or document it comes from), and Owner.

Package structure matters: segregate requirements by type and domain, with baseline packages that capture a locked version of approved requirements at each review gate. The baseline package is read-only; active development happens in working packages.

DOORS / ReqIF integration

Many defense and aerospace programs use IBM DOORS (now DOORS Next Generation) as the contractually mandated requirements system of record. Sparx EA supports bidirectional integration through ReqIF (Requirements Interchange Format).

ReqIF import: DOORS modules exported as ReqIF import into Sparx EA as requirement packages, with text, identifiers, and attributes mapped to element properties. The imported requirements can then link to design elements and test cases.

ReqIF export: Requirements authored or refined in Sparx EA export as ReqIF for import into DOORS, keeping the text and properties.

The practical pattern: requirements are owned in DOORS (the contractual record) and linked to the design model in Sparx EA. Changes in DOORS are re-imported periodically; the design and test traceability lives in Sparx EA; the two synchronize via ReqIF roundtrip at defined milestones. This works well where the prime contractor controls DOORS but the systems integrator works in Sparx EA — the ReqIF interface is the handoff point.

Showing an auditor complete traceability

The scenario: a certification authority asks you to demonstrate that Requirement REQ-047 (from IEC 62304, EN 50128, or a defense specification) has been implemented and tested. With complete traceability in place:

1. Navigate to REQ-047 in the requirements package.
2. Open the Traceability window — it shows all connected design elements via Realize connectors.
3. Follow the connected Test Cases via Verify connectors.
4. Check the test result tagged values on those test cases.

The full chain is visible in the tool, and the matrix export provides the tabular evidence. An auditor can follow requirement to implementation to test result and see the dates, the status, and the result. The alternative — compiling that evidence from disconnected documents at audit time — is expensive, error-prone, and fragile under change. This is the discipline our work on Sparx EA and with architects is built to install.

FAQ