An Inquiry, Not an Inquisition

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

Many years ago, my manager, Jerry, sat in on a discussion I had with a customer named Steve to explore his requirements for a new application. After the meeting, Jerry pointed out that I had been rather aggressive in my questioning of Steve. He was right. I hadn’t realized how hard I’d been pressing Steve to make up his mind on certain points and tell me exactly what he wanted. Fortunately, when I contacted Steve to apologize, it was clear that he wasn’t offended. Nonetheless, our discussion probably felt like an inquisition to Steve, rather than an inquiry into what he was asking us to build. Not the best strategy for a business analyst to take.

Another extreme approach to requirements elicitation is for the BA simply to record whatever the customer says and pass that information on to the developers. This doesn’t work very well, either. As with most things in life, the appropriate behavior lies in between the possible extremes.

Requirements elicitation is a process of exploration and discovery, not just collection (which is why I don’t talk about “gathering requirements”), and the BA is the guide. BAs need to recognize that customers won’t be able to present all their requirements in a single workshop or discussion. They probably don’t even know what their real requirements are yet. Elicitation requires multiple cycles of refinement, clarification, and adjustment as the participants move back and forth between high-level concepts and specific details.

But First, Some Questions to Avoid

The worst question you can ask during a requirements discussion is “What do you want?” The second-worst question is “What are your requirements?” No one knows quite how to answer these questions. Customers and other elicitation participants might not share the BA’s understanding of what the word “requirement” even means. When customers attempt to answer these questions in good faith, they typically generate a large number of random—yet important—thoughts.

I’ve observed this in some of my training classes, in which small groups of students conduct a practice requirements elicitation workshop on a sample project called the Cafeteria Ordering System. The groups are trying to learn how to employ use cases to explore user requirements. One member of each group plays the role of a user who would employ this system to order meals. Some groups begin by asking this student, “What do you want?” because this is how they’re accustomed to launching requirements discussions. They typically get responses such as:

• I need to be able to pay by either credit card or payroll deduction.
• I want to be able to order group meals for lunch meetings.
• The system has to be available from home as well as from work.
• I’ll have to submit delivery instructions for my meals.
• I shouldn’t have to pay any delivery charges.
• Can contractors order meals or just employees?
• I want to be able to order meals at least a week in advance.
• It would be nice if I could easily reorder the same meal I ordered sometime in the past.
• Could I get nutrition information for a whole meal?

These are unquestionably important thoughts and ideas. However, when asked “What do you want?” the workshop participants tend to spew out these thoughts in a random sequence with no organizing structure. This makes it hard for both the BA and the customers to know what the information means, what to do with it, where to store it, and what to discuss next. The student groups who take this approach invariably flounder in the sea of random input. In contrast, those groups that grasp the use case approach early on make much faster progress. An important BA skill is to structure the dialogue and ask questions that will guide elicitation participants through progressive layers of refinement in an organized fashion.

The BA should remember his role as a neutral facilitator. We all filter what we hear through our own biases, preferences, experiences, and hot button issues. Avoid asking leading questions that steer customers to agree with your own intentions. Also avoid overruling a customer’s idea just because it doesn’t agree with your own point of view. I once observed a 60-participant “voice-of-the-customer” workshop that one of my consulting clients conducted to explore requirements for a major new product. The workshop facilitator was the senior manager responsible for the product. He had strong opinions about the project’s direction and didn’t hesitate to steer the discussion toward his predetermined outcomes. This is discouraging for participants, who will feel that they’re wasting their time if the facilitator already knows what the answers will be.

In the next installment in this series, I’ll explore some questions that are helpful for eliciting business requirements. These requirements define the organization’s business objectives for undertaking the project, define the product vision, and enable scope definition and management.

This series of articles describes some questions a BA might consider asking during elicitation discussions—as well as some to avoid. The articles are adapted from my book More about Software Requirements: Thorny Issues and Practical Advice (Microsoft Press, 2006). A classic resource of good questions for discussing requirements for any type of project is Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg (Dorset House, 1989). Roxanne Miller also suggests hundreds of questions to help the BA with requirements elicitation in her book The Quest for Software Requirements (MavenMark Books, 2009).

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.