From 'Build Me a Dashboard' to Real Requirements — A Worked Example
One request, followed through the conversation that turns it into testable requirements — the questions asked, what they surfaced, the requirement nobody had mentioned, and what was deliberately not built.
This is an illustrative example. The scenario and any figures in it are composed to show the method, not drawn from a named client engagement.
An operations manager asks for a dashboard. She has drawn it: four charts, a filter by region, a traffic-light panel down the side.
Building what she drew would have taken six weeks and been used twice. What follows is the conversation that happened instead, and what it produced.
The first question#
"What decision would you make with this that you cannot make today?"
Long pause. Then: "I want to know which orders are going to be late before the customer calls."
That is not a dashboard. That is a prediction, a threshold and an alert — and it is a completely different piece of work from the one that was drawn.
The drawing was not wrong. It was her attempt to describe a need in the only vocabulary available, because "dashboard" is what people are shown when they ask for visibility.
The second question#
"Walk me through the last time this went wrong."
A specific instance, not the general case. She described a Tuesday: a customer rang about an order due that day, she checked three systems, found it had been sitting at a depot since Friday, and spent forty minutes arranging a courier while the customer waited on hold.
From one story:
- The information exists, in three systems that do not talk to each other
- The trigger today is the customer calling — that is the actual detection mechanism
- The cost is a customer already annoyed before anyone knew
- Forty minutes of manual work per occurrence
None of that was on the drawing.
The third question#
"What do you keep in a spreadsheet outside the system, and why?"
This is the highest-yield question in business analysis, and it produced the requirement nobody had mentioned.
She maintained a sheet of "customers who must never be late" — around 30 accounts where a delay triggered a contractual penalty. It was not in any system. She had built it herself, updated it from memory, and two other people had their own versions that disagreed.
That sheet was the real requirement. A late order matters; a late order for one of those accounts matters differently, and the business had no system-of-record for which was which.
What the requirements became#
| ID | Requirement | Acceptance |
|---|---|---|
| BR-001 | Orders at risk of missing their promised date are identified before the promised date | An order with no depot scan within X hours of promised delivery appears on the at-risk list |
| BR-002 | Accounts with contractual delivery penalties are held in a maintained system-of-record | Named owner; changes are audited; a single list, not three |
| BR-003 | At-risk orders for penalty accounts are escalated ahead of others | Ordering reflects account tier; the tier comes from BR-002 |
| BR-004 | The operations manager is notified without needing to open anything | Notification within X minutes of an order becoming at-risk |
Four requirements. Testable, each provable in one sentence.
What was deliberately not built#
The four charts. Nobody needed to look at aggregate trends daily; they needed to be told about individual exceptions. Charts were moved to a monthly review, where a trend is actually useful.
The region filter. She had drawn it because dashboards have filters. Asked when she would change it, she could not think of an occasion.
The traffic-light panel. Replaced by the notification. A panel requires someone to be looking.
Recording these as explicitly out of scope mattered — she had shown the drawing to colleagues, and without the exclusion list they would have expected it.
The outcome#
Delivered as a scheduled check and a notification, plus a small maintained list. Roughly a fifth of the effort of the dashboard, and it addressed the Tuesday she had described.
The penalty-account list — the requirement nobody asked for — turned out to matter to finance and account management too. It was found by asking about a spreadsheet.
What transfers#
Ask what decision the person is trying to make. A drawing is an answer; the need is underneath it.
Ask for a specific incident, not the general case. Generalities produce generalities. "Walk me through the last time" produces facts.
Ask about the spreadsheets. Shadow systems mark exactly where the official system fails, and they are the most accurate requirements documentation in most organisations.
Record what you are not building. People who saw the original drawing will expect it.
See business analysis and the elicitation checklist for the questions used here.