The Claims Portal and the Word 'Real-Time'
Meridian Health's claims portal is entering acceptance testing. The requirements specification contains 214 numbered requirements; 37 describe performance, and 9 of those use the phrase 'real-time' or 'fast'. The portal must call a mainframe adjudication service with a documented p95 of 1.8 s; that service is unavailable during a nightly batch window from 01:00 to 03:00. The product owner has told the vendor that 'the portal must feel instant', and the contract contains a service credit if 'response time is unsatisfactory'. Two stakeholders disagree on audit-log retention: the compliance officer cites a 7-year regulatory expectation, while the infrastructure lead wants 90 days to control storage cost. Traceability shows 9 requirements with no linked test case, all in the audit and notification areas. The vendor's test lead says coverage is fine because 88% of requirements map to at least one test.
1. The phrase 'real-time' is unverifiable. Rewrite the performance requirement set into measurable acceptance criteria, and explain how the mainframe constraint changes the target.
Read the worked answer
Why the phrase fails: it names a feeling, not an observable. It cannot pass or fail, so it will be argued at acceptance and the service credit becomes a negotiation rather than a measurement.
Split it into three requirements, because they have different owners and different tests:
- Perceived responsiveness: after submit, the UI acknowledges within 300 ms p95 and shows progress with status text; no blocking spinner without feedback.
- End-to-end adjudication: for a clean claim, p95 at or below 3.0 s and p99 at or below 5.0 s at 300 concurrent users, measured at the portal boundary over a 30-minute steady-state run on an agreed reference dataset.
- Batch-window behavior: requests received between 01:00 and 03:00 are accepted, persisted, and queued; the user sees an expected completion time; no request is lost.
Why 3.0 s and not 1.8 s: the mainframe p95 alone is 1.8 s, so a sub-2 s end-to-end target is unachievable without caching or asynchronous adjudication. Splitting the budget (portal 400 ms, network 100 ms, mainframe 1.8 s, margin 700 ms) makes the constraint explicit and gives the architect a lever. If the business truly needs 1 s, that changes the architecture, for example pre-adjudication or a local rules engine, and it is a scope decision rather than a tuning task.
Measurement clause: specify percentile, load profile, dataset, warm-up, exclusion rules, and who adjudicates disputes. Tie the service credit to the same definition; otherwise the contract and the test measure different things.
2. The compliance officer says 7 years, the infrastructure lead says 90 days. How should the team resolve this, and what artifact should record the outcome?
Read the worked answer
This is a decision-rights problem, not a storage problem. Compliance owns the regulatory floor; infrastructure owns cost. Neither can unilaterally set retention.
Reasoning: if a 7-year obligation applies, it is a minimum, so 90 days is non-compliant regardless of cost. But 'retain for 7 years' does not mean 'keep hot and queryable for 7 years'. Separate three requirements: hot retention (searchable, 90 days), archive retention (immutable, 7 years, retrieval within 24 hours), and deletion (provable purge after the period). The cost estimate should be for tiered storage, not primary database capacity. Ask compliance for the specific rule and jurisdiction and obtain legal's written interpretation. If the rule is ambiguous, record the interpretation as an assumption with an owner and review date; do not average the two positions.
Artifact: an architecture decision record plus a requirement with a measurable acceptance test, for example a record created on day 0 is retrievable on day 2,555, and a record is provably not retrievable after purge. Also define legal hold: retention must be suspendable per case. That is usually missed and is expensive to retrofit.
What not to do: let the database team decide by default, or treat the 90-day proposal as a cost-driven compromise. Both create an audit finding.
3. Nine requirements in audit and notification have no linked tests. What should the test lead do before signing acceptance?
Read the worked answer
Risk triage first, tests second. The nine untraced requirements sit in audit and notification, the two areas where a defect is a compliance event rather than a usability bug. That changes the priority.
Steps:
- For each requirement, determine whether it is implemented at all, by inspecting code and configuration, before writing a test. An untraced requirement is often an unimplemented one.
- Classify into must-test-before-acceptance versus defer-with-sign-off. Audit trail and regulator notifications are must-test; cosmetic notification wording can be deferred with the product owner's written acceptance.
- Write the test at the level where the behavior lives. The audit trail is a persistence and integration concern; test it against a real database, not a mock, because the failure mode is a missing write or a wrong actor identifier.
- Close the loop with bidirectional traceability, and also list tests that trace to no requirement; those are candidates for deletion or indicate a missing requirement.
Why the 88% mapping is weak: it counts the presence of a link, not the strength of a test. A test that opens the audit page and asserts HTTP 200 links to the requirement but verifies nothing.
Gate: do not sign acceptance while any compliance-sensitive requirement has no executed test. Record residual risk for deferred items in the acceptance report, with the acceptor named.