I am not sure if you recall my earliest posts, but ambiguity is one of the biggest requirement pitfalls. You can refer to the following: Requirements & ambiguity, Bad Practices - Part I - Ambiguity and Bad Practices - Part IV - Speculative & Vague Terms to understand the consequences of a miscommunication.Then I got the not so brilliant idea to start up a list of simple words that can be viewed as ambiguous within the context of business requirements. This list is by no means exhaustive:
- Reliable (from Scott)
- Fast (also from Scott)
- User-friendly
- Flexible
- Easy-to-use
- Never
- Intuitive
- Future-proof
Basically, if you hear qualitative statements from your clients, these are areas where you may need to clarify things using simple techniques such as active listening. This may sound like paranoia but remember it is much cheaper to clean up a miscommunication early in a project versus later in the system development life cycle.
There is a great post on Tyner Blain called How to interview when gathering requirements that I suggest you read as it will give you tips on how to extract the information you need.
No comments:
Post a Comment
Thanks for taking the time to comment or provide feedback!