Wittgenstein's Language Games and Requirements Ambiguity

Ludwig Wittgenstein argued in “Philosophical Investigations” (1953) that the meaning of a word is its use in a language game. Software requirements are a language game where at least 3 communities (business, design, engineering) use the same words with different meanings. A 2020 IEEE study found that 56% of software defects trace back to requirements misunderstanding, not requirements omission. The problem is not that we fail to communicate. The problem is that we believe we have communicated when we have not.

Why are software requirements fundamentally ambiguous?

Because the same word means different things in different language games. “Performance” means response time to the engineer, revenue per user to the business analyst, and interface smoothness to the designer. They all nod in agreement at the word. They are agreeing to different things.

Wittgenstein demonstrated that language does not work by pointing to fixed meanings. It works through use within specific contexts, which he called “language games.” A requirements document is a collision of at least 3 language games happening simultaneously. I have seen a single user story, “the system should be fast,” interpreted as sub-200ms API response (engineering), instant visual feedback (design), and “loads before the user loses patience” (product). All three are valid uses of “fast.” None of them is the same requirement.

This is not a communication failure. It is a structural feature of language. Wittgenstein would say that the ambiguity cannot be eliminated, only surfaced. The task is not to write better requirements but to build conversations that reveal the different games being played. When requirements go wrong, the instinct is to add more words. Wittgenstein’s insight suggests the opposite: add more dialogue. Meaning emerges from exchange, not from documentation.

The next time your team argues about a requirement, ask: “Are we playing the same language game?” The question sounds strange. But the answer, almost always “no,” reveals why 56% of defects start not in code but in the gap between what was said and what was heard.