What Are ’Good’ Business Requirements?
Many of our students have asked us to give them examples of ’good’ business requirements. Some of the braver have even asked for ’bad’ business requirements for comparison. Presumably the bravest by far are those who have presented us with samples of their business 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 post), 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. 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 we are 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’ business 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.