The authoritative statement of what the business needs from this program and why — the document every downstream artifact traces back to. Requirements are classified using the PMBOK® Guide §5.2 Collect Requirements schema: business, stakeholder, solution (functional and non-functional), and transition requirements — the same classification set out in the IIBA BABOK Guide, from which PMI adopted it. Baselined at the Requirements & Vendor Selection Complete milestone (3 November 2026); changes after that date follow formal change control.
59
Requirements baselined
5
PMBOK §5.2 classes
6
Downstream integrations
MoSCoW
Prioritization
03 Nov 26
Baseline date
01 Document Control & Purpose
| Attribute | Detail |
|---|---|
| Document owner | F. Jones — Lead Business Analyst |
| Accountable | C. Tyrrell — Program Manager |
| Contributing analysts | M. Ferraro (Underwriting/Billing), T. Whitaker (Claims/Commission), R. Okonkwo (Data Warehouse/Payment) |
| Baseline milestone | Requirements & Vendor Selection Complete — 03 Nov 2026 |
| Change authority after baseline | Change Control Board via the Change Control Log |
| Downstream consumers | Vendor SOW & configuration, Test & Quality Strategy, UAT scenarios, training curriculum, WBS |
This BRD states requirements in business terms and is deliberately design-agnostic: it defines what must be true of the solution and why, not how the vendor's platform will achieve it. Configuration and technical design decisions belong to the Solution Architect and the vendor, traced back to the requirements below.
02 Executive Summary
The organization's enrollment and claims platform has reached the end of its vendor-supported life. The vendor has announced end-of-support, and the platform cannot be extended past that date. This is therefore a mandatory replacement, not a discretionary modernization — a distinction that shapes every requirement and prioritization decision in this document.
The program delivers a vendor-delivered core platform upgrade, conversion of member, policy, provider/producer and historical claims data, and re-establishment of six downstream integrations. Go-Live is targeted for 24 August 2027, ahead of the following open-enrollment period.
The requirement that governs all others. Continuity of business operation is not one requirement among many — it is the condition under which every other requirement is judged. A health plan that cannot enroll members or adjudicate claims on the day after cutover has failed regardless of how much new functionality it gained. Requirements are prioritized accordingly: continuity first, parity second, improvement third.
03 Business Context & Drivers
| Driver | Description | Consequence of inaction |
|---|---|---|
| Vendor end-of-support | The incumbent platform version passes end-of-support; no security patching, regulatory updates or defect remediation after that date | Unsupported system of record for regulated healthcare data — unacceptable to Compliance and Internal Audit |
| Capacity & volume | The current system can no longer efficiently support transaction volume and integration load | Degrading performance during enrollment peaks |
| Integration burden | Point-to-point interfaces to six downstream systems are increasingly costly to maintain | Rising run cost and change lead time |
| Regulatory currency | State filing and reporting requirements continue to evolve | Compliance exposure without vendor-supplied regulatory updates |
Why the business case reads the way it does. The Cost-Benefit Analysis shows a negative 10-year NPV, and that is presented rather than adjusted. When replacement is mandatory, the CBA's job is not to prove the investment clears a hurdle — it is to demonstrate that the chosen scope is the most cost-effective way to satisfy an obligation the organization cannot avoid. This BRD's scope discipline is what that argument rests on.
04 Business Objectives & Success Measures
| Objective | Success measure | Measured when |
|---|---|---|
| Exit unsupported software before end-of-support | Production cutover complete on the supported platform version | Go-Live, 24 Aug 2027 |
| Preserve uninterrupted enrollment and claims operation | No business-day outage beyond the agreed cutover window; no missed claims payment cycle | Cutover + 30 days |
| Convert historical data completely and accurately | 100% record and financial control-total reconciliation; zero unexplained variance | Data Conversion Sign-off, 16 Mar 2027 |
| Re-establish all six downstream integrations | All six operating in production with reconciled outputs | Go-Live |
| Maintain regulatory and financial-reporting integrity | SOX controls tested and evidenced; state reporting outputs verified | Pre-Go-Live |
| Transition the business, not just the system | Trained users operating unaided at the end of hypercare | Closeout, 02 Nov 2027 |
05 Scope
Functional decomposition
Core Platform
Vendor-delivered version upgrade; configuration of plans, benefits and rules
Data Conversion
Member, policy, provider/producer, historical claims
Integrations
Six downstream systems re-established
Reporting
Operational and regulatory reporting continuity
Business Transition
Training, process change, cutover and decommissioning
In scope
- Core platform version upgrade (vendor-delivered) and configuration to current business rules.
- Conversion of member, policy, provider/producer and historical claims data from the legacy platform.
- Six downstream integrations: Billing, Underwriting, Claims Administration, Commission Management, Data Warehouse/Reporting, Payment Processing.
- Operational and regulatory reporting continuity.
- User training, process documentation, cutover execution and legacy decommissioning planning.
Out of scope
- New product lines, benefit designs or business capabilities not present in the legacy platform.
- Re-engineering of downstream systems themselves beyond their interfaces.
- Ongoing run-state production support beyond the vendor warranty period.
- Member- or provider-facing portal redesign.
Scope discipline is the cost control. On a mandatory replacement, the strongest pressure is to attach long-wanted enhancements to a programme that is happening anyway. Every such request is assessed against a single test: is this required to operate on the new platform, or is it an improvement that could be delivered separately afterwards? Improvements are routed to the post-implementation backlog, not absorbed into the baseline.
06 Stakeholders
| Stakeholder | Interest in requirements | Role in this BRD |
|---|---|---|
| Executive Sponsor / Steering Committee | Business case, scope boundary, funding | Approves the baseline |
| C. Tyrrell — Program Manager | Deliverability within schedule and budget | Accountable |
| F. Jones — Lead Business Analyst | Completeness, clarity, traceability | Owns and authors |
| Enrollment Operations | Member and policy administration continuity | Provides and validates requirements |
| Claims Operations — D. Kessler (SME) | Adjudication behaviour and claims continuity | Provides requirements; UAT |
| Underwriting — M. Yamamoto (SME) | Rating inputs, policy issuance | Provides requirements; UAT |
| Finance & Billing | Premium, invoicing, payment integrity | Provides requirements; validates control totals |
| G. Fenwick — Internal Audit / SOX | Financial-reporting controls | Approves control-related requirements |
| J. Albert — Solution Architect | Feasibility and solution design | Reviews for technical viability |
| W. Donnelly — Vendor / Procurement Manager | Requirements that bind the vendor SOW | Translates into contractual scope |
| L. Bergström — Change Manager (OCM) | Business impact and adoption | Owns transition requirements |
| Platform vendor | What must be configured and delivered | Consumes the baselined BRD |
07 Current State & Future State
| Dimension | Current state (as-is) | Future state (to-be) |
|---|---|---|
| Platform version | Approaching vendor end-of-support; no forward patching path | Vendor-supported current version with regulatory update stream |
| Data | Member, policy, provider and claims history in the legacy platform, with known duplication in historical claims | Converted, de-duplicated and reconciled on the upgraded platform, with full audit trail |
| Integrations | Six point-to-point interfaces, individually maintained | Six interfaces re-established against the upgraded platform, documented and testable |
| Reporting | Operational and regulatory reporting from the legacy platform | Equivalent reporting continuity, verified against legacy output |
| Operations | Staff trained on legacy screens and processes | Staff trained and operating unaided on the upgraded platform |
08 Requirements Elicitation Approach
Requirements were elicited using a combination of techniques recognized by both the PMBOK® Guide and the BABOK Guide, chosen for what each surfaces reliably:
| Technique | Applied to | Why chosen |
|---|---|---|
| Document analysis | Legacy configuration, existing interface specifications, regulatory filings | Establishes the baseline of what the system currently does — the de facto requirement |
| Stakeholder interviews | Enrollment, Claims, Underwriting, Finance leads | Surfaces intent and exception handling that documentation omits |
| Facilitated workshops | Cross-functional sessions per business domain | Resolves conflicting requirements between functions in the room |
| Observation | Enrollment and claims processing in operation | Reveals workarounds staff no longer consciously notice |
| Interface analysis | The six downstream integrations | Exposes actual behaviour where specification and code disagree |
| Data profiling | Historical claims and member records | Converts assumptions about data quality into measured fact |
Two elicitation findings changed the requirements. Data profiling revealed higher-than-expected duplicate member records in historical claims (I-001), which created transition requirements for de-duplication rules and audit trail that had not been anticipated. Interface analysis found a discrepancy between the Commission Management integration specification and the legacy calculation logic (I-004) — the specification described what the system was believed to do, and the code did something else. Where the two disagree, the requirement is set by a documented business decision, not by defaulting to either source.
09 Business Requirements BR
Why the change is being made and how success will be assessed — the highest-level statement of need, from which all other requirements derive.
| ID | Requirement | Priority | Success measure |
|---|---|---|---|
| BR-001 | The organization must operate its enrollment and claims system of record on vendor-supported software | Must | Cutover complete before end-of-support |
| BR-002 | Business operations must continue without interruption through and after cutover | Must | No outage beyond the agreed window; no missed payment cycle |
| BR-003 | All member, policy, provider/producer and historical claims data must be retained and remain accessible | Must | Full reconciliation at conversion sign-off |
| BR-004 | Financial and regulatory reporting integrity must be preserved across the transition | Must | SOX controls evidenced; state reporting verified |
| BR-005 | The organization must not increase its ongoing run cost as a result of the upgrade | Should | Run cost at or below baseline post-warranty |
| BR-006 | Staff must be able to perform their work on the new platform without degradation in productivity after hypercare | Must | Productivity at or above baseline at closeout |
| BR-007 | The legacy platform must be decommissioned once data retention obligations are satisfied | Should | Decommissioning plan approved; retention verified |
| BR-008 | The program must not introduce new business capability that was not present in the legacy platform | Must | Scope boundary held; enhancements deferred to backlog |
10 Stakeholder Requirements SR
Needs of specific stakeholder groups that the solution must satisfy in order to meet the business requirements above.
| ID | Stakeholder | Requirement | Priority |
|---|---|---|---|
| SR-001 | Enrollment Operations | Must be able to enroll, change and terminate member coverage with equivalent or fewer steps than the legacy platform | Must |
| SR-002 | Claims Operations | Must be able to adjudicate, adjust and reverse claims with the same outcomes the legacy system produced for equivalent input | Must |
| SR-003 | Underwriting | Must receive complete and timely risk data for rating and policy issuance | Must |
| SR-004 | Finance & Billing | Must be able to reconcile premium, claims payment and commission to the cent across the transition | Must |
| SR-005 | Internal Audit / SOX | Must be able to evidence control operation over financial reporting and payment paths | Must |
| SR-006 | Customer Service | Must be able to answer member and provider enquiries using converted history without recourse to the legacy system | Must |
| SR-007 | Compliance | Must be able to produce required state filings and regulatory reports on schedule | Must |
11 Solution Requirements — Functional FR
Capabilities the solution must provide. Stated as business behaviour, not platform configuration.
Core platform & administration
| ID | Requirement | Priority | Traces to |
|---|---|---|---|
| FR-001 | The solution shall administer member enrollment, changes, terminations and reinstatements, including retroactive effective dates | Must | SR-001 |
| FR-002 | The solution shall maintain policy, group and benefit-plan configuration equivalent to current production | Must | SR-001 |
| FR-003 | The solution shall maintain provider and producer records, including hierarchy and effective dating | Must | SR-001, SR-003 |
| FR-004 | The solution shall adjudicate claims according to configured benefit rules, producing the same outcome as legacy for equivalent input | Must | SR-002 |
| FR-005 | The solution shall support claim adjustment, reversal and reprocessing with full audit trail | Must | SR-002, SR-005 |
| FR-006 | The solution shall support coordination of benefits where more than one coverage applies | Must | SR-002 |
| FR-007 | The solution shall maintain accumulators (deductible, out-of-pocket) accurately across the conversion boundary | Must | SR-002, BR-003 |
| FR-008 | The solution shall provide role-based access aligned to current segregation-of-duties requirements | Must | SR-005 |
Integrations — six downstream systems
| ID | Requirement | Priority | Traces to |
|---|---|---|---|
| FR-009 | Billing: the solution shall transmit premium and adjustment data sufficient for invoicing on the current cycle | Must | SR-004 |
| FR-010 | Underwriting: the solution shall provide risk and policy data required for rating and issuance | Must | SR-003 |
| FR-011 | Claims Administration: the solution shall exchange claim intake, status and adjudication data at current volume | Must | SR-002 |
| FR-012 | Commission Management: the solution shall provide the data required to calculate and trigger producer commission payments | Must | SR-004 |
| FR-013 | Data Warehouse / Reporting: the solution shall deliver extracts sufficient for operational and regulatory reporting | Must | SR-007 |
| FR-014 | Payment Processing: the solution shall initiate payment instructions and consume payment status with full reconciliation | Must | SR-004, SR-005 |
| FR-015 | Each interface shall handle failure conditions without silent data loss, with retry and exception reporting | Must | BR-002 |
| FR-016 | Commission calculation behaviour shall follow the documented business decision where specification and legacy logic differ | Must | SR-004 · issue I-004 |
Reporting & compliance
| ID | Requirement | Priority | Traces to |
|---|---|---|---|
| FR-017 | The solution shall produce all state-mandated filings and regulatory reports currently produced | Must | SR-007, BR-004 |
| FR-018 | The solution shall retain an auditable record of every financially material transaction | Must | SR-005 |
| FR-019 | The solution shall support enquiry against converted historical claims and enrollment data | Must | SR-006, BR-003 |
| FR-020 | The solution shall provide operational reporting equivalent to legacy for daily business management | Should | SR-001, SR-002 |
12 Solution Requirements — Non-Functional NFR
| ID | Category | Requirement | Priority |
|---|---|---|---|
| NFR-001 | Performance | The solution shall sustain peak open-enrollment concurrency without degradation beyond agreed response targets | Must |
| NFR-002 | Performance | Claims batch processing shall complete within the existing overnight window at current and projected volume | Must |
| NFR-003 | Availability | The solution shall meet or exceed the availability the legacy platform provided during business hours | Must |
| NFR-004 | Recoverability | Backup, restore and failover shall be demonstrated by rehearsal before Go-Live | Must |
| NFR-005 | Security | PHI shall be encrypted in transit and at rest; access shall follow minimum-necessary principles | Must |
| NFR-006 | Privacy | The solution shall maintain HIPAA-compliant audit logging of access to protected health information | Must |
| NFR-007 | Compliance | Controls over financial reporting and payment paths shall be testable and evidenced (SOX) | Must |
| NFR-008 | Data integrity | Financial control totals shall reconcile exactly between source and target | Must |
| NFR-009 | Retention | Data retention shall satisfy regulatory and contractual obligations for historical records | Must |
| NFR-010 | Supportability | The platform version shall remain within vendor support for the defined horizon | Must |
| NFR-011 | Usability | Common enrollment and claims tasks shall require no more user steps than the legacy equivalent | Should |
| NFR-012 | Maintainability | Interfaces shall be documented to a standard permitting change without reverse engineering | Should |
13 Transition Requirements TR
Why this class matters here more than usual. Transition requirements exist only during the change and cease to apply once the organization reaches its future state. On most programs they are a footnote. On a mandatory platform replacement with a full data conversion, they are where the program actually succeeds or fails — and because they are temporary, they are the requirements most often left undocumented and therefore unfunded.
| ID | Requirement | Priority | Owner |
|---|---|---|---|
| TR-001 | Historical member, policy, provider and claims data shall be converted with 100% record and control-total reconciliation | Must | T. McCormick |
| TR-002 | Duplicate member records identified during conversion shall be resolved by documented rule, with every merge auditable and reversible | Must | T. McCormick · issue I-001 |
| TR-003 | Records that cannot be converted shall be quarantined, reported and owned — never silently dropped | Must | T. McCormick |
| TR-004 | Conversion shall be rehearsed at full volume prior to production execution | Must | T. McCormick |
| TR-005 | Legacy and new platform shall be run in parallel on representative transactions, with variances explained before cutover | Must | R. Whitfield |
| TR-006 | Conversion shall complete within the available cutover outage window | Must | T. McCormick |
| TR-007 | A tested rollback path shall exist up to the defined point of no return | Must | M. Alvarez |
| TR-008 | Affected staff shall be trained and assessed as competent before cutover | Must | H. Osei |
| TR-009 | Business process documentation shall be updated to reflect the new platform before Go-Live | Must | L. Bergström |
| TR-010 | Hypercare support shall be staffed at elevated levels for the defined period following cutover | Must | C. Tyrrell |
| TR-011 | Legacy platform access shall be retained read-only until data retention obligations are verified as satisfied | Should | M. Alvarez |
| TR-012 | Members and providers shall be notified of any externally visible change in advance | Should | V. Alaoui |
14 Prioritization Method
| Priority | Definition on this program | Treatment |
|---|---|---|
| Must | Required to operate the business on the new platform, or required by regulation | In baseline; cannot be descoped without Steering Committee decision |
| Should | Important for efficiency or maintainability, but the business can operate without it at Go-Live | In baseline; first candidates if schedule pressure requires descoping |
| Could | Desirable improvement with no operational dependency | Post-implementation backlog |
| Won't | Explicitly excluded from this program | Recorded so the decision is not relitigated |
The Won't category is written down deliberately. On a mandatory replacement, the same enhancement requests resurface repeatedly; recording the decision and its date is what stops the scope boundary being renegotiated informally.
15 Assumptions, Constraints & Dependencies
| Type | Statement | Reference |
|---|---|---|
| Assumption | Existing network and security infrastructure supports the upgraded platform without separate capital investment | A-001 |
| Assumption | Named resources are available at planned allocation; no extended unplanned absences | A-002 |
| Assumption | The vendor's upgrade approach will not require a change to the underlying database platform | A-003 |
| Assumption | Go-Live completes before the next open-enrollment period begins | A-004 |
| Assumption | Cleansed historical claims data requires no legal/compliance review beyond scope | A-005 |
| Constraint | Go-Live date is fixed by the open-enrollment calendar and cannot move | A-004 |
| Constraint | Vendor-delivered scope is bounded by the vendor SOW | R-003 |
| Constraint | PHI may not be accessed from offshore locations | Test Strategy §11 |
| Dependency | Vendor SOW finalization gates environment provisioning | R-003 |
| Dependency | Downstream system owners must be available for interface testing | Test Strategy §07 |
16 Traceability
Every requirement traces forward to the artifacts that implement and verify it. Traceability is maintained by the Lead Business Analyst and reviewed at each phase gate.
| Requirement class | Traces forward to | Verified by |
|---|---|---|
| Business (BR) | Project Charter objectives; CBA benefit case | Benefits review at closeout |
| Stakeholder (SR) | UAT scenarios; training curriculum | UAT sign-off by the owning function |
| Functional (FR) | Vendor configuration; integration build; test cases | System and integration testing |
| Non-functional (NFR) | Architecture and infrastructure design | Performance, security and DR testing |
| Transition (TR) | Conversion plan; cutover plan; training plan | Conversion sign-off; parallel run; cutover rehearsal |
Known gap, stated honestly. The PMBOK® Guide names two outputs of Collect Requirements: requirements documentation (this document) and a Requirements Traceability Matrix. The RTM now exists as a maintained artifact — see the Requirements Traceability Matrix, which is generated directly from this document and the Functional Specification so it cannot drift from them. Constructing it surfaced four functional requirements that were covered by specification but not explicitly traced; those traces have since been made explicit.
17 Risks to Requirements Integrity
| Risk | Effect on requirements | Mitigation |
|---|---|---|
| R-001 — historical claims data quality | Transition requirements expand as conversion defects surface | Early profiling; pre-funded third dry run (D-002); TR-002/TR-003 written to anticipate it |
| R-004 — mid-program regulatory change | New compliance requirements added after baseline | Regulatory monitoring; FR-017 scoped modularly so additions are contained |
| R-003 — vendor SOW delay | Requirements cannot be bound contractually on schedule | Baseline held at 3 Nov 2026 regardless; SOW tracks the baseline, not the reverse |
| Scope pressure on a mandatory program | Enhancements absorbed into the baseline informally | MoSCoW with a recorded Won't list; change control after baseline |
| Specification/behaviour divergence | Requirements written from documents that misdescribe the legacy system | Interface analysis against observed behaviour (I-004 precedent) |
18 Approval
| Role | Name | Approval basis | Date |
|---|---|---|---|
| Lead Business Analyst | F. Jones | Completeness and clarity of requirements | 03 Nov 2026 |
| Program Manager | C. Tyrrell | Deliverability within schedule and budget | 03 Nov 2026 |
| Solution Architect | J. Albert | Technical feasibility | 03 Nov 2026 |
| Internal Audit / SOX | G. Fenwick | Control and compliance requirements | 03 Nov 2026 |
| Vendor / Procurement Manager | W. Donnelly | Requirements are contractually bindable | 03 Nov 2026 |
| Executive Sponsor / Steering Committee | — | Business case and scope boundary | 03 Nov 2026 |
Governing relationship. This BRD is subordinate to the Project Charter and governs the vendor SOW scope, the Test & Quality Strategy, UAT scenarios and the training curriculum. After the 3 November 2026 baseline, all changes route through the Change Control Log — requirements are not amended in place.