What is a ‘good’ requirement?

Many customers have asked us to provide examples of “good” business requirements. Some of the brave have even asked for ‘bad’ requirements to compare. Presumably the bravest by far are those who have submitted samples of their requirements to us and requested an assessment of the “quality” of the requirements. After much hair-pulling, brain-bashing, and ash-dumping on our heads, we’ve decided to tackle this topic head-on (don’t even get me started on that announcement!). Since the topic is, however, quite extensive (ie, too big to be considered in a single article), we have decided to break it down.

‘Good’ requirements, albeit young and immature

First of all, we should 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’, ‘Clarify’ and ‘Confirm’.

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

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

• begins with the words ‘I (or We, or Our Department, or My people, or a specific function) need (or don’t need or want or don’t want or should or shouldn’t or won’t)’ OR defines some dimension of a specific component of the future solution;
• names a single component/characteristic/behavior/claims that whoever has the authority in the business community to make the decision decides it is a project outcome worth funding;
• 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 (IONSHO – in our not so humble opinion) Examples:

1. Sales must 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 applicable sales tax laws.
3. The website visitor will not need to click more than once to reach 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 located by the zip code of the shipping address.

About the clarification of requirements

Clarification of requirements is really about making sure that more than one person (ie the author) fully understands what the requirement means. After all, requirements are a means of communication, so unless both the creator and the reader of the requirement agree on what it really means, it can’t call itself a clear requirement.

As a good example, let’s take the first requirement from the above set:

“Sales needs to be able to see which contracts are due to expire in the next 90 days.”

It makes perfect sense to me, after all, I wrote it. What does it mean for developers (whether they are sitting in a third world country or in a cube next to me, whether or not they speak English as their mother tongue, 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 in your analytical skills, at this point you might want to take two minutes to see how many questions you can think of that you would like answered to make sure 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.

Alright, here’s my two-minute list:

1. Who or what are “Sales”? What can they do? What will they do with what he gives 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 daily, weekly, monthly, hourly, or what?
6. Come to think of it, what constitutes a day in this context, 24 hours (a day in one place) or the global day (and is it 47 hours or how does that work, anyway)?

Okay, those are the first 6 (or however many you want to count) questions that popped into my weak mind, but remember, I’m 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 have some subjectivity that needs to be worked out so that it doesn’t lead us to develop the wrong solution.

When does it ever stop?

Let’s consider what we just did. We take one sentence and create a bunch of questions that will lead to who knows how many more sentences, each consisting 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! Actually, possibly THE question for business analysts everywhere. The most expensive answer is, of course, to build the solution and then see if you understood the requirements correctly or not (which could have a negative impact on your chances of a career in business analysis).

The best answer our industry has given to date is the old Chinese quote: “A picture is worth a thousand words.” In other words, draw a diagram or prototype of what you think works and test your understanding. If you and your counterparts (subject matter experts aka SMEs on one side and 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 means and then compare models. However, models are not the only method available to you.

Why don’t we clarify?

“Why do so 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 don’t 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 hard as being president, but still.) Even if 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? Clarified or confused? Ahhh, the puzzles we create by yearning for clarity.

This thought and that pesky looming deadline leads him down the rosy path of, “Well, the subject matter expert should say this, since that’s the only thing that makes sense to me”; and another promising project goes haywire. There is a better way, there has to be.

The decomposition dilemma

Requirement statement decomposition probably has as many different definitions as there are letters in the technique name, but our opinion is the simplest (it really is, 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. In 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 do 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 with, to see 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 state or imply that the system (or a person) must DO?” Since doing anything requires some kind of action, we’re looking 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 the system or users must DO, the second question for each item on the list is, “What data does the system need to KNOW to do that?” Since data is a thing, we are now looking for nouns or noun phrases (ie “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 of the system (i.e. the bank, the customer, the IRS – sorry about the last one, but it’s a valid source and a pain in the anatomy)

And so it goes on

Well, you started with a simple sentence that defined a function, state, or future behavior of a trading system component, and now you have a couple 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 in 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 work the way you want them to work once the solution is delivered.

Is everything clearer now?

Confirmation before encoding

Confirming business requirements is really about making sure that the business community and the technical community understand the same thing about the requirements. It is also about ensuring that both agree on the relative priorities within the set of requirements, so that those requirements that are most important to the business community are addressed first. Prioritization isn’t something you can do unless it’s important, so we’re not going to delve into the intricacies of this critical step right now. Suffice to say, unless your business requirements are confirmed and prioritized, they won’t be ready for prime time, which in our philosophy means “Ready to Manage.” In the end, the manageability, maintainability, and feasibility of business requirements is what makes the difference between “good” and “bad” business requirements.

May the best requirement win.