In my previous article I asked two questions (I paraphrase):
Well, why does everyone feel that requirements ought to be easy to write and easy to manage in a tool, but that for some inexplicable reason, everyone else has made a meal of it?
At first glance, requirements look very much like a simple shopping list. You are the customer; your suppliers are the shops. Fine. You write a list of things to buy:
It seems as easy as shooting fish in a barrel.
But then the fun begins. What do you need to know about each item? Why is it wanted, and how much, and by whom? Is is agreed yet? How will you know you have got the right thing and that it works properly when the supplier delivers it? How will it be used – what does it have to fit together with?
Clearly you need to record database fields like priority, status, owner. Sounds easy: just pop in some fields for the requirements table. Any fool could do it. And of course everybody has. There are literally dozens of Requirement Management tools and vendors out there, and it is a Sisyphean task to keep up with them.
But there are other, trickier, elements to record. How does it all fit together? You have to tell stories – scenarios, use cases.
"The driver tells the device where to navigate to. It finds the shortest / fastest / least trafficked (TBD) route from A to B. On the way it warns of traffic up ahead. Optionally it also shows points of interest like fuel stations, restaurants and picnic sites."
This is better: closer to the world of the customer – but it introduces new challenges for tool vendors and for the requirements process.
The philosopher Lao Tsu said "Out of the Nothing came the One. Out of the One came the Two. And out of the Two came the Many."
Requirements Discovery (and for the same reason, Requirements Management) is way bigger than it seems at first Byte.
(c) Ian Alexander 2009
Ian's book, Discovering Requirements, was published by Wiley in March 2009.
Books you may like:
