Ambiguity and what to do about it [requirements engineering]

A major concern of most software customers, managers, and requirements engineers is to remove ambiguity in communication of requirements and specifications. The most obvious solution is to try to anticipate all possible misunderstandings and write the requirements perfectly precisely. In practice, this does not work. This talk explains why it does not work, and offers easy, inexpensive methods for removing ambiguity - methods that anyone can do. The fundamental principle is to add redundancy, especially redundancy relating to context. High-bandwidth, informal communication is always a necessary supplement to formal, mathematical expressions. As software development is in essence the creation of formal, executable descriptions for the informal domains where our intents lie, we explore many ways to break up this process into small stages, allowing programmers and customers to detect ambiguity through real-world feedback.