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

End-to-end requirements traceability means you can show 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. What makes it auditable is connector discipline: the right connector type at every link, applied consistently, so the traceability matrix can be queried and trusted.

Building and maintaining those links has always been the expensive part. Working AI-augmented, the engineer or architect states the traceability rules and AI does much of the linking, gap-finding and change tracing. Whether each link is true stays with the people who know the system.

Manual traceability, kept in Word documents and disconnected spreadsheets, is expensive to maintain and fragile under change. A missed link can mean a certification failure.

Why it matters

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

The practical question these sectors face is whether they can demonstrate traceability efficiently. When a requirement changes, identifying every affected design and test artifact across disconnected documents is a manual trace, and the risk of a missed link, an untested requirement or an unimplemented design element, is real. Sparx EA addresses this by holding the whole 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 whether a requirement is 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, so the question “has this requirement been tested, and what was the result?” can be answered from the model.

Picking the right connector

The most common mistake is using Trace for everything, which flattens the model so queries cannot 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 is directional, with the design element at the source end and the requirement at the target. Asking whether a requirement is implemented means traversing Realize connectors.

Trace is supplementary: this element is related to that one for traceability purposes, without asserting a specific realization. Use it for cross-domain traceability that is not implementation, such as a system requirement tracing to a business capability. It is flexible and semantically weaker.

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

Verify links test cases to design elements or requirements. Verification relationships are what make the test coverage matrix possible.

Building the traceability matrix

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

Several matrix views serve different stages:

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

The quality of these matrices depends on how consistently the team applies the correct connector types. Applied inconsistently, the matrix shows false gaps 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, and active development happens in working packages.

DOORS / ReqIF integration

Many defense and aerospace programs use IBM DOORS or DOORS Next as the contractually mandated requirements system of record. Sparx EA exchanges requirements with them 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 as the contractual record and linked to the design model in Sparx EA. Changes in DOORS are re-imported at defined milestones, and the design and test traceability lives in Sparx EA. This works well where the prime contractor controls DOORS and the systems integrator works in Sparx EA, with ReqIF as the handoff point.

Maintaining traceability AI-augmented

Creating links. Today an engineer reads each requirement and each design element and draws the connectors by hand, which is where links get missed or mistyped. Working AI-augmented, the engineer states the rules, such as which connector applies between which element types and which packages are in scope, and AI proposes links from the requirement text and the design, with the reason for each. The engineer approves, corrects or rejects them. The skill is knowing the connector semantics and the system well enough to judge a proposed link, because a wrong Satisfy link is false certification evidence.

Finding gaps. Today the team builds the matrix and scans it for empty cells before a gate review. Working AI-augmented, AI checks the whole chain continuously and lists requirements with no realizing element, design elements with no verifying test, and connectors of the wrong type. Automation checks completeness, people own correctness. Whether a gap is an oversight, a waiver or a requirement that should be deleted is a human decision.

Tracing a change. Today a requirement change starts a manual hunt for affected design elements and tests. Working AI-augmented, AI follows the connectors, flags every affected element and drafts the impact list, and the engineers decide what the change means for each one.

Tools that help include Claude or GitHub Copilot with AI Power Tools for Sparx EA, and Kernaro Assist in the EA client.

Showing an auditor complete traceability

A certification authority asks you to show 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, which 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, status and results. Compiling the same evidence from disconnected documents at audit time is expensive, error-prone and fragile under change. See the requirements management discipline for how this fits a wider practice.

FAQ