To get good requirements, you have to ask good questions. But what makes good questions, and how can you use them to systematically uncover requirements? In this week's column, Becky Winant shares the art and science behind asking questions that work.
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:
- 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.
- 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?"
- 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