Requirements and readiness

01The problem

The Lagos pilot was run with workarounds: a checklist app built quickly, and assessors approving claims under an informal rule. To roll it out to five regions, it needs proper requirements, controls the finance controller will accept, and tested software. User acceptance testing (UAT) has just finished, and the results are in uat.csv. The managing director wants to know: can we roll out next month?

02The concept

From cause to requirement

Every requirement should trace back to a root cause, so nobody builds something that doesn't solve a real problem:

Business rules and controls

The finance controller's worry is fair: if assessors can approve payments, who checks them? Write the controls as rules:

• An assessor may approve only windscreen or accident damage claims under ₦1m. Theft and third-party claims always go to a manager.
• The approving assessor must be different from the one who assessed the claim.
• If a claim's amount changes after approval, the approval is cancelled and the claim goes back for approval.
• Finance receives a weekly report of every assessor approval, and audits a sample.

User stories and acceptance criteria

As a [role], I want [capability], so that [benefit]. Then acceptance criteria in Given / When / Then form, including the cases that must fail, which is where the controls live.

Measures

Define the KPIs before rollout, exactly: days to settle (paid claims, closed_at − submitted_at), % of claims with documents requested, % paid within 30 days, withdrawals, complaints per 100 claims, and assessor approvals audited. Each needs a baseline and a target.

Go or no-go

Agree the exit criteria before testing: for example, no open critical or major defects, and minor ones only with a workaround and a fix date.

03Example

Test results by user story:

SELECT story_id,
       COUNT(*) AS tests,
       SUM(result = 'Pass') AS passed,
       SUM(result = 'Fail') AS failed,
       SUM(status IS 'Open') AS still_open
FROM uat
GROUP BY story_id
ORDER BY story_id;

story_id  tests  passed  failed  still_open
US-01         6       4       2           0
US-02         4       3       1           1
US-03         6       4       2           1
US-04         5       3       2           2
US-05         3       3       0           0

The defects still open, worst first:

SELECT test_id, story_id, severity, scenario
FROM uat
WHERE status = 'Open'
ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END, test_id;

test_id  story_id  severity  scenario
UAT-14   US-03     Critical  Claim amount edited upwards after assessor approval
UAT-20   US-04     Major     SMS not sent to a customer who opted out
UAT-10   US-02     Minor     Large photo upload on a slow connection
UAT-21   US-04     Minor     SMS in Hausa and Yoruba

The answer to "can we roll out next month?" is not yet. UAT-14 is critical: if a claim's amount can be raised after an assessor approves it, the ₦1m limit can be bypassed, which is exactly the fraud risk the finance controller raised. UAT-20 is major: sending SMS to customers who opted out breaks their data protection choices. Both must be fixed and retested. The two minor defects can follow, with workarounds (staff can send the Hausa and Yoruba messages manually for now).

04Walkthrough

1. Write user stories US-01 to US-05 from the requirements table, each with at least three acceptance criteria.
2. Write the business rules for assessor approval as a decision table: claim type × amount × who assessed it.
3. Write the KPI definitions with baselines from lessons 2 and 5, and a target for each.
4. Run the UAT queries and write the go/no-go note, with what must happen before rollout.
5. Write US-03 in full (the task below).

05Practice

06Check your understanding