Direct Answer: End-to-end requirements traceability means you can demonstrate — to an auditor, a certification authority, or a project board — that every regulatory or business requirement is accounted for in the design, and that the design has been tested. In Sparx EA, this chain runs from Requirements packages (capturing business and regulatory requirements) through design elements (components, interfaces, behaviours) via Realization and Derive connectors, to Test Cases linked via Test elements and tagged verification results. Sparx EA also supports DOORS / ReqIF import and export for programmes that use IBM DOORS as the requirements management system of record. The critical thing that makes this work is the connector discipline: Trace and Realization connectors must be consistently applied at each link in the chain, and the traceability matrix must be queryable. Without that discipline, the traceability exists in the model but cannot be audited efficiently.
Key Takeaways
- End-to-end traceability in Sparx EA runs: Business Goal → Stakeholder Requirement → System Requirement → Design Element → Test Case → Test Result.
- The key connectors are: Derive (requirement-to-requirement), Realization (requirement-to-design), Trace (any-to-any supplementary traceability), and Satisfy (element satisfies a requirement).
- Sparx EA’s built-in Requirement element is the anchor type. All requirements — business, system, functional, non-functional — can be typed as Requirements with appropriate stereotypes.
- ReqIF export enables roundtripping with DOORS and other ALM tools. This is important for programmes where DOORS is contractually mandated.
- Relationship Matrix views in Sparx EA provide the traceability matrix view auditors typically request.
Why Requirements Traceability Matters
For sectors where regulatory compliance, safety certification, or government contract compliance applies — defence (MIL-STD-882, DO-178C, DEF STAN), medical devices (IEC 62304, ISO 13485, FDA 21 CFR Part 11), rail (EN 50128, EN 50657), and aerospace (DO-178C, ARP 4754A) — end-to-end requirements 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?” Manual traceability — maintained in Word documents, Excel matrices, or disconnected DOORS modules — is expensive to maintain and fragile under change. When a requirement changes, identifying all design and test artefacts affected requires a manual trace through multiple documents. The risk of a missed link — an untested requirement, an unimplemented design element — is a certification failure.
Sparx EA addresses this by maintaining the entire traceability chain within a single governed repository, with relationship types that carry formal semantic meaning and can be queried automatically.
The Traceability Chain in Sparx EA
The complete chain from business goal to test result looks like this in Sparx EA:
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 (or Association with «trace» stereotype) links the requirement back to its originating goal. This is the “why does this requirement exist?” link — important for change impact analysis.
Stakeholder Requirement → System Requirement: High-level stakeholder requirements are decomposed or derived into system requirements. The «derive» connector formalises this: System Requirement X is derived from Stakeholder Requirement Y. This step is where the requirements analysis happens — translating business needs into verifiable system 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 requirements-to-design allocation — the link that certifiers check when they ask “is this requirement implemented?”
Design Element → Test Case: Test Cases in Sparx EA (using the UML Testing Profile or custom test stereotypes) are linked to the design elements they verify via «verify» connectors. Each Test Case describes what is being tested, the test procedure, the expected result, and the actual result.
Test Case → Test Result: Test results are recorded as tagged values on Test Case elements or as separate result elements linked to their test cases. This allows the traceability query “has this requirement been tested and what was the result?” to be answered from the model.
The Realization and Trace Connectors: Understanding the Difference
Realize (or Satisfy) is the primary implementation link. It states: “this design element implements this requirement.” The link has directional meaning — the design element is on the source end, the requirement on the target. When you query “is this requirement implemented?”, you traverse Realize connectors.
Trace is a supplementary link. It states: “this element is related to this element in a traceability sense, without asserting a specific realisation relationship.” Trace is used for cross-domain traceability that is not implementation: a system requirement traces to a business capability, a test case traces to a stakeholder requirement, a design decision traces to a requirement it was influenced by. Trace is flexible but less semantically strong than Realize.
Derive is used between requirements. A system requirement is derived from a stakeholder requirement. A sub-requirement is derived from a parent requirement. Derive establishes the inheritance chain within the requirements hierarchy.
Verify links test cases to design elements or requirements. It states: “this test case verifies this element.” Verification relationships are what make the test coverage matrix possible.
The common mistake is using Trace for everything, including Realisation and Derive relationships. This reduces the semantic precision of the traceability model — all links look the same, and automated traceability queries cannot distinguish implementation from related context. Use the specific connector type appropriate to each relationship.
Building the Traceability Matrix
The traceability matrix is what auditors ask for. It shows, in tabular form, which requirements are covered by which design elements and which test cases — and where there are gaps.
In Sparx EA, the Relationship Matrix view provides this automatically. Configure a matrix with:
- Rows: Requirements package (source elements)
- Columns: Test Cases package (target elements)
- Relationship filter: Verify connector (direct or transitive)
The matrix populates automatically from the repository’s connector data. Cells are filled where a verify relationship exists; empty cells are gaps. This view is exportable to CSV or HTML for audit documentation.
Multiple matrix views serve different traceability 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. If connectors are applied inconsistently, the matrix has false gaps (valid relationships not captured) and the audit evidence is unreliable.
Requirements Packages and Stereotypes
Sparx EA’s built-in «Requirement» element is the foundation. Extend it with stereotypes for your requirements taxonomy:
«StakeholderRequirement»— business and stakeholder needs«SystemRequirement»— system-level verifiable specifications«FunctionalRequirement»— what the system shall do«NonFunctionalRequirement»— quality, performance, security constraints«RegulatoryRequirement»— legally or contractually mandated specifications
Tagged values on each requirement type should include: RequirementID (for cross-referencing with external tools), Status (Draft, Baselined, Verified, Waived), Priority, Origin (which 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 programmes in defence and aerospace use IBM DOORS (now DOORS Next Generation) as the contractually mandated requirements management system. Sparx EA supports bidirectional integration with DOORS through ReqIF (Requirements Interchange Format).
ReqIF import: DOORS modules exported as ReqIF can be imported into Sparx EA as requirement packages, with requirement text, identifiers, and attributes mapped to Sparx EA’s element properties. The imported requirements can then be linked to design elements and test cases within Sparx EA.
ReqIF export: Requirements authored or refined in Sparx EA can be exported as ReqIF for import into DOORS, maintaining the requirements text and properties.
The practical use case: programme requirements are owned in DOORS (the contractual record) and linked to the design model in Sparx EA. Changes to requirements in DOORS are re-imported periodically. The design and test traceability lives in Sparx EA; the requirements baseline lives in DOORS. The two systems are synchronised via ReqIF roundtrip at defined programme milestones.
This approach works well for programmes where the prime contractor controls DOORS but the systems integrator or subcontractor works in Sparx EA. The ReqIF interface is the handoff point.
Showing Auditors Complete Traceability
The audit scenario: a regulatory body or certification authority asks your team to demonstrate that Requirement REQ-047 (drawn from IEC 62304 or EN 50128 or a defence system specification) has been implemented and tested.
In Sparx EA with complete traceability:
- Navigate to REQ-047 in the requirements package.
- Open the Traceability window — it shows all connected design elements via Realize connectors.
- Navigate to the connected Test Cases via Verify connectors.
- Check the test result tagged values on the test cases.
The full chain is visible in the tool, and the traceability matrix export provides the tabular evidence. An auditor can follow the chain from requirement to implementation to test result and see the dates, the status, and the result.
This is the value proposition of end-to-end traceability in Sparx EA. The alternative — compiling this evidence from disconnected documents at audit time — is expensive, error-prone, and fragile under change.
FAQ
What is requirements traceability and why does it matter for regulated industries? Requirements traceability is the ability to demonstrate, at any point in a programme, that every requirement is accounted for in the design and verified by test. For regulated industries — defence, medical devices, rail, aerospace — traceability is a certification prerequisite. Standards like DO-178C, EN 50128, IEC 62304, and DEF STAN specifications mandate demonstrable traceability from system specification to implementation to test evidence. Without traceable links, certification fails or requires expensive retrospective evidence compilation.
What connector types should I use for requirements traceability in Sparx EA? Use: Derive for requirement-to-requirement relationships (system requirement derived from stakeholder requirement), Realize or Satisfy for design-to-requirement links (component realises requirement), Verify for test-to-element links (test case verifies design element or requirement), and Trace for supplementary cross-domain relationships. Avoid using Trace for all relationship types — the semantic precision of Realize, Derive, and Verify enables automated traceability matrix generation and query.
How does Sparx EA generate a traceability matrix? Sparx EA’s Relationship Matrix view generates traceability matrices automatically from connector data. Configure rows (requirements), columns (design elements or test cases), and a connector filter (Realize, Verify, Derive). The matrix populates from the repository with cells filled where relationships exist and empty cells flagging gaps. Export to CSV or HTML for audit documentation. Matrix accuracy depends on consistent connector type application across the requirements team.
Does Sparx EA integrate with IBM DOORS? Yes. Sparx EA supports ReqIF (Requirements Interchange Format) import and export, enabling bidirectional integration with IBM DOORS and DOORS Next Generation. DOORS modules can be exported as ReqIF and imported into Sparx EA as requirement packages. Requirements authored in Sparx EA can be exported to DOORS via ReqIF. This supports programmes where DOORS is the contractual requirements system of record and Sparx EA manages the design and test architecture.
How do I handle requirement changes in the traceability model? When a requirement changes, Sparx EA’s impact analysis shows which connected design elements and test cases are affected via the traceability connectors. The change management process: update the requirement, flag connected elements for review (tagged value Status = Affected), review and update impacted design elements, update or add test cases as needed, re-run the traceability matrix to verify closure. The automation that makes this manageable is the consistent connector discipline — without it, change impact analysis is manual.
Can EA GraphLink query the requirements traceability model? Yes. With governed MDG stereotypes on requirement elements and consistent connector types, EA GraphLink can traverse the traceability model. AI queries like “which requirements lack an associated test case?” or “which design components have no verified requirements?” can be answered from the repository via natural language. This is a significant productivity improvement over manual matrix review, particularly for large programmes with hundreds or thousands of requirements.
What is the difference between Trace and Realize connectors? Realize (or Satisfy) is the implementation link — it states that a design element implements a specific requirement. It has directional semantic meaning. Trace is a supplementary link for cross-domain traceability that does not assert implementation: a test case traces to a business goal, a decision traces to a requirement it influenced. Trace is flexible; Realize is precise. For traceability matrices that must demonstrate compliance to a certifier, Realize and Verify carry more evidential weight than Trace alone.
How do I structure requirements packages for baseline management? Use separate packages for working requirements (under active development) and baseline packages (locked snapshots at review gates). Baseline packages are read-only copies of the working package at a defined programme milestone — Stage 1 baseline, PDR baseline, CDR baseline. Lock baseline packages against modification. All change activity happens in the working package, with periodic comparisons to the baseline to identify deltas. This approach supports programme gate reviews and provides the “as-approved” requirements set that auditors need.
Automate Requirements Traceability for Your Programme
Sparx Services’ Amplify offering builds requirements traceability capability into Sparx EA programmes — covering the package structure, connector conventions, matrix configuration, DOORS/ReqIF integration, and Kernaro Assist automation for traceability gap detection.
For programmes where audit traceability is a delivery obligation, this is the investment that makes compliance evidence manageable rather than a last-minute scramble.
