What is a ‘good’ requirement?
Many customers have asked us to give them examples of “good” business requirements. Some of the brave have even called for ‘bad’ requirements for comparison. Presumably the bravest by far are those who have submitted samples of their requirements to us and have requested an assessment of the “quality” of the requirements. After much hair-pulling, brain-bumping, and ash-dropping on our heads, we’ve decided to tackle this issue head-on (don’t even get me started on that ad!). Since the topic is, however, quite extensive (i.e. too big to be considered in a single article), we have decided to break it down.
‘Good’ requirements, albeit young and immature
First, we should note that the ‘goodness’ of a business requirement depends on where it is in its evolution. For convenience, we divided 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 American business, 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 as business analysts (also known as those responsible for capturing business requirements) need to do 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 in any way you can: through interviewing, observation, analysis, blue sky, brainstorming, brainwashing, butt-kicking, or whatever works for you.
At this formative stage in 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 that it is a project outcome worth funding;
- focuses on the business outcome, 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:
- Sales should be able to see which contracts are due to expire in the next 90 days.
- I want the system to automatically calculate sales tax based on the applicable sales tax laws.
- The website visitor will not need to click more than once to reach 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 located by the zip code of the shipping address.
About the clarification of requirements
Clarifying the 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 of 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 they speak English as their native language 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 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 to answer to make sure you understand my intent and not just your interpretation of my words. Whether you write them or not, tell them. In this case, quantity counts.
Alright, here’s my two-minute list:
- Who or what are the “Sales”? What can they do? What will they do with what I give them?
- What does “see” mean? Do you need the physical contracts or just a list?
- What constitutes a contract?
- What makes a contract “expire” and why do they care?
- Next 90 days? From when? Does this view change from day to day, weekly, monthly, hourly, or what?
- 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)?
Well, those are the first 6 (or as many as you want to count) questions that popped into my weak mind, but remember, I am the author! You can probably do a lot 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 resolved lest it lead us to develop an incorrect 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 dithering and start developing the solution?
Big question! Actually, possibly THE question for business analysts everywhere. The more 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 analytics).
The best response our industry has given to date is the ancient 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. If you and your counterparts (subject matter experts aka SMEs on one side 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, rail 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 so many of us skip the clearing 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!). Second, figuring out what to ask is hard work. (Of course, 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 that 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 puzzles we create by yearning for clarity.
This thought and that pesky looming deadline leads you down the rosy path of: “Well, the subject matter expert needs to say this, since that’s the only thing that makes sense to me”; and another promising project goes wild. 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 name of the technique, but our opinion is the simplest (it really is, believe me). All you need to think about are 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 the 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 begin 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) shall DO?” Since doing anything requires some kind of action, we are 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 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 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 the system (ie bank, customer, IRS – sorry for that last bit, 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 function, state, or future behavior of a trading system component, 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 list item 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
Confirmation of business requirements is really about making sure that the business community and the technical community have the same understanding of the requirements. It is also about ensuring that both agree on 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 here 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 viability of the business requirements is what makes the difference between “good” and “bad” business requirements.
May the best requirement win.