There are so many things that impact the quality of our requirements. We have the ability to influence many of them, but our influence is often limited. One thing we do have control over are the words we use to describe and document (if needed) requirements.
It can be tough to choose the right words. Pressed by time constraints, we often fall into the habit of using vague (a.k.a. mushy) words so we can keep our requirements moving forward. These mushy words may speed up our requirements process short-term, but they lead to gaps, defects and disappointed end users downstream.
Here are a few examples of mushy words and some more precise alternatives:
Do you see how the mushy words create a false consensus? When you present mushy words to stakeholders, everyone agrees and moves forward with their own understanding of what it means to manage, process, review or track. Then, the developers and testers get to work on the mushy words and compound the confusion because mushy words force them to guess or assume end user needs.
So, it’s no surprise that mushy words lead to disappointed end users. The solution does not meet their expectations, because their expectations were not properly elicited and set.
Luckily, you have lots of control over the words you use. Do your part to create high value solutions that delight your end users by choosing words that are actionable, testable and codeable. It’s an excellent way for every BA to contribute to a successful project!