FREE REQUIREMENTS TRACEABILITY AND UAT PRACTICE
Requirements Traceability Matrix and UAT: Find the Coverage Gap
A requirements traceability matrix (RTM) links a requirement to the checks intended to verify it. User acceptance testing (UAT) then helps responsible users evaluate whether the delivered behavior meets the agreed business need. A link in a matrix is evidence of planning; a passing result needs an actual execution record.
This original fictional exercise continues the Harbor Community Studio business requirements document example. No booking software is implemented here. Every execution status starts as NOT RUN; none of the expected results below is a test pass or stakeholder sign-off.
1. Establish the baseline before counting coverage
Draft v0.1 allows an active signed-in member to reserve an offered future slot for Projector-A. Slots last 60 minutes, start on the hour from 10:00 through 15:00 UTC and have capacity one. Requests use server receipt time on 12 November 2026. In v0.1, a request must arrive before slot start; there is no 30-minute notice rule yet.
- BR-01: membership, offered-slot and booking-time eligibility.
- BR-02: at most one confirmation per asset and slot, even with concurrent requests.
- BR-03: understandable outcomes, persistent own-booking confirmation and no disclosure of another member's identity in an availability refusal.
Keep requirement IDs stable across the BRD, matrix, test cases and defect records. Include the document version being evaluated. Without a shared baseline, two people can attach the same test ID to different rules.
2. Inspect an intentionally incomplete matrix
The six acceptance criteria below come from the BRD. A dash means no planned test is linked. Before reading the answer, identify which criterion is missing and explain why another row cannot stand in for it.
| Requirement | Criterion | Behavior to check | Planned test |
|---|---|---|---|
| BR-01 | AC-01 | Eligible request for an empty future slot | UAT-01 |
| BR-01 | AC-02 | Inactive membership refusal without a booking | UAT-02 |
| BR-01 | AC-03 | Refusal at or after slot start | UAT-03 |
| BR-02, BR-03 | AC-04 | Occupied-slot refusal; preserve booking and privacy | UAT-04 |
| BR-02 | AC-05 | Two concurrent valid requests, one confirmation | — |
| BR-03 | AC-06 | Own confirmation survives reload | UAT-06 |
Show the coverage answer and missing-case rationale
Expected answer: AC-05 has no linked test. All three business requirements have at least one link, so requirement-level mapping is 3/3. Acceptance-criterion mapping is only 5/6, about 83.3%. Neither number establishes executed coverage or product quality.
Missing-case rationale: UAT-04 starts after a reservation exists. It cannot establish what happens when two requests both evaluate an empty slot before either completes. Add UAT-05 to AC-05. A generic test named “booking works” would hide that distinction.
Once UAT-05 is linked, acceptance-criterion mapping becomes 6/6. That is complete mapping for this small supplied list, not proof that the list is complete. Unoffered slots, failed identity checks, unavailable dependencies and other risks still need review.
3. Write executable instructions, including the state to preserve
Reset the fictional data between independent tests. Use two distinct active members for conflict cases and an inactive member for UAT-02. Confirm the offered-slot list and server clock in the eventual test environment. The steps below are a test design; the guide does not run them.
| Test | Criterion | Setup and action | Expected result |
|---|---|---|---|
| UAT-01 | AC-01 | An active member requests the empty 11:00 slot at 10:00. | One confirmation and reservation ID; exactly one stored booking for that slot. |
| UAT-02 | AC-02 | An inactive member requests the empty 12:00 slot at 10:00. | Eligibility refusal; zero new bookings and unchanged slot occupancy. |
| UAT-03 | AC-03 | In separate reset runs, an active member requests the empty 14:00 slot at 14:00:00 and at 14:00:01. | Both requests are refused; each leaves zero bookings in its reset run. |
| UAT-04 | AC-04 | Member A already reserved 11:00. Member B requests that same slot at 10:01. | Availability refusal; A's original reservation ID is unchanged; B sees no identifying details about A. |
| UAT-05 | AC-05 | Coordinate two active members' requests for the empty 13:00 slot at 10:00 so their processing overlaps. | Exactly one confirmation and one availability refusal; exactly one stored booking for the slot. |
| UAT-06 | AC-06 | Complete UAT-01, retain its reservation ID, then reload as that member and open their own bookings. | The same reservation ID and 11:00–12:00 slot remain visible. |
UAT-06 intentionally depends on UAT-01 rather than starting from empty data. For UAT-05, ask the technical team to arrange and evidence overlapping processing; opening two tabs is not proof of concurrency. Combine a business-visible result with appropriate technical verification of stored state. Do not record a pass based solely on two similar screenshots.
4. Keep planned coverage separate from execution evidence
For each run, record the test ID, baseline version, build, environment, tester, timestamp, input data, actual result, evidence reference and any defect ID. Use safe fictional test data. A result can be PASS, FAIL or BLOCKED only when its evidence supports that status; otherwise keep NOT RUN.
For example, if the test environment cannot coordinate overlapping processing, record UAT-05 as BLOCKED with that reason once an attempted run is blocked. Do not substitute a sequential run and label AC-05 passed. A resolved defect needs a linked retest; deleting the old failure would lose the decision history.
After completing the matrix on paper, the expected execution summary is still zero tests executed and zero recorded passes. A business owner would also need to review unresolved risks and the agreed acceptance process before approving a real release.
5. Assess change CR-01 before editing the baseline
The coordinator now proposes: “Receive the request at least 30 elapsed minutes before slot start.” For this exercise, the equality boundary is included. Treat this as proposed change CR-01 for v0.2; no approval has been recorded.
- Identify the business requirement and acceptance criteria whose rule changes.
- Predict the time decision for each case below, assuming active membership, an offered empty slot and no competing request.
- Name existing tests to review, new tests to add and previous evidence that cannot prove the changed behavior.
| Case | Server receipt | Time remaining | Expected v0.2 time decision |
|---|---|---|---|
| C01 | 10:29:59 | 30 minutes 1 second | Eligible |
| C02 | 10:30:00 | 30 minutes exactly | Eligible |
| C03 | 10:30:01 | 29 minutes 59 seconds | Refuse |
| C04 | 11:00:00 | Zero | Refuse |
Compare the expected change-impact answer
Affected rule: revise BR-01, AC-01 and AC-03 together. AC-01 now requires at least 30 minutes of lead time. AC-03 must cover refusal below 30 minutes, including equality with or passage beyond slot start. Retain their stable IDs and record the new version and change rationale.
New boundary checks: add UAT-07 for C01 and C02 as separate reset runs, linked to AC-01. Add UAT-08 for C03, linked to AC-03, expecting a 30-minute-rule explanation and no new booking. UAT-03 already covers C04 and a post-start request; review its expected explanation under the new rule.
Existing checks: UAT-01 remains a positive case because its 10:00 request has 60 minutes of notice. UAT-02, UAT-04, UAT-05 and UAT-06 retain their purpose, but review their preconditions and rerun the relevant regression checks against v0.2. Check customer-facing policy text and refusal messages too.
Why the missing case matters: C03 was time-eligible under v0.1 but becomes ineligible under v0.2. Testing only requests at or after slot start would miss this changed behavior. C02 distinguishes “at least 30 minutes” from “more than 30 minutes.” A prior pass from another build or rule version cannot demonstrate the revised boundary.
6. Maintain a useful matrix rather than a decorative checklist
Your working matrix can add requirement version, risk, test owner, execution status, evidence and defect links to the four columns shown above. Keep expected and actual results separate. When a requirement changes, follow its links in both directions: which checks need revision, and which checks no longer correspond to an agreed requirement?
For your next attempt, introduce an unoffered 16:00 start time. It falls outside the supplied slot list even if requested hours early. Propose a distinct eligibility test linked to BR-01, state the expected refusal and explain why the 30-minute checks do not cover offered-slot validation.
Review the BRD and copyable outline, practise a smaller requirements and acceptance-criteria example, or explain your reasoning with the interview practice guide. Explore all BA resources or the free demo. Sales remain closed.