Requirement #1: Ask Honest Questions

To get good requirements, you have to ask questions. This may seem obvious, but I've known analysts who believed that they had to have the answers instead. This stifled requirements sessions and left customers feeling as if their contributions were unimportant. Questions that don't elicit involvement from the participants are false questions. Use an honest question and you'll engage people, provoke interaction, and upgrade requirements quality. 

Here is how it works. Though important, don't stop with the basics of who, what, why, where, when, and how. Refine your questions by evaluating the expectation and intent behind each question. If honest, your questions

• Are egoless
• Seek useful answers
• Make no assumptions 

Practicing Egoless Questioning
Working in New York City, I had many clients from Wall Street. To develop financial systems, I had to interview financial managers and analysts. Since I wasn't a financial expert, I asked lots of questions. They were happy with the systems I delivered, and I was happy with my process.

One day my manager Roger sat in on discussions for a new system. After the meeting he sputtered, "How can you do that?" "Do what?" I asked. He went on, "How can you ask basic questions about standard financial practices?" Roger felt that he could never do that!

Probably Roger was afraid to appear foolish. I'm sure he knew that he wasn't a financial expert, but his MBA in Finance made him feel that he needed to appear "qualified"—even though many people have degrees that they never apply professionally. This made it hard for Roger to realize that a question, far from indicating that you are dumb, instead indicates interest in the other person's answer. I suspect that when Roger assumes he has to have the answers, he ultimately frustrates himself and his clients.

Seeking Useful Answers
When you ask a question, is the answer useful? Perhaps you wanted specific rules governing bonds, but received a survey of the bond business. Or you needed the accounting system overview, but got a litany on accounting procedure. Ask yourself, "How could I have asked the question differently?"

Try these approaches: 

1. If you want a broad perspective, consider types of questions that are necessary for any project effort. These probe for project parameters and motivation. Examples are "What problems are you trying to solve?" and "What problems might the solution create?" These are called "context-free" questions. 
2. If you seek specific information, ask pointedly narrow questions. Ask specifically how, specifically when, and specifically what. For example, "Exactly how does an invoice get processed?" 
3. If you're lost, ask about your requirements-gathering process. Ask "What questions should I be asking you?" This meta-question invites the people closest to the system and the problems to express what is important to them. Responses target important issues and expectations for a project and may reposition your requirements efforts. 

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?

Reference
See Gerald M. Weinberg's Exploring Requirements: Quality Before Design for a good discussion of questions.