Taking the Mystery out of Requirements

the experts' suggestions would make their product less flexible and therefore would limit their market. As their product evolved it eventually veered away from providing the very support their customers expected and needed. They reacted to this problem by ignoring all customer requests, except bugs. In essence, executive management drove the product strictly from a cost perspective. This software vendor didn't pay attention to everyone offering clues and believed they knew what was needed to shape the product. Eventually they lost their leading market share and prospective customers looked elsewhere.

Remember that you are laying a foundation for all requirements and system decisions that follow. By discussing all of the clues, you are testing the boundaries and exploring the risk of including or excluding a feature or function.

4. Connect the dots
Detectives develop theories about their cases, and test these against what they know. Similarly, you can assemble requirements information and see what stands out. Use text, pictures, models, and whatever works to piece your current "theory" together. Most frameworks for requirements list information pertinent to the system. One I like is James and Suzanne Robertson's Volere model .

It is sensible and easy to understand and to adapt to your needs. In addition, I like to collect information about status and progress:

• assumptions of all kinds
• questions you need to have answered
• what you know and where you think it fits
• what you know you don't know
• open issues not yet researched
• conflicts in what you have researched
• what you perceive as critical to system success
• who you have talked with and who you haven't
• who has reviewed your "theory"
• how tightly you must define the requirements contract up front, and how you will know that you got there
• what your confidence level is for each requirement you have

Why try to uncover the elusive mystery requirements? One of my clients builds telephony systems. They had been recording what they knew in text form, graphic system models, and use cases. Then we talked about reviewing the use cases with their marketing group. I spent a week working with people from both engineering and marketing. As we explored use cases and asked questions about expectations, assumptions, and "what isn't happening," the marketing people began to realize how different their perspectives were from engineering. They saw how their product might change based on different answers. These two groups learned new respect for each other and went on to build more robust products that pleased their customers.

By capturing information explicitly, your progress is visible and you won't have to rely on memory, which can be notoriously faulty.

Let me ask you a question that may read the pulse of your requirements process:

• When nothing is coming together, who can you tell?

There is either an answer to this or not. And if not, then it may be time to put on your detective hat to protect the project from ending up in the morgue.