A six-step requirements interview that ends in a testable sentence

Most requirements interviews end with minutes, and minutes are the wrong artifact. A minute records what people said. What the next stage needs is one sentence that two people can hold a prototype against. Almost all rework starts here, and it does not start with a badly worded question. It starts with an interview that stopped as soon as an answer sounded reasonable.

Five slots with no adjectives

Aim at a shape, not a topic. The sentence has five slots:

When a certain kind of input arrives, a named role gets a named output in a named place. When a stated condition does not hold, the case goes to a named person. We check it against a named dataset over a stated window.

Filled in, the sentence can fail; filled in badly, it can be argued with. Left unfilled, it becomes the description everyone agrees with and no one can test, which is the most expensive thing an interview can produce.

The slot people drop is the stop condition. "Generate a reply", with no rule for when to hand the case to a person, cannot be built badly. It can only be built forever, because each wrong answer looks like a tuning problem and tuning has no end. The stop condition is what turns quality from an opinion into a boundary.

Two of the slots, the dataset and the window, are the metric definition table arriving early, as one sentence instead of five columns. An interview that fills them ends an argument before it starts.

The six steps

1. Purpose before object. Ask what the output changes, and for whom, before asking what the tool is. Skip it and the interview becomes a feature list: every answer begins with "we could add", and when you ask what will be different on Monday morning, either the room goes quiet or someone says efficiency. A purpose that cannot name a person and a decision is not a purpose yet. This is also where you find out who is exposed if the thing works, which the seven questions put inside the first two weeks.

2. Land on the most recent real case. Do not ask how the process works. Ask them to open the last actual instance — the message, the order, the ticket — and walk it with you. Skip it and you collect averages: "usually about two hours", from someone who was not in the room, attached to nothing. Averages cannot be verified, and they are exactly the numbers you will be held to later.

3. Stop where a judgement happens. Every flow has a point or two where a person decides. They arrive as "it depends", "we look at it", "here we would check". Stop on those. Ask what the conditions are, who decides, and what happens when the decision turns out wrong. Skip it and the flow looks smooth; three weeks later the prototype is almost right, and stays almost right, because the branch nobody recorded is the branch it keeps getting wrong.

4. Check the costliest step. Ask which step takes longest, then check the answer against the artifact. In a price enquiry the time usually goes into confirming stock and price with two other people, not into writing the reply, so a tool that writes faster saves a fraction of what the customer expects. Skip it and the efficiency claim attaches to the visible step rather than the expensive one, and the first measurement after go-live disappoints both sides.

5. Restate once, then test the restatement. Say the sentence back and walk two cases through it: one the customer raised, one the material does not cover. If the second produces "that case we handle differently", you have found the boundary. Skip it and you get "yes, roughly" with no correction, which usually means politeness, not agreement. The correction then arrives at the demo, at the worst possible price.

6. Offer one bounded next step. Not a plan. One group of users, one week, one output, one named dataset, and one named person on their side who will supply it. Skip it and the interview ends with "we will send the materials over" — no date, no owner — and two weeks later the build starts on documents that describe the process as designed rather than the one that runs.

Question wording matters less than the order. If you need a starting set, the discovery question bank is a list to adapt rather than recite.

Write it the same day

The handbook this sequence comes from is blunt about timing: a reconnaissance record written the next morning loses about a third of its detail, and the lost third is always the part you were unsure about. That is the part worth keeping, because it is the part that will be contested later.

The version that produces a document instead

The familiar failure is a twelve-page write-up with a section per department, each internally consistent, and no sentence in it. At the demo the manager says this is not what they meant, and nobody can point to where it was agreed, because the document recorded statements such as "the service team wants to respond faster". That sort of statement cannot be wrong, and therefore cannot be right.

A quieter failure looks like success. The interview is so productive that it jumps from purpose to architecture, and the written requirement describes the documented process. The one that runs — the spreadsheet, the group chat, the private list — never makes it into the sentence, and never makes it into the build either.

Before you leave the room

• The sentence has all five slots, including the stop condition.
• One real artifact is attached to it, not a description of one.
• The person who does the work has heard the sentence and corrected details, not structure.
• One bounded next step, with a date and a named person on the customer side.
• The dataset to check against is named, and someone has confirmed it can be exported.
• The sentence and the artifact list are written down before the day ends.

If the sentence cannot be read aloud to the person who does the work and be corrected at the level of detail, the interview is not finished. It is a meeting that ended.

What the six steps surface is usually not a requirement but a judgement the operator has stopped noticing they make. Extracting tacit knowledge is the next move: the interview produces the sentence, and the extraction produces the conditions under which the person applies it.