Weasel Words to Avoid in Marketing State of the Art

Number 4 in the series, "How to Shoot Yourself in the Pes: 7 means to do software requirements poorly to prepare your projection up for failure and what to do instead."

1. Short-change Time Spent on Software Requirements or Don't do Them at All
2. Don't Mind to Your Client's Needs
3. Don't utilize models
4. Use weasel words
5. Don't prioritize requirements
6. Don't  baseline and modify command requirements
7. Don't practise requirements traceability

You have done a corking job and so far eliciting requirements from your customers and have made good use of models, only your trigger finger is simply itching to shoot yourself in the foot. So what exercise you practice?  Use weasel words to certificate your software requirements!

Weasel word

The American Heritage® Dictionary of the English Language defines information technology this way:

due north. An equivocal word used to deprive a argument of its force or to evade a directly delivery.

[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 significant far beyond the claim actually made."

So why are weasel words especially bad for software requirements? In Karl Weiger's article, "Karl Wiegers Describes ten 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 ambivalence if a requirement statement can accept several different meanings and you're not sure which is correct. A more than insidious form of ambiguity results when multiple readers translate a requirement in dissimilar ways. Each reader concludes that his or her interpretation is correct, and the ambiguity remains undetected until after—when it's more than expensive to resolve.

Some other hint that your requirements are vague or incomplete is that the SRS is missing information the developers demand. If you can't think of exam 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 grade of requirements is a definitive and complete product description, just 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 virtually what is really intended. The extent of this guessing game might non be recognized until the project is far along and implementation has diverged from what is really required. At this point, expensive rework may exist needed to bring things back into alignment."

Karl Weigers lists several solutions to the problem of ambiguity. The commencement one relates to fugitive ambiguity in the kickoff place:

" Solutions : Avert using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize, rapid, user-friendly, like shooting fish in a barrel, uncomplicated, oftentimes, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are especially dangerous. Avoid "and/or" and "etc." like the plague. Requirements that include the word 'support' are not verifiable; define merely what the software must exercise to "support" something. It's fine to include "TBD" (to be determined) markers in your SRS to indicate current uncertainties, only make sure you resolve them before proceeding with design and construction."

Ambiguity causes problems to snowball and the cost to fix increases equally the project life bike progresses. Good software requirements are unambiguous. Is the clarification exact and not vague? Is there a single-interpretation? Is it piece of cake to read and empathize?

Hither 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. Y'all can easily generate custom bingo cards using the Tom Davis Buzzword Bingo generator. Here is a card I generated:

For boosted 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.

Adjacent time I will look at "Don't Prioritize Requirements"

murphysexper.blogspot.com

Source: https://argondigital.com/blog/product-management/use-weasel-words/

Share this post