Requirements & Requirements Management

Five Ways Ambiguous Language Will Ruin Your Requirements

By |

When a requirement can be interpreted in more than one way, problems ensue. In his paper, “Writing High-Quality Requirements,” expert Karl Wiegers gives examples of ambiguity issues in requirements and best practices to successfully clarify them. Here are five sources of ambiguity and tips to overcome. 

Complex Logic

Boolean logic offers many opportunities for ambiguities and missing requirements. Try using a decision tree to reveal gaps and ensure clarity.
Use A Decision Tree To Remove Ambiguity From Complex Logic

Omissions

When requirements lack important pieces of information, it’s unlikely that all readers will interpret them in the same way unless they make precisely the same assumptions. Be sure to include trigger causes that lead to the behavior and indicate what is required to happen because of or after the behavior. Further, specify the action as well as the reverse operation as part of the requirement. For example:

“The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.”

Changes to:

“The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.”

Boundaries

Boundary values in numerical ranges are common sources of ambiguity, and they are a good place to look for missing requirements. One easy way to resolve boundary confusion is to show the information in a table. If you see a number represented in two ranges, you know something needs fixing. Conversely, if there is no value in one of the table’s cells, you can quickly identify the missing requirement.
Use Tables To Remove Ambiguity In Boundary Values

Synonyms

Using synonyms to describe the same thing across different requirements unnecessarily introduces ambiguity. Will the reader automatically know you mean the same thing or might they assume them to be different? If they are truly identical, use the same word consistently. If there are differences, even subtle ones, place such definitions in a shared glossary so team members understand the terms and use them consistently.

Pronouns

Pronouns can be a source of headaches in a requirements specification. Be certain that the antecedent is crystal clear whenever you employ a pronoun. If you use a word such as this or that, there should be no confusion in the reader’s mind about what you’re referring to.

Learn more requirements best practices from expert Karl Wiegers. In his paper, “Writing High-Quality Requirements,” he explains they begin with proper grammar, well-constructed sentences and a logical organization.

Jama Software
Latest posts by Jama Software (see all)