RTM in QA: requirements traceability matrix

Requirements Traceability Matrix: Structure and Application in QA

The Requirements Traceability Matrix (RTM) is a table that documents the relationships between requirements, test cases, and defects across all stages of the software lifecycle. It provides answers to key questions: what has been tested, what remains uncovered, and why a specific test is performed.

Without an RTM, testing loses transparency; with it, testing becomes a measurable process with clear coverage metrics.

Goals of Using the Matrix

RTM addresses the following tasks:

• Assessing the completeness of requirement coverage by tests.
• Identifying gaps in test documentation.
• Analyzing the impact of requirement changes on existing tests.
• Tracing the path from requirement to defect.
• Generating reports for stakeholders with quantitative indicators.

These functions make RTM indispensable in medium and large projects with extensive requirements.

Types of Traceability in RTM

Different approaches exist for building relationships:

| Type | Direction of Link | Application |

|------|-------------------|-------------|

| Forward | Requirement → Test Case | Verifying tests exist for a requirement |

| Backward | Test Case → Requirement | Justifying the need for a test |

| Bidirectional | Requirement ⇄ Test Case | Full control in both directions |

| Vertical | Requirement → Design → Code → Test | End-to-end traceability across stages |

| Horizontal | Test → Bug → Fix → Retest | Traceability within testing |

The choice of type depends on project complexity and development stage.

Column Structure in the RTM Table

A standard matrix includes the following fields:

• Requirement ID — unique identifier (REQ-AUTH-01).
• Requirement Description — brief description (email authorization).
• Test Case ID — list of related test cases (TC-LOGIN-01, TC-LOGIN-02).
• Test Status — execution status (Pass/Fail/Blocked/Not Run).
• Defect ID — defect identifiers (BUG-101).
• Defect Status — bug status (Open/Fixed/Closed).
• Coverage Status — coverage status (Covered/Not Covered/Partial).
• Coverage % — coverage percentage (100%/0%/50%).

Examples of RTM Tables

Basic Table (Requirements and Test Cases)

| REQ ID | Requirement | Priority | Test Case ID | Test Status | Defect ID | % Coverage |

|--------|-------------|----------|--------------|-------------|-----------|------------|

| REQ-01 | Authorization | High | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | Pass, Pass, Fail | BUG-101 | 100% |

| REQ-02 | Password Recovery | Medium | TC-REC-01, TC-REC-02 | Pass, Not Run | — | 50% |

| REQ-04 | Price Filtering | Low | — | — | — | 0% |

Extended Table with Development Links

| REQ ID | Requirement | Test Case ID | Result | Defect ID | Dev Task | Component |

|--------|-------------|--------------|--------|-----------|----------|-----------|

| REQ-01 | Login | TC-AUTH-01 | ✅ Pass | — | TASK-101 | Auth Module |

| REQ-01 | Login | TC-AUTH-03 | ❌ Fail | BUG-001 | TASK-101 | Auth Module |

Such tables allow for quick localization of problematic areas.

Textual Traceability Schemas

Classic Forward Link

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ REQUIREMENT  │      │ TEST CASE    │      │   DEFECT     │
│ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101      │
└──────────────┘      └──────────────┘      └──────────────┘

End-to-End Vertical Traceability

┌─────────────────────┐
│  BUSINESS REQUIREMENT│
└──────────┬──────────┘
           ▼
┌─────────────────────┐    ┌─────────────┐
│  FUNCTIONAL         │───▶│   TEST      │
│   REQUIREMENTS      │    │   CASES     │
└──────────┬──────────┘    └──────┬──────┘
           │                     │
           ▼                     ▼
┌─────────┐              ┌─────────────────────┐
│TECHNICAL│              │  TEST EXECUTION     │
│TASKS    │              └──────────┬──────────┘
└────┬────┘                        │
     │                             ▼
     └────────────────────┬───────┘
                          │
                  ┌─────────────────────┐
                  │      DEFECTS        │
                  └─────────────────────┘

Coverage Statistics Analysis

A typical RTM report includes:

| Metric | Value | Formula |

|--------|-------|---------|

| Total Requirements | 50 | — |

| With Tests | 45 | — |

| Without Tests | 5 | — |

| % Coverage | 90% | (45/50)×100% |

| Tests per Requirement (avg.) | 3.6 | 180/50 |

Common errors: outdated matrix, formal links, lack of defect links, duplicate tests.

Checklist for QA Engineers

• Each requirement has at least one test case.
• No "orphaned" test cases without links.
• Related tests are updated when requirements change.
• Each defect is linked to a requirement.
• The matrix is updated after each sprint/release.
• Analysis of failure causes is possible via RTM.

RTM Automation Tools

| Tool | Type | Features |

|------|------|----------|

| Jira + Xray/Zephyr | Plugins | Agile traceability |

| TestRail | Test Management | Native RTM |

| Qase | Test Management | Simple links |

| Excel/Google Sheets | Manual | For small projects |

| Polarion/Azure DevOps | ALM | Enterprise-level |

When to Avoid RTM

The matrix is not suitable for:

• Projects with <20 requirements.
• Teams of <3 people.
• Short sprints (1-2 weeks).
• Ad-hoc testing or MVPs with frequent changes.

Drawbacks: high update effort, risk of formalism, overhead for startups.

Rule: RTM pays off with >20 requirements and teams of 3+ people.

Key Takeaways

• RTM ensures 90%+ requirement coverage by tests in large projects.
• Bidirectional traceability minimizes risks during regression.
• Matrix relevance is key to its value; update after every change.
• Use ALM tools for automation at the enterprise level.
• Analyze metrics: coverage gaps and test cases per requirement.

— Editorial Team