I was commenting on a post on Tyner Blain called Top five ways to be a better listener, when I saw a comment by Scott that stated, "reliable and fast can be completely ambiguous terms, because they mean different things to different people." I could not agree more.
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)
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.