This requirements traceability matrix template finds uncovered requirements, tests without a source requirement, and links that need review after a change. The worked example includes all requirements, test descriptions, and mappings, so you can inspect the findings yourself.
Give requirements and tests stable identities
The original fictional example is a badge-preview interface. Its current requirement set is:
| Requirement | Current text |
|---|---|
| R1 v2 | The attendee-name field accepts 1–40 characters. R1 v1 previously allowed 1–20. |
| R2 v1 | Editing the attendee name clears an existing badge preview until it is rebuilt. |
| R3 v1 | The badge preview displays the supplied event title. |
Its three planned test descriptions are:
| Test | Description and currently recorded source link |
|---|---|
| TC1 v1 | Enter a 25-character name and expect rejection. Linked to R1 v1. |
| TC2 v1 | Build a preview, edit the name, and check that the old preview clears. Linked to R2 v1. |
| TC3 v1 | Check that a theme preference is remembered. No source requirement is recorded. |
All items are invented teaching records. No badge application has been built or tested for this guide, and no result evidence is supplied. The names and versions make the mapping exercise concrete without implying a real software test run.
Historical NASA Software Engineering Handbook guidance on bidirectional traceability explains tracing links back to their sources and forward into related development and verification items. It also discusses source-less elements and change impact. Those principles inform this small example; the template is not a claim of NASA compliance or a current certification rule.
Read the matrix as a set of review questions
| Current requirement | Recorded linked test | Mapping review | Execution evidence |
|---|---|---|---|
| R1 v2 | TC1 v1 references R1 v1 | Stale requirement-version link; inspect the changed name-length boundary. | None supplied; not executed here. |
| R2 v1 | TC2 v1 references R2 v1 | Current link; inspect whether the test adequately checks the requirement. | None supplied; not executed here. |
| R3 v1 | No linked test | Uncovered in this supplied mapping. | None supplied. |
TC3 appears in a separate Tests without a requirement list. Its missing source is a question for the owner, not proof that the test is useless. There could be an omitted requirement, an approved nonfunctional source, or a test that no longer belongs. Find the basis before deciding what to keep.
Choose Review supplied links in the example. The worked findings should identify R1's stale version, R3's missing test, and TC3's missing source. It should not label R2 as a passed requirement merely because TC2 points to the current version.
Follow the changed rule into the test
Select R1 v2. Compare the previous 20-character maximum with the new 40-character maximum, then read TC1's expected rejection of a 25-character name. Under the supplied new rule, that input falls within the accepted range. The expected rejection needs review.
Changing the link text from v1 to v2 would hide the mismatch without repairing the test. Review the test input and expected result, identify any other affected cases, and record a new test revision through the team's process. A test for the old maximum may need replacement or a different boundary check.
Keep an explanation beside a proposed link. “Exercises the upper name-length boundary” is useful to a reviewer; “related test” leaves the relationship unexamined. A requirement can need several tests, and a test can cover several requirements. Record those links explicitly rather than packing unrelated IDs into an unexplained cell.
Keep mapping coverage separate from results
The matrix answers where verification is planned or recorded. A result needs its own identity: test version, requirement version or baseline, build, environment, observation, and evidence reference. A link alone supplies none of those observations.
When a requirement changes, retain earlier result records with the versions they actually tested. Ask which mappings and tests need review; do not relabel an old result as proof for the new rule. The current example leaves all execution references blank because no execution evidence exists.
After reviewing the findings, the team might write a test for R3, resolve TC3's source, and revise TC1. Those are proposed next actions. They become updated coverage only when the maintained records actually contain the new items and reviewed links.
Copy a prompt for the matrix and impact review
Create one complete HTML requirements-traceability review page.
Current requirements with stable IDs, versions and text: [PASTE]
Tests with stable IDs, revisions, descriptions and expected behavior: [PASTE]
Recorded links and the requirement versions they reference: [PASTE]
Change history, rationale and actual result/evidence records: [PASTE]
Owners and review conventions: [PASTE]
Use only supplied records. Trace from requirements to tests and
back from tests to requirements. Keep version identity and link
rationale visible. Identify uncovered requirements, source-less
tests and stale version links without silently repairing them.
Coverage links do not establish execution or pass status.
Include this separate original fictional badge-preview example:
Current R1 v2: attendee name accepts 1–40 characters. Previous
R1 v1 accepted 1–20. R2 v1: editing attendee name clears an
existing preview until rebuilt. R3 v1: preview shows event title.
TC1 v1: enter a 25-character name, expect rejection; link R1 v1.
TC2 v1: build preview, edit name, check old preview clears;
link R2 v1. TC3 v1: theme preference remembered; no source link.
No software has been built/tested for this exercise. All execution
and evidence references remain blank; no historical pass supplied.
Review supplied links must identify:
R1 v2/TC1 v1 stale target version and obsolete 25-character rejection.
R3 v1 uncovered in supplied mapping.
TC3 v1 without recorded source requirement, requiring human review.
R2 v1/TC2 v1 current mapping, not a passed test.
R1 selection shows old 20/new 40 maximum and the TC1 expectation.
Explain why renaming its link v2 alone is insufficient; the test
expectation/revision needs review. Do not invent revised tests,
source requirements, approvals or results to make findings disappear.
Keep planned mappings separate from actual result records. An actual
result would need test/version, baseline, build, environment,
observed behavior, evidence; do not fabricate these fields.
Provide complete requirement/test lists, matrix, reverse orphan
list, Review supplied links and selected-requirement impact view.
Add a blank scaffold and temporary reviewer-notes area. Preserve
typing across views and ask before reset. No test runner, automatic
link repair, release/standard compliance or passed coverage badge.
Use at least 16px text, labeled native controls, visible focus and
stacked records at 360px without overflow. Inline CSS/JavaScript,
no external assets, network or storage. Return complete HTML and
the source/link questions still requiring a person's decision.
Check the generated findings against every supplied ID. A useful review preserves TC3 for investigation and keeps TC1 attached to the old version it actually references. It does not make the matrix look cleaner by dropping inconvenient records.
Let a reviewer inspect the link and its reason
Put the HTML review copy in your NOS workspace when a requirement owner and tester need to read the changed rule beside the affected case. Ask them whether TC1's input and expected result still test what the current requirement says.
You can clarify a static explanation such as “old length rule” to “R1 v1 allowed at most 20 characters” in visual editing mode. Save the correction so colleagues can reopen the existing link and read it. Update the maintained mapping and test records through their actual process; changing an explanatory label does not revise a test or rerun it.
Record the agreed change, its affected links, and the next verification work. Return to the matrix after those records are updated to see which coverage questions remain.