The second output of Collect Requirements (PMBOK® Guide §5.2), alongside the requirements documentation itself. Every baselined requirement is traced forward to the specification that realizes it, the method that verifies it, and the point at which it is accepted. Generated directly from the BRD and FSD, so the traces reflect those documents rather than a manual transcription of them.
59
Requirements baselined
52
Functional specifications
20/20
Functional reqs specified
100%
FR coverage
3
Open traceability gaps
What building this matrix found. Before the RTM existed, four functional requirements — FR-015, FR-018, FR-019 and FR-020 — were covered by the specification but not traced to it. The shared error-handling standard satisfied FR-015 without carrying specification identifiers at all. Constructing the trace forced those to be made explicit: the error-handling standard became FS-090–095, and three further specifications gained explicit references. That is the RTM doing the job it exists for — coverage you cannot demonstrate is coverage you cannot defend at a gate review.
01 How to Read This Matrix
Traceability runs downward through the requirement classes and outward to verification:
| Class | Traces down to | Realized in | Verified by |
|---|---|---|---|
| BR | Stakeholder requirements | Programme objectives | Benefits review at closeout |
| SR | Functional requirements | Solution behaviour | UAT by the owning business function |
| FR | Functional specifications (FS) | Configuration and integration build | System and integration testing |
| NFR | Architecture and infrastructure design | Technical design | Performance, security and DR testing |
| TR | Conversion, cutover and training plans | Transition activity | Dry runs, parallel run, cutover rehearsal |
Business requirements do not trace to functional specifications and are not expected to — they trace downward to stakeholder requirements and forward to the benefit case. Non-functional and transition requirements are largely realized outside the FSD, which is why their specification coverage is deliberately partial rather than a gap.
02 Coverage Summary
| Class | Requirements | Traced to a specification | Assessment |
|---|---|---|---|
| BR | 8 | 0 | Expected — business requirements trace to objectives and the benefit case, not to specifications |
| SR | 7 | 5 | The remainder are satisfied through UAT scenarios rather than a discrete specification |
| FR | 20 | 20 | Complete — every functional requirement has at least one specification |
| NFR | 12 | 4 | Realized in technical design; all verified under the Test Strategy |
| TR | 12 | 3 | Remainder realized in the conversion, cutover and training plans — see gaps below |
BR Business Requirements
Why the change is being made — verified by Benefits review at closeout (CBA · Closeout Report).
| ID | Requirement | Priority | Specified by (FSD) |
|---|---|---|---|
| BR-001 | The organization must operate its enrollment and claims system of record on vendor-supported software | Must | — see note |
| BR-002 | Business operations must continue without interruption through and after cutover | Must | — see note |
| BR-003 | All member, policy, provider/producer and historical claims data must be retained and remain accessible | Must | — see note |
| BR-004 | Financial and regulatory reporting integrity must be preserved across the transition | Must | — see note |
| BR-005 | The organization must not increase its ongoing run cost as a result of the upgrade | Should | — see note |
| BR-006 | Staff must be able to perform their work on the new platform without degradation in productivity after hypercare | Must | — see note |
| BR-007 | The legacy platform must be decommissioned once data retention obligations are satisfied | Should | — see note |
| BR-008 | The program must not introduce new business capability that was not present in the legacy platform | Must | — see note |
SR Stakeholder Requirements
What each stakeholder group needs — verified by UAT — business scenario execution (Test Strategy §09).
| ID | Requirement | Priority | Specified by (FSD) |
|---|---|---|---|
| SR-001 | Must be able to enroll, change and terminate member coverage with equivalent or fewer steps than the legacy platform | Must | — see note |
| SR-002 | Must be able to adjudicate, adjust and reverse claims with the same outcomes the legacy system produced for equivalent input | Must | FS-030–034 |
| SR-003 | Must receive complete and timely risk data for rating and policy issuance | Must | FS-020–023 |
| SR-004 | Must be able to reconcile premium, claims payment and commission to the cent across the transition | Must | FS-010–014, FS-040–043, FS-060–064 |
| SR-005 | Must be able to evidence control operation over financial reporting and payment paths | Must | FS-060–064 |
| SR-006 | Must be able to answer member and provider enquiries using converted history without recourse to the legacy system | Must | — see note |
| SR-007 | Must be able to produce required state filings and regulatory reports on schedule | Must | FS-050–054 |
FR Solution Requirements — Functional
What the solution must do — verified by System & integration testing (Test Strategy §04, §07).
| ID | Requirement | Priority | Specified by (FSD) |
|---|---|---|---|
| FR-001 | The solution shall administer member enrollment, changes, terminations and reinstatements, including retroactive effective dates | Must | FS-001–002 |
| FR-002 | The solution shall maintain policy, group and benefit-plan configuration equivalent to current production | Must | FS-003 |
| FR-003 | The solution shall maintain provider and producer records, including hierarchy and effective dating | Must | FS-004 |
| FR-004 | The solution shall adjudicate claims according to configured benefit rules, producing the same outcome as legacy for equivalent input | Must | FS-005 |
| FR-005 | The solution shall support claim adjustment, reversal and reprocessing with full audit trail | Must | FS-006 |
| FR-006 | The solution shall support coordination of benefits where more than one coverage applies | Must | FS-007 |
| FR-007 | The solution shall maintain accumulators (deductible, out-of-pocket) accurately across the conversion boundary | Must | FS-008 |
| FR-008 | The solution shall provide role-based access aligned to current segregation-of-duties requirements | Must | FS-009, FS-080 |
| FR-009 | Billing: the solution shall transmit premium and adjustment data sufficient for invoicing on the current cycle | Must | FS-010–014 |
| FR-010 | Underwriting: the solution shall provide risk and policy data required for rating and issuance | Must | FS-020–023 |
| FR-011 | Claims Administration: the solution shall exchange claim intake, status and adjudication data at current volume | Must | FS-030–034 |
| FR-012 | Commission Management: the solution shall provide the data required to calculate and trigger producer commission payments | Must | FS-040–043 |
| FR-013 | Data Warehouse / Reporting: the solution shall deliver extracts sufficient for operational and regulatory reporting | Must | FS-050–054 |
| FR-014 | Payment Processing: the solution shall initiate payment instructions and consume payment status with full reconciliation | Must | FS-060–064 |
| FR-015 | Each interface shall handle failure conditions without silent data loss, with retry and exception reporting | Must | FS-090–095 |
| FR-016 | Commission calculation behaviour shall follow the documented business decision where specification and legacy logic differ | Must | FS-040–043 |
| FR-017 | The solution shall produce all state-mandated filings and regulatory reports currently produced | Must | FS-050–054 |
| FR-018 | The solution shall retain an auditable record of every financially material transaction | Must | FS-064, FS-082 |
| FR-019 | The solution shall support enquiry against converted historical claims and enrollment data | Must | FS-071 |
| FR-020 | The solution shall provide operational reporting equivalent to legacy for daily business management | Should | FS-050 |
NFR Solution Requirements — Non-Functional
Qualities the solution must have — verified by Performance, security, DR testing (Test Strategy §10).
| ID | Requirement | Priority | Specified by (FSD) |
|---|---|---|---|
| NFR-001 | The solution shall sustain peak open-enrollment concurrency without degradation beyond agreed response targets | Must | — see note |
| NFR-002 | Claims batch processing shall complete within the existing overnight window at current and projected volume | Must | FS-034 |
| NFR-003 | The solution shall meet or exceed the availability the legacy platform provided during business hours | Must | — see note |
| NFR-004 | Backup, restore and failover shall be demonstrated by rehearsal before Go-Live | Must | — see note |
| NFR-005 | PHI shall be encrypted in transit and at rest; access shall follow minimum-necessary principles | Must | FS-080, FS-083 |
| NFR-006 | The solution shall maintain HIPAA-compliant audit logging of access to protected health information | Must | FS-082 |
| NFR-007 | Controls over financial reporting and payment paths shall be testable and evidenced (SOX) | Must | FS-081 |
| NFR-008 | Financial control totals shall reconcile exactly between source and target | Must | — see note |
| NFR-009 | Data retention shall satisfy regulatory and contractual obligations for historical records | Must | — see note |
| NFR-010 | The platform version shall remain within vendor support for the defined horizon | Must | — see note |
| NFR-011 | Common enrollment and claims tasks shall require no more user steps than the legacy equivalent | Should | — see note |
| NFR-012 | Interfaces shall be documented to a standard permitting change without reverse engineering | Should | — see note |
TR Transition Requirements
Temporary capabilities needed only during the change — verified by Conversion dry runs, parallel run, cutover rehearsal (Test Strategy §05, §08).
| ID | Requirement | Priority | Specified by (FSD) |
|---|---|---|---|
| TR-001 | Historical member, policy, provider and claims data shall be converted with 100% record and control-total reconciliation | Must | FS-008, FS-070–072 |
| TR-002 | Duplicate member records identified during conversion shall be resolved by documented rule, with every merge auditable and reversible | Must | FS-074 |
| TR-003 | Records that cannot be converted shall be quarantined, reported and owned — never silently dropped | Must | FS-073 |
| TR-004 | Conversion shall be rehearsed at full volume prior to production execution | Must | — see note |
| TR-005 | Legacy and new platform shall be run in parallel on representative transactions, with variances explained before cutover | Must | — see note |
| TR-006 | Conversion shall complete within the available cutover outage window | Must | — see note |
| TR-007 | A tested rollback path shall exist up to the defined point of no return | Must | — see note |
| TR-008 | Affected staff shall be trained and assessed as competent before cutover | Must | — see note |
| TR-009 | Business process documentation shall be updated to reflect the new platform before Go-Live | Must | — see note |
| TR-010 | Hypercare support shall be staffed at elevated levels for the defined period following cutover | Must | — see note |
| TR-011 | Legacy platform access shall be retained read-only until data retention obligations are verified as satisfied | Should | — see note |
| TR-012 | Members and providers shall be notified of any externally visible change in advance | Should | — see note |
03 Traceability Gaps — Now Closed
An RTM that reports complete coverage on a programme still in build is not being maintained. The three transition-requirement gaps this matrix recorded are now closed: each is owned by a maintained plan, cross-referenced below. Recording both the gap and its closure — rather than quietly deleting the gap once filled — is what lets a reviewer see that the matrix was worked, not decorated.
| # | Gap (as recorded) | Affected requirements | Now owned by | Status |
|---|---|---|---|---|
| G-01 | No Data Conversion Plan artifact. Nine transition requirements name conversion behaviour that was specified nowhere as a maintained document; TR detail lived in the FSD and the Test Strategy | TR-001 – TR-007 | Data Conversion Plan (T. McCormick) | Closed |
| G-02 | No Cutover Plan artifact. Rollback, hypercare and cutover-window requirements had no single owning document | TR-006, TR-007, TR-010, TR-011, TR-012 | Cutover Plan (C. Tyrrell) | Closed |
| G-03 | No Training Plan artifact. Training and process-documentation requirements were owned but not documented | TR-008, TR-009 | Training Plan (H. Osei / L. Bergström) | Closed |
All three gaps are closed against maintained documents. Every transition requirement TR-001 through TR-012 now traces to exactly one owning plan: TR-001–007 to the Data Conversion Plan, TR-006/007 runbook plus TR-010/011/012 to the Cutover Plan, and TR-008/009 to the Training Plan. The gaps were documentation gaps, not planning gaps — the WBS already contained the conversion, cutover and training work and the Test Strategy already specified verification; what was missing was the owning document a reviewer traces a transition requirement into, and now exists.
04 Maintenance & Governance
| Aspect | Rule |
|---|---|
| Owner | F. Jones — Lead Business Analyst |
| Baseline | Tracks the BRD baseline of 3 Nov 2026 |
| Update trigger | Any approved change to a requirement or specification, via the Change Control Log |
| Review point | Every phase gate; coverage reported to the Steering Committee |
| Generation | Regenerated from the BRD and FSD rather than edited in place, so the matrix cannot drift from the documents it traces |
| Exit condition | At Go-Live every Must requirement must show specification, verification and acceptance |
Why it is generated rather than maintained by hand. A hand-maintained RTM degrades the moment a requirement changes and someone forgets to update a row — and it degrades silently, which is worse, because the matrix continues to assert coverage it no longer has. Deriving it from the source documents means the matrix is wrong only if the documents are wrong.