Business Analyst Times

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.

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 Cecilie_Hoffman@Symantec.com.

Comments (22)

Subscribe to this comment's feed

...
written by slyoung1, April 07, 2009

You know, I receive this at work and am considering unscribing because this series of articles contains completely inappropriate language for our email system. I realize you think it's cute. What it really is is a recipe to force people to just stop reading the BA Times in order to avoid the email police.

• 
• -1
• 
• 

...
written by djras08, April 07, 2009

What do you mean, inappropriate? I thought this was a bad-ass article!

• 
• +0
• 
• 

...
written by arw1969, April 07, 2009

While I don't believe this is a recipe for anything, I do agree that 'Bad-Ass' seems inappropriate, not mention unprofessional. I work with a number of Business Analysts, and I would not associate 'Bad Ass' with the likes of any of them. Inconsiderate, gum-snappers? Yes. Bad Asses? Never.

• 
• -1
• 
• 

...
written by lhdupard, April 07, 2009

"Bad Ass" may be a little uncharacteristic of us, but I am not so highly offended as to miss the good content of the articles. This particular one was on point. I like the suggestion of peer reviews.

• 
• +1
• 
• 

...
written by kabelle, April 07, 2009

It would have been more appropriate to use a headline using the word "weasel" instead of "bad-ass." I think "appropriate" usage could be defined as lacking in street English, yet still maintaining a colloquial style. This *is* a professional eZine.

• 
• -1
• 
• 

...
written by ultrafuchsia, April 07, 2009

While the series name is a bit rich, it is in keeping with the point this series makes. Once you understand the rules, you may have to break them to get things done or get people's attention.

I do, indeed, have to be bad-ass at times and drop the tact and politeness, and then I have to be ready to handle the blow-back. I don't do it all the time, but when needed, it can be remarkably effective.

(Incidentally, culturally speaking, Silicon Valley (where the author works) is a bit immmature. I remember hearing a CEO of a 10,000+ person company drop the F-bomb in an all-hands employee meeting. Bad-ass wouldn't even raise an eyebrow.)

• 
• +0
• 
• 

...
written by ndaza, April 08, 2009

My bad-ass analysts and I frequently have coffee at the Bad Ass Coffee House a block from our work place. We need to get our heads out of the corporate gutter and start enjoying our work.

• 
• +0
• 
• 

...
written by darpearson01, April 08, 2009

Wow, what too sensitive folks. I thought it was a great article and no offense taken. Chill out!

• 
• +0
• 
• 

...
written by pmulvey, April 09, 2009

I agree that we, as BAs, need to push for quantifiable metrics to show the benefit of a particular solution. Too often, we hear sponsors state, "better than it is today" - how much better? 10% better, 100% better? 1% better? When validating the deliverable, BAs could have written "better", coders could have made it "better", but the "better-ness" is only .05% better, and the sponsor is unhappy.

Bottom line - get the sponsor to commit to a success measurement for the goals and objectives.

• 
• +0
• 
• 

...
written by Scoty024, April 11, 2009

I loved this article and found it very usefull. I haven't been a BA long so this is the kind of stuff I love to hear and will be applying to my documents and meetings starting Monday.

Having only known about this eZine for about 1.5 minutes now and having this be the first article I came to... rarely do I get excited about about joining an online community... rarely do I join an online community.

I'm looking forward to what the BA Times has to offer!

• 
• +0
• 
• 

...
written by kburoz, April 14, 2009

Remove the pickles from your bad-asses.

• 
• +0
• 
• 

...
written by johnstde, April 15, 2009

Loved the article. It is right on. I will use many of the suggestions. Thanks Cecilie! On the title, I love all the Bad Ass articles, but have to admit, it is inappropriate where I work. It is ultra conservative here and I have hesitated sending the article to my peers for that reason. For me,, I take no offense,,, I like the idea.

• 
• +0
• 
• 

...
written by SteveM54, April 15, 2009

First, let me comment on the content of the article. I think it does a very good job of succinctly a describing we can all fall into from time to time.

Now on to the debate that the title of the article has generated. I will not propose an opinion one way or another on it but, to me, it illustrates another challenge the BA so often has to overcome. That of multiple interpretations of a single, seemingly simple, term. How often do we find that when a person states something they infer a meaning that is different if not contradictory to others use of the same term.

Just a different perspective.

• 
• +0
• 
• 

...
written by SteveM54, April 15, 2009

And I've just shown another one. Proof read your work before publishing :-)

• 
• +0
• 
• 

...
written by safa, April 22, 2009

If you're that sensitive to the term "Bad-Ass" you shouldn't be a BA - BA's are supposed to be thick skinned to deal with the countless cheap-shots BAs take on projects from all angles. So I suggest you get over it - another thing BAs should be accustomed to doing. Ironic tho, because i think Bad-Ass could be interpreted in many ways (its really up to the individual) but thats kinda what this article is saying we (as BAs) should be weiry of... Maybe BA Times should take some time to define what they mean by "Bad Ass" to clear the confusion/dislike of the term.

• 
• +0
• 
• 

...
written by Naidoo, April 23, 2009

The first poster's core problem hasn't been addressed - that her company's mail sweep program blocks this article. While the content of the article is great and well-received by the community at large (from the comments above), the choice of the title is clearly a problem.

So - we can all write to our mail administrators saying please allow distribution of emails with the word "Ass" in them OR the title of this excellent series of articles could change.

I'm hoping reason will prevail and a slightly less offensive but still fun title can be found...how about Bad-Buttocked ? :-)

• 
• +0
• 
• 

...
written by haroldwolf, April 27, 2009

How about "The Big Bad BA"?

• 
• +0
• 
• 

...
written by jborden, April 28, 2009

I completely agree with the first comment. "Bad-Ass" is inappropriate and often filtered by email servers.

"Tough-Ass" would be a much better word choice.

PS - Remember no matter how bad or tough you are... a good BA doesn't ass-ume anything. Validate those assumptions and make them conditions. :)

• 
• -1
• 
• 

...
written by charlieboz, May 13, 2009

Perhaps she has a bad ass and is just being honest?

• 
• +0
• 
• 

...
written by anujvaidya, May 22, 2009

Removing those weasel words and ensuring that you make a customer commit to a measurable and traceable functionality is the key thing for managing scope. A better your work product is the further you are away from the dog house.

The bigger and more important question is how you do you help your client not even think of those weasel words? How do you help him create a clearer vision of the application? How do you ensure he understands what will bring value to his company?

• 
• +0
• 
• 

...
written by fabian.guttke@transpower.co.nz, June 04, 2009

If you're offended by the expression "Bad-Ass"... tsk tsk.

• 
• +0
• 
• 

...
written by fitcatgirl, August 04, 2009

I think it's sad that the majority of comments on this article are in response to the terminology used as it makes a really important point about a duty of care when delivering project documentation to ensure it is specific and measurable. I am constantly picking up weasel words when peer reviewing documents and am often disappointed when I am labelled as pedantic and picky. However, if you dont understand yourself what you are meant to be be delivering for your business users and sponsors, how can you effectively pass this knowledge on to developers and testers to ensure a successful implementation? When conducting peer reviews on business requirements documents some of the key questions I ask myself are "if I was to develop this would I know what i need to do?", "if I was testing this, what exactly do I need to test to ensure that what has been developed will meet this requirement" and, if my customer challenges whether I have met his expectations - how will I find the evidence to prove that I have done exactly that? Get your business users and sponsors to articulate specifics and ensure your requirements do the same and you maximise your chances of delivering a system that meets your customer's objectives.

• 
• +0
• 
•