Bad-Ass BA Caution!

Weasel Words Will Send You to the Requirements Dog House

The holy grail of writing requirements is for the requirement to be validated before the application or system is released. Quality Assurance analysts inherit the work of Business Analysts. QA analysts are looking for something they can measure. All too often we business analysts are guilty of allowing what I call “weasel words” to nest in our requirements. Just as catching a wriggly weasel is hard, so is trying to validate a requirement that has no boundaries.

Weasel words are qualitative descriptors that are typical of that most difficult of categories of requirements, User Requirements. User requirements are often given to us with a wave of the hand, “Oh, you know what I mean. I just want it to be good.” “Good compared to what?” you ask, knowing in your heart this is going to be an uphill climb. “Well, better than what we have now. We’ll talk next week, okay? Bye!” With that farewell, the customer has just weaseled out of giving you something quantifiable, and, when the QA analyst looks at your BRD or Functional Requirements document, you will be in the Requirements Dog House.

Cultural Note: “In the dog house” is an idiomatic expression for being in trouble. Dog houses are a small shelter separate from the main dwelling. In the middle 1900s, if a wife knew her husband was out drinking, she might lock him out, forcing him to sleep it off in the dog house.

Here is a list of my favorite weasel words. I’m sure you have some to add.

average	optimize
best-of-breed	optionally
best-in-class	preferably
easy	probably
efficient	rapid
etcetera	reasonable
fast	robust
flexible	simple
improved	state-of-the-art
intuitive	sufficient
maximize	user-friendly
minimize	usually

These words may creep in from the original benefits statement. There’s more to creating a requirement than just restructuring a benefits statement into the Trigger Actor Action Condition syntax and removing the weasel words from the text. Weasel words indicate that the customer’s thinking in a particular area is fuzzy; there will be a lot of work to help them articulate their intentions and true needs. As business analysts, we must ask,

• “Maximize? Do we have a baseline to maximize from? How much do we need to maximize before the improvement is satisfactory? Are we looking for a 25% improvement or a 65% improvement?”
• “When we say, ‘state of the art,’ do we mean that we want an application that is in the Leadership quadrant of Gartner’s Magic Quadrant?”
• “When we say, ‘flexible,’ what attributes do we anticipate needing to change?”
• “When we say, ‘usually,’ that implies that sometimes ‘such and such’ will not be true. Could you tell more about the circumstances when it is true and when it is not true?”
• “Rapid? Fast?” what part of the user-system interaction are we talking about? Could we focus on the time it takes the system to process the transaction request and respond back to the user? Fast meaning sub-second response?”

Customers don’t understand that weasel words weaken the BRD. Weasel words deprive the system designer of clear performance boundaries. Weasel words make test script writing a nightmare for the QA analysts. And, when conducting User Acceptance Testing, the BA may wish she could run to the dog house to avoid the customer’s disappointment.
So, how do you catch weasels words and address them properly? Try conducting a peer review of your BRD or Functional Requirements document with your friendly QA analyst or another BA. Neither needs to know the domain of the document, just give them your list of weasel words and promise them a doughnut for every one they find.

---

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].