Requirement Traceability Matrix
Imagine a project manager asks you a simple question: "Are we sure every requirement for RecipeBox v2.0 actually got tested?" Without a system for answering that, you're stuck scrolling through test case documents trying to remember. A Requirement Traceability Matrix (RTM) exists to answer that exact question instantly, on paper — it maps every requirement to the specific test case(s) that verify it, so coverage is provable rather than assumed.
Why an RTM Matters
| Problem without an RTM | How an RTM fixes it |
|---|---|
| A requirement quietly has zero test cases covering it | Any row with an empty "Test Case ID(s)" column is an instantly visible coverage gap |
| A requirement changes mid-project and nobody updates the related tests | You can find every test case tied to that requirement and review them in one place |
| Auditors, clients, or managers ask "prove this was tested" | The RTM row is the proof — no digging required |
| Team is unsure whether it's safe to remove/skip a test case | Check if that test case is the only one mapped to a requirement before touching it |
Worked Example: RTM for RecipeBox
Below is a small but realistic RTM for a handful of RecipeBox requirements. The "Test Case ID(s)" column references test cases of the kind you'd have written earlier in this track (in Writing Effective Test Cases) — each ID stands for a full test case with its own steps, expected result, etc.; here we just show the mapping.
| Req ID | Requirement | Test Case ID(s) | Status |
|---|---|---|---|
| REQ-01 | User can add a new recipe with title, ingredients, steps, optional photo, category, and prep time | TC-101, TC-102, TC-103 | Covered |
| REQ-02 | User can search for recipes by title from the Recipe List screen | TC-201, TC-202 | Covered |
| REQ-03 | Prep time must be a positive number of minutes; non-positive or non-numeric values must be rejected | TC-104, TC-105, TC-106 | Covered |
| REQ-04 | User can edit an existing recipe and save changes, including changing its category | TC-301 | Partially covered |
| REQ-05 | User can log in with a valid username and password, and is blocked with an error on invalid credentials | none | Gap |
Reading the Gaps
The value of this table isn't the rows that say "Covered" — it's the two that don't:
- REQ-04 (edit recipe) — Partially covered. TC-301 likely tests the basic "edit title and save" flow, but the requirement also explicitly mentions changing the category. If there's no test case for "edit a recipe's category and confirm it saved correctly," that's a real, specific gap — not a vague feeling that "editing needs more testing," but a precise missing test case to go write.
- REQ-05 (login) — Gap. Zero test cases map to this requirement at all. Maybe login testing exists somewhere and just never got logged with a Test Case ID, or maybe it was genuinely overlooked because everyone assumed "login is old, it's fine." Either way, the RTM is what surfaces it — before a user finds it, not after.
When to Build and Update an RTM
| Point in the project | What happens to the RTM |
|---|---|
| Requirements are finalized | Create the RTM skeleton — one row per requirement, "Test Case ID(s)" column still empty |
| Test cases are written | Fill in the mapping as each test case is written against a requirement |
| Before the exit criteria checkpoint (see the Test Plan lesson) | Review the RTM specifically for "Gap" rows — this is often a formal exit-criteria check on its own |
| Mid-project requirement changes | Revisit every test case mapped to the changed requirement to confirm it's still valid |