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.