Requirements / Test coverage / Product documentation
Requirements traceability matrix: a worked brief-to-test template
Build a requirements traceability matrix with a worked example, reusable columns, coverage calculations, and links from product decisions to test evidence.
At a glance
A requirements traceability matrix connects each requirement to its source, implementation work, verification, and recorded result. Use it to identify missing coverage and assess changes in both directions. A linked test shows planned coverage; only a relevant execution and its evidence show what was actually verified.
A requirements traceability matrix helps answer a practical release question: for each behavior we agreed to deliver, where is the implementation and what evidence verifies it? It also works in reverse. When a test fails or a requirement changes, the links show which work and decisions need another look.
The matrix can be a small table supported by links to issues, test cases, and runs. Its usefulness comes from the accuracy of those connections. A large spreadsheet full of stale references can make a release look documented while leaving the important questions unanswered.
This guide provides a reusable template and an illustrative bulk-archive feature in an imaginary application. The requirements, record labels, and coverage calculations are examples. They are not a claim that Leera offers that particular bulk-archive feature or that these checks have run.
Decide what each link is supposed to prove
Forward traceability follows a requirement into implementation and verification. Backward traceability asks which requirement justifies a piece of work or a test. Both are useful when a team needs to distinguish necessary behavior from accidental scope.
The NASA Software Engineering Handbook describes bidirectional relationships among requirements, design, code, verification, and non-conformances in its engineering context. A software team can use that linking principle without claiming that a simple matrix satisfies NASA requirements or certifies its product.
Keep three kinds of evidence distinct:
| Record | What it establishes | What it does not establish |
|---|---|---|
| Requirement | Agreed intended behavior | That the implementation follows it |
| Test procedure | A proposed way to check behavior | That the check has been executed |
| Execution result | What happened for a recorded build and context | That every other behavior is correct |
A closed implementation issue is useful project information. It cannot replace an execution result. Similarly, a screenshot without a build, procedure, and expected result may be difficult to interpret later.
Start from a brief with a bounded outcome
Our imaginary product lets project leads archive completed items so the active list is easier to review. The brief excludes deleting records and changing another project’s work. It also says that an unsuccessful operation must not be presented as a complete success.
That description still contains decisions. Who counts as a project lead? Can active items be archived? What should happen when one selected item changes state before the request completes? What recovery behavior is promised?
Resolve those questions before filling in test links. A matrix cannot repair an ambiguous requirement merely by assigning it an ID. If a decision remains open, record an owner and make the affected work visibly unready.
For this example, the team agrees on four requirements:
- REQ-01: authorization. Only an authorized project lead can submit the archive operation for that project.
- REQ-02: scope. The operation affects only selected completed items in the specified project.
- REQ-03: outcome. The response identifies which selected items were archived and which were refused; the interface reflects those outcomes.
- REQ-04: recovery. An authorized project lead can restore an archived item to the active list without changing its completion state.
These are example policy choices. In a real product, link each requirement to the reviewed brief or decision that establishes it.
Copy a small template and populate the missing links
Use stable identifiers instead of row numbers, which can change whenever a table is sorted. References such as “Implementation A” and “Case 01” below stand for links to your actual records; they are deliberately not live issue keys.
| Requirement | Source and acceptance criterion | Implementation | Verification |
|---|---|---|---|
| REQ-01 | Brief: only authorized leads can archive | Implementation A: permission check | Case 01: allowed role; Case 02: denied role |
| REQ-02 | Brief: selected completed items in this project only | Implementation B: selection and state checks | Case 03: selection; Case 04: invalid or foreign item |
| REQ-03 | Decision note: each selected item has an explicit outcome | Implementation C: response and message | Case 05: mixed successful and refused items |
| REQ-04 | Brief: restore without changing completion state | Implementation D: restore operation | Missing; assign a case owner |
Keep results in a linked execution table so a new run does not overwrite the meaning of an earlier one:
| Requirement | Run and build | Observed result | Evidence or gap |
|---|---|---|---|
| REQ-01 | Not run | No execution result | Cases prepared only |
| REQ-02 | Not run | No execution result | Cases prepared only |
| REQ-03 | Not run | No execution result | Cases prepared only |
| REQ-04 | Not run | No execution result | No verification procedure yet |
This first version already reveals something useful: recovery has implementation work but no planned check. That gap deserves an owner before the matrix gains more columns or formatting.
Review the substance of each test connection
One requirement often needs several tests. Authorization needs both an allowed and a denied path. Scope needs checks for selected items, unselected items, incompatible state, and another project where relevant. A single successful click cannot establish all of that.
One case may support several requirements if it verifies each explicitly. For example, a mixed-result case could check that only eligible items changed and that the response describes the refused items correctly. Link both requirements only when the expected results cover both questions.
Inspect the test procedure, not just its title. A case named “Verify permissions” may only check that a button is hidden. If the requirement concerns an operation, verify the permission boundary where the operation is accepted or refused as well.
Remove decorative links. If an implementation task is attached to every requirement because it “touches the feature,” reviewers cannot identify the affected scope when something changes. Prefer specific relationships that another person can explain.
Calculate coverage without confusing it with success
In the first table, three of four requirements have a proposed verification case. The illustrative planned coverage is therefore 3 divided by 4, or 75%. None has execution evidence yet.
Adding a recovery case raises planned linkage to 100%. It does not mean the product passed. A case could be blocked, unsuitable, or not executed against the candidate build.
Report the question alongside the metric:
- Planned coverage: how many in-scope requirements have reviewed verification procedures?
- Execution coverage: how many received the intended checks for this release context?
- Results: what passed, failed, was blocked, or was not run?
- Residual risk: which important behaviors remain uncertain, and who owns the decision?
Be explicit about the denominator when scope changes. Removing an untested requirement from a spreadsheet can improve the percentage while concealing a product decision. Record why it left the release and what happens to its implementation and promised behavior.
Preserve the context of an execution
Attach the application build or commit, environment, relevant configuration, and date to each run. Include dataset or role details when they affect the check. “Passed in staging” is insufficient when staging changes several times during a release review.
Preserve the procedure associated with the result. In Leera QA, a run keeps case snapshots, so later changes in the library do not rewrite what the run captured. If a requirement changes, decide which results still apply and create the necessary new execution.
Keep a failure connected to its defect, then record the follow-up result after the fix. A developer resolving the defect is a handoff for verification, not evidence that the original symptom is gone.
For a completed Leera run, a test manager can create a frozen test report with a verdict and optional review and approval. The report records the submitted results; the team still needs to assess whether the selected checks answer the release question.
Use backward links when requirements change
Suppose the example team changes REQ-02 to allow archiving active items as well as completed ones. Start from the requirement and inspect the selection logic, Case 03, Case 04, the mixed-result behavior, and any wording that says active items will be refused.
Then inspect the reverse direction. Does the recovery behavior still make sense? Does the documentation distinguish archived state from completion state? Are any tests now enforcing a rule that the product deliberately removed?
Keep the old requirement context with the earlier release evidence. Mark the new requirement version and its affected work rather than editing history until an old passing result appears to verify the new policy.
This is where a small, maintained matrix repays its cost. It turns “we changed one sentence” into a reviewable list of consequences without pretending that a link automatically identifies every consequence.
Fit maintenance into the team’s existing workflow
Assign responsibility for keeping links current when work is created, requirements change, and a release is reviewed. Product owns the intended behavior; engineers and testers help establish implementation and verification connections. One person can coordinate the matrix without becoming the only person able to interpret it.
In Leera, keep the reviewed brief in Documents, record acceptance criteria in Planner issues, and link QA cases to the issues they verify. Use a project document for this template and release notes for the relevant run and report references. This is a practical arrangement of existing records, not a separate automatic matrix feature.
Start with one release slice and ask a teammate to follow a row from the original decision to its latest evidence. If the path is understandable and missing coverage is visible, the matrix is doing useful work. Continue with the QA test management guide for case, plan, and run practices. The NASA reference was checked on October 11, 2026.
Frequently asked questions
What is a requirements traceability matrix?
It is a table or equivalent set of maintained links connecting requirements with their source, implementation, verification, and results. It helps a team find requirements without checks, work without a clear purpose, and the records affected by a changed requirement.
What columns should a traceability matrix include?
Start with a stable requirement ID, source or brief reference, concise acceptance criterion, implementation reference, verification reference, and result with execution context. Add owner, risk, version, or decision fields when they answer a real review question. Keep detailed procedures in their test cases rather than copying them into every row.
Does 100% requirements coverage mean a release is ready?
No. A coverage percentage may only mean that every requirement has a linked test. It does not establish that the tests are sufficient, ran against the release candidate, passed, or cover important risks. Report planned coverage, execution, results, and accepted gaps separately.
Can one test cover more than one requirement?
Yes, if the test contains a meaningful assertion for each linked requirement. Likewise, one requirement may need several tests for roles, boundaries, or failure paths. Avoid adding broad links simply to make a coverage report look complete.
How do we maintain traceability in Leera?
Keep the brief in Documents, acceptance criteria in Planner issues, and verification cases linked to those issues in QA. Plans select coverage and runs retain execution snapshots and results. You can maintain the template in a project document; this guide does not describe a separate automatically generated traceability-matrix feature.