The Craft of Requirements — Why "We Built Exactly What They Asked For" Fails

Why shipping precisely what a stakeholder asked for produces software that works and nobody uses. Stated versus latent needs, use cases, turning "fast" and "secure" into numbers, and a set of question templates that expose ambiguity on the spot.

A Quarter-Inch Drill and a Quarter-Inch Hole

There is an old line in marketing: people don't want a drill, they want a hole. What someone asks for is a tool. What they need is an outcome.

The same thing happens in software. Someone asks for a CSV export button. You build the button. It ships, it passes acceptance, everyone signs off. Six months later almost nobody uses it. Ask again and it turns out what they actually wanted was "get the month-end numbers to accounting," and CSV was simply the only mechanism they could think of at the time. The thing that would have mattered was pushing the numbers straight into the accounting system.

"We built exactly what they asked for" is the easiest excuse to say and the least useful one to have. Requirements engineering is the work of neither swallowing nor dismissing what a stakeholder says, but digging down to the outcome underneath it and rewriting it in a form you can verify. Sometimes the rewrite comes out identical to the original request. Even then, arriving there by checking is a completely different situation from arriving there by assuming.

Needs Come in Three Layers

What is in a stakeholder's head does not arrive in the order they say it. It sits roughly in three layers.

Stated needs are the ones they can put into words themselves. "I want a CSV export." "I need a login screen." These come out when you ask — but notice that by the time they surface, they have already been shaped into somebody's proposed solution.

Latent needs are the ones they would be delighted to have but will never volunteer, for the simple reason that they don't know such a thing can be built. "I spend twenty minutes a month retyping these figures by hand" will come out if you ask the right way. "Please automate that retyping" will not. People can only assemble requests out of options they already know exist.

Assumed needs are the ones considered too obvious to be worth saying. "The totals don't drift." "Nobody can see someone else's salary." "Pressing save actually saves." Meeting these earns you no credit; violating one destroys trust instantly. The Kano model in quality engineering names this asymmetry directly, separating must-be quality (expected by default, a source of dissatisfaction when absent) from attractive quality (not missed when absent, delightful when present). The layer that causes accidents is the first one: nobody said it, so nobody built it, and after release you hear "well, obviously."

So what happens if you carefully collect only the stated needs and build those? You get a system that behaves perfectly on the cases you heard about and falls apart on the ones you didn't. The shape of that failure is very close to overfitting in machine learning.

"Need" and "Requirement" Are Different Words

These get used interchangeably in conversation, but they belong to different stages of work. ISO/IEC/IEEE 29148, the international standard for requirements engineering, treats stakeholder requirements and system requirements as distinct artifacts.

• A need is what a stakeholder, user, or operator wants to be true. The subject is a person.
• A requirement is a condition the system must satisfy in service of that. The subject is the system, and whether it is satisfied can be judged.

"I want to stop retyping figures into accounting" is a need. "The system shall transmit the current month's journal entries to the accounting system's API by 09:00 on the first business day after close" is a requirement. Two different people can judge the second one identically. That is the whole test of requirement quality: can everyone who reads it write the same test?

Use Cases: Putting a Person Back in the Subject Position

Write features as a bullet list and the subject quietly becomes "the system" everywhere, which drops out who is doing this, why, and in what order. A use case rewrites the same thing from the human side. The minimum viable form has five parts.

• Actor: who. "The accounting clerk," not "the user"
• Preconditions: what is already true before it starts. "The current month's sales are finalized"
• Main scenario: the numbered happy path, kept to five to nine steps
• Alternate flows: where it branches. "If the API times out"
• Postconditions: what is true when it ends. "At least one journal entry for the current month exists in the accounting system"

Most of the value is in the last two. The main scenario comes out roughly the same no matter who writes it. But the moment you try to write alternate flows, you are forced to ask "and what happens when that fails?" — and any place where the answer is undefined becomes visible on the spot. Postconditions are the act of deciding, up front, what you will look at to declare the thing done.