Why Traceability Matters
Requirements traceability answers three critical questions:
- Is every requirement tested? Forward traceability — no untested features
- Does every test have a purpose? Backward traceability — no orphan tests
- If a requirement changes, which tests need updating? Impact analysis
Without traceability, you cannot confidently say “we tested everything that matters.”
The Requirements Traceability Matrix
Basic RTM Structure
| Req ID | Requirement | Test Case IDs | Coverage | Status |
|---|---|---|---|---|
| REQ-001 | User can register with email | TC-001, TC-002, TC-003 | Full | Passed |
| REQ-002 | Password must meet complexity rules | TC-010, TC-011, TC-012 | Full | 2/3 Passed |
| REQ-003 | Two-factor authentication | — | None | Not tested |
| REQ-004 | Session timeout after 30 min | TC-020 | Partial | Passed |
Reading the RTM
- REQ-001: Fully covered with 3 test cases, all passing
- REQ-002: Covered but 1 test failing — investigate
- REQ-003: No test cases mapped — critical gap
- REQ-004: Only 1 test case — may need more scenarios (timeout at exactly 30 min, timeout reset on activity, etc.)
Creating an RTM
Step 1: List All Requirements
Gather from requirements documents, user stories, acceptance criteria.
Step 2: Map Test Cases
For each requirement, identify which test cases verify it. One requirement may have multiple test cases. One test case may cover multiple requirements.
Step 3: Identify Gaps
- Requirements with no test cases = untested functionality
- Test cases with no requirements = potential orphan tests (or missing requirements)
Step 4: Assess Coverage Quality
Having a test case mapped does not mean adequate coverage. Evaluate if the test cases cover positive, negative, and boundary scenarios.
Bidirectional Traceability
Forward (Requirement → Test): Every requirement has at least one test case. Backward (Test → Requirement): Every test case traces to at least one requirement.
| Direction | Finds | Action |
|---|---|---|
| Forward gaps | Untested requirements | Write test cases |
| Backward gaps | Orphan test cases | Remove or link to requirement |
| Many-to-many links | Complex dependencies | Review for simplification |
Tools for Traceability
| Tool | Approach |
|---|---|
| Spreadsheet | Manual, simple, error-prone at scale |
| Jira + Xray | Link stories to test cases natively |
| Jira + Zephyr | Test cases linked to requirements |
| Azure DevOps | Built-in work item linking |
| TestRail | Requirements integration module |
Exercise: Build an RTM
Given these 8 requirements for a file sharing application, create an RTM and identify coverage gaps:
Requirements:
- Users can upload files up to 100MB
- Users can share files via email link
- Shared links expire after 7 days
- Users can set password protection on shared links
- File versioning — keep last 5 versions
- Admin can set storage quotas per user
- Files are encrypted at rest
- Activity audit log for all file operations
Existing test cases: TC-001 (upload 50MB file), TC-002 (upload 101MB file rejected), TC-003 (share via email), TC-004 (open shared link), TC-005 (password protected link), TC-006 (upload new version), TC-007 (admin set quota).
Solution
| Req | Requirement | Test Cases | Coverage | Gaps |
|---|---|---|---|---|
| R1 | Upload up to 100MB | TC-001, TC-002 | Good | Add: exactly 100MB boundary, 0-byte file |
| R2 | Share via email | TC-003, TC-004 | Partial | Add: invalid email, multiple recipients |
| R3 | Links expire 7 days | — | NONE | Critical gap: no expiry tests |
| R4 | Password protection | TC-005 | Partial | Add: wrong password, empty password |
| R5 | File versioning (5) | TC-006 | Partial | Add: 6th version (should delete oldest), view older version |
| R6 | Admin quotas | TC-007 | Partial | Add: exceed quota, quota near limit |
| R7 | Encryption at rest | — | NONE | Critical gap: no encryption verification |
| R8 | Audit log | — | NONE | Critical gap: no audit log tests |
Critical gaps: R3 (link expiry), R7 (encryption), R8 (audit log) have zero coverage. These need immediate test case creation, especially R7 (security) and R8 (compliance).
Orphan test check: All existing test cases map to requirements — no orphans.
Key Takeaways
- An RTM maps requirements to test cases, revealing coverage gaps
- Bidirectional traceability catches both untested requirements and orphan tests
- Requirements with no test cases are blind spots — prioritize based on risk
- Maintain the RTM throughout the project — it is a living document
- Use tools (Jira+Xray, Azure DevOps) to automate traceability where possible