Bad Practices - Part I - Ambiguity

I have been focusing on good practices to employ when gathering and articulating requirements. For the next series of posts I will be discussing things to avoid. The first bad habit would be to introduce ambiguity to requirements.

Requirements are intended to further understanding. Great care must be undertaken to ensure that their meaning is understood. What happens when they are not clear?

One can say, "To maintain the ecological & environmental balance within the facilities, when using transportation services ensure the facilities remain in a locked-down state.” Alternatively, one can say, “When you enter & exit the building, close the door.” By using excessive language, the underlying meaning can be lost or misinterpreted.

If one has to go over a requirement three, four, five or more times; the requirement is most-likely unclear and ambiguous. Even worse, what if everyone thinks they understand but their interpretations are all different? What is the consequence of this to a project?

My tips for reducing ambiguity are:

1. Be brief. Revise. Rewrite. (Sounds familiar - See my post 3 simple rules for business writing.)
2. Try to view the requirements from the perspective of someone else.
3. Review with different users.

The acid test for understanding - Can someone who has no knowledge of my project understand what is going on by reading my requirements?