Making No Assumptions
In a court of law, they call questions with built-in assumptions leading questions. "You didn't like Miss Smith, did you?" This leaves little room for an answer. By contrast, an analyst needs to expose as much information as possible within the bounds of the project mission. So, open up the dialogue.
Perhaps the problem perceived isn't even the problem to solve. One client of mine built software for geologic surveys. In the field they experienced repeated system failures. Investigation of the software and hardware produced no clues to the problem. Noticing a cyclical pattern in the timing of the failures, one person asked questions about daily operations. It turned out that the local crew in Turkey was cutting the grid wires to shut down the system. They did this to accommodate their normal breaks for tea and cigarettes. The Americans made adjustments to fit local custom.
What else may be easily assumed? Examine scope, budget, schedule, what information is available, who has useful information, the problem boundary, timing, and the solution as resolution. Use context-free and meta-questions to get past assumptions:
- "Where do you expect this to be used?" yields locations, departments, people, distribution, size, and implications for equipment, safety, security, and added physical requirements
- "What is it worth to you to solve this problem?" yields insight into budget assumptions, motivation, level of commitment, and true interest in defining requirements
- "When do you do this?" returns business and product cycles, timing, and ad hoc and planned system events. Events mark critical stages, starts and stops to processes, and granting and denying permissions. If an event doesn't happen, that may be another event
- "Who should I talk to?" and "Who doesn't need to be involved?" find people who know the business and system, need to use it, are backing it, benefit from it, and those who may want it to fail
- "How does this work?" and "How might it be different?" may come back with surprises you hadn't anticipated
Anything can be taken for granted. One analyst didn't include in his requirements document the database that fed his system. I asked him why. He said, "Everyone knows it's there. It's obvious." Words to be wary of! It turned out that the database was scheduled for redesign.
You might know a lot about the business and systems in your organization or industry. But remember my story about Roger. Your clients will give better answers when you recognize that they are the experts. Any questions?
See Gerald M. Weinberg's Exploring Requirements: Quality Before Design for a good discussion of questions.