---
name: requirements-traceability-matrix
description: Convert messy stakeholder interviews, discovery notes, BRDs, user stories, Jira exports, test notes, or regulatory requirements into a Business Analyst requirements traceability matrix. Use this whenever a Business Analyst needs to map business objectives to functional and non-functional requirements, acceptance criteria, test coverage, owners, gaps, conflicts, change impact, or sign-off readiness before handing work to product, engineering, QA, compliance, or implementation teams.
---

# Requirements Traceability Matrix

## Intended User Role

Business Analyst

## Workflow It Solves

Turn fragmented discovery and delivery inputs into a traceable requirements matrix that shows where each business need came from, how it maps to solution requirements, how it will be validated, who owns it, and what is still missing before approval or build handoff.

## Required Inputs

- Source material such as stakeholder interview notes, workshop notes, BRDs, FRDs, epics, user stories, Jira exports, process notes, compliance requirements, test scenarios, defect notes, or change requests.
- Project context if available: product area, release, process, customer segment, regulation, decision deadline, current scope, known constraints, or delivery phase.
- Stakeholder context if available: requester, approver, product owner, engineering owner, QA owner, compliance owner, support owner, or affected business unit.
- Desired output audience if available: product, engineering, QA, compliance, implementation partner, steering committee, or business sign-off group.

If source material is incomplete, proceed with labeled gaps. Ask a clarifying question only when the missing information changes scope, compliance exposure, approval readiness, or the ability to separate an actual requirement from an assumption.

## Expected Outputs

Produce a requirements traceability package with:

- Scope summary: project, source inputs, audience, traceability goal, and readiness status.
- Requirements traceability matrix with columns for ID, source, business objective, requirement statement, type, priority, owner, acceptance criteria, validation/test coverage, dependencies, status, and gaps.
- Gap and ambiguity log with missing evidence, unclear terms, conflicting requests, unowned requirements, and validation gaps.
- Conflict and change-impact notes when requirements compete, duplicate each other, or imply downstream design, data, testing, migration, training, compliance, or operational impact.
- Sign-off readiness assessment with evidence-based status and recommended next decision.
- Follow-up questions grouped by stakeholder or owner.
- Handoff note that the Business Analyst can paste into a delivery, QA, or stakeholder channel.

## Procedure

1. Identify the project or process, source artifacts, release or phase, audience, and decision the matrix should support.
2. Extract candidate business objectives before extracting detailed requirements. Objectives explain why the requirement exists and help identify orphaned features or gold-plating.
3. Normalize each requirement into one testable statement. Split combined requirements when a single sentence contains multiple behaviors, rules, data needs, permissions, integrations, reporting needs, or non-functional expectations.
4. Classify each requirement:
   - Functional: user behavior, workflow, data capture, approval, integration, notification, reporting, or system action.
   - Non-functional: performance, availability, security, privacy, accessibility, retention, auditability, usability, supportability, or compliance.
   - Business rule: policy, threshold, eligibility condition, exception, approval rule, calculation, or regulatory constraint.
   - Data requirement: source, field, validation rule, migration need, lineage, retention, or reporting dimension.
5. Assign a stable ID using short prefixes such as `BO-01`, `FR-01`, `NFR-01`, `BR-01`, and `DR-01`. Preserve source references such as ticket IDs, interview dates, document section names, or stakeholder names when available.
6. Link each detailed requirement to at least one business objective. If no objective is visible, mark it as `Unlinked` and add it to the gap log rather than inventing a rationale.
7. Derive acceptance criteria only from the provided evidence. When acceptance criteria are implied but not stated, label them as proposed and add the validation question needed for confirmation.
8. Map validation coverage:
   - `Covered` when a test scenario, acceptance criterion, inspection step, or measurable validation approach is present.
   - `Partial` when validation exists but misses edge cases, negative cases, roles, data, timing, compliance, or non-functional thresholds.
   - `Missing` when no validation path is visible.
9. Identify conflicts, duplicates, and change impact. Explain why the issue matters for scope, design, testing, operations, customer experience, compliance, or timeline.
10. Assess sign-off readiness:

- Ready: requirements are linked, owners are known, priority is clear, acceptance criteria are testable, and validation coverage is sufficient.
- Needs review: minor gaps or owner questions remain but scope is mostly stable.
- Not ready: material conflicts, missing objectives, unclear owners, untestable requirements, or compliance-critical gaps remain.

11. Draft follow-up questions by owner or stakeholder so the BA can close gaps without sending a generic request for clarification.
12. Keep the matrix concise enough to paste into a document or issue, but preserve the evidence trail needed for audit, QA, and stakeholder review.

## Quality Checks

Before finalizing, verify that:

- Each detailed requirement links to a source and at least one business objective, or is explicitly marked `Unlinked`.
- Requirement statements are testable and do not combine unrelated behaviors.
- Acceptance criteria are separated from requirements and labeled when proposed.
- Validation coverage is honest: do not mark a requirement covered just because a related test exists.
- Conflicts, duplicates, missing owners, unclear priority, and compliance-sensitive gaps are visible.
- The sign-off readiness assessment follows from the matrix, not from optimism.
- Follow-up questions identify the stakeholder or owner best positioned to answer them.
- The handoff note includes the readiness status, top risks, and specific asks.

## Example Task

User prompt:

```text
I am the BA on a claims portal update. Please turn these notes into a traceability matrix for product, QA, and compliance review.

Business goal from ops: reduce duplicate claim submissions by letting clinic admins see claim status before resubmitting. Compliance says we must keep an audit trail of every status lookup. Product wants this in the August release.

Stakeholder notes:
- Clinic admins need to search by patient ID and claim number.
- Search results should show status, last updated timestamp, denial reason if denied, and next action.
- Compliance asked whether PHI is masked for non-admin billing users.
- QA has a draft test for exact claim number search only.
- Engineering says status data comes from the payer integration and may be delayed up to 15 minutes.
- Support wants an error state when payer data is unavailable.
- Product says "fast enough for front desk use" but gave no SLA.
```

Expected behavior:

- Create a matrix linking the duplicate-submission goal and audit-trail need to functional, non-functional, business-rule, and data requirements.
- Split search, result display, audit trail, PHI masking, integration-delay, error-state, and performance expectations into separate traceable rows.
- Mark QA coverage as partial because exact claim number search does not cover patient ID, roles, denied claims, unavailable payer data, or audit trail.
- Surface gaps for PHI masking rules, performance SLA, owner decisions, compliance sign-off, and integration-delay wording.
- Assess sign-off as not ready or needs review with rationale.
- Draft targeted follow-up questions and a paste-ready handoff note.