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

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

Karl Wiegers
Jan 24 · 6 min read
A woman with a thoughtful expression standing in front of a blackboard covered with question marks.
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

  • 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?

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

Why Ask Why?

“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

  • 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?

Metaquestions

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.

Analyst’s corner

We are passionate about helping businesses do their job better!

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store