Requirements Traceability Matrix: How to Prove Every Requirement Is Tested
One table that links every requirement to its tests, their latest results and any open defects, so coverage gaps show up well before release.
For QA engineers and leads who need to show which requirements are tested, and teams preparing a release sign-off or an audit.
What Is a Requirements Traceability Matrix?
A requirements traceability matrix (RTM) is a table that maps each requirement to the test cases that verify it, usually with their latest results and any linked defects. It answers two questions at a glance: is every requirement tested, and does every test trace back to a requirement?
Teams use it to find untested requirements early, to see which tests to update when a requirement changes, and to back a release decision with evidence.
Forward, Backward and Bidirectional Traceability
Traceability can be read in two directions, and a complete RTM supports both:
Forward traceability: requirement to tests
Backward traceability: test to requirement
Bidirectional traceability: both at once
The Columns of a Useful RTM
Keep the matrix to the columns you will actually read at sign-off. These eight cover most teams:
| Column | What it holds | Example |
|---|---|---|
| Requirement ID | A stable, unique ID from your backlog or spec | REQ-102 |
| Requirement | A one-line summary of what must be true | A valid promo code reduces the order total |
| Priority or risk | How much a failure would hurt, so gaps can be ranked | High |
| Test scenario | The scenario that verifies the requirement | REQ-102 Promo codes |
| Test cases | How many cases cover it, or their titles | 6 cases |
| Latest result | The outcome of the most recent run | 5 passed, 1 blocked |
| Defects | Open defects linked to the requirement | None open |
| Status | Your verdict for this row | Covered, re-test the blocked case |
The priority column matters more than it looks: it turns a list of gaps into an ordered to-do list. For how to rank requirements by risk, see the Test Coverage guide.
A Sample Matrix
Here is the checkout feature two days before release:
| ID | Requirement | Scenario | Cases | Latest result | Defects | Status |
|---|---|---|---|---|---|---|
| REQ-101 | Guests can check out without an account | REQ-101 Guest checkout | 4 | 4 passed | None | Covered |
| REQ-102 | A valid promo code reduces the order total | REQ-102 Promo codes | 6 | 5 passed, 1 blocked | None | Re-test blocked case |
| REQ-103 | A declined card shows a clear message | REQ-103 Card payment | 5 | 4 passed, 1 failed | 1 open | At risk |
| REQ-104 | An order confirmation email is sent | (none) | 0 | Not tested | Gap: add tests | |
| REQ-105 | The cart keeps items for 7 days | REQ-105 Cart persistence | 3 | Not run yet | Run before release |
- REQ-101 is done: every case passed and nothing is open.
- REQ-102 needs one re-test once the blocker is cleared.
- REQ-103 has a failing case with an open defect, so the release owner decides whether to fix first or ship with a known issue.
- REQ-104 is a forward-traceability gap: no tests exist yet, so it goes to the top of the list.
- REQ-105 has tests that have not run yet, so it is scheduled before sign-off.
How to Build an RTM with Evaficy Smart Test
The matrix itself lives in a spreadsheet or your requirements tool. Evaficy Smart Test supplies the links and results that fill it, as long as each scenario carries its requirement ID:
One scenario per requirement, ID first
Name each scenario with the requirement ID at the front, such as "REQ-102 Promo codes", in the Save dialog's Scenario Name field. Scenario search matches words in the name and description, so the ID keeps each scenario easy to find.
Paste the requirement into the Requirement field
Add the Requirement custom field and paste the requirement or its acceptance criteria. AI generation treats it as a spec every case must follow, and it is saved with the scenario and restored whenever the scenario is reopened. To start from a Jira ticket, see Jira Acceptance Criteria to Test Cases.
Group the release in a Test Plan
Add every requirement's scenario to a Test Plan for the release. Its coverage figure shows the share of those scenarios with at least one completed test run, which is your forward-traceability score at scenario level.
Run, then export the results
Each test run executes one scenario and records a result per case: Passed, Failed, Blocked or Skipped. Export the run report as CSV (test case, status, executed by and at, actual result, defect, block and skip reasons) or PDF, and copy the outcome into the Latest result column.
Link defects to the scenario
Set the defect's Linked Scenario. A defect promoted from a test run arrives with its scenario selected and the test case title in brackets at the start of its title, and a defect pushed to Jira or Linear carries "Linked Scenario: <name>" in its description.
Here is where each RTM column comes from:
| RTM column | Source in Evaficy Smart Test |
|---|---|
| Requirement ID and text | Scenario name (ID first) and the Requirement custom field, saved with the scenario |
| Test scenario and cases | The saved scenario and its test cases |
| Scenario coverage for a release | Test Plan coverage: the share of the plan's scenarios with at least one completed test run |
| Latest result | Test run report, exported as CSV or PDF |
| Defects | Defects with a Linked Scenario, including defects pushed to Jira or Linear |
Test Plans and test runs, including their CSV and PDF reports, are part of the Enterprise plan. Scenarios, the Requirement field and defects are available on every plan. For tracing individual acceptance criteria inside a scenario, see the requirement-ID naming used in Spec-Driven Development Testing.
Keeping the Matrix Current
An RTM stays useful when updating it is part of the normal workflow:
- When a requirement is added, add its row and its scenario in the same sprint.
- When a requirement changes, update the Requirement field, review the scenario's cases, and note the change in the Status column.
- After each test run, refresh the Latest result and Defects columns from the run report.
- When a requirement is removed, retire its scenario too, so backward traceability stays clean.
- Review the whole matrix once per release, with one named owner.
Using the RTM for Gaps and Release Sign-off
A sign-off check in four questions
Sort by priority and status so the riskiest open rows are at the top. Attach the matrix and each run's PDF report to the sign-off, and the release decision comes with its evidence. For the full release checklist, see the Release Readiness Checklist.
Common Questions
Is a traceability matrix only for regulated industries?
Regulated teams in health, finance and automotive rely on it for audits, but any team benefits. A small RTM is the quickest way to answer "is this release fully tested?" with evidence instead of a feeling.
Should each row be a requirement or an acceptance criterion?
Start with one row per requirement or user story. Split a row into its acceptance criteria only where a requirement is high risk or keeps failing, so the matrix stays small enough to maintain.
Who should maintain the RTM?
Give it one owner, usually the QA lead for the release. Testers update results after each run, and the owner reviews the gaps and statuses before sign-off.
Does Evaficy Smart Test create the traceability matrix for me?
Evaficy Smart Test keeps the links that fill the matrix: requirement text saved with each scenario, Test Plan coverage, per-case run results with CSV and PDF export, and defects linked to scenarios. You assemble the matrix itself in a spreadsheet or your requirements tool.
How is an RTM different from test coverage?
Test coverage is a measure of how much is tested. The RTM is the evidence behind that measure: it names each requirement and shows the exact tests, results and defects attached to it.
Key Takeaways
- A requirements traceability matrix maps each requirement to its tests, latest results and linked defects.
- Forward traceability proves coverage; backward traceability keeps the suite lean; a good RTM supports both.
- Eight columns cover most teams: ID, requirement, priority, scenario, cases, latest result, defects and status.
- Put the requirement ID first in the scenario name and the requirement text in the Requirement field.
- Test Plan coverage, run reports and defects linked to scenarios fill the matrix.
- Read the matrix before every release: every requirement tested, every failure decided, every defect accepted or fixed.
Trace every requirement to a tested result
Create your free account to save a scenario per requirement, keep the requirement text with it, and build your matrix from real results.
Create your free account