Number 4 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”
- Short-change Time Spent on Software Requirements or Don’t do Them at All
- Don’t Listen to Your Customer’s Needs
- Don’t use models
- Use weasel words
- Don’t prioritize requirements
- Don’t baseline and change control requirements
- Don’t do requirements traceability
You have done a great job so far eliciting requirements from your customers and have made good use of models, but your trigger finger is just itching to shoot yourself in the foot. So what do you do? Use weasel words to document your software requirements!
Weasel word
The American Heritage® Dictionary of the English Language defines it this way:
n. An equivocal word used to deprive a statement of its force or to evade a direct commitment.
[From the weasel’s habit of sucking the contents out of an egg without breaking the shell.]
Wikipedia defines it this way:
“’Weasel words’ is an informal term for words and phrases that, whilst communicating a vague or ambiguous claim, create an impression that something specific and meaningful has been said. Weasel words manage to vaguely imply meaning far beyond the claim actually made.”
So why are weasel words particularly bad for software requirements? In Karl Weiger’s article, “Karl Wiegers Describes 10 Requirements Traps to Avoid”, trap #3 is “vague and ambiguous requirements”. Karl Weigers lists some of the symptoms of vague and ambiguous requirements as follows:
“Symptoms: Ambiguity is the great bugaboo of software requirements. You’ve encountered ambiguity if a requirement statement can have several different meanings and you’re not sure which is correct. A more insidious form of ambiguity results when multiple readers interpret a requirement in different ways. Each reader concludes that his or her interpretation is correct, and the ambiguity remains undetected until later—when it’s more expensive to resolve.
Another hint that your requirements are vague or incomplete is that the SRS is missing information the developers need. If you can’t think of test cases to verify whether each requirement was properly implemented, your requirements are not sufficiently well defined. Developers might assume that whatever they’ve been given in the form of requirements is a definitive and complete product description, but this is a risky assumption.
The ultimate symptom of vague requirements is that developers have to ask the analyst or customers many questions, or they have to guess about what is really intended. The extent of this guessing game might not be recognized until the project is far along and implementation has diverged from what is really required. At this point, expensive rework may be needed to bring things back into alignment.”
Karl Weigers lists several solutions to the problem of ambiguity. The first one relates to avoiding ambiguity in the first place:
“Solutions: Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize, rapid, user-friendly, easy, simple, often, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are particularly dangerous. Avoid “and/or” and “etc.” like the plague. Requirements that include the word ‘support’ are not verifiable; define just what the software must do to “support” something. It’s fine to include “TBD” (to be determined) markers in your SRS to indicate current uncertainties, but make sure you resolve them before proceeding with design and construction.”
Ambiguity causes problems to snowball and the cost to fix increases as the project life cycle progresses. Good software requirements are unambiguous. Is the description exact and not vague? Is there a single-interpretation? Is it easy to read and understand?
Here is a list of weasel words for software requirements I have compiled. Do you have some favorites I have missed?
For fun, you can play a variant of Dilbert’s Buzzword Bingo, focused on software requirements weasel words. You can easily generate custom bingo cards using the Tom Davis Buzzword Bingo generator. Here is a card I generated:
For additional weasel reading:
(Software requirements specific) Karl Wiegers Describes 10 Requirements Traps to Avoid
(General) Weasel Words.com
(General) Wikipedia entry on Weasel Words
Don’t shoot yourself in the foot on your next project! Resolve today to avoid weasel words in your software requirements. The choice is yours.
Next time I will look at “Don’t Prioritize Requirements”
