Requirements Traceability Matrix

01 Purpose & how this matrix is built

On a $99M, three-year, three-workstream AI transformation, the requirements do not live in one document — they live in three BRDs written for three different parts of the business, each with its own AI models, its own regulatory drivers and its own delivery team. That separation is correct: a claims prior-authorization requirement and an underwriting-risk requirement should not be forced into one document to satisfy a tool. But it creates a gap. No single artifact answers the cross-workstream question a steering committee actually asks — across everything we have committed to, what is the coverage, and where is the risk? This matrix is that artifact.

It is built by extraction, not by hand. Every requirement below is pulled directly from its BRD's Functional Requirements section; the identifier, the MoSCoW priority and the statement are the BRD's own. The verification method is derived from what each requirement does — a fairness requirement is proven by fairness testing, an integration requirement by integration testing — and cross-checked against the testing model each BRD already specifies in its own Section 12. A hand-maintained RTM drifts from its sources the moment either changes; a derived one is wrong only if its sources are wrong, and says so loudly when they move.

02 Coverage summary

03 Verification method distribution

The spread of methods is itself a finding. This is an AI program, and it shows: model-accuracy validation, fairness testing, explainability and adversarial testing together account for a large share of the verification effort — methods that a conventional software RTM would not contain at all. A requirements matrix that traced these requirements only to "unit test / integration test" would be hiding exactly the risk that makes this program an AI program.

04 BRD-01 — Claims & Prior Authorization (17 FRs)

Traces to the acceptance gate in BRD-01 §13: accepted into production when all Must requirements are implemented and tested, all five AI models pass independent validation with zero uncorrected High findings, fairness testing passes within the demographic-deviation threshold, and UAT passes.

05 BRD-02 — Member & Provider Experience (20 FRs)

Traces to the acceptance gate in BRD-02 §13. This is the most requirement-dense workstream, and the one where UAT carries the heaviest load — member- and provider-facing experience is proven by the people who use it, not only by the models behind it.

06 BRD-03 — Underwriting & Risk (12 FRs)

Traces to the acceptance gate in BRD-03 §13. Every requirement here is Must-priority — there is no discretionary scope in underwriting and risk, because a risk model that is "mostly" governed is not governed. Explainability and independent model validation dominate its verification, which is correct for a workstream whose outputs drive pricing and coverage decisions.

07 Traceability gaps — recorded, not hidden

An RTM that reports complete coverage on a program in early execution is not being maintained. These are the genuine open items this matrix surfaces — each is a real finding about the current state of the requirement baseline, not a defect in the requirements themselves.

08 How to read this matrix against the program

The chain this matrix sits in is: business case (CBA) → workstream requirements (the three BRDs) → this RTM → verification (Master Test & QA Strategy) → acceptance (each BRD §13) → realized benefit (Benefits Realization Plan). This matrix is the hinge between what was asked for and how it will be proven. It reconciles to the BRDs on the left — every requirement ID here exists there — and to the Test Strategy's verification levels on the right. When a BRD requirement changes, this matrix is regenerated from it; when the Test Strategy adds a verification level, the method column is revisited. That is what keeps a traceability matrix a live control rather than a snapshot that quietly goes out of date.