Requirements Disambiguation

Every requirement is a compression of intent, and the decompression is where projects fail. The cost of a misunderstood requirement compounds through every downstream decision; resolve ambiguity before code, not after.

Recover the intent behind the words

1. Find the underlying job: why is this being asked? The stated solution often hides the real problem (the "faster horse" trap). Ask what outcome makes this a success.
2. Identify the actors and their conflicts: different stakeholders want incompatible things and each assumes theirs is "the" requirement. Surface the conflict explicitly rather than averaging it into mush.
3. Make it testable: rewrite each requirement as an observable acceptance criterion. "Fast" → "p95 < 200ms"; "easy" → "completes task in ≤ 3 steps without docs". If you can't write the test, the requirement isn't defined.

Hunt the unstated

The dangerous requirements are the ones nobody says because "everyone knows":

• Non-functional: latency, scale, availability, security, compliance, accessibility, localization — almost always assumed, rarely stated, frequently the hardest part.
• Edge cases: empty, maximum, concurrent, malicious, offline, partial-failure. "What happens when there are zero / a million / a hostile user?"
• The negative space: what is explicitly out of scope? Undeclared non-goals become scope creep.
• Implicit constraints: existing systems, deadlines, budgets, team skills, regulatory limits.

Adversarial validation

• Take the requirement literally and construct a technically-compliant solution the stakeholder would hate. That gap reveals the unstated intent.
• Find two readings of the same sentence that lead to different implementations; force a decision before building.
• Ask "how will we know this is done and correct?" — if the answer is fuzzy, the requirement is fuzzy.
• Check for requirements that silently conflict (e.g., "fully audited" + "no added latency"); they can't both win — surface the tradeoff to the decider.

Non-obvious risks

• Stakeholders state solutions, not problems; building the stated solution can perfectly miss the actual need.
• "Obvious" shared assumptions differ between people; the most expensive bugs are agreed-upon misunderstandings.
• Gold-plating unstated quality bars wastes effort; under-delivering on assumed ones causes rejection. Both come from leaving them unstated.

Output structure

Deliver: the underlying job-to-be-done, each requirement rewritten as a testable acceptance criterion, the explicit non-goals, the surfaced conflicts with the decision needed from whom, and the edge-case + non-functional requirements that were implicit and now must be confirmed.