Stakeholder brief
Northstar Retail receives 1,200 online return requests per month. Agents copy email details into a spreadsheet; warehouse staff update a separate tracker. Median request-to-refund is 8 working days. 18% of cases need a second contact. The sponsor wants median refund time ≤4 working days within 90 days of launch, without increasing incorrect refunds above the current 0.5%. Budget: £60,000. Delivery window: 10 weeks. Payments integration has a 3-week lead time. Refunds above £200 need finance approval. Fraud review and statutory policy decisions remain with existing teams. All numbers are fictional training data.
1. Discovery and scope
Identify affected roles, decision rights, evidence gaps and the smallest useful release. Separate facts, assumptions and questions. Write three discovery questions that could change scope.
Deliverable template
Problem / baseline / target: In scope / out of scope: Stakeholders (role, need, influence, approach): Facts / assumptions / open questions: Decision owner / sign-off:
Worked example & tradeoffs
Operations owns the outcome; finance owns refund controls; agents and warehouse staff validate workflow; security reviews access. Include intake, status tracking and approval routing; defer automated fraud decisions. Validate whether 8 days includes customer shipping time before promising a 4-day SLA. Interview agents and sample timestamps, rather than treating a sponsor request as a proven root cause.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
2. AS-IS and TO-BE process
Map at least five current steps and five future steps. Label handoffs, wait states, exception paths and control owners. Define where the clock starts and stops.
Deliverable template
AS-IS: actor → action → handoff / wait → outcome Pain point and evidence: TO-BE: actor → action → decision → outcome Exception / recovery / owner: Metric boundary:
Worked example & tradeoffs
AS-IS: customer emails → agent rekeys → warehouse checks item → agent chases status → finance refunds → customer informed. TO-BE: validated intake → case ID → warehouse scan → rule-based approval queue → finance confirms payment → status notification. Missing item and failed payment go to named exception queues. Measure accepted return request to confirmed refund; separately track shipping delays so an apparent improvement cannot hide backlog.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
3. Requirements and business rules
Write three functional requirements and two NFRs with stable IDs, sources, priority and verification method. Resolve the £200 boundary explicitly.
Deliverable template
ID | requirement | source | priority | acceptance evidence BR-01 | approval boundary: NFR-01 | measurable condition: Assumptions and unresolved decisions:
Worked example & tradeoffs
FR-01: issue a unique case ID after valid intake (agent workshop, Must). FR-02: route amounts >£200 to finance before payment (finance policy, Must). Exactly £200 follows standard approval; confirm policy currency conversion. FR-03: expose latest case status to agents. NFR-01: 95% of case lookups complete within 2 seconds under agreed peak load. NFR-02: agent can complete intake using keyboard only, verified in accessibility testing. Avoid vague words such as fast or user-friendly.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
4. Stories and acceptance criteria
Produce two user stories, at least three Given/When/Then criteria per story, including a negative case and a boundary case. Include dependencies and a discussion point.
Deliverable template
US-01: As a … I want … so that … Given … When … Then … Negative / boundary case: Dependency / unresolved question:
Worked example & tradeoffs
As a finance approver I want high-value returns queued so that unauthorized refunds cannot be sent. Given a £200.01 request, when warehouse receipt is confirmed, then the case awaits finance approval and payment is blocked. Given exactly £200, it follows the agreed standard path. Given approval is rejected, no payment is submitted and the reason is visible to the agent. Add a second story for agent status lookup, including unknown case ID and stale warehouse updates.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
5. Traceability and change impact
Connect objective → requirement → story → test. Assess a late request for instant refunds before warehouse receipt. Record the decision and affected artifacts.
Deliverable template
Objective | requirement ID | story ID | UAT test ID | owner | status Change / reason / benefit: Impact: scope, cost, time, risk, control: Options / decision / approver / date:
Worked example & tradeoffs
O-01 shorter refund cycle → FR-02 approval routing → US-01 → UAT-03 £200.01 hold. Instant refunds alter fraud exposure and finance controls, not merely a screen. Compare a low-risk customer pilot with deferral; quantify expected value, seek finance/sponsor decision, and update baseline, tests and support guidance. A traceability matrix should reveal uncovered requirements rather than claim that every link is already passed.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
6. UAT and benefits handover
Create four UAT cases with realistic inputs and expected outcomes. State entry/exit criteria, severity rules and sign-off ownership. Define post-launch measurement and operational support.
Deliverable template
Test ID | requirement | precondition | steps | data | expected | actual | status | evidence | defect Entry / exit criteria: Defect severity / retest owner: Business sign-off / residual risks: Benefit metric / baseline / target / owner / review date:
Worked example & tradeoffs
UAT covers standard refund, exactly £200, £200.01 awaiting approval, and failed payment retry without duplicate refund. Entry: stable build, representative masked data, trained users. Exit: all critical scenarios pass, no unresolved critical/high defects, accepted residual risks documented by sponsor. Finance signs control behavior, operations signs usability. Operations tracks median, 90th percentile, incorrect-refund rate and second-contact rate weekly; compare cohorts and disclose seasonality. Training completion alone is not a business benefit.
One defensible approach. Your decision can differ if your evidence and tradeoffs support it.
Write the artifacts in your own words. Use identifiers to connect the objective, requirements and tests.