IT Requirements Are Captured, Clarified, Confirmed and Managed

A couple of posts ago, I initiated a discussion on “good” versus “bad” business requirements. In that post, I also introduced the stages in the life cycle of an IT requirement, namely IT requirements in the wild, captured, clarified, confirmed, and, finally, managed. I promised back then to continue that discussion, so in the spirit of New Year’s Resolutions and Kept Promises, this post is for you.

We left off with some examples of what we considered reasonably good requirements in the “Captured” stage. Just so you don’t have to dig out that old issue to reread the examples, here they are:

• Sales needs to be able to see which contracts will be expiring within the upcoming 90 days.
• I want the system to automatically calculate sales taxes based on relevant sales tax laws.
• The website visitor won’t need to click more than once to get to 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.

If I now repeated all of the rules that got us here, that would make this article a total copy of the previous one, so if you want to review the rules, you will have to take the time to dig out that old issue and reread it. Meanwhile, I am going to take it from there.

On Clarifying IT Requirements

IT Requirements clarification is really all about making sure that more than one person (i.e., the author) fully understands what the requirement means. IT 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, it can not call itself a clear requirement.

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

“Sales needs to be able to see which contracts will be expiring within the upcoming 90 days.”

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

An Exercise in Clarity

As an exercise in your analytic abilities, you might at this point want to take two minutes to see how many questions you can think of that you would like answered to make sure that 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.

All right, here is my two-minute list:

OK, those are the first 6 (or however many you want to count) questions that hit my feeble mind, but remember, I am 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 just have some subjectivity that needs to be resolved lest it lead us to develop the wrong solution.

When Does It Ever Stop?

Let’s consider what we just did. We took one sentence and created 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 do we finally know enough to stop dithering around and start developing the solution?

Great question! Actually, quite possibly THE question for business analysts everywhere. The most expensive answer is, of course, to build the solution and then see whether or not you understood the requirements correctly (which could have a negative impact on your chances for a career in information technology).

The best answer our industry has come up with 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, a.k.a. SMEs on the one side and the 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 to mean and then compare models. I would show you an example, but that would officially exceed the scope of this segment in our continuing series “Good vs. Bad Business Requirements”.

Give It Your Best Shot.

Since this article has gotten rather lengthy, I recommend you try that diagramming thing out for yourself. You can try it on my sample requirements (above) or on REAL requirements from your project. If you can’t get a SME or a developer to work with you, grab a colleague and try it out. You just may be amazed at what comes out.