The Business Analyst as Explorer, Part 5 of 6 by Karl Wiegers

An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to <do something>?” and “Could <some condition> ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user.

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. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified.

In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to 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 is a way to detect 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 exception conditions, so I like to have someone with testing experience participate in requirements elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation and look for exceptions and alternatives we haven’t considered.

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. Of course, this doesn’t mean you can’t ever ask a question with a closed list of possible responses. Just make sure you aren’t prematurely constraining the exploration.

The last question I typically ask in a requirements elicitation discussion is, “Is there anything else I should be asking you?” This is an example of 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.

I use this same question in daily life. A few 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 issue we had not yet discussed. This is also a collaborative question to ask. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome.

Business analysis is hard! Because it is intrinsically a communication-centric human activity, I don't know of any shortcuts. Business participants in the requirements elicitation process can get frustrated by the number of questions the BA asks and how long the process can take. But that's just the way it is. And it's a whole lot cheaper and less painful to have those discussions before you've actually built the software.

Don't forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.