Home » WordPress231 » 2008 » 02 » 01 » Requirements are conversations

Requirements are conversations

The word requirement is often heavily charged with frustration and disappointment, especially in the software industry, from all sides – customers, business people, designers, developers.

Too often, customers are asked what they want, only to hear later that it cannot be done, for some confusing technical reason. Too often, developers or designers are trying to understand what customers need holistically, but only hear tactical details and change requests that fail to capture the fundamental needs of their task, which would otherwise make a profound difference in their work. Too often business people try to define the big picture on the basis of a high-level strategy, but do not understand how to put together the various expectations and constraints into a coherent product plan.

All these frustrations are very real. And anyone who has been involved in a software project, be it the development of an enhancement for Siebel CRM, the configuration of SAP, or the development of a web API will connect with these challenges. Now the question is: how to avoid these frustrations?

Well, I would love to say it starts with the right tool, our tool. But it doesn’t. It start, as often, with the right perspective. The only thing a tool will do if you do not understand the purpose of requirements is to get you faster where you do not want to go. For instance, let say you need to overhaul a web-based mapping application to include accurate routing information, because it does not address the basic need of the sales force. If you fail to recognize this fact and hand a requirement form to your users, they might just hammer on and give you plenty of ideas on how to change the screens, you will get what you asked for, not what you need! You will get plenty of ideas, often contradictory, on how to move this field a little on the right, and remove this one field, and show this one only for people from Fargo, and replace this one by these two for the reps in New Guinea. You will not, however, notice that what you need is to replace the local mapping database you have been using so far with a standard one, such as Yahoo!, Google or Mappoint, since they include reasonably accurate routing information. You would not want that, would you?

As you can see, speaking about requirements involves framing at a high level the type of change you want. This could be typically summarized as four different types of expectations:

- We want to do something entirely new. Customers in this type of situations would tell something along the line of: “We do not have an expense system. We want one. Thanks“. Sorry for the confusion, they would usually not say thanks. They would say “When can we have it?“.

- We want to keep doing what we do but add new features. For instance, you might hear “We have a legacy expense system, and we want to add automatically the mileage coming from the route information determined by our new web-based mapping system as an expense for the sales reps into the legacy expense system“.

- We want to do the same thing, but better, faster, with more automation, better data visibility, a better interface, some glitz and all the bells and whistles. Clues that you are in this situation would sound like “We have an expense system that works well when users are within our network. We need it to work even when our users are on the road“.

- We want to do exactly the same thing, but for some sustainability reason, we need to change the platform we’re working on. And you would hear “We have a legacy expense system built in Cobol. It requires an army of gerbils to maintain. Our IT team is telling us Cobol is not great for Web 2.0. Plus our last Cobol programmer died in 2002. We want to be able to do exactly what the system currently allows to do (or better). Can we build a similar tool with web-based technologies?” Note that they would be lying. They Cobol programmer is not dead. She moved to another company for twice the salary, because these assets are precious these days.

Each of these expectations should be the beginning of a conversation, a different type of conversation… In the something new conversation, you will try to firm up what they mean by new, and what’s good enough for a start. You’ll also try to build common ground thru mock-ups early on. In the same with some new stuff, you will try to scope the exact thing they want to add, and place it in the whole system appropriately, defining as precisely as possible the interactions between the new and the old. In the same only better, you will try to compile all the things they want to improve, and identify whether this should be done as an incremental upgrade, or should be done with a new technology altogether. The last one, same thing but with new technology, is tricky because it could be a something new or same only better in disguise, or include some aspects of the three. In this situation, you need to capture what is the essence of the limitations that they hope to transcend with the help of new technologies.

In any case, it seems that all these requirements gathering exercises are conversations in good standing. So in the future, we will really look at how we should handle these conversations, to enhance their quality and the value of their output.

For more information on TeamALM and nexb, go to www.nexb.com. For more information on Requirements, specifically, go to requirements.nexb.com.

Home