The Maltese Falcon mystery begins as a woman enters the office of Sam Spade, private investigator, explaining her situation and asking him for help. But she doesn't tell him everything. He has to figure it out as he gets new information that doesn't fit her original story. Sound familiar? Like Sam Spade, we cope with ambiguity as we uncover a customer's true requirements.

One could argue that "complete requirements" are only known once software is proven and accepted. But that's at the end! How can analysts remove the veil of mystery sooner? What can we do at the beginning that provides value? I've heard opinions ranging from "we can't know anything until we code" to "we have to define everything in as much detail as possible up front." People can get stuck focusing on the tangible aspect of requirements products. What will they look like and "how much" should we produce? But sometimes pursuing the intangible provides more valuable answers.

Here are four pointers to help you thrive amid requirements mysteries:

1. Start an Investigation
Investigations can start with whatever information is available and build outward to understand what of significance happened in the past and what might happen in the future.

So what can you know at the start?

• Emotional and political issues: Look for evidence of conflicting desires. The customer wants a slew of new features. Software developers want to build robust products. Product managers need to satisfy product version support and integration, not to mention budget and schedule concerns. Everyone might not get all that they want. The divergence of opinion and potential alliances of individuals with similar interests can change almost anything you thought you were after.
• The scope of investigation: Setting a boundary is important for understanding where the investigation may go next. If your investigation goes outside the boundary, you just learned that the scope is not as originally expected. Other "facts" can shift as well.
• The problem domain that the software addresses: A system might support building security, airline reservations, or a complete mortgage process. Typically these subjects have a defined set of rules, policies, and facts that are independent of technology concerns and are stable relative to technology and operational preferences. These subject-specific requirements merge later with user interactions and technology requirements to fully integrate as "complete requirements."

2. Explore What Isn't Happening
Something not happening may be as significant as something that is. In the Sherlock Holmes tale The Silver Blaze the case was cracked when Sherlock noted that on the night of the incident, the ever-vigilant watchdog did not bark. Therefore, things could not have taken place as the suspect had described. A company building software to track equipment and raw materials assumed that if a client used a certain amount of raw material, it was taken from inventory. End of story. After their first product release, customers called complaining that they couldn't back out "used" items that were expected to be used, but, in fact, were not.

So to uncover mystery requirements, you can question your existing use cases and storyboards to consider what might happen if one event in the sequence happened differently or didn't happen at all. Is there a consequence the system must monitor or report?

3. Follow All the Clues
When a project starts, you may get information from various sources. It is worth checking all of them out to understand the potential impact on the product.

One software vendor I worked with ignored many clues that were offered. They listened to their customers, but ignored advice from experts in the subject area. They complained that 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.