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.

Karl Wiegers
Analyst’s corner

--

A photo of a young woman who looks confused.
Human photo created by wayhomestudio — www.freepik.com

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…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com