The Requirement That Was Really a Solution
A hospital trust is specifying a new outpatient booking system. The requirements catalogue contains: 'The system shall provide a drag-and-drop calendar view with colour-coded clinics.' 'The system shall send SMS reminders 48 hours before appointment.' 'The system shall allow patients to rebook without calling.' 'The system shall reduce did-not-attend rate from 11% to 7%.' The clinical director says the colour-coding is essential. A business analyst has been asked to sign off the catalogue so procurement can begin. The trust has no agreed definition of a 'did not attend' and two departments count it differently.
1. Classify these statements and rewrite them as proper requirements.
Read the worked answer
The catalogue mixes four different things.
- 'Drag-and-drop calendar with colour-coded clinics' - a solution design, not a requirement. The underlying need is that schedulers can see clinic capacity and constraints at a glance. Rewrite: 'The system shall enable a scheduler to view clinic capacity, bookings and constraints for a chosen date range and identify over- and under-booked clinics without leaving the scheduling screen.' Colour-coding becomes a design option to be evaluated, not a mandate.
- 'SMS 48 hours before' - a solution. The need is reducing missed appointments through timely reminder. Rewrite as a business requirement: 'The system shall remind patients of upcoming appointments through the patient's preferred channel, at a time shown by evidence to reduce non-attendance.' The 48-hour/SMS choice is a design decision.
- 'Patients rebook without calling' - a genuine, well-formed business requirement, though it needs a measure: '...within X minutes, without staff involvement.'
- 'Reduce DNA from 11% to 7%' - a business objective/benefit, not a system requirement. It belongs in the business case with an owner, and it cannot be attributed to the system alone.
The BA should not sign off. Signing off a catalogue that mandates a UI design forecloses options and hands the vendor a spec it must match rather than a problem it must solve.
2. What must be resolved before procurement, and what is the risk of not resolving it?
Read the worked answer
The DNA definition. Two departments count it differently, so the 11% baseline is not a single number and the 7% target is unmeasurable. If procurement proceeds, the vendor will be held to a target the trust cannot verify, and the benefit will be disputed at post-implementation review.
Resolve by:
- Agreeing one definition (which appointment types, what notice period, how cancellations by the trust are treated).
- Rebaselining the 11% under that definition.
- Attributing the benefit: the system is one contributor; reminder policy, clinic design and patient transport also affect DNA. State the system's expected contribution, not the whole 4-point drop.
The colour-coding mandate. The clinical director's 'essential' must be tested. Ask what decision the colour-coding supports and how often. If it is genuinely essential, it is a requirement with a rationale; if it is preference, it is a design option. Leaving it in the catalogue narrows the market and may exclude better-value solutions.
Risk of not resolving: procurement on an ambiguous baseline produces a contract that cannot be enforced, a benefit that cannot be evidenced, and a specification that constrains the solution. The BA's sign-off would transfer that risk onto the project.