No One Expects the Requirements Inquisition: Asking Next-Level Questions

A business analyst must dive below the surface during requirements discussions.

Pattern photo created by creativeart — www.freepik.com/photos/pattern

A business analyst is not merely a scribe who records whatever customers say and passes the information to the development team. The BA needs to ask thought-provoking questions to stimulate the thinking of the people they’re interviewing. This article suggests some unobvious questioning tips for BAs to consider as they cast a wide net for requirements input. Keep in mind that an elicitation discussion is an inquiry, not an interrogation. Watch out for questions that could come across as aggressive or confrontational.

Probing Beneath the Surface

As well as exploring the functionality that customers bring up, the BA should help customers think at a deeper level. After you’ve discussed some usage scenario, consider asking questions such as these:

• Is there any other way someone might perform that task?
• Would a user ever want to <do something>?
• Could <some condition> ever occur? What happens then?
• What else could happen that we haven’t already discussed?

These are ways to discover lower-probability scenarios or options the system should provide to the user.

Questions that solicit a yes/no or multiple-choice reply can unnecessarily constrain the answer. The requirements discussion could miss an opportunity to discover — or invent — something that goes beyond the BA’s preconceptions. Questions that present a limited set of options (“Does availability really need to be 99.9 percent or would 97 percent be adequate?”) can restrict the thought process. You might miss an even better response that wasn’t in the list of possibilities you presented. Consider more open questions like, “What are acceptable periods for the system to be unavailable?”

What Could Go Wrong?

Requirements elicitation discussions typically emphasize the expected normal behavior of the system. That’s what users naturally think about and bring up. However, anyone with programming experience knows that good developers write a lot of…