Bad Practices - Part V - Possibilities & Dreams

Suggestions or possibilities
In my last post, requirements were defined as needs. Note that there is a significant difference between a need and a possibility. One must be wary of the language used to define requirements. Avoid using terminology such as: may, might, should, ought, could, perhaps or probably. Either a client wants something or they do not want it.

In the past, I have seen language used to indicate the importance of a requirement. For example, "must", indicated that without this requirement being fulfilled the project would not deliver maximum benefit while, "could," indicated that this feature would be nice to have but is not necessary. This method works however, I suggest using something like mandatory, need-to-have and nice-to-have to show how important a requirement is to a project.

Avoid wishful thinking
Business users want everything to be perfect. A system will always be available, never fail, never slow down and be future proof. Unfortunately the last time I checked, I did not live in a utopian society. Murphy's law is something one must be vigilant against. What does this have to do with requirements?

The implication is that one must never interpret wishful thinking or impossible terms as requirements. A customer may want 100% reliability, but as a business analyst, one must recognize that this is not achievable.