Generate the Traceability Matrix and Hunt the Orphans

Workflow area: Requirements Quality · Tier: Core · Hands-on time: ~35 minutes

A traceability matrix answers two questions that decide whether a project is under control: does every requirement serve a stated objective, and does every requirement have a test that would prove it delivered? The matrix itself is pure derivation — every link already exists implicitly in your BRD, story export and test plan — which is why it is the perfect AI task: no judgment in the generation, all judgment in the exceptions. Orphan requirements (serving no objective) are scope creep wearing a requirement ID; untested requirements are promises nobody will check; tests tracing to nothing are effort spent verifying the void. The model builds the table and surfaces the exceptions; you disposition them. And because generation is now cheap, the matrix stops being a sign-off artifact produced once and abandoned — it regenerates at every change and stays true.

When to use — and when not to

• Use it once requirements and tests both exist with IDsthe matrix needs artifacts to link; before test design, run coverage thinking through pb-34 instead.
• Use it at every stage gate and audita regenerated matrix with dispositioned exceptions is exactly the evidence governance forums and auditors ask for.
• Use it after every CR roundchanges orphan requirements and strand tests silently; regeneration makes the damage visible the same day (pair with pb-22).
• Skip hand-maintaining what you can regenerateif you are editing matrix cells by hand, you have built a second source of truth that will drift; fix the source artifacts and regenerate.
• Skip it when IDs are unstableif requirements are still being renumbered daily, generate throwaway matrices for insight but do not publish; a matrix over shifting IDs is noise with columns.
• Skip the theatera matrix nobody acts on is compliance decoration. If orphans and gaps do not become backlog items, stop generating and fix the process first.

The recipe

1. 1.

   Export the three layers with IDs. Objectives (from the BRD, OBJ-x), requirements (BR-x / stories with keys), and test cases (TC-x from Jira/Xray/ADO, with their claimed requirement links if any). CSV or markdown — structure matters more than format. Include the scope statement so the model knows what "in scope" means.

2. 2.

   Run the generation with structured output. Paste into Claude or ChatGPT (or drive an LLM API with a JSON schema for pipeline use):

   Copy

   You are building a requirements traceability matrix.
   Layers: objectives, requirements, test cases (below, with IDs).
   
   TASK 1 — MATRIX. Output a table:
   Requirement ID | Requirement (short) | Traces up to (objective
   IDs) | Traced by tests (TC IDs) | Status
   Status is one of: FULL (≥1 objective AND ≥1 test) / NO-TEST /
   NO-OBJECTIVE / ISOLATED (neither).
   
   TASK 2 — EXCEPTIONS. List:
   - ORPHAN REQUIREMENTS: no objective. Quote the requirement.
   - UNTESTED REQUIREMENTS: no test case.
   - ORPHAN TESTS: test cases tracing to no requirement.
   - SUSPECT LINKS: links you inferred from wording similarity
     rather than an explicit reference — mark each INFERRED with
     your reasoning in one line.
   
   Rules: use explicit references (IDs mentioned in text) first;
   only infer a link when wording clearly matches, and ALWAYS mark
   inferred links INFERRED. Never invent an ID. If an artifact's
   trace target is ambiguous, put it in SUSPECT LINKS rather than
   choosing silently.
   
   Objectives: [PASTE]
   Requirements: [PASTE]
   Test cases: [PASTE]
   

3. 3.

   Audit the links before trusting the exceptions. Good output looks like this:

   Copy

   BR-017 | Duplicate-invoice detection | OBJ-2 | TC-041, TC-042 | FULL
   BR-023 | Vendor portal branding    | —     | TC-055        | NO-OBJECTIVE
   BR-029 | 45-day payment SLA alert  | OBJ-1 | —             | NO-TEST
   
   ORPHAN TESTS: TC-070 "legacy export regression" — no requirement
   references legacy export.
   SUSPECT LINKS: BR-017→TC-042 INFERRED (both mention "duplicate
   match rules"; TC-042 does not cite BR-017).
   

   Verify every INFERRED link at source — confirm it and make it explicit in the artifact, or sever it. Spot-check a sample of explicit links too; a matrix is only as good as its worst link, and explicit references can be stale.

4. 4.

   Disposition every exception with an owner. Orphan requirement: trace it to an objective it genuinely serves, get it deliberately descoped, or escalate it as scope creep — sponsor's call. Untested requirement: a test gets written (feed pb-34) or the risk of shipping unverified is signed for. Orphan test: retired, or it reveals an undocumented requirement that must be surfaced and decided. Every disposition is a log entry, not a mental note.

5. 5.

   Make regeneration the habit. Save the prompt (or the API script) beside the artifacts and regenerate after every CR, sprint, or test-plan update. Publish the matrix with its generation date and diff the exception list between runs — a growing orphan count is an early-warning indicator no status report will give you.

Make it yours

• LLM API + JSON schema for programs at scale: emit the matrix as structured output, load it into a spreadsheet or dashboard, and diff runs mechanically; the exception trend becomes a standing quality KPI.
• Jira/ADO native links as the backbone: where story-to-test links live in the tool, export and let the model handle the layer tools miss — objectives — and the narrative exception report.
• ReqView/DOORS-class estates: formal RM tools own the links; use the model to audit their exports for suspect and stale links and to draft the exception narrative for governance packs.
• Lightweight mode for small projects: one sheet, three columns, same prompt monthly — the ritual of dispositioning exceptions matters more than the tooling.

Quality check

• Every INFERRED link was verified or severedno inferred link survives unreviewed, and confirmed ones were written back into the source artifact as explicit references.
• No invented IDsevery ID in the matrix exists in the exports; sample-check, because a fabricated TC number in a governance artifact is a credibility fire.
• Every exception has a disposition and an ownertraced, descoped, test-written, retired, or risk-accepted with a name; "noted" is not a disposition.
• Orphan requirements went to the sponsorscope-creep candidates are a business decision, not an analyst's quiet cleanup.
• The matrix regenerates from sourceno hand-edited cells; fixes were made in the artifacts and the matrix rebuilt, keeping one source of truth.
• Generation date and version are on the artifacta matrix without a date is presumed stale, because it usually is.