What is a ‘Good’ Requirement?
Many customers 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 humongous (i.e., too big to consider in a single article), we have decided to break it down.
‘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’.
Our basic philosophy is that business requirements may exist in the wilds of corporate America, we don’t know for sure. The reason we don’t know is that we can’t tell whether something is a requirement or not until we have captured them. What we as business analysts (a.k.a. those responsible for capturing business requirements) need to do first is plan the hunt. We need to study requirements in their natural habitat to try to learn as much about them as we can. Anything we can learn about their habits, their behaviors and their preferences will aid us in the upcoming hunt to ensure that we can snare as many of them as possible in the time allotted. ‘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.
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)’ OR it defines some dimension of a specific component of the future solution;
- 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.
- The sales tax will be localized by the zip code of the ship-to address.
On Clarifying Requirements
Requirements clarification is really all about making sure that more than one person (i.e., the author) fully understands what the requirement means. Requirements are, after all, a means of communication, so unless both the creator and the reader of the requirement agree on what it actually means, it can not call itself a clear requirement.
Just as a good for instance, let’s take the first requirement from the set above:
“Sales needs to be able to see which contracts will be expiring within the upcoming 90 days.”
Makes perfect sense to me, after all, I wrote it. What does it mean to the developers (whether they are sitting in a third world country or a cube next to me, whether or not they speak English as their native tongue, and whether or not they share a cultural background with me)? What kinds of questions could those developers have?
An Exercise in Clarity
As an exercise in your analytic abilities, you might at this point want to take two minutes to see how many questions you can think of that you would like answered to make sure that you understand my intent and not just your interpretation of my words. Whether you write them down or not, count them. In this case, quantity counts.
All right, here is my two-minute list:
- Who or what are “Sales”? What can they do? What will they do with whatever I give them?
- What does “to see” mean? Do they need the physical contracts or just a list?
- What constitutes a contract?
- What makes a contract “expire” and why do they care?
- Upcoming 90 days? Starting from when? Does this view change day-by-day or weekly or monthly or hourly or what?
- Come to think of it, what constitutes a day in this context, 24 hours (a day in a single location) or the global day (and is that 47 hours or how does that work, anyway)?
OK, those are the first 6 (or however many you want to count) questions that hit my feeble mind, but remember, I am the author! You can probably do much better because you look at the world from your perspective. All of this indicates that, although the requirement was clear to me when I wrote it, it may just have some subjectivity that needs to be resolved lest it lead us to develop the wrong solution.
When Does It Ever Stop?
Let’s consider what we just did. We took one sentence and created a bunch of questions that will lead to who knows how many more sentences, each of which will consist of terms that need clarification. Sounds like a classic example of analysis paralysis to me. How does it end, when do we finally know enough to stop dithering around and start developing the solution?
Great question! Actually, quite possibly THE question for business analysts everywhere. The most expensive answer is, of course, to build the solution and then see whether or not you understood the requirements correctly (which could have a negative impact on your chances for a career in business analysis).
The best answer our industry has come up with to date is the old Chinese quote, “A picture is worth a thousand words”. In other words, draw a diagram or create a prototype of what you think works and test your understanding of it. If you and your counterparts (Subject Matter Experts, a.k.a. SMEs on the one side and the developers on the other) are versed in modeling techniques, a good exercise is to have each side draw a quick diagram (process model, data model, swimlane diagram, whatever) of what they understand the requirement to mean and then compare models. Models are, however, not the only method available to you.
Why Do We Not Clarify?
“Why do many of us skip the clarification process”, you ask? (At least, I think that’s what I heard you say in my head.) For starters, many people don’t like to ask questions for fear of appearing ignorant. (That’s my line — questions don’t show ignorance, they show interest!). Secondly, figuring out what to ask is hard work. (Of course, not as hard as being President, but still.) Even though a question shows interest, some questions at least SOUND stupid, so how can you be sure that YOUR questions are not the stupid kind? O.K., how many of you picked up on the preposterous use of parenthesis in this paragraph to “clarify” what was meant? Did it clarify or confuse? Ahhh, the conundrums we create by craving clarity.
This thinking and that pesky deadline that is looming lead you down the rosy path of, “Well, the subject matter expert must mean this, since that is the only thing that makes sense to me”; and another promising project goes kerplunk. There is a better way, there has to be.
The Decomposition Dilemma
Decomposing requirements statements probably has as many different definitions as there are letters in the name of the technique, but our take on it is the simplest (really, it is, trust me). All you need to think about are two things.
People and systems both do things. In our parlance, we call these things functions, activities, or processes. In doing things, both people and systems consume resources (such as data) and they create new resources (including new data). The primary purpose of information technology is to help us do things cheaper, better, faster and remember what we did by keeping track of the related data. Well, since requirements are supposed to define a future information technology, maybe we should just focus what the system will DO and what it has to KNOW for starters to see where it leads us.
Functional and Informational Components
In its simple form, decomposing a requirement statement consists of asking three questions, starting with “What does the requirement state or imply that the system (or a person) will need to DO?” Since doing anything requires some form of action, we are looking for answers in the form of verbs and objects (i.e., “calculate sales tax”, “deposit check”). Since the verbs indicate the action, the objects are typically data (or something that we need to have data about).
Once we have a list of all of the things that the system or the users need to DO, the second question for each item on the list is, “What data does the system have to KNOW in order to do that?” Since data is a thing, now we are looking for nouns or noun phrases (i.e., “sales tax”, “amount due”, issuing bank”).
The third question is “Where does that data come from?” and the answer here can only be another function or somewhere outside the system (i.e., the bank, the customer, the IRS – sorry bout that last one, but it is a valid source as well as a pain in the anatomy)
And So It Goes
O.K., you started out with a simple sentence that defined a future feature, state, or behavior of a component of the business system and now you have a couple of long lists of things the system has to do and things it has to know. The only significant question left standing is whether you know enough about each item on the list to communicate to the developers or assemblers of the solution. It might even be a good idea if you also knew how to recognize if these things are there and work the way you want them to once the solution is delivered.
Is everything clearer now?
Confirming before Coding
Confirming business requirements is really about making sure that the business community and the technical community understand the same thing under the requirements. It is also about ensuring that they both agree on relative priorities within the set of requirements so those requirements that are most important to the business community will be addressed first. Prioritization is not something that can be done unless it matters, so we are not going to delve here into the intricacies of this critical step at this time. Suffice it to say that unless your business requirements are confirmed and prioritized, they are not ready for prime time which, in our philosophy, means “Ready to be Managed”. In the end, the manageability, maintainability, and feasibility of your business requirements is what makes the difference between ‘good’ and ‘bad’ business requirements.
May the best requirement win.
