Six Tips for Writing Unambiguous Requirements — Or Anything Else
Ambiguity is the great bugaboo of requirements, leading team members in different directions. Here’s how to avoid many types of ambiguity.
There’s a joke about the manager of a nuclear power plant who said the secret of running the plant safely is, “You can’t have too much heavy water.” Does this mean if you have too much heavy water you’re in trouble, or the more heavy water you have the better off you are? It could go either way.
Ambiguity is the great bugaboo of software requirements (and many other types of human communication). Ambiguity shows up in two forms. The first form I can catch myself, when I read a requirement and realize I can interpret it in more than one way. I don’t know which interpretation is correct, but at least I spotted the ambiguity.
The other type of ambiguity is much harder to detect. Suppose a business analyst hands a requirements document to several reviewers. They encounter an ambiguous requirement that makes sense to each of them but means something different to each of them. The reviewers all report back, “These requirements are fine.”
They didn’t find the ambiguity because each reviewer knows only his own interpretation of that…
