9.2 Requirements Traceability Matrix
Key Takeaways
- The Requirements Traceability Matrix (RTM) links requirements throughout the project life cycle from origin to deliverables to test cases
- Traceability enables impact analysis when changes are proposed — showing which deliverables, tests, and stakeholders are affected
- Forward traceability links requirements to design and test cases; backward traceability links requirements to business needs
- The RTM helps prevent scope creep by ensuring every deliverable traces back to an approved requirement
- In agile, traceability is maintained through the product backlog, user stories, acceptance criteria, and the Definition of Done
Last updated: March 2026
Requirements Traceability Matrix
The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. It provides a way to trace each requirement from its origin through design, implementation, and testing.
What Is Traceability?
Traceability is the ability to trace a requirement from its source (business need) through its implementation (deliverable) to its verification (test case). It ensures that:
- Every requirement has a business justification
- Every deliverable maps to a requirement
- Every requirement is tested and verified
- Changes can be assessed for their full impact
RTM Structure
A typical RTM includes the following columns:
| Column | Purpose |
|---|---|
| Requirement ID | Unique identifier for each requirement |
| Requirement Description | What the requirement states |
| Business Need/Source | Which business objective or stakeholder need it traces to |
| Priority | Importance ranking (high, medium, low) |
| Status | Current state (active, deferred, deleted, approved, completed) |
| Design Reference | Which design element addresses this requirement |
| Deliverable | Which project deliverable fulfills this requirement |
| Test Case ID | Which test verifies this requirement |
| Test Status | Whether testing is complete and passed |
| Owner | Who is responsible for this requirement |
Example RTM
| Req ID | Description | Source | Priority | Design | Test Case | Status |
|---|---|---|---|---|---|---|
| REQ-001 | User login with email/password | BR-01 | High | DD-03 | TC-001 | Approved |
| REQ-002 | Password reset via email | BR-01 | High | DD-04 | TC-002 | In Progress |
| REQ-003 | User profile dashboard | BR-02 | Medium | DD-07 | TC-005 | Approved |
| REQ-004 | Export data to CSV | BR-03 | Low | DD-12 | TC-008 | Deferred |
Types of Traceability
| Type | Direction | Purpose |
|---|---|---|
| Forward Traceability | Requirements → Design → Test | Ensures every requirement is implemented and tested |
| Backward Traceability | Requirements → Business Needs | Ensures every requirement has a valid business justification |
| Bi-directional Traceability | Both directions | Complete traceability from business need to test verification |
Using the RTM
Impact Analysis
When a change is proposed, the RTM shows:
- Which requirements are affected
- Which design elements must change
- Which deliverables are impacted
- Which tests must be updated or re-run
- Which stakeholders should be notified
Scope Validation
The RTM helps validate scope by ensuring:
- No deliverable exists without a traced requirement (prevents gold plating)
- No requirement exists without a deliverable (prevents missed requirements)
- All requirements are tested before delivery
Coverage Analysis
The RTM enables analysis of:
- Requirements coverage — Are all requirements addressed in the design?
- Test coverage — Are all requirements verified through testing?
- Business alignment — Are all requirements linked to business needs?
Traceability in Different Methodologies
Predictive (Waterfall)
- Formal RTM document maintained throughout the project
- Detailed traceability from business requirements to system requirements to test cases
- RTM is updated at each phase gate
- Often maintained in requirements management tools
Agile
- Traceability is maintained through the product backlog structure
- User stories trace to acceptance criteria (validation)
- Acceptance criteria are verified through acceptance tests
- The Definition of Done ensures all stories meet quality standards
- Less formal documentation but traceability still exists
Hybrid
- High-level requirements in formal RTM
- Detailed implementation tracked through agile backlog
- Key compliance and regulatory requirements formally traced
- Flexible approach based on organizational needs
Product Backlog as a Traceability Tool
In agile environments, the product backlog serves a traceability function:
Business Objective → Epic → User Story → Acceptance Criteria → Test
| Agile Artifact | Traceability Role |
|---|---|
| Epic | Links to business objective (backward traceability) |
| User Story | Describes the requirement in user terms |
| Acceptance Criteria | Defines how the story is verified |
| Sprint Backlog | Shows which stories are being implemented |
| Increment | Deliverable meeting Definition of Done |
| Automated Tests | Verify acceptance criteria are met |
Test Your Knowledge
What is the primary purpose of the Requirements Traceability Matrix (RTM)?
A
B
C
D
Test Your Knowledge
Forward traceability links requirements to:
A
B
C
D
Test Your Knowledge
How is requirements traceability maintained in agile environments?
A
B
C
D