This is the third entry in a series on what constitutes good requirements, regardless of how they are written, stated, shown, or otherwise intended. In this entry, we cover how language affects the ambiguity of requirements. When requirements are unambiguous it means that they have one and only one interpretation by everyone involved.
How would you respond to this personal ad?
SINGLE FEMALE seeks male companionship, ethnicity unimportant. I’m a very good looking girl who loves to play. I love long walks in the woods, riding in your pickup truck, hunting, camping, fishing trips, and cozy winter nights lying by the fire. Candlelight dinners will have me eating out of your hand. I’ll be at the front door when you get home from work wearing only what nature gave me. Call and ask for Daisy.
The Atlanta Humane Society received over 15,000 calls asking for Daisy – a Labrador Retriever!
There is nothing like that terrible moment when two people come to the realization that they have two very different expectations about something like a key feature of your software. Of course, Murphy’s Law states that this realization will occur the day before the product demo to the senior management team. In the previous post in this series, we discussed ways to ensure that the requirements are correct and complete, which goes a long way in preventing these painful situations. But it is not enough.
Ambiguous requirements are actually a great way to get the project ideas off the ground and get the project team in the same ballpark. You can quickly get a sense of the direction the product needs to go, what features are important, and some the technical challenges you will have. Somewhere between a hallway conversation and a white board sketch that was subsequently erased, we get can pretty close. But close only counts in horseshoes and hand grenades, and eventually we need to ensure that everyone involved has the same understanding.
As I’ve said before, this is not an endorsement of one methodology or another. We can try to write all of the requirements perfectly up front, and we can patiently iterate on the product to determine the product readiness as we go. Both are strategies that have evolved to ensure that the product and requirements are lined up. And of course our friend at the IEEE have also pondered this problem in IEEE 830-1998. What follows is a collection of tips and red flags to avoid ambiguous language.
- Replace every pronoun, particularly “it” or “its.” Each should have an explicit and unmistakable reference.
- Avoid passive voice, such as “the counter is set.” (By whom or what?)
- Vague words and phrases such as: almost, applicable, but not limited to, generally, ideally , including, nearly, normally, optionally , sometimes, timely, to the greatest extent, when necessary, where practical.
- Imprecise verbs such as: be able to, be capable, handled, maximize, processed, provide for, supported.
- Implied certainty is a flag for suspicious ambiguity. Avoid words such as: all, always, every, never, none.
- Comparatives such as: earliest, highest, improved, latest, words ending in “-er” or “-est” should be suspect.
- Words and phrases that are not or cannot be quantified such as: , accomplish, achievable, adequate, as a minimum, better, correct (or correctly) , efficient, fast, faster, flexible, higher, infrequent, less, minimum acceptable, minimum required, modular, normally, often, possible (or possibly) , several, slower, steady-state, sufficient, to be associated with, to be compatible, to the extent required, to the extent , specified, typically.
- Words and phrases whose meaning can be disputed between developer and customer such as: achievable, adjacent, average, coincident, degraded, easy-to-use, effective, finish, flexible, instantaneous, intuitive, minimum, nominal, normal, reasonable, appropriate, seamless, simple, simultaneous, state-of-the-art, synchronous, transparent, user-friendly.
The next post in this series will be delivered soon, ideally with a higher level of satisfaction, acceptable meaning, and improved user-friendliness. It will be published in the future…
