Use cases are a powerful requirements elicitation and analysis tool that have unfortunately fallen out of favor. Use them anyway!
Image by Freepik
I like use cases. There, I said it, and I’m not sorry. Use cases have fallen out of fashion in recent years, being largely replaced by user stories on agile projects. The two techniques can coexist and complement each other, however.
Use cases offer several advantages that user stories lack. This article describes some of the many benefits that use cases can provide and why every business analyst (BA), product owner (PO), and software development team should include them in their tool kit.
What’s a Use Case?
This definition comes from the inventor of use cases, Ivar Jacobson: “A use case is all the ways of using a system to achieve a particular goal for a particular user.” This concise definition includes three important ideas:
- Focusing on goals that a user has in mind when using a product.
- Recognizing that there are multiple classes of users, each of which might have different use cases that the BA or PO must elicit, understand, and address.
- Indicating that there can be multiple related pathways (scenarios) by which a user could attain a desired outcome.
Use cases are a powerful requirements elicitation tool to discover and explore the user-valuable transactions a solution must provide. Each time a user interacts with a product, they have an intent in mind, something they wish to accomplish. When an elicitation participant says “I want to [do something]” or “I need to [do something]” the [do something] probably is a use case. The name of a use case begins with a verb and concisely states the user’s goal for a single interaction session: Register for a Course, Pay Credit Card Bill, Cancel My Subscription.
Different authors describe use cases in different ways. There are some variations in terminology and multiple ways to apply them. That’s fine. It’s the use-case mindset and thought process that’s particularly valuable, not the specific approach a particular team or analyst follows.
Documenting Use Cases
A use case description is best presented in the form of structured text. The Unified Modeling Language (UML) includes a use case diagram as a way to visually show the connections between various types of users (often called actors) and their corresponding use cases. It’s often valuable to supplement a textual use case specification with visual models such as a sequence diagram, activity diagram, or flowchart. Diagrams are particularly valuable when the product being developed is a high-risk, complex, or life-critical system as in pharma, defense, or telecom. But at heart, you describe a use case using text.
A use case template provides a structured outline that helps the BA record as detailed—or as simple—a description of a user task as required. If you don’t need all the information in the template to adequately understand a particular use case, complete only the sections that add value. The level of detail in a particular use case description can range from casual to fully dressed (in the terminology of author Alistair Cockburn), whatever achieves the overarching requirements specification goal of clear and effective communication.
The core of a use case describes a dialogue or interaction between the user and the system (and possibly other entities) that leads to achieving the user’s stated goal. This success scenario goes by many names, most commonly the basic flow. Related scenarios that represent other pathways for achieving the goal are alternative flows. Exceptions are conditions or events that could prevent achieving the user’s goal.
A use case template includes slots for other key pieces of information, including preconditions, postconditions, assumptions, and pertinent business rules. The use case template guides exploration, reminding you of what information might be valuable to have and providing a consistent place for project participants to store—and find—it.
Usage-Centric Elicitation
The most important lesson I’ve learned about software development is to focus requirements elicitation on usage rather than on the product and its features. Use cases facilitate that emphasis on usage. Let’s first understand what people need to do with the solution. From that knowledge, the BA can determine what functionality to implement. Asking users “What do you need to do with the product?” is more informative than asking “What are your requirements?” or “What features should the product contain?” or (horrors!) “What do you want?”
A usage-centric perspective increases the chance of discovering the functionality that will let users get things done without missing any functionality. Concentrating on usage scenarios makes it less likely that the team will waste time implementing functionality that perhaps seemed like a good idea but goes unused because it doesn’t contribute to known user tasks.
People can review and understand use cases because they describe interaction sessions that relate to the user’s intent and actions. Users can find omissions: “I don’t see how I would do this particular thing” or “How should the system handle this less common situation?” Readers can identify exception conditions for particular scenarios: “How should the system react if this input is missing or invalid?” If you don’t detect a functionality omission before implementation or handle an error condition sensibly, you can expect rework when a tester finds it or unhappy users encounter that situation.
Providing Context
People manage complexity using organization, hierarchy, and abstraction. A mass of unstructured user stories or functional requirements lacks all three. Without structure, it’s difficult for stakeholders to see the context into which each set of user needs and corresponding functionality fits. This lack of context makes it easy both to overlook something that’s missing and to include something that’s unnecessary. It also makes it more challenging to develop a robust, well-architected solution by building on previously completed work.
Figure 1 shows that use cases lie at a higher level of abstraction than individual user stories or functional requirements. This abstraction makes that content more tractable than having a pile of information bits with no obvious connections. A use case can group multiple related scenarios or stories—both those leading to a successful outcome and exceptions that might not—to show their links and make them easier to manage as a set.
Requirements knowledge like business rules, data objects, quality attributes, and assumptions can span multiple stories. The BA can record such information at the use-case level of abstraction, instead of duplicating them in multiple stories or—worse—overlooking them. Identifying those influences provides continuity as the team implements additional use case flows over time.
Figure 1. Relative abstraction levels for several types of requirements objects (from Software Requirements Essentials by Karl Wiegers and Candase Hokanson)
Use cases are more of a top-down requirements exploration technique; user stories are more bottom-up. I find it more efficient to think top-down, decomposing initially proposed use cases into details and fleshing them out. That works better for me than trying to figure out how to group related detailed items from a large set, like assembling a jigsaw puzzle. The BA can also take a middle-out approach, adjusting the abstraction level up or down as they acquire more information. This strategy avoids combining multiple unrelated use cases inappropriately. It also avoids subdividing the information too finely into an explosion of similar use cases.
Use cases provide an end-to-end understanding of the user’s workflow and the interconnections that are often lacking in a mass of user stories. They give the big picture and context that will ultimately be implemented scenario by scenario. A catalog of use cases leads logically from the business goals through user interactions and on to more detailed requirements and designs, retaining the context of both problem and solution.
Slicing, Prioritizing, and User Stories
Use cases aren’t an end in themselves. They’re a tool for understanding user goals, which leads to an understanding of the functionality needed in the solution, which then leads to team members designing, developing, and verifying the solution. The intent is to identify those scenarios that will deliver the most stakeholder value quickly.
If you identify the use case’s basic flow of events and its exceptions, along with possible alternative flows and their exceptions, you can split the use case into slices that the team can implement independently during multiple development iterations based on their relative priority. If your team is accustomed to allocating user stories to iterations, a sliced-up use case can serve as a prioritized set of related stories. Modeling use case scenarios with, for example, activity diagrams provides another way to slice use cases into stories for implementation at the right time.
Use Cases and Testing
When I began employing use cases as a BA, I immediately saw how naturally they lead to writing tests. I found it easy to envision tests to determine whether each success scenario behaved as I expected and whether we handled each identified exception appropriately. Early test thinking gives you a jump-start on writing acceptance criteria that lead to a robust solution. The Given–When–Then structure commonly used for writing acceptance criteria on agile projects works well for defining tests based on use cases.
There’s another benefit to deriving tests from use cases. I’ve found it valuable to have a BA write functional requirements from a use case specification and concurrently have a tester write test cases from it. Comparing the outputs from these two complementary thought processes can reveal errors: missing, wrong, or unneeded requirements; missing, wrong, or unneeded tests; missing information; ambiguous requirements; and conflicting assumptions. It’s cheaper and less painful to find such problems early rather than late.
If you create only a single representation of requirements, you must believe it: It’s all you have. But if you create multiple representations or views— use cases, functional requirements, tests, diagrams, tables, prototypes—you can compare them. Disconnects reveal problems , well before a user encounters them.
Valuable but Not Sufficient
The information in a use case isn’t always enough to fully implement the right solution for that portion of the product. For instance, a use case specification doesn’t say what the system should do if some precondition is not satisfied. Someone must figure that out, though. Someone needs to determine all the bits of functionality that developers must implement to let a user fully perform the interaction, including how to handle all the exceptions. Business rules and quality attributes associated with the use case often lead to additional functionality.
User representatives and other stakeholders won’t provide all of that information. It’s up to the BA—or whoever fills that role on the team—to figure it out. Nor will users tell the BA about behind-the-scenes functionality that’s needed but isn’t apparent to the end user. For instance, if a user withdraws cash from a bank’s ATM, the bank system must update its record of how much cash remains in the machine. Users rarely think of such details—it’s not their problem or part of achieving their goal. It’s the next ATM user’s problem!
For some types of products, such as real-time systems containing both software and hardware components, event analysis can be a more effective elicitation technique. While use cases are a powerful tool in the hands of a BA, they don’t provide a complete solution to the requirements problem.
An Experience Report
I have some empirical evidence that use cases are an effective elicitation tool. I have taught a two-day course on software requirements more than 180 times. In that course, we do a one-hour practice elicitation workshop. I break the students into four teams and present them with a project. I ask them to identify several user classes for the project, identify several use cases for one user class, and then explore one of those use cases and write some functional requirements from it. I’ve observed about 700 teams perform this exercise.
The same pattern prevails in nearly every class. One team gets the idea of use cases right away; they make impressive progress in one hour. Two of the teams struggle a bit. With a little coaching, they get on track and make good headway.
The fourth team just doesn’t grasp the use case concept. Their flip chart is covered with sticky notes showing random pieces of information: functional requirements, features, stories, quality attributes, business rules, data objects, constraints, and user tasks. The team then just stares at those sticky notes, not knowing what to do next.
When I ask that fourth team how they started the elicitation workshop, the facilitator always says, “I asked the group what their requirements were and wrote down what they told me.” The teams that understand what use cases are about make much more progress on the problem far quicker. That’s been my personal experience on projects as well.
Why Not Employ Use Cases?
Several software developers have asked me recently, “Is it okay to employ use cases on an agile project?” After all, use cases aren’t an explicit practice in agile methodologies.
My answer is, “Yes, of course it is!” Why is that even a question open to debate? Software practitioners have a professional responsibility to use the best available techniques to perform their work. Use cases are a proven and powerful tool for effective requirements development. If they’re suitable for the nature of your project, use them.
Perhaps use cases are out of fashion now, but I’ve never heard a convincing explanation of why. Use case analysis is a timeless, valuable technique that belongs in every business analyst’s repertoire.
For More Information
Many books and articles on use cases have been published in the past 30 years. The following publications will give you an excellent start to understanding and applying use cases on your projects.
- Chapter 8 of my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) presents a concise yet fairly detailed introduction to use cases.
- Perhaps the best-known book is Alistair Cockburn’s Writing Effective Use Cases (Addison-Wesley, 2001).
- My favorite book on the topic is Use Cases: Requirements in Context, 2nd Ed. (Addison-Wesley, 2004) by Daryl Kulak and Eamonn Guiney.
- Use Case 2.0: The Guide to Succeeding with Use Cases by Ivar Jacobson, Ian Spence, and Kurt Bittner describes a lightweight and scalable way for agile teams to apply use cases.
Author: Karl Wiegers
Karl Wiegers is the Principal Consultant at Process Impact. He’s the author of numerous books, including Software Requirements (co-authored with Joy Beatty), More About Software Requirements, Software Development Pearls, and The Thoughtless Design of Everyday Things. Karl’s most recent book is Software Requirements Essentials with Candase Hokanson.