Testing, Validation & Quality Assurance

The Requirements Traceability Matrix

18 min Lesson 6 of 10

The Requirements Traceability Matrix

A Requirements Traceability Matrix (RTM) is a table that links every requirement from your SRS to the test cases that verify it, and then onward to the test results that prove it was actually tested. If a requirement has no row in the RTM, it might never be tested. If a test case has no requirement column, nobody knows what business rule it is protecting. The RTM closes both gaps.

Traceability runs in two directions:

  • Forward traceability — from requirements down to test cases and results. Answers: "Have we written tests for everything we were asked to build?"
  • Backward traceability — from test cases back up to requirements. Answers: "Does every test we wrote map to something a stakeholder actually asked for? Are we testing scope creep?"
The RTM is a living document. Every time a requirement is added, changed, or removed, the corresponding row in the RTM must be updated. A stale RTM is worse than no RTM, because it gives false confidence that everything is covered.

Anatomy of an RTM

At minimum an RTM contains these columns:

  1. Req ID — the unique identifier from the SRS (e.g. FR-012).
  2. Requirement Description — a short statement of what the requirement says.
  3. Test Case ID(s) — the identifier(s) of the test cases that cover this requirement.
  4. Test Result — Pass, Fail, or Not Run (updated after each test cycle).

More mature RTMs add columns for the design artefact that realises the requirement (e.g. a class name or API endpoint), the priority, and the sprint or release in which the requirement is scheduled. Keep the table as lean as your project needs — the core purpose is coverage visibility, not bureaucracy.

Diagram 1: RTM Structure for an Online Clinic Booking System

Consider a clinic's patient-booking system. The SRS contains six functional requirements. The matrix below shows how each maps to test cases and their current results after the first test cycle.

Requirements Traceability Matrix — Clinic Booking System Req ID Requirement Description Test Case IDs Result FR-001 Patient can register with email and password TC-001, TC-002, TC-003 PASS FR-002 Patient can search available appointment slots TC-004, TC-005 PASS FR-003 System sends confirmation email within 2 minutes of booking TC-006, TC-007 FAIL FR-004 Doctor can view their daily appointment schedule TC-008, TC-009 PASS FR-005 Admin can cancel any appointment and notify all parties TC-010, TC-011 NOT RUN FR-006 Patient can view past appointment history — none defined — NOT RUN Legend: PASS FAIL NOT RUN Coverage: 4 of 6 requirements have test cases (66%). FR-006 is a coverage gap — no tests defined. Defect risk: FR-003 (email confirmation) has a failing test — a known defect must be opened and tracked.
Requirements Traceability Matrix for a clinic booking system: each row links one requirement to its test cases and current result. FR-006 has no test cases — a coverage gap the analyst must address before release.

Reading the Matrix

Three signals jump out of the matrix above the moment you scan it:

  • Green rows (PASS) — the requirement is covered by at least one test case and all those cases passed. The feature is demonstrably working as specified.
  • Red row (FAIL) — FR-003 has test cases but they failed. This is not a coverage problem; it is a defect. The analyst must open a defect ticket and track it to resolution before the release quality gate can be cleared.
  • Amber rows (NOT RUN) — FR-005 has test cases but the test cycle has not reached them yet. FR-006 is worse: it has no test cases at all. That is a coverage gap — a requirement that can leave the project with zero evidence of working correctly.
A coverage gap is a release risk. If FR-006 reaches production without test coverage, any defect in patient history retrieval will be caught by real users, not testers. Whenever a row shows "none defined" in the Test Case column, the analyst must treat it as a blocker for the next test cycle.

Diagram 2: Traceability Flow — From Requirement to Evidence

The RTM is not just a static table. It represents a chain of evidence. Each requirement in the SRS flows downward through design, into test cases, and finally into test execution records. The diagram below shows this chain for a logistics firm's parcel-tracking feature.

Traceability Chain: SRS Requirement to Test Evidence SRS Design Artefact Test Cases Test Results FR-021 Customer views real-time parcel tracking status TrackingController GET /api/parcels/ {id}/status TC-041: Valid parcel ID TC-042: Invalid parcel ID TC-043: Expired parcel ID PASS PASS NOT RUN Forward Traceability Backward Traceability FR-021 coverage: 3 test cases defined, 2 passed, 1 not yet run. Requirement cannot be signed off until TC-043 is executed and passes.
Traceability chain for a logistics parcel-tracking requirement: forward traceability links FR-021 through design to test cases and results; backward traceability confirms every test maps to a real requirement.

Building the RTM in Practice

Analysts typically build and maintain the RTM as a spreadsheet (Excel, Google Sheets) or inside a dedicated requirements management tool (Jira, Confluence, Helix ALM). The process follows these steps:

  1. Seed the rows. Export every requirement ID and description from the SRS. Each gets one row. At this stage the Test Case and Result columns are blank.
  2. Assign test cases. As the test team writes test cases, they tag each one with the requirement ID it covers. The RTM is updated with those IDs. One requirement can have multiple test cases; one test case can cover multiple requirements (though covering too many in a single case is a sign it should be split).
  3. Check for gaps. After the first pass, any row without at least one test case ID is a coverage gap. The analyst raises this with the test lead — either a test case must be written, or a deliberate decision is made to accept the risk (documented in writing).
  4. Update after each test cycle. When a test run completes, results (Pass/Fail/Blocked) are recorded in the Result column. Failed rows produce defect tickets that link back to the requirement ID.
  5. Use it at quality gates. Before releasing to UAT or production, the RTM is reviewed. The agreed threshold (for example, 100% requirements with test cases, and 95% passing) must be met. Any failing requirement is either fixed or formally deferred.
Traceability pays double. When a requirement changes late in the project, the RTM instantly tells you which test cases are now invalid and must be updated. Without it, analysts and testers spend days hunting for the impact of a change. With it, the answer is one filter away.

RTM Anti-Patterns to Avoid

The RTM is only useful if it is kept accurate. Watch for these common failure modes on real projects:

  • The orphan test case. A test case that maps to no requirement is either testing something nobody asked for (scope creep) or the requirement was deleted but the test was not cleaned up. Both waste tester time.
  • The vanity pass rate. Marking a test "Pass" when the tester only partially executed it. This inflates the coverage number and misleads stakeholders at quality gates.
  • One test case per requirement. A single test case rarely covers all the boundary conditions of a requirement. Requirement FR-003 ("confirmation email within 2 minutes") needs at least three cases: happy path, system under load, and email service unavailable. Treating one case as sufficient creates hidden risk.
  • RTM written post-hoc. When analysts fill in the RTM after testing rather than before, they unconsciously link test cases to requirements that happen to match — instead of proactively identifying missing coverage before it is too late to write new tests.

In the next lesson we look at defect management — how defects discovered through RTM-driven testing are raised, classified, prioritised, and resolved within the project workflow.

Previous Lesson User Acceptance Testing (UAT)
Next Lesson Defect Management
Back to Course