Functional Specification — Project Aurora

🎓

Billie · Your BA Coach

This is a waterfall functional specification — the traditional BA deliverable for projects with fixed scope. In agile projects you'd use the user stories board instead. Notice how this document defines what the system must do (functional requirements) separately from how well it must do it (non-functional requirements). New to writing waterfall reqs? Read how to write a "shall" statement → · Want the side-by-side with agile? Open the comparison →

📥

Inherited from the previous BA

Alex Reeve (the previous BA) produced v1.0 → v1.2 of this spec in January 2026 before handover. Their draft was written against a misread of Maya's brief — it described a "claims modernisation programme" for a much larger insurer. Two stakeholders (Jess, Maya) had already signed v1.1 on that basis.

Your v1.3 is the rebaseline. Stakeholder titles are corrected, operational figures match Maya's actual numbers, the integration story now reflects Sara's reality (Oracle Forms + SOAP wrapper, not a clean REST API), and all sign-offs are reset to Re-review because the underlying content has materially changed.

Three open actions wait for you — see the callout in Section 8 Sign-off & Review Notes at the bottom of this document.

Section 1 Executive Summary ▼

Purpose of this document

Business Problem

Proposed Solution

Expected Benefits

Section 2 Business Context ▼

Organisation Background

Drivers for Change

1. REGULATORY: FCA Consumer Duty (in force July 2023) requires Northcape to demonstrate fair customer outcomes — including a reportable trail of response times by customer cohort, complaint outcomes, vulnerability flags and repeated contacts. The current cross-channel pattern cannot produce that evidence. Priya Roshan confirms the FCA will look for these metrics in any thematic review.
2. OPERATIONAL: 80+ duplicate cases per day across the ~400-person operation. £14 per case in agent time → ≈£24k/month wasted, ≈£288k annualised. Ben Carlisle (12 yrs on the floor) believes the real figure is higher because duplicates "get fixed quietly without anyone logging them".
3. CUSTOMER: Two FOS complaints upheld last quarter cited the duplicate-handling pattern directly. Customer NPS on the multi-channel cohort is softening on Maya's quarterly sample. Customers are receiving contradicting replies from different agents within the same week.
4. ROADMAP: Aurora is the second of four programme-level bets this year. The portal refresh has shipped; the next bet ('agent assist with AI') depends on Aurora's case-linking model being in place to feed it. Tom Hewitt's instruction: leave architectural hooks for the AI piece — do not paint the team into a corner.

Stakeholder Summary

• Maya Okafor (Head of Customer Operations) — Sponsor. Owns the budget, the success metrics, and the FOS exposure.
• Tom Hewitt (Product Manager) — Day-to-day partner. Owns roadmap fit, the three product KPIs (time-to-resolution, agent productivity, customer effort score), and the architectural link to the 'agent assist with AI' bet.
• Jess Akinyemi (Product Owner) — Delivery-team accountability. Owns the backlog if the team is running agile; co-owns acceptance with the BA in waterfall.
• Sara Lin (Tech Lead) — Architecture and integration risk. Owns the SOAP-wrapper conversation, the cache-layer trade-off, and the resilience requirements.
• Priya Roshan (Compliance Officer, DPO function) — Consumer Duty, GDPR Article 17 (erasure), audit-trail requirements, DPIA sign-off. Internal title is Compliance Officer; she also performs the DPO function under UK GDPR Article 37.
• Ben Carlisle (Senior Customer Service Agent, 12 yrs) — Frontline voice. Represents the day-to-day agent perspective; primary user-research input. <strong>Not a sign-off authority</strong>, but no design decision should be made without him in the room.

Section 3 Scope ▼

Scope Boundary

In Scope / Out of Scope

Area	Status	Notes
Unified customer case view (phone / email / web)	IN SCOPE	Core MVP. Single screen, all open cases, all three channels, keyed by customer.
Real-time duplicate detection on case creation	IN SCOPE	Match on customer identity + open-case signature before a new case is committed.
PolicyCore integration (read-only)	IN SCOPE	Read via the existing SOAP wrapper. Cache layer required — see Section 6 Constraints.
Channel-system integration (phone CC, shared mailbox, web portal)	IN SCOPE	Read case-headers from each channel into the unified view.
Immutable audit log	IN SCOPE	All case events, 7-year retention. Consumer Duty + Article 30 GDPR.
Consumer Duty reporting dashboard	IN SCOPE	Response time by cohort, complaint outcomes, vulnerability flags, repeated contacts.
Vulnerability flags on customer records	IN SCOPE	Configurable, visible to all agents on every case view for that customer.
GDPR Article 17 erasure / anonymisation workflow	IN SCOPE	Triggered by DPO (Priya's role). Pseudonymise PII; preserve case skeleton for regulatory retention.
Architectural hooks for 'agent assist with AI' (next bet)	IN SCOPE	Tom's instruction: do not paint the team into a corner. Hooks, not implementation.
Replacement of any channel system (phone CC / mailbox / portal)	OUT OF SCOPE	Aurora integrates; the channel systems remain owned by their teams.
Replacement of PolicyCore (the core policy system)	OUT OF SCOPE	Budget cannot fund a core-system replacement. SOAP-wrapper improvement only.
Customer-facing self-service portal changes	OUT OF SCOPE	The portal refresh shipped three months ago — separate programme.
Payment processing	OUT OF SCOPE	Finance system owns all payment workflows. Aurora does not touch money movement.
AI / ML automated case routing or reply suggestion	OUT OF SCOPE	That is the next programme bet ('agent assist with AI'). Aurora leaves hooks; does not implement.
Native mobile app for agents	OUT OF SCOPE	Responsive web only. No mobile build within this budget.

Section 4 Functional Requirements ▼

How to read this section. Each row is a single, testable "shall" statement with a MoSCoW priority and a named source. Click a priority chip to cycle it; click any text to edit. New to writing waterfall reqs? Open the explainers in the learning library: → Writing waterfall requirements · → Waterfall vs agile reqs · → Integration for BAs (for FR-INT-*)

Filter by area

ID	Area	Requirement	Priority	Source

Section 5 Non-Functional Requirements ▼

Section 6 Assumptions & Constraints ▼

Assumptions

Constraints

1. TIMELINE: 5 months to go-live, per Maya's mandate. No extension absent a fresh business case to the board, which the sponsor does not want to re-open.
2. BUDGET: £180,000 one-off capital. Hard ceiling. Scope changes that breach the ceiling trigger formal change control via Tom (PM) and re-approval by Maya. The ceiling derives from ≈7.5 months of currently-wasted spend (£24k/month × 7.5), so anything bigger than the wasted spend itself cannot self-justify.
3. INTEGRATION: PolicyCore (the core policy system) is on Oracle Forms (2008). Aurora must read from PolicyCore via the existing SOAP wrapper — a previous team's middleware that handles reads adequately but breaks above a few transactions per second. Wrapper replacement, upgrade or fronting it with a cache layer is in scope; replacement of PolicyCore itself is not. See <a href="learn#integration-for-bas" target="_blank" style="color:var(--coral);font-weight:700">→ Integration for BAs</a> for the why-this-matters explainer.
4. REGULATION: The solution must comply with UK GDPR, FCA Consumer Duty (2023), the Insurance Distribution Directive, and the FCA's Operational Resilience rules (PS21/3). Priya's DPIA is the gating sign-off.
5. ARCHITECTURE: Architectural hooks must be left for the next programme bet ('agent assist with AI'). Aurora's case-linking model must be queryable from outside the application.
6. DATA: No new master customer record is created — Aurora links case records, it does not become the system of record for customer identity. Customer identity remains with PolicyCore.
7. TEAM CAPACITY: Engineering team has just shipped the portal refresh. Team fatigue has been flagged in delivery-team reviews; two engineers are reported as quietly looking around. Aurora cannot be the third major programme on top of BAU without that being acknowledged in the plan and the first sprint demonstrating a well-organised cadence.

Dependencies

Section 7 Out of Scope (Rationale) ▼

Explicitly excluded and why

CHANNEL-SYSTEM REPLACEMENT: Replacing any of the three channel systems (phone CC, shared mailbox, web portal) was floated as the "clean" solution. Excluded because: budget cannot fund a channel-system replacement (each is ≈£300k+ of work in its own right); the channel teams are not aligned on replacement; and Maya is explicit that integration is faster than replacement. Aurora integrates; the channel systems remain in place.

POLICYCORE REPLACEMENT: Replacing the Oracle Forms core policy system was discussed and excluded. The system is stable and rebuilding it cannot be funded within £180k. Aurora improves the SOAP wrapper or fronts it with a cache, but does not touch PolicyCore itself.

CUSTOMER-FACING CHANGES: Any change visible to the customer (portal redesign, status notifications, self-service updates) is out of scope. The portal refresh shipped three months ago; Aurora is an internal agent-facing tool. Marketing may request a customer-side view in a later phase.

PAYMENT PROCESSING: Aurora does not initiate, approve, route or display payment status. The Finance system owns all payment workflows. If a case requires a payment outcome, the agent continues to use the Finance system directly.

AI / ML FUNCTIONALITY: Automated case routing, suggested replies, or any machine-learning capability is excluded from Aurora. That is the next programme bet ('agent assist with AI'). Aurora must leave architectural hooks (per Tom Hewitt) but must not implement.

NATIVE MOBILE APP: Native iOS/Android app for agents was raised by Ben Carlisle during discovery. Excluded — responsive web covers the agent use case; the Manchester floor is not a field-operations environment. Revisit if the role evolves.

HISTORICAL CASE MIGRATION: Pre-2024 case data will not be migrated into Aurora's case-linking model. Agents retain read-only access to historical records via the existing channel systems. Cost-benefit does not justify deep migration within the 5-month window.

NEW MASTER CUSTOMER RECORD: Aurora does not create or own a new master customer record. Customer identity remains in PolicyCore. Aurora's case-linking model references PolicyCore's customer ID — it does not duplicate or supersede it.

Section 8 Sign-off & Version History ▼

Approval Matrix

Name	Role	Status	Date	Notes
Maya Okafor	Head of Customer Operations (Sponsor)	Re-review	—	Signed v1.1 on 10 Jan against the previous BA's misread brief. Re-review required against v1.3 rebaseline.
Jess Akinyemi	Product Owner	Re-review	—	Signed v1.1 on 12 Jan against the previous BA's misread brief. Re-review required against v1.3 rebaseline.
Tom Hewitt	Product Manager	Pending	—	v1.2 sign-off was never received (PM role mislabelled as "Head of Change" in v1.2). Reviewing v1.3 now.
Sara Lin	Tech Lead	Pending	—	Awaiting outcome of SOAP-wrapper transaction-rate spike (Week 2 dependency). FR-INT-03 may need renegotiating depending on result.
Priya Roshan	Compliance Officer (DPO function)	Pending	—	DPIA in progress (due Week 4). DPIA outcome may affect FR-COMP-01 and FR-COMP-02.

Version History

Version	Date	Author	Changes
1.0	05 Jan 2026	Alex Reeve (prev. BA)	Initial draft. Subsequently identified as written against a misread of Maya's brief — see v1.3 changelog.
1.1	09 Jan 2026	Alex Reeve (prev. BA)	Incorporated Jess's comments on scope; added GDPR section. Signed by Jess (PO) and Maya (Sponsor) on this basis.
1.2	14 Jan 2026	Alex Reeve (prev. BA)	NFRs expanded; Out of Scope rationale added; Sara's review pending. Last version produced before handover.
1.3	(today)	You (BA — rebaseline)	Rebaselined against Maya's original brief. Corrected: company shape (~400 in Manchester, not 1,200 across three sites); problem (multi-channel duplicate cases, not claims-platform modernisation); budget (£180k, not £4.2m); timeline (5 months, not 18); integration story (Oracle Forms + SOAP wrapper, not clean REST API); stakeholder titles (Maya is Customer Ops, Tom is PM, Priya is Compliance Officer w/DPO function); added Ben Carlisle as agent voice in Section 2 (no sign-off); v1.1 sign-offs reset to Re-review.

Review Notes (working area)

📌 Three open actions waiting for you

The factual rebaseline is complete. These three calls remain — each one belongs to you as BA, each one unblocks a different group of stakeholders, each one is the kind of decision a mid-level Software BA owns in a real waterfall project:

Drive the three-options business case (build / buy / integrate). Maya is open. Tom favours buy. Sara is the integration anchor. Until this lands, FR-INT-* and FR-CM-* cannot be fully tightened — some requirements change shape depending on which option wins. Use aurora-business-case.html. Due: Week 4. Owner: you (with Tom).
Commission Sara's SOAP-wrapper transaction-rate spike. The integration story rests on whether the existing wrapper can sustain Aurora's read load. The spike is a £10k week-2 effort that either validates FR-INT-03 as written or forces a cache-layer-mandatory rewrite. Background: learn.html#integration-for-bas. Due: Week 2. Owner: Sara (you commission and chase).
Confirm DPIA and Consumer Duty mapping with Priya. Until the DPIA is complete, FR-COMP-01 and FR-COMP-02 cannot be signed off. The DPIA outcome may also change the Consumer Duty reporting requirements in Section 4. Due: Week 4. Owner: Priya (you co-author the data-mapping inputs).

Each of these is a normal mid-level BA call. None requires inventing anything not already surfaced by the stakeholder discovery in project-aurora.html.