’Good’ vs ’Bad’ Business Requirements

What is a ’Good’ Requirement?

Many of our students have asked us to give them examples of ’good’ business requirements. Some of the braver have even asked for ’bad’ requirements for comparison. Presumably the bravest by far are those who have presented us with samples of their requirements and requested an evaluation of the ’quality’ of the requirements. After much hair pulling, brain thrashing, and pouring ashes on our heads, we have decided to approach this topic head-on (don’t even get me started with that ad!). Since the topic is, however rather humungous (i.e., too big to consider in a single Noiseletter), we have decided to break it down.

Just to give y’all an idea of the magnitude of this undertaking, consider that we have identified 18 different categories and subcategories of business requirements and an equivalent number for technical specifications. (You can read all about ’em in our free Requirements Taxonomy paper.) Ergo, our plan is to give you a couple of high-level recommendations in this initial article on the topic and then follow it up with an article each issue or so. (All right, so that’s a CYA — as in Cover Your Anatomy — statement, OK? It means that RSG is going to address this august issue in a series of articles starting right about now and continuing now and then until we are done and not one issue earlier.)

’Good‘, Albeit Young and Immature Requirements

First off, we need to point out that the ’goodness’ of a business requirement depends on where it is in its evolution. For convenience’s sake, we divide the requirements determination process into three major stages, ’Capturing’, ’Clarifying’, and ’Confirming’.

During the first stage, ’Capturing’, it is all about getting the requirement any which way you can — through interviewing, observation, analysis, blue-skying, brainstorming, brainwashing, butt-kicking, or whatever-works-for-you.This phase is primarily based on the theory that requirements exist ’in the wild’, but until they have been captured, they are of little value.

In this formative stage of its life, a ’good’ requirement is a statement that:

starts with the words ’I (or We, or Our Department, or My people, or a specific role) need (or don’t need or want or don’t want or should or should not or will or will not) ’;
names a single component/feature/behavior/state that whoever has the authority in the business community to make the decision decides is an outcome of the project worth funding;
focuses on the business outcome, not the technology to be used; and
can be traced back to the individual with the authority to ’own’ and ’fund’ this requirement.

A couple of fine (IONSHO — in our not-so-humble opinion) examples:

Sales needs to be able to see which contracts will be expiring within the upcoming 90 days.
I want the system to automatically calculate sales taxes based on relevant sales tax laws.
The website visitor won’t need to click more than once to get to the order page from any other page on the site.
We need to be able to respond to a code red incident anywhere on the planet within 24 hours.

Tom Hathaway
Managing Partner
Requirements Solutions Group, LLC

Promises, Promises — A Note from the Editors

Since this article would now officially exceed what we like to publish in a single edition of the Noiseletter, we will continue on with ’clarifying’ and ’confirming’ stages in the evolution of a requirement in an upcoming edition. For those of you who can’t wait to get the skinny, call us. (We can always arrange a webinar, a virtual workshop or a live instructor-led session to bring you all of the facts of life of a business requirement presented just for you or your group, hint, hint)

Requirements Solutions Group, LLC.

Tom Hathaway
Managing Partner
Requirements Solutions Group, LLC

Editors’ Report on e-Learning

We offered several issues back to keep you up-to-date on our progress in the arena of e-Learning or virtual workshops. In that vein, we have created a snippet from one of our webinars (not a real virtual workshop, no exercises in this one) to give you the flavor of our latest thinking in the field of requirements gathering. If you have 5 minutes and would like to see what we are thinking, listen to our ’The Case of the Missing Requirements’ recording (you will need sound on your computer to hear it) and let us know what you think. We appreciate any feedback we can get and will continue to keep you abreast of our latest findings in this exciting new venue.

Requirements Solutions Group, LLC.