Why this matters
- Prove that every requirement is implemented and tested (coverage).
- Assess change impact quickly: what stories, tests, and components are affected.
- Spot gaps early: orphan stories, missing acceptance criteria, or untested requirements.
- Support audits and compliance with a clear trace from need to validation.
Concept explained simply
Worked examples
Example 1: Checkout speed objective
Objective (OBJ-01): Reduce average checkout time by 30%.
Business Requirement (BR-01): Enable one-click payment for returning users.
Epic: One-Click Checkout.
User Story (US-101): As a returning shopper, I can pay with a saved card in one click.
Acceptance Criteria (AC):
- AC1: One-click button visible when a default payment method exists.
- AC2: Payment succeeds with no additional form fields.
- AC3: Transaction time under 2 seconds for 95% of cases.
Test Cases:
- TC-01 covers AC1 and AC2 (happy path).
- TC-02 covers AC3 (performance test).
Trace slice: OBJ-01 β BR-01 β Epic β US-101 β AC1/AC2/AC3 β TC-01/TC-02.
Example 2: Accessibility compliance
Non-Functional Requirement (NFR-05): Conform to WCAG level AA for checkout pages.
Epic: Accessible Checkout.
User Story (US-202): As a screen reader user, I can complete checkout with labeled controls.
AC:
- AC1: All interactive elements have accessible names.
- AC2: Focus order follows visual order.
Tests:
- TC-10: Screen reader audit (AC1).
- TC-11: Keyboard navigation sequence (AC2).
Trace slice: NFR-05 β Epic β US-202 β AC1/AC2 β TC-10/TC-11. This demonstrates that non-functional requirements are also traceable.
Example 3: Backward traceability from a defect
Defect (BUG-77): One-click button shown without saved card.
Backward tracing: BUG-77 β linked Test TC-01 failed β AC1 violated β User Story US-101 β BR-01 β Objective OBJ-01. This path shows business risk and helps prioritize the fix.
Who this is for
- Business Analysts defining or validating user stories and acceptance criteria.
- QA Analysts ensuring test coverage against requirements.
- Product Owners tracking delivery against objectives.
Prerequisites
- Basic understanding of user stories and acceptance criteria.
- Familiarity with how your team stores requirements and test cases.
Learning path
- Learn the artifacts: Identify where business requirements, user stories, and tests live in your team.
- Define mapping rules: Decide required links (e.g., every story must link to exactly one parent requirement; every AC must be covered by at least one test).
- Create a simple RTM: Build a small Requirements Traceability Matrix for one feature (spreadsheet or tool links).
- Run a coverage review: Find orphans (unlinked items) and gaps (uncovered requirements).
- Scale and automate: Reuse templates and add traceability checks to your Definition of Ready/Done.
How to do it (quick steps)
- List the top-level requirements (business/system/NFR/objectives).
- Group stories under the correct parent requirement or epic.
- Ensure each acceptance criterion maps to at least one test case.
- Record links in your tool or a matrix with IDs.
- Review weekly: add, fix, or remove links as items change.
Exercises
Try these. Solutions are available in the exercise cards below.
Exercise 1: Build a mini RTM slice
Scenario: Requirement BR-12 "Support order cancellation within 30 minutes of purchase." You have:
- US-310: As a buyer, I can cancel an order from the order history within 30 minutes.
- US-311: As a buyer, I cannot cancel after 30 minutes and I see a clear message.
- AC for US-310: AC1 show "Cancel" if age <= 30 min; AC2 refund initiated automatically.
- AC for US-311: AC1 hide "Cancel" if age > 30 min; AC2 show message "Cancellation window passed".
- Tests: TC-21 happy path; TC-22 time boundary; TC-23 message display.
Your task: Create an RTM slice linking BR-12 β stories β AC β tests. Note any gaps.
- Expected: every AC linked to at least one test; each story linked to BR-12.
Exercise 2: Impact analysis
Change: The cancellation window changes from 30 to 45 minutes.
Your task: Identify which artifacts you must update and in what order. Note risks.
- Hint: Start from the changed requirement, then propagate down to stories, AC, tests, and any performance or notification rules.
Exercise checklist
- Every story has exactly one parent requirement (or a justified exception).
- Every AC is covered by at least one test.
- No orphan tests; every test traces to an AC or story.
- Changes propagate both forward and backward.
Common mistakes and self-check
- Orphan stories: Stories without a parent requirement. Self-check: filter stories with missing links; they should be zero.
- Unverified AC: Acceptance criteria not covered by tests. Self-check: count AC vs. linked tests; gaps must be addressed.
- Over-linking: Story linked to many unrelated requirements. Self-check: each story should primarily serve one requirement; secondary links need justification.
- Ignoring NFRs: Non-functional requirements not traced. Self-check: include NFR IDs in your RTM and ensure tests exist.
- Stale links: Requirements changed but links not updated. Self-check: whenever text of a requirement changes, trigger a link review.
Practical projects
- Create an RTM for one feature with 2β3 requirements, 4β6 stories, and 8β10 tests. Review with QA.
- Add traceability acceptance checks to your Definition of Ready/Done. Pilot for one sprint.
- Migrate an existing spreadsheet RTM to your work tracking tool using consistent IDs and required link types.
Quick Test
Take the quick test below. Available to everyone. Note: only logged-in learners have their progress saved automatically.
Next steps
- Adopt a simple, shared RTM template for your team.
- Schedule a 15-minute weekly traceability check during backlog refinement.
- Track a single metric: percent of requirements with complete coverage (stories + tests).
Mini challenge
Pick one real requirement from your current or past project. Map it to at least two stories, list AC for each, and identify or draft tests. Find and fix one gap. Timebox to 25 minutes and note your coverage percentage before and after.