Requirements Decomposition for the Sake of Clarity

Ties to the Past

In a previous article (“The Clarification of a Good Business Requirement”, January, 2007), we started a discussion on clarifying requirements. Clarifying is the second step in our “Capture, Clarify, and Confirm” concept for getting to good business requirements BEFORE we develop the solution (arguably, a risky idea, but go with us for the sake of argument here).

In that article, we discussed using a simple questioning technique to determine if the requirement meant the same thing to two people. In this article, we need to push the envelope a tad further. The reason is that requirements clarification is one of the steps that many sacrifice for the sake of speed and, in the end, pay the price in the form of challenged or failed projects.

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?

From the Editors

There is a lot more we could write about this simple technique, but that would eventually lead us to a book which we would then have to publish and then have to sell and then have to promote and that really starts to sound like real work, so to put in a plug for the good guys (that’s us, you know), you can learn a lot more about requirements decomposition in our class “How to Gather and Define Business System Requirements”. (That should at least tie the record for the longest sentence in this series of articles.)

Thank you for paying attention.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "How Process Models Clarify Requirements"