Ambiguity, false assumptions, theories, and red herrings. These basic elements of a good mystery story are also encountered in software requirements gathering. And just as the detective has his bag of tricks for solving the mystery, you can learn a few things about uncovering elusive requirements in this week's column from Becky Winant.
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 canyou 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