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. Ouch. 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 called 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 the system he was asking us to build. Not the best strategy for effective business analysis.
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 well, either. As with most situations, the appropriate behavior lies between the possible extremes.
Requirements elicitation is a process of exploration and discovery, not just a simple collection activity, and the BA is the guide. BAs must recognize that customers won’t be able to present all their requirements in a single workshop or discussion, assuming they even understand what the BA means by “requirements”. They probably don’t even know what their real needs are yet. Elicitation requires an iterative and incremental approach, with multiple cycles of refinement, clarification, and adjustment as the participants move back and forth between high-level concepts and specific details.
This article suggests some questions a BA might consider asking during requirements elicitation discussions.
But First, Some Questions to Avoid
The worst question you can ask during elicitation is “What do you want?” The second-worst question is “What are your requirements?” No one knows quite how to answer these questions. Such questions typically generate many random — yet important — thoughts, stirred together with extraneous information and seasoned heavily with business rules and assumptions.
I’ve observed this in some of my training classes, in which small groups of students conduct a practice elicitation workshop on a project called the Cafeteria Ordering System. 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. This question typically leads to input like the following:
- 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.
- 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 ideas. However, when asked simply “What do you want?” the workshop participants tend to spew out these thoughts in a random sequence with no organizing themes. This makes it hard for both the BA and the customers to know what the information means, what to do with it, how and where to store it, and what to discuss next. The student teams who take this approach invariably struggle to make order out of the chaos, and they never make much progress in this one-hour exercise.
A vital BA skill is to structure the dialogue and ask questions that will guide elicitation participants through progressive layers of refinement in an organized fashion. Use cases serve as one such organizing structure. After watching hundreds of groups perform this exercise, I’ve observed that the ones who absorb the use case approach quickly and apply it effectively always make impressive progress during the practice session.
Exploring User Requirements
The objective of exploring user requirements (or what the IIBA calls “stakeholder requirements”) is to understand what members of each user class expect to be able to do with the product. Stated another way, how could the product let users achieve specific goals? The user requirements must align with the project’s business objectives as 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 requirements, 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 securely access a system remotely with a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes.
Agile projects typically employ user stories as the basic requirement artifact. User stories often are written according to the following template:
As a <type of user>, I want <some goal> so that <some reason>.
When written in this form, user stories also represent an approach to user requirements, because they seek to identify and understand the goals users need to accomplish with the system.
Beyond user tasks, it’s also important during elicitation to surface pertinent business rules, design and implementation constraints, and assumptions various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so she can record both functional and nonfunctional requirements that will guide the development team’s work and indicate when the product is ready for release.
When eliciting user requirements, the BA typically works with a number of key users (“product champions”) 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. This strategy is far more powerful than the traditional focus of requirements discussions on system features and functions. Both use cases and user stories emphasize this usage-centric perspective on requirements elicitation.
Instead of asking “What do you want the system to do?” the usage-centric approach asks, “What do you need to do with the product?” Your users might not be accustomed to a dialogue like this. It can be difficult to shift their thinking from the traditional focus on the system itself. Don’t expect to just ask people to list their use cases or user stories and get meaningful responses, even if you’ve explained what those things are. The BA must work with whatever input users provide to determine the real goals they have in mind and craft that knowledge into structured requirements statements.
Candidate Use Cases
I sometimes use the example of an airline flight reservation app when describing use cases. 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 app?” During the ensuing discussion, some of the responses are indeed candidates for use cases, such as:
- 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
I call these “candidate use cases” because 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. For instance, “Check on flight status” 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 capability would help us achieve our business objectives for this product at acceptable cost.
Notice that all these use cases begin with a verb. This is a standard convention for naming use cases. Listen for responses from customers that don’t begin with a verb so you can explore 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 app?” one student simply said, “Weather.” Okay, we need a verb. Did she want to create the weather, change the weather, report the weather, or what? Ah, 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 good way to discover the task or goal behind her initial response.
Just because a user’s response begins with a verb doesn’t mean it’s a use case. One student suggested “Enter my frequent-flier number” as a possible use case. But is that really a goal in itself? A use case should describe a standalone task: A user has a specific goal in mind, accesses 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 open a flight reservation app, enter his frequent-flier number, and say “Thanks, that was great,” and close the app.
Therefore, I had to ask follow-up questions 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 an 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 he can review or modify it.
The main point here is that the BA must expect to work with users to determine whether a “requirement” a customer rep requests is a user task, a bit of system functionality, a quality expectation, a business rule, or something else.
Focusing requirements elicitation on usage rather than features is a powerful way to design systems that meet user expectations without including a lot of unnecessary functionality. This is why I find exploring user requirements to be so helpful in making sure that the functional requirements will align with achieving the project’s business objectives.