How To Avoid Vague Requirements

Remember last year when Jesse James made that vague public apology to his wife and children, following allegations he’d had an affair with Michelle “Bombshell” McGee?

He looked like an idiot. Well. More of an idiot.

“The vast majority of the allegations reported are untrue and unfounded…”

If you’re writing vague requirements for your products, your engineers probably have some choice words for you, too. Because vague is frustrating. Ambiguity leaves things open to interpretation, and when those guesses are wrong they can be costly.

Let’s stop being vague and start being real.

“Reports will be generated quickly and easily.”

One way to make your requirements less vague is to consider how they’ll be tested.

Think about the above (poorly written) requirement: What does “quickly” mean? What does “easily” mean? How do you test something that’s so vague?

You can’t.

Avoid the subjective; go for the concrete.

A better way to get your requirements across is to make them so real that there’s no doubt in the minds of the people coding and the people testing.

For example, we could rewrite our sample requirement above as:

“The report will be generated and available to the user in 25 seconds or less.”

Twenty-five seconds is far more concrete than “quickly”. And it’s eminently testable.

Of course, that rewrite doesn’t address the subjective “easily” modifier… so we probably need a second requirement to address that idea. Maybe something like:

“The system will enable the user to create a new report in 10 clicks or less.”

Quickly. Easily. Simply. Graceful. Good.

These are all words that create uncertainty because they can mean one thing to one person and something else to another person. Don’t use them in your requirements. Or in your public apologies about affairs you may or may not have had.

Be concrete. Specific. Let development know exactly what to build, and QA what to test. The better your requirements, the better your chances of getting what you want the first time around and keeping your relationships with the development team healthy and productive.

New Around Here?

Subscribe to the feed to receive future updates; follow me on Twitter to keep the discussion going and/or tell me how to properly conduct a podcast.

Christopher Cummings

Blogs about product management. Loves Jesus, his family, comic books, video games, and giant robots. Occasionally crawls through mud and leaps over fire.

2 thoughts on “How To Avoid Vague Requirements

  1. From the customer side, I must confess that few things frustrate me more than vague rules for a game. I’ve encountered a few that made up words to describe a specific move, but then they never define what that move IS! *Facepalm*

    I realize that not every player launches straight to the rules before they play a game, but for those of us that do, clarity (and brevity) are a godsend.

Comments are closed.

%d bloggers like this: