Fast and Real Time: Turning Adjectives into Testable Requirements
At a regional insurer, the policy administration replacement team has baselined this requirement: 'The system must be fast and must integrate with the billing platform in real time.' Volumes are 2,400 endorsements per day, peaking at 400 in the busiest hour. The billing platform accepts 60 API calls per minute and pushes invoice adjustments through a 15-minute batch window. The vendor contract commits to 99.5% monthly availability. The test lead says the requirement cannot be verified and will not sign the test strategy. The vendor's delivery lead says 'real time' means anything under 30 seconds. The billing platform owner says adjustments cannot be real time at all.
1. Rewrite the requirement so it can be tested, and explain what makes the rewrite defensible.
Read the worked answer
Separate the two hidden requirements and bind each to a measure, a condition, and a measurement point.
Response time: 'When a user submits an endorsement, the confirmation screen returns within 2 seconds for 95% of submissions and 4 seconds for 99%, measured server-side at the API gateway, at loads up to 400 endorsements per hour.'
Data latency to billing: 'Endorsement financial data is visible to the billing platform within 15 minutes of endorsement approval for 99% of records, measured from approval timestamp to billing acknowledgement.'
Availability: 'The service is available 99.5% of each calendar month, excluding announced maintenance windows, measured by the monitoring platform agreed at design.'
Why this is defensible: each statement has a number, a percentile, a boundary condition, and a named measurement point, so the test lead can write a pass/fail case and the vendor can price it. 'Fast' and 'real time' are not requirements - they are adjectives hiding a design decision. The vendor's 30-second interpretation and the test lead's objection both dissolve once latency is split by data flow.
2. The billing platform owner says real-time invoice adjustments are impossible. How do you resolve the conflict?
Read the worked answer
The conflict is not volume - 400 per hour is under seven per minute, well inside the 60-calls-per-minute limit. The conflict is the invoice adjustment flow: the business is asking for real-time behaviour from a system that only opens a 15-minute batch window.
Resolve it in three moves:
- Split by data element. Endorsement status and premium change can post via API immediately. Invoice adjustments cannot - the billing platform's accounting cycle owns that. Write two requirements with different latencies.
- Test the business need, not the phrasing. Ask Finance what decision actually breaks if an invoice adjustment appears in 15 minutes rather than 30 seconds. Usually nothing; occasionally a month-end reconciliation.
- Document as a dated assumption with an owner - 'real time = within 15 minutes for invoice adjustments, agreed by billing platform owner'.
If Finance genuinely needs faster, that is a change request against the billing platform roadmap with its own cost and decision. It cannot be smuggled into the policy admin build as an undefined word.