Where does Requirements Decomposition Fit?
In a previous post titled “How to Clarify IT Requirements to Ensure a Common Understanding“, I started a discussion on clarifying requirements. Clarifying is the second step in my Capture, Clarify, and Confirm concept for getting to good business and stakeholder requirements BEFORE you develop the solution (arguably, a risky idea, but go with me for the sake of argument here).
In that article, I discussed using a simple questioning technique to determine if the requirement meant the same thing to two people. In this post, I 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 Requirements 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?
