Uwayxt A requirement without a trace is a requirement that will be forgotten. Every user story, acceptance criterion, and feature in the PRD must map to exactly one or more UI elements — or be explicitly marked as not yet implemented.
1. Parse the PRD
Extract every requirement. Isolate the minimum unit: one user story or acceptance criterion. Assign each a unique ID (US-001, AC-001, etc.) if not already numbered. Record:
- ID
- Requirement text (one sentence)
- Category (functional / non-functional / UX / business rule)
- Priority (must-have / should-have / nice-to-have)
2. Map to UI elements
For each requirement, identify:
- Which page/screen implements it
- Which component handles it (button, form, table, etc.)
- Which route is involved
- Which function/handler is responsible (if known)
3. Assign implementation status
Determine current status against four discrete states:
DONE: implemented and verifiedIN_PROGRESS: partially implementedNOT_STARTED: not yet implementedDEFERRED: explicitly deferred to later phaseBLOCKED: cannot proceed (dependency or decision needed)
4. Identify gaps
Locate requirements with status NOT_STARTED that are must-have priority. Flag them explicitly as blockers. Requirements with no UI mapping at all are critical gaps.
5. Generate the matrix
Output as a structured table based on MATRIX-TEMPLATE.md. Treat the matrix as a living document. Update it every time a feature is completed.
6. Link to downstream QA
Feed this matrix to the qa-feedback-loop-orchestrator as the authoritative source for "which PRD requirement does this bug violate?". Never let the QA loop report a bug without citing its PRD requirement ID.
Completion Criteria
- Every PRD requirement has a unique ID
- Every requirement has a status (no blank status cells)
- Every must-have requirement is either DONE or explicitly flagged
- All gaps are documented with rationale
- Matrix is saved as a file in the workspace
Output
prd-traceability-matrix.md— structured table with columns: ID | Requirement | Category | Priority | Screen/Page | Component | Route | Status | Notes
Anti-patterns
- Writing requirements as vague goals instead of testable statements
- Not assigning IDs — makes cross-referencing in QA loop impossible
- Treating the matrix as a one-time artifact — it must be updated continuously
- Marking requirements as DONE based on visual inspection without functional verification
- Including implementation details in the requirements column (the matrix captures WHAT, not HOW)