Bad Practices Part I – Ambiguity

266614_9797

This is part I of Bad Practices Series

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 and environmental balance within the facilities, when using transportation devices, ensure the facilities remain in a locked-down state”. Alternatively, one can say, “When you enter and 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 time; the requirement is most likely unclear or ambiguous. Even worse, what if everyone thinks they understand but their interpretation 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 review 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?

 

Shares