The document exists. It was reviewed. It was signed off.
The engineer reads it and builds what it describes. The stakeholder sees the result and says "That is not what I meant."
This is not a communication failure. It is a structural impossibility.
⸻
The Ambiguity Gradient
Natural language is ambiguous by design. A sentence like "The user should be able to edit their profile" contains at least four implicit decisions: which fields, which users, what validation rules, and what happens when the edit fails.
The requirements document does not specify these decisions because the stakeholder does not think at that level of resolution. They think about the outcome. The engineer must think about the mechanism.
This gap cannot be closed by writing more requirements. More words produce more ambiguity, not less. The document grows. The precision does not.
⸻
The Frozen Assumption
Requirements are written at a moment in time. They capture what the stakeholder understood about the problem on the day the document was drafted.
By the time engineering begins, the business context has shifted. A competitor has launched. A customer has complained. Leadership has changed the priority stack. But the requirements document is static. It reflects the world of three weeks ago.
The engineer builds against the frozen assumption. The stakeholder evaluates against the current reality. The gap between them is not the engineer's fault or the stakeholder's fault. It is the fault of treating a living problem as a fixed specification.
⸻
The Telephone Effect
The stakeholder describes the need to the product manager. The product manager writes the requirement. The designer creates the wireframe. The engineer reads the wireframe and the requirement and builds the feature.
Each handoff compresses information. Each compression introduces interpretation. By the time the code is written, the original intent has passed through three or four layers of translation. The result is like a message passed through a chain of translators: technically coherent, semantically drifted.
⸻
The Conversation Fix
Requirements documents are useful as starting points. They are dangerous as contracts.
Replace the signed-off document with a continuous conversation. Build small. Show early. Let the stakeholder react to a working prototype instead of imagining the final product from prose.
The fastest way to discover what the stakeholder actually wants is to show them what they asked for. The difference between the two is where the real requirements live.
End.