Requirements Elicitation
Common requirements elicitation techniques that successful Business Analysts use to understand the problem and define a satisfactory solution.
This chapter is from the book
This chapter is from the book
This chapter is from the book
The first step in dealing with requirements is to get some. People often speak of “gathering requirements,” as though it were a simple collection process: The requirements are sitting around in people’s heads, and the business analyst merely asks for them and writes them down. It’s never that simple. In reality, stakeholders begin with random fragments of information: dissatisfaction with their current systems, bits of functionality they want, tasks to perform, important pieces of data, and ideas of what screen displays might look like.
Requirements elicitation is a better term for this foundational activity. To elicit something means to draw it forth or bring it out, particularly something that’s hidden or latent. The Merriam-Webster Thesaurus (2022) says, “elicit usually implies some effort or skill in drawing forth a response.” That skill is a significant asset that a business analyst brings to software development. Requirements elicitation does involve collection, but it also involves exploration, discovery, and invention. The BA guides this imaginative journey, working with diverse stakeholders to understand the problem and then define a satisfactory solution. The BA looks for potential requirements from many sources, including these:
User representatives and many other stakeholders
Documentation about business processes, current systems, and competing products
Laws, regulations, and business policies
Existing systems, which may or may not be documented
User problem reports, help desk records, and support staff
An experienced BA exploits multiple techniques for elicitation, choosing the appropriate tool for a particular situation. Factors to consider when selecting elicitation methods include the types of information needed; who has that information, where those people are located, and their availability; the effort that the method requires; the budget and time available; the development team’s life cycle model and methodologies; and the cultures of the developing and customer organizations (IIBA 2015).
This book does not go into elicitation techniques in detail, as those are thoroughly described in other resources (e.g., Davis 2005, Robertson and Robertson 2013, Wiegers and Beatty 2013, IIBA 2015). Table 3.1 lists several commonly used elicitation activities and the typical participants.
Table 3.1 Some common requirements elicitation techniques
Participants |
Activities |
|---|---|
Business analyst |
|
Business analyst and stakeholders |
|
This chapter describes four core practices that are particularly valuable for eliciting both functional and nonfunctional requirements:
Practice #6. Understand what users need to do with the solution.
Practice #7. Identify events and responses.
Practice #8. Assess data concepts and relationships.
Practice #9. Elicit and evaluate quality attributes.
Practice #6 Understand what users need to do with the solution.
If you were holding a requirements elicitation discussion with some users about a new information system, which of these questions do you think would yield the greatest insights?
What do you want?
What are your requirements?
What do you want the system to do?
What features would you like to see in the system?
What do you need to do with the solution?
We favor the final question. While the first four questions can provide a good starting point to ask why a stakeholder wants those things, they all inquire about the solution, not the user’s problems, needs, or goals. Focusing on features can lead the team to implement incomplete functionality that doesn’t let users do all the things they must do. The feature-centered mindset also can lead to building functionality that seems like a good idea but goes unused because it doesn’t directly relate to user tasks. Regardless of your development approach, if you don’t understand what the users need to do with the features they request, you might release a product that you must rework later.
Karl once saw the limitations of elicitation questions that focus on the solution. A company held a daylong workshop with about sixty participants to brainstorm ideas for a large new commercial product. They stapled together the output from their six subgroups and called it a requirements specification. But it wasn’t. It was a mishmash of functionality fragments, feature descriptions, user tasks, data objects, and performance expectations, along with extraneous information, all stirred together with no structure or organization. Simply asking people to imagine what they wanted to see in the new product didn’t produce actionable requirements knowledge. Much more requirements development work was needed following the workshop.
Focusing on Usage
The question “What do you need to do with the solution?” is a more effective opening for discussing requirements. By understanding what the users need to do, the BA can deduce just what functionality is needed. A usage-centric approach makes it more likely that the solution will satisfy user needs, incorporating the necessary capabilities without wasting development effort on unneeded functions (Wiegers 2022).
Stories, scenarios, and use cases are variations on a common theme: asking users to describe an interaction they might have with a software system or a business to achieve some goal (Alexander and Maiden 2004). These descriptions of user goals and the interactions that lead to achieving them constitute the user requirements. User requirements appear in the middle section of the requirements information model in Figure 1.1, as reproduced in Figure 3.1. The user requirements should align with the business objectives from the vision and scope document and contribute to solving an identified business problem.
){kind=link}
Figure 3.1 User requirements lie between business requirements and solution requirements.
Eliciting User Requirements
A person doesn’t launch an application to use a particular feature; they launch it to do something. It’s difficult for users to articulate their “requirements,” but they can easily describe how they might perform a business activity. During an elicitation discussion, the BA might ask a user representative, “Please describe a session you might have with the product we’re talking about. What would you be trying to accomplish? How do you imagine your dialogue with the system would go?” A description of a single interactive session like this is called a scenario.
A scenario identifies a sequence of steps that define a task to achieve a specific intent (Alexander and Maiden 2004). When you ask a user to describe a scenario, they’ll usually begin with the most typical or frequent activity they perform. This is sometimes called the normal flow, main flow, main success scenario, or happy path. From that initial scenario, the BA and user can then explore alternative scenarios (or flows), variations that also lead to a successful outcome. They can also discuss exceptions, possible conditions that could prevent a scenario from concluding successfully.
An effective way to organize these related scenarios is in the form of use cases (Cockburn 2001, Kulak and Guiney 2004). A use case structures all this information according to a template, which is described in the next section. The use case technique helps the team acquire and organize the mass of requirements information that any sizable system involves. If an elicitation participant says “I want to <do something>” or “I need to be able to <do something>,” the <do something> likely is a use case.
The various user classes will have different use cases, different things they need to accomplish with the solution. That’s why it’s a good idea to conduct group elicitation activities with members of each user class separately. As an example, Table 3.2 lists a few use cases for each of the user classes named earlier for the hypothetical Speak-Out.biz publication platform in Practice #4, “Identify and characterize stakeholders.”
Table 3.2 Some use cases for several Speak-Out.biz user classes
User class |
Use cases |
|---|---|
Author |
Draft an Article Edit an Article Publish an Article Submit an Article to a Publication View Article Statistics |
Reader |
Read an Article Comment on an Article Subscribe to an Author |
Publication Editor |
Create a New Publication Accept or Reject a Submitted Article Reply to an Author |
Administrator |
Respond to a Reader Complaint Suspend an Author’s Account |
Each use case name is a concise statement that clearly indicates the user’s goal, the outcome of value that the user wishes to achieve. Notice that all the use cases in Table 3.2 begin with a definitive action verb. This is a standard use case naming convention.
Agile projects often rely on user stories as a technique for discussing system capabilities. According to agile expert Mike Cohn (2004), “A user story describes functionality that will be valuable to either a user or purchaser of the system or software.” A user story is intentionally brief, a starting point for further exploration of its details so that developers can learn enough to implement the story. User stories conform to a simple pattern, such as this one:
As a <type of user>, I want to <perform some task> so that I can <achieve some goal>.
Stories that focus on what users need to do with the solution, rather than on bits of system functionality, can serve the goal of usage-centric requirements exploration. Here’s a user story we might hear from a Speak-Out.biz author:
As an author, I want to view the page-view statistics for my published articles so that I can see which topics my readers enjoy the most.
This story addresses a piece of the functionality for the final use case shown for the Author user class in Table 3.2, View Article Statistics. The user story format offers the advantages of naming the user class and describing the intent. That information would appear in a use case specification, but it’s helpful to see it right up front like this.
There are ongoing debates about whether use cases are appropriate—or even allowed—for agile development. This isn’t the place to rehash those debates, but the short answer is: They are (Leffingwell 2011). Both use cases and user stories have their advantages and limitations (Bergman 2010). Both can be used to explore what users need to accomplish with the solution.
One of the BA’s challenges is to examine a particular scenario that describes a single usage session and consider how to generalize it to encompass a group of logically related scenarios. That is, the BA moves up the abstraction scale from a specific scenario to a more general use case. Similarly, the BA on an agile project might see that a set of related user stories can be abstracted into a larger epic that needs to be implemented over several iterations.
At other times, elicitation participants might begin with a complex usage description that the BA realizes should be split into multiple use cases. Those individual use cases often can be implemented, and executed, independently, although several could perhaps be chained together during execution to carry out a larger task. On an agile project, a user story that’s too large to implement in a single iteration is split into several smaller stories. Moving between levels of abstraction like this is a natural part of exploring user requirements.
Use cases facilitate top-down thinking, describing multiple scenarios and fleshing out the details of the user–system interactions. Use cases provide a context for organizing related pieces of information. Epics perform an analogous top-down function on agile projects. User stories describe smaller user goals or pieces of system functionality without much context or detail. Stories generally are smaller than use cases, describing slices of functionality that can be implemented in a single development iteration. Related user stories can be grouped together and abstracted into an appropriate use case or an epic. Any approach can be effective—use cases or user stories, top-down or bottom-up—provided the focus stays on usage.
Anatomy of a Use Case
Unlike the simple user story format, a use case specification follows a rich template like the one in Figure 3.2 (Wiegers and Beatty 2013). You may download this template from the website that accompanies this book. A collection of use case descriptions could serve as the contents of the user requirements document (“container”) that appears in Figure 3.1. Nothing says that you must complete this full template for each of your use cases. Write in whatever level of detail will clearly communicate the use case information to those who must validate, implement, or write tests based on it.
)
Figure 3.2 A rich use case specification template.
Applying Usage-centric Requirements Information
User requirements serve as a starting point for several subsequent activities. Both use cases and user stories need to be further elaborated into a set of functional requirements, which is what developers implement. This step takes place whether a BA does it analytically and documents the resultant details or whether each developer does it in their head on the fly (not the recommended approach).
Use cases and user stories both facilitate starting testing early in the development cycle. If a BA derives functional requirements from a use case and a tester derives tests, you now have two representations of requirements knowledge that you can compare. That comparison can reveal requirements errors, ambiguities, and omissions. See Practice #18, “Review and test the requirements,” for more on this topic. Documenting how the system should handle exceptions lets developers build more robust software and helps testers do a more thorough job.
User stories and use cases also lie at the core of requirements prioritization. The deciding stakeholder typically prioritizes user stories or use cases in a sequence that maximizes customer value. The team then fits them into iterations or increments based on the team’s available capacity, considering any relevant technical and functional dependencies. While user stories are each prioritized on their own, the individual flows within a use case could have different priorities. You might opt to implement the normal flow and its exceptions in one development increment, and then implement alternative flows and their corresponding exceptions in upcoming increments.
Usage-centric requirements exploration won’t reveal behind-the-scenes capabilities, such as a timeout to turn off some device or log out a user after a period of inactivity. Nonetheless, focusing elicitation on understanding what users must do with the system helps the team implement all the necessary—and no unnecessary—functionality. Usage-centric thinking also leads nicely into designing an optimal user experience (Constantine and Lockwood 1999).
Related Practices
Practice #2. Define business objectives.
Practice #4. Identify and characterize stakeholders.
Practice #7. Identify events and responses.
Practice #13. Prioritize the requirements.
Practice #16. Identify and document business rules.
Practice #18. Review and test the requirements.
Next Steps
If your team has not explored the tasks that users want to perform with the solution you’re building, have conversations with your user representatives to identify their use cases. Explore alternative scenarios along with the normal flow. Make sure to note exceptions and how they should be handled.
Try completing the use case template in Figure 3.2 for several of your use cases. How could you simplify the template and still meet the needs of your developers and testers?
If your project is employing user stories, try documenting a group of related scenarios both in the use case format and as a set of user stories. Which approach seems most effective and efficient for your team?