Business requirements: what is the difference between good and bad?

What is a “good” requirement?

Many customers have asked us to give them examples of “good” business requirements. Some of the bravest have even asked for “bad” requirements to compare. Presumably the bravest are by far the ones who have provided us with samples of their requirements and requested an assessment of the ‘quality’ of the requirements. After many hair-pulling, brain-fluttering, and pouring ashes all over our heads, we’ve decided to tackle this issue head-on (don’t even get me started on that ad!). However, since the topic is quite humongous (that is, too big to consider in a single article), we have decided to break it down.

‘Good’ requirements, although young and immature

First of all, we must note that the ‘goodness’ of a business requirement depends on where it is in its evolution. For convenience, we divide the requirements determination process into three main stages: “Capture”, “Clarification” and “Confirmation”.

Our basic philosophy is that business requirements can exist in the nature of American corporations, we don’t know for sure. The reason we don’t know is that we can’t tell if something is a requirement or not until we’ve captured it. What we as business analysts (also known as those responsible for capturing business requirements) need to do first is plan our search. We need to study the requirements in their natural habitat to try to learn as much as we can about them. Everything we can learn about their habits, behaviors, and preferences will help us on the next search to make sure we can catch as many of them as possible in the allotted time. ‘Catch it’ is about getting the requirement in any way you can: through interview, observation, analysis, blue skies, brainstorming, brainwashing, kicking butt, or whatever works for you.

At this formative stage in your life, a ‘good’ requirement is a statement that:

• starts with the words ‘I (or We, or Our Department, or My people, or a specific function) need (or I don’t need or want or don’t want or should or shouldn’t or don’t want or don’t want)’ Or defines some dimension of a specific component of the future solution;
• names a single component / characteristic / behavior / declares that whoever has the authority in the business community to make the decision decides it is a project result worth financing;
• it focuses on the business result, not the technology to be used; Y
• it can be traced back to the individual with the authority to ‘own’ and ‘fund’ this requirement.

A couple of good examples (IONSHO, not so humble in our opinion):

1. Sales should be able to see which contracts will expire in the next 90 days.
2. I want the system to automatically calculate sales tax based on the relevant sales tax laws.
3. The website visitor will not need to click more than once to access the order page from any other page on the site.
4. We need to be able to respond to a code red incident anywhere on the planet within 24 hours.
5. Sales tax will be localized based on the postal code of the shipping address.

About clarification of requirements

Requirement clarification is really 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, you cannot call yourself a clear requirement.

Just as good, for example, let’s take the first requirement from the set above:

“Sales should be able to see which contracts will expire in the next 90 days.”

It makes perfect sense to me, after all, I wrote it. What does it mean to developers (if they are sitting in a third world country or in a cube next to me, if they speak English as their mother tongue or not, and whether or not they share a cultural background with me)? What kinds of questions might those developers have?

An exercise in clarity

As an exercise of your analytical skills, at this point you can take two minutes to see how many questions you can think of that you would like to answer to make sure you understand my intention and not just your interpretation of my words. Whether you write them or not, count them. In this case, the amount counts.

Alright, here’s my two-minute checklist:

1. Who or what are “Sales”? What can they do? What will they do with everything I give them?
2. What does “see” mean? Do they need the physical contracts or just a list?
3. What constitutes a contract?
4. What makes a contract “expire” and why do they care?
5. Next 90 days? From when? Does this view change from day to day or weekly or monthly or hourly or what?
6. Now that I think about it, what constitutes a day in this context, 24 hours (a day in one place) or the global day (and it’s 47 hours or how does it work, anyway)?

Okay, those are the first 6 (or whatever you want to count) questions that hit my weak mind, but remember, I am the author! You can probably do much better because you look at the world from your perspective. All this indicates that, although the requirement was clear to me when I wrote it, it may only have a certain subjectivity that needs to be resolved, a burden that leads us to develop the wrong solution.

When does it stop?

Let’s consider what we just did. We take a sentence and create 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 we finally know enough to stop hesitating and start developing the solution?

Big question! In fact, possibly THE question for business analysts around the world. The most expensive answer is, of course, to build the solution and then see whether or not you understood the requirements correctly (which could negatively impact your chances of pursuing a career in business analytics).

The best answer our industry has found 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, also known as SMEs on the one hand and developers on the other) are well versed in modeling techniques, a good exercise is to have each side draw a quick diagram (process model , data model, lane diagram, whatever) of what they understand the requirement to mean and then compare models. However, models are not the only method available to you.

Why don’t we 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.) To begin with, many people do not like to ask questions for fear of appearing ignorant. (That’s my line: questions don’t show ignorance, they show interest!). Second, figuring out what to ask is hard work. (Of course, it’s not as difficult as being president, but still.) Even though a question shows interest, some questions at least SOUND stupid, so how can you be sure YOUR questions aren’t the stupid kind? Well, how many of you noticed the absurd use of parentheses in this paragraph to “clarify” what was meant? Did it clarify or confuse? Ahhh, the riddles we create by yearning for clarity.

This thought and that pesky looming deadline lead you down the rosy path of, “Well, the subject matter expert must say this, since that’s the only thing that makes sense to me”; and another promising project becomes kerplunk. There is a better way, there has to be one.

The decomposition dilemma

The decomposition of requirements statements probably has as many different definitions as there are letters in the technique name, but our version is the simplest (really, trust me). All you need to think about is two things.

Both people and systems do things. In our language, we call these things functions, activities, or processes. By doing things, both people and systems consume resources (such as data) and create new resources (including new data). The main purpose of information technology is to help us make things cheaper, better and faster and to remember what we did by keeping track of related data. Well, since requirements are supposed to define a future information technology, maybe we should focus on what the system will do and what it has to KNOW to start seeing where it takes us.

Functional and informative components

In its simplest form, decomposing a requirement statement consists of asking three questions, starting with “What does the requirement indicate or what does it imply that the system (or a person) should DO?” Since doing anything requires some kind of action, we look for answers in the form of verbs and objects (ie “calculate sales tax”, “deposit check”). Since verbs indicate action, objects are usually data (or something we need to have data about).

Once we have a list of all the things that the system or users need to DO, the second question for each item on the list is: “What data does the system have to KNOW to do that?” Since data is one thing, we are now looking for nouns or noun phrases (ie “sales tax”, “amount due”, issuing bank “).

The third question is “Where does this data come from?” and the answer here can only be another function or somewhere outside the system (i.e bank, customer, IRS, sorry for the latter, but it’s a valid source and a pain in the anatomy)

And so it goes on

Well, you started with a simple sentence defining a future characteristic, 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 important question that remains is whether you know enough about each item on the list to communicate with 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 working the way you want once the solution is delivered.

Is everything clearer now?

Confirm before encoding

Confirming business requirements is about making sure the business community and technical community understand the same under the requirements. It’s also about ensuring that you both agree on relative priorities within the set of requirements, so that the requirements that are most important to the business community are addressed first. Prioritization isn’t something you can do unless it matters, so we’re not going to delve into the intricacies of this critical step here at this point. Suffice it to say that unless your business requirements are confirmed and prioritized, they will not be ready for prime time which, in our philosophy, means “Ready to be Managed”. Ultimately, 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.