Everybody signed off the requirement and two of them still mean different things by it. How do you catch that before the build?

Why sign-off is weak evidence

A signature says the sentence was acceptable, and a sentence is acceptable to two people whenever it is compatible with both of their assumptions. That is not a failure of diligence by anybody: general wording reads as agreeable precisely because each reader fills the gaps with what they already believe. The head of operations reads "customers should be notified when their order is delayed" and pictures an email once, when the delay is confirmed. The customer service manager reads the same words and pictures a notification each time the estimated date moves. Both signed. Neither was careless.

The consequence lands at demonstration, when the build satisfies one reading and the other stakeholder says this is not what we agreed. That conversation is expensive and it is also unwinnable, because they are correct: it is not what they agreed. So the whole problem is one of detection, and detection is the part of elicitation that has a technique.

Examples, not rewording

The instinct is to make the sentence more precise, and precision alone does not help, because a more careful sentence is still read through the same assumptions. What breaks a false consensus is a specific case whose correct handling differs between the two readings.

Take the notification requirement. The question that exposes it is not "what do you mean by notified" — both will answer that confidently and identically. It is: an order due Tuesday moves to Wednesday on Monday morning, then to Thursday on Monday afternoon, then back to Wednesday on Tuesday. How many messages does the customer receive, and what does the last one say? Now they cannot both be right, the difference is on the table in one minute, and neither person has had to admit to a misunderstanding, because the disagreement is about a case rather than about their comprehension.

The general form is to construct examples at the boundaries and let the answers diverge. Pick the zero case, the many case, the simultaneous case, the reversal case and the retrospective case. Ask each stakeholder to answer independently before hearing the other, in writing if you can, because a second person in the room will unconsciously converge on the first answer given.

The words that hide it

Ambiguity clusters in predictable places, and knowing them lets you find candidates for testing quickly rather than examining every sentence.

Pattern	What it conceals	Example to force
Undefined actor ("the system notifies the customer")	Which customer record, on a joint account	Two names on one account, different email addresses
Bare quantifier ("all outstanding invoices")	Whether disputed or credited items count	An invoice in dispute and a credit note
"And/or" in a condition	Whether both must hold or either	A record satisfying only one condition
Undefined timing ("when the order ships")	Which system event, and what if it is reversed	A shipment cancelled after the event fired
Passive voice ("must be approved")	Who approves, and what if they are absent	The approver on leave for a fortnight
Comparatives ("faster", "improved")	Against what baseline	The current measured figure, if one exists

The pattern worth noticing is that every one of these is resolved by naming a specific record, a specific person or a specific number. Ambiguity survives in the abstract and dies on contact with an instance, which is why the technique is to reach for an instance rather than a definition.

Use real data

Hypothetical examples let people answer in principle. Real records do not, and they also surface volumes, which changes the decision.

A worked case. The requirement says active customers receive the new statement. Pull the actual data before the workshop: 12,400 customer records, of which 9,800 have transacted in the last 90 days, 1,100 have an open balance but no transaction in 18 months, and 260 have a live direct debit and no transactions at all. Now ask each stakeholder which of those three groups is active. Finance almost always counts the 1,100 because they represent money owed; marketing usually does not. That is 1,100 customers, roughly 9 per cent of the base, receiving or not receiving a statement, and the disagreement has a number attached rather than being a matter of interpretation. Numbers end these arguments in a way that definitions do not, because a stakeholder who will happily argue about the meaning of active will not argue that 1,100 people should get nothing.

Doing this before the workshop rather than during it is the difference between a decision and an action item.

Distinguish it from the disagreement nobody wants to have

Sometimes the vagueness is not accidental. Two stakeholders who know they disagree will occasionally accept a general form of words precisely because it postpones the argument, and each expects the detail to fall their way later. That is a different problem from a genuine misunderstanding and it needs a different response.

You can tell them apart by what happens when you present the example. A genuine misunderstanding produces surprise, then a quick resolution, usually with one party saying they had not thought about that case. A deferred disagreement produces evasion: the case is dismissed as an edge case, the answer is that it depends, or the discussion moves to who ought to decide. When you see that, stop trying to elicit and start escalating, because no amount of careful questioning resolves a conflict that both parties have chosen to avoid. The move is to write down both readings, state the cost of each, and take it to whoever holds the decision.

Record examples, not a better sentence

The output of all this should be the examples with their agreed answers, held next to the requirement and carried into the acceptance criteria. A rewritten sentence loses most of what you learnt, because the next reader brings their own assumptions to your improved wording and the cycle restarts.

Concretely, the resolution reads as a short table of cases: an order whose date moves twice in one day produces two notifications, each stating the current date; an order whose date reverts to the original produces a notification confirming the original date; an order cancelled after a delay notification produces a cancellation message and no further delay messages. A developer can build from that, a tester can test it, and a stakeholder who reads it in six months cannot reinterpret it. That is the whole point: examples are the only form of requirement that is resistant to being read charitably.

The failure that persists even in careful teams is that this checking happens at the requirement stage and never again. Rules change during the build, and a rule changed in a refinement conversation gets no examples, no second reader and no cross-check. So the habit that matters is applying the same test to every mid-build change, which costs about five minutes and is the reason experienced analysts ask for an example when a developer describes a rule back to them.

Agreement on wording is not agreement on meaning, and rewording will not tell you which you have. Put a specific case in front of each stakeholder separately, and keep the answers as the requirement.