step 3 / 32 · 5 min
Finding out what is actually needed
Requirements arrive as solutions. "Add a dropdown to filter by region" is an answer to a question nobody wrote down, and building it without finding the question is how teams ship things that get used twice.
Ask what they will do with it
"Add an export to CSV button."
why: "So I can open it in a spreadsheet."
why: "To total last month's orders by region."
why: "For the Monday report."The request was a CSV export. The need is a monthly regional total, which might be a page, an email, or a number on a dashboard. The export is one solution and probably not the best one.
Asking twice is usually enough. Asking five times becomes an interrogation.
Functional and everything else
Functional: what it does. "A user can reset their password by email."
Non functional: how well. Speed, availability, capacity, security, accessibility, compliance.
The second category is where projects fail late, because the functional requirements were written down and these were assumed. "It should be fast" is not a requirement, as the earlier page argued, and neither is "it should be secure".
Write it so it can be checked
| Vague | Checkable |
|---|---|
| Fast | search responds within 400ms at p95 with 500 concurrent users |
| Reliable | 99.9 percent monthly, measured at the load balancer |
| Secure | passwords hashed with bcrypt, all traffic over TLS, no secrets in logs |
| Easy to use | a new user completes signup without help, tested with five people |
The discomfort of writing the right hand column is the point. It forces a decision the vague version let everyone avoid, at a time when changing your mind is free.
Edge cases are requirements
What happens when the list is empty, the name has an apostrophe, the payment is declined, the upload is 4GB, two people edit the same record, the third party is down?
These are where most defects live, and asking about them during planning is far cheaper than discovering them in review or in production.
Say what is out of scope
Writing down what you are not building is as valuable as what you are. "This release does not include bulk editing" prevents the conversation three weeks later where someone assumed it did.
Your responsibility
An engineer who builds exactly what was asked and knew it would not work has not done their job. You have information the requester does not: what is expensive, what is risky, what is nearly free.
Saying "that will take three weeks, but this variation takes three days and covers the same need" is the most useful thing an engineer does in a planning conversation.