Skip to main content

Questions for Eliciting User Requirements

FEATUREDec6thThe Business Analyst as Explorer, Part 4 of 6 by Karl Wiegers

This article presents several sets of questions the business analyst might consider asking customer representatives during a discussion about user requirements. Don’t use these questions as a script to be followed by rote in an elicitation workshop. Instead, look for ways to build these sorts of questions into the natural flow of a requirements exploration.

What are some reasons why you or your colleagues would use the new product? These “reasons to use” could become candidates for use cases. They might identify business tasks or objectives that members of a particular user class might need to achieve from time to time.

What goals might you have in mind that this product could help you accomplish? Use cases normally are directed toward helping the user achieve a specific goal. The name of the use case indicates the goal the user has in mind: Print a Boarding Pass, Withdraw Cash, Submit an Employment Application, and so on.

What problems do you expect this product to solve for you? Understanding the problems and limitations the users perceive in their current environment helps the BA determine appropriate capabilities for the new system. This question also helps determine whether the end users’ objectives for the system align well with senior management’s objectives, as captured in the business requirements. If not, you need to iterate between the business requirements and user requirements to align expectations.

What external events are associated with the product? BAs sometimes use the term business event to describe the triggering condition that launches execution of a use case. Perhaps a help desk receives a phone call from a user who needs assistance. This external event triggers the help desk staffer to create a problem report ticket. In products such as real-time control systems, use cases aren’t a valuable technique for understanding user requirements. An alternative approach is to identify the external events the system must detect. Then describe the appropriate system response, which depends on the state the system is in at the time each event is detected.

Most requirements discussions focus on functionality. However, a product’s nonfunctional characteristics also have a great impact on how users feel about the product. Questions such as the ones that follow help the BA understand the user’s expectations about aspects of the product’s quality.

What words would you use to describe the product? Consider asking users to close their eyes and describe their vision of the future system. Listen to the words they use to describe the product. Nouns suggest objects the system must be able to manipulate (such as order, reservation, chemical, account balance, sensor). Verbs can indicate actions the user expects to be able to take or expects the system to take (such as place, create, revise, submit, receive, detect, measure, display). Adverbs convey the user’s thoughts about the product’s characteristics (for example, quickly, reliably, efficiently, flexibly, easily).

 

Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics? You can never create a product that combines the maximum levels of all quality characteristics. Tradeoffs are necessary between properties such as usability and efficiency, integrity and usability, and integrity and interoperability. (See Chapter 12 of my book Software Requirements, 2nd Edition for more about tradeoffs.) Therefore, it’s important to understand which specific portions or aspects of the product have critical quality demands so that developers can optimize their designs to achieve those objectives.

Are there any constraints or rules to which the product must conform? Most products are subject to corporate policies, industry standards, government regulations, and computational algorithms. It’s essential to know about such business rules so the BA can specify functional requirements to enforce or comply with those rules. Look for subject matter experts within the organization who have current knowledge about the business rules.

How is the product you envision similar to the way you do business now? How should it be different? When automating current business processes or replacing an existing information system with a new one, it’s easy to inadvertently re-implement all the shortcomings of the current approaches. This is known as “repaving the cow paths.” It’s difficult for people to break from the mindset of their current ways of working and to envision something that’s really different and better. The BA should stimulate the thinking of the user representatives to rethink business rules and business processes to see what has changed—or what could change.

What aspects of the current product or business process do you want to retain? To replace? Customer acceptance of a new product depends partly on how familiar it feels to them. Similarity to previous products and processes reduces the learning curve, making it easier for users to master a new system and workflow.

The following questions help the BA gain a richer understanding of how potential users view the product. Asking these questions of people who represent different stakeholder groups can reveal conflicts that you’ll need to reconcile.

Which aspects of the product are most critical to creating business value? A user’s view of business value might be different from a manager’s view or an acquiring customer’s view. A user might value a more efficient way to perform a specific task that will save considerable time over many executions. A manager could be more impressed if the product has lower acquisition and support costs than the one it’s replacing.

What aspect of the product will be most valuable to you? Least valuable? No project can deliver everything to everybody on day one. Someone needs to determine the implementation sequence for various capabilities. Ask this question of different user representatives, and look for patterns that indicate certain product capabilities are more important and more urgent than others. Those capabilities should have top priority.

What is most important to you about the product? This deliberately vague question could generate responses dealing either with the product itself or with other aspects of the project. One user might say, “It’s most important that this system be available before the beginning of the next fiscal year.” Another might respond, “It’s most important that this system will let me import all my data from these older systems we’ve been using.” A manager might say, “It’s most important that the people in my department can get up to speed on this new system without training.” These responses have implications for how the project is planned, the functionality to include, and usability, respectively.

How would you judge whether the product is a success? A business manager might judge the success of the product quite differently from how members of various user classes determine success. Surface these different perspectives early so that they can be reconciled to keep all stakeholders working toward a common objective.

Can you describe the environment in which the product will be used? The operating environment has a big impact on both requirements and design decisions. The user interface is also highly sensitive to the operating environment. Touch screen displays are superior to keyboards in some settings, for example, and speech recognition is becoming increasingly effective for certain applications.

The more the BA can learn about how users intend to employ the product, the better she can do at determining and specifying the functionality that developers need to implement. When you get right down to it, users don’t really care about product features; they care about getting their job done efficiently and maybe even enjoyably.

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.


Karl Wiegers

Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 14 books, including Software Requirements Essentials, Software Requirements, More About Software Requirements, Successful Business Analysis Consulting, Software Development Pearls, The Thoughtless Design of Everyday Things, and a forensic mystery novel titled The Reconstruction. Karl also has written many articles on software development, design, project management, chemistry, military history, and consulting, as well as 18 songs. You can reach him at ProcessImpact.com or KarlWiegers.com.