The Business Analyst as Explorer, Part 3 of 6 by Karl Wiegers
The business requirements will help the business analyst identify potential user classes for the product. The objective of exploring user requirements is to understand what members of these user classes expect to be able to do with the product and how the product will let them achieve specific goals. The user requirements must align with the higher-level business goals captured in the business requirements.
Some user goals might pertain to tasks the users must perform; use cases often are an effective way to record these tasks. Other user goals, though, might indicate the importance of specific nonfunctional requirements. Examples include the ability to complete a task within a certain length of time, and the ability to access a system remotely from a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes.
It’s also important to surface pertinent business rules, design and implementation constraints, and assumptions the various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so he can record both functional and nonfunctional requirements that will guide the development team’s work. Furthermore, documented requirements and user acceptance criteria will help testers determine whether the delivered product satisfies its requirements.
When eliciting user requirements, the BA typically works with a number of key users who represent specific user classes. The BA needs to ask questions that will help those users describe the goals they want to accomplish with the help of the system. For most types of software projects, this is far more valuable than the traditional focus of requirements discussions on system features and functions. The emphasis on user tasks or goals is the essence of the use case approach to requirements elicitation. Scenarios and stories also emphasize a usage-centric perspective to requirements elicitation.
Instead of asking, “What do you want?” or even “What do you want the system to do?” an approach based on usage and user goals asks, “What do you need to do with the product?” Your users might not be accustomed to a dialogue of this nature. It can be difficult to shift their thinking from the traditional focus on the system itself, so some education of your user representatives is in order. It’s not realistic to think you can simply ask the users what their use cases are and get a meaningful response. Even if you explain what use cases are, don’t expect users to hand you a tidy, precise, and complete list of their use cases. The BA must work with the input that users provide to determine the real goals they have in mind.
I sometimes use the example of an airline flight reservation kiosk when describing use cases in my training seminars. Instead of just asking the class what their use cases would be for such a product, I ask, “What are some things you would imagine doing with an airline flight reservation kiosk?” A variant question is, “What are some reasons you would want to use an airline flight reservation kiosk?” During the class discussion, some of the responses are indeed candidates for use cases, although they still need to pass through a filter that asks “Is this in scope?” before we determine that they belong in the system we’re exploring. These use cases include:
- Find Available Flights for an Itinerary
- Make a Flight Reservation
- Select Seats
- Print an Itinerary
- Change a Reservation
- Cancel a Reservation
- Check on Flight Status (This one might not be in scope because it requires real-time access to current flight information from the airlines. The business requirements should indicate whether this sort of capability will help us achieve our business objectives.)
Notice that all these use cases begin with a verb. This is a standard convention for naming use cases. The BAs should listen for responses from customers that do not begin with a verb and discuss the intent behind each such response. Once when I held this discussion in a class and asked, “What are some things you would imagine doing with an airline flight reservation kiosk?” one student simply said, “Weather.” This one-word response prompted me to explore exactly what aspect of weather the student had in mind, to find an appropriate verb. Did she want to create the weather, change the weather, or what? I learned that she wanted to check the weather forecast at the originating, destination, and connection cities for a specific flight itinerary. Hunting for the verb the customer has in mind is a way to discover the task or goal behind the initially presented input.
Just because a user provides a response that begins with a verb doesn’t mean that it’s actually a use case. Someone might suggest as a possible use case, “Enter my frequent-flier number.” A use case should describe a standalone task: A user has a specific goal in mind, walks up to the system, interacts with it in some way, and—if all goes well—achieves the goal and walks away happy. However, no one would ever walk up to this kiosk, enter his frequent-flier number, and feel fulfilled. I needed a follow-up discussion to determine what the user was really trying to accomplish by entering a frequent-flier number. Some possibilities are:
- See how many miles he has accrued.
- Purchase a ticket using frequent-flier miles.
- Purchase a seat upgrade using frequent-flier miles.
- See if he has received mileage credit from a previous flight, car rental, or hotel stay.
- Recall his stored profile so that he doesn’t have to reenter a lot of information when making a reservation.
The first four of these items are use cases, something a user might do as a standalone task. The last one, though, doesn’t represent a discrete task. It’s likely part of some other use case, such as Make a Flight Reservation. The main point here is that the BA must expect to work with users to determine whether a piece of presented input is a user task, a bit of system functionality, a quality attribute, a constraint, a business rule, extraneous information, or something else.
(adapted from More about Software Requirements by Karl Wiegers)
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.
Comments