Requirements Ambiguity

In the AI Story

The nurse who says she needs fast access to vital signs may mean something specific about visual layout, click depth, default time window, and alerting behavior — none of which she will articulate until she uses a system that gets one of these wrong. She does not have the requirement in propositional form waiting to be extracted. She has a set of operational needs that will surface only when the system's behavior fails to meet them. The requirements elicitation conversation, however skilled, cannot close this gap, because the conversation addresses the user's current understanding, and the current understanding does not include the needs that the not-yet-existing system will reveal.

This is why iterative development became orthodox. Build something. Show it to users. Observe what goes wrong. Adjust. Repeat. AI compresses each cycle from months to hours, which is valuable — more iterations per unit of calendar time means more opportunities to discover what the users actually need. But the value of the acceleration depends on the quality of the observation between iterations. If the builder generates a new version without observing how users struggled with the previous one, the iterations degenerate into fluent fabrication: rapid production of variants that do not converge because the convergence requires information only observation provides.

The AI does not perform the observation. It generates implementations from specifications. The specifications must come from somewhere, and requirements ambiguity means they cannot come from asking users what they want, because users cannot tell you. They must come from watching users, inhabiting their context, inferring what they need from what they do. This is embodied work that requires the builder to be present in the users' world in ways no AI substitutes for.

Requirements ambiguity interacts with the second-system effect and the tar pit in predictable ways. The second-system builder over-specifies based on requirements inferred from first-system experience, and the inferred requirements encode the first system's context rather than the second system's users. The tar pit accumulates when each iteration adds features to address requirements the previous iteration revealed, and the additions interact combinatorially.

Origin

Brooks identified requirements ambiguity as the first and most important form of essential complexity in No Silver Bullet (1986). The observation was not original — requirements-specification literature had discussed the problem for decades — but Brooks's framing, as a form of complexity no tool could reduce, gave the observation its enduring analytical weight.

Key Ideas

Requirements emerge through use. They are not discoverable in advance because they are constituted by the user's interaction with the system that does not yet exist.

Three distinct things differ: what users say, what they think they want, and what they need. The three align only by accident.

Iteration compresses but does not eliminate the gap. Faster iteration is better, but only if each iteration includes observation of how users actually behave.

AI accelerates the fabrication but not the observation. The builder must supply the observation; otherwise rapid iteration diverges rather than converges.

Requirements ambiguity is why embodied presence matters. The builder must be in the users' world in ways that surface needs users cannot articulate.