No One Expects the Requirements Inquisition: Asking Next-Level Questions
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 code to handle exception conditions. Therefore, elicitation must also identify things that could go wrong and describe how the system should detect and respond to errors.
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 might reveal missing requirements that haven’t come up in the discussion yet. I like to have someone with testing experience participate in elicitation sessions because testers are particularly adept at spotting exception conditions. I also engage a tester to review requirements documentation and look for exceptions and alternatives we haven’t considered.
Don’t Believe Everything You Hear
A BA needs to be a bit of a skeptic. One project was replacing an existing system with a package solution. A user requested to add a specific function to the core package; it wouldn’t have been cheap. When the BA asked why they needed that function, the user said it was present in the current application. The BA probed further and eventually discovered that several stakeholders all thought someone else was using the data. In reality, no one used it! By asking “why” a few times, the BA and the user representative agreed that the function wasn’t needed, thereby saving considerable money and effort.
Why Ask Why?
During a reengineering project, a BA named Dawn asked a developer why a utility company’s fee calculation was being performed a certain way in the current system. “A government statute dictates how we have to calculate these fees,” he replied. Upon investigation, Dawn discovered that the current system hadn’t implemented the computation correctly according to that statute. The system had miscalculated those utility fees for an embarrassingly long time. The discrepancy would never have come to light had Dawn simply accepted the stated need for the current formula. Asking why revealed a significant error that the replacement system corrected.
“Why?” is an excellent question in the BA’s bag of tricks. Try to ask it in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin with, “Can you please help me understand…” This phrase is longer than a simple why, but it means the same thing and has a more collaborative feel. Ask “why” enough times to give you confidence that you’ve got the real requirement in hand.
When a user presents a requirement that contains an embedded solution idea, you need to find out whether the solution idea is a valid design constraint or just a thought. Asking why several times in succession is a way to drill down from a superficially proposed customer want to the underlying need. This helps the software team address the real issue, not just a superficially presented issue.
The answer to why might illuminate a business rule that affects the project. Then you can confirm whether the business rule is still pertinent and whether the information you have about it is complete and accurate. You can learn whether and where the business rule is documented, who maintains the information, and if there are related rules you need to know about.
Asking why sometimes surfaces assumptions. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it really is true. Try to identify assumptions that various stakeholders might be making — they could be incorrect, obsolete, or inapplicable. They also could be at odds with other people’s assumptions, making it hard to reach a shared expectation for the project’s outcome.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it’s necessary. That knowledge helps the BA determine if a request lies within the project scope. This question sometimes reveals that the “requirement” is actually a solution idea for an unstated, higher-level requirement.
Suppose you encounter a requirement that a user presented as being of high priority. The requirement doesn’t seem that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other high-priority requirements. Without this understanding about requirement dependencies, someone might defer the requirement that doesn’t seem so important, crippling related functionality that’s planned for early implementation.
Out of Context
In their book Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg describe context-free questions. In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions.” Such questions supplement specific questions about the product’s capabilities and characteristics. Here are some sample context-free questions:
- What problems do you expect this system to solve?
- What problems could it create?
- How could we judge the success of this project?
- Who will make that judgment?
- What’s a highly successful solution worth to the customers?
- Who should I work with to get the best information about the system?
My final question in a requirements elicitation discussion is, “Is there anything else I should ask 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 after I ask that, the person I’m speaking with realizes that we haven’t yet discussed some important topic: “Yes, we need to talk about the default security privileges for new employees.” I simply didn’t know enough to bring that up.
I use this same question in daily life. When I had new kitchen counters installed in my home, I asked the contractor, “Is there anything else I should be asking you about this job?” He thought for a moment and then asked if I wanted the countertop edges to be flat, full bullnose, or beveled. Huh? I’d never considered the appearance of the countertop edges. That final “Is there anything else?” question acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome. If you don’t ask, people might make assumptions that don’t yield the results you want.
Business analysis is hard! As it’s an intrinsically communication-centric human activity, I don’t know of any shortcuts. Customers who participate in requirements elicitation can get frustrated by all the BA’s questions and how long the process can take. But that’s just the way it is. It’s a lot less painful to have those discussions before you build the software.
This article is adapted from More About Software Requirements by Karl Wiegers. Karl is the Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. Karl’s latest book is The Thoughtless Design of Everyday Things.