Ask Open-Ended Questions to Elicit Open-Minded Responses

Summary

The article emphasizes the importance of asking open-ended questions during business analysis to elicit comprehensive requirements and encourage creative thinking, which is crucial for identifying unstated assumptions and handling exceptions in system design.

Abstract

Effective requirements elicitation is vital in business analysis, and the use of open-ended questions is a key strategy to explore beyond the surface of stakeholder needs. These questions, often starting with "Why" or "How," encourage a broader scope of dialogue, revealing innovative solutions and uncovering issues that have not been previously discussed. The article suggests that business analysts (BAs) should focus on stimulating creative thinking by asking questions that challenge assumptions and consider various scenarios, including potential errors and exception conditions. It also highlights the value of involving testers in the elicitation process to spot unconsidered exceptions and the importance of asking metaquestions to ensure all relevant topics are covered. The approach is not limited to software development but is applicable in everyday situations where thorough planning is essential.

Opinions

Open-ended questions are more effective than closed ones during requirements elicitation as they allow stakeholders to elaborate and explore new areas.
BAs should not rely solely on "What do you want?" as it may be too broad and yield superficial responses.
Questions that begin with "Why" or "How" are particularly useful in encouraging detailed and thoughtful responses.
Discussing potential error conditions and exceptions is crucial for developing robust systems and should be a part of the requirements elicitation process.
Including testers in elicitation sessions can provide valuable insights into unhandled exception conditions and unverifiable requirements.
The metaquestion "Is there anything else I should be asking you?" is a powerful tool to uncover additional important topics that the BA may not have considered.
The article acknowledges that business analysis is complex and requires thorough communication, but it is more cost-effective to have these discussions before system development begins.

Open-ended questions can stimulate creative thinking during requirements elicitation or in any other discussion.

“What do you want?” is hardly the most useful question a business analyst (BA) can ask during a requirements elicitation discussion. Sure, you’ll get some answers, but they’ll likely just skim the surface. Many online resources suggest other useful questions to ask when eliciting requirements, such as an extensive list from Laura Brandenburg.

Open-ended questions that don’t solicit a brief, fixed answer are valuable during both requirements discussions and any other type of interview or conversation, as well. They invite the participants to expand their reply, explain their thought process, and broaden the dialogue’s scope into fresh areas. Open-ended questions often begin with “Why” or “How.”

When eliciting requirements for a software system, the BA needs to stimulate the creative thinking of the people they’re interviewing to get below that top layer of response, without making the interview sound like an interrogation. Questions like these can help you explore issues the stakeholders have not brought up previously and hence create a more valuable solution:

“Can you think of any other ways that a user might want to <do something>?”

“Could <some condition or event> ever occur? If so, what should happen then?”

“Would it be useful for users if they could <do something>?”

“What assumptions are we making here that we should validate?”

“What else could happen that we haven’t already discussed?”

In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever programmed knows that good developers write a lot of code to deal with exception conditions. An important aspect of requirements elicitation therefore is to identify things that could go wrong, determine how the system should detect an error, and describe how it should prevent, respond to, or recover from the error.

As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if <some error condition arises>?” This could reveal missing requirements that haven’t come up in the discussion yet. It’s also a way to surface previously unstated assumptions.

Testers are particularly adept at spotting unhandled exception conditions. I like to have someone with testing experience participate in elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation to look for exceptions and alternatives we haven’t considered, as well as spotting unverifiable requirements.

Beware of asking questions that solicit a yes/no or multiple-choice type of response. Such questions can unnecessarily constrain the answer so that the requirements discussion misses an opportunity to discover, or invent , something that goes beyond the BA’s preconceptions. This doesn’t mean you can’t ever ask a question with a closed list of possible responses. Sometimes your stakeholder collaborators do need to make a choice. Just make sure you aren’t prematurely constraining the exploration in that way.

The last question I typically ask in an elicitation discussion is, “Is there anything else I should be asking you?” This is a metaquestion, a question about a question. I freely admit that I don’t know all the right questions to ask. Sometimes the person of whom I’ve asked this question realizes that we haven’t yet discussed some important topic. I simply didn’t know enough to bring it up. “Is there anything else I should be asking you?” is also a collaborative question. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory outcome.

I use this same question in daily life. Some years ago I had new kitchen counters installed in my house. I’d never done any home remodeling before and didn’t know that much about the process. Near the end of my discussion with a contractor, I asked, “Is there anything else I should be asking you about this job?” He thought for a moment and then brought up an important issue we had not yet discussed, a design decision that I needed to make. I’m glad we explored that issue while we were still in the planning stage, not in the middle of construction when all the materials had already been purchased and shaped.

Business analysis is hard! It’s a communication-centric human activity, with few shortcuts. Stakeholders who participate in requirements elicitation can become frustrated by the number of questions they’re asked. Sometimes the BA must revisit an issue to flesh out initial thoughts, revise based on new understanding, refresh a memory, or clarify an earlier conversation. But that’s just the way it is. It’s a lot cheaper and less painful to have those discussions before you’ve built the software. Open-ended questions that stimulate creativity and invite unconstrained thinking are a valuable tool in the business analyst’s tool kit.

And, yes, “What do you want?” is indeed an open-ended question — but perhaps too open-ended to be useful.

=============