9.2 Requirements Traceability Matrix
Key Takeaways
- The Requirements Traceability Matrix (RTM) links every requirement from its business origin through design and deliverables to its test cases
- Traceability enables impact analysis — when a change is proposed, the RTM shows which deliverables, tests, and stakeholders are affected
- Forward traceability links requirements forward to design and tests; backward traceability links them back to business needs; bi-directional combines both
- The RTM prevents both scope creep/gold plating (no deliverable without a requirement) and missed scope (no requirement without a deliverable)
- In agile, traceability flows through the product backlog: business objective → epic → user story → acceptance criteria → test
What Traceability Means
The Requirements Traceability Matrix (RTM) is a grid that links each requirement throughout the project life cycle. Traceability is the ability to follow one requirement from its source (a business need) through its implementation (a deliverable) to its verification (a test case). A well-maintained RTM guarantees four things the CAPM exam repeatedly tests:
- Every requirement has a documented business justification.
- Every deliverable maps back to an approved requirement.
- Every requirement is verified by at least one test.
- The full impact of any proposed change can be assessed quickly.
The RTM is created during the requirements phase and is kept current throughout the project — it is a living document, not a one-time artifact.
RTM Structure
A typical RTM contains these columns:
| Column | Purpose |
|---|---|
| Requirement ID | Unique identifier (REQ-001) |
| Description | What the requirement states |
| Source / Business Need | The objective or stakeholder it traces to |
| Priority | High / Medium / Low (often MoSCoW) |
| Status | Active, approved, in progress, deferred, deleted |
| Design Reference | Design element that addresses it |
| Deliverable | Project output that fulfills it |
| Test Case ID | Test that verifies it |
| Test Status | Not run, passed, failed |
| Owner | Person accountable for it |
Worked Example
| Req ID | Description | Source | Priority | Design | Test Case | Status |
|---|---|---|---|---|---|---|
| REQ-001 | Log in 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 | Profile dashboard | BR-02 | Medium | DD-07 | TC-005 | Approved |
| REQ-004 | Export data to CSV | BR-03 | Low | DD-12 | TC-008 | Deferred |
Reading the matrix: REQ-001 and REQ-002 both trace to business requirement BR-01, so a change to BR-01 immediately flags two requirements, two design elements, and two tests for review. REQ-004 is Deferred, so it is intentionally out of the current release but still tracked — it has not been lost.
Types of Traceability
| Type | Direction | Question it answers |
|---|---|---|
| Forward | Requirement → design → test | "Is every requirement built and tested?" |
| Backward | Requirement → business need | "Does every requirement have a valid reason to exist?" |
| Bi-directional | Both | "Is there complete coverage from need to verification?" |
Trap: Candidates flip forward and backward. Forward = toward the future (design and tests, downstream). Backward = toward the origin (business need, upstream). If a stem asks how to confirm a requirement is actually justified by a business goal, the answer is backward traceability.
Using the RTM: Impact Analysis, Scope Validation, Coverage
Impact analysis
When a change request arrives, the analyst reads the RTM to see exactly what is affected before the change control board decides:
- Which requirements change.
- Which design elements and deliverables must be reworked.
- Which test cases must be updated or re-run.
- Which stakeholders to notify.
This is why the RTM is the analyst's first stop in integrated change control — it converts a vague "can we just add this?" into a concrete list of consequences.
Scope validation (prevents gold plating and missed scope)
| Risk | How the RTM catches it |
|---|---|
| Gold plating | A deliverable exists with no traced requirement → flag and remove |
| Missed scope | A requirement exists with no deliverable → flag and build |
| Untested work | A requirement with no test case → add a test |
Coverage analysis
The RTM answers three coverage questions: are all requirements covered in the design, verified by tests, and linked to business needs? Gaps in any column are corrective-action triggers.
Traceability by Delivery Approach
| Approach | How traceability is maintained |
|---|---|
| Predictive | Formal RTM document updated at each phase gate; detailed links from business → system requirements → tests |
| Agile | Backlog hierarchy provides traceability; less paperwork but the links still exist |
| Hybrid | Formal RTM for compliance/regulatory items; agile backlog for the rest |
The Product Backlog as a Traceability Tool
In agile, the product backlog is the traceability mechanism. The chain runs:
Business Objective → Epic → User Story → Acceptance Criteria → Test
| Agile artifact | Traceability role |
|---|---|
| Epic | Links a feature group back to a business objective (backward) |
| User story | States the requirement in user terms |
| Acceptance criteria | Defines how the story is verified |
| Definition of Done | Ensures every story meets quality standards |
| Automated tests | Verify acceptance criteria, closing forward traceability |
Trap: A common wrong answer claims "agile projects do not need traceability." They do — it is simply embedded in the backlog structure and acceptance criteria rather than a separate spreadsheet.
A change request proposes modifying the login feature. The analyst needs to identify every design element, deliverable, and test affected before the change board decides. Which tool provides this directly?
An auditor wants to confirm that every requirement in the project actually traces back to an approved business need, with no orphan requirements. Which type of traceability is being checked?
During delivery the team discovers a completed feature that does not map to any approved requirement in the RTM. This most likely indicates: