November 11, 2023
Volume 21, issue 5

Download PDF version of this article PDF

Use Cases are Essential

Use cases provide a proven method to capture and explain the requirements of a system in a concise and easily understood format.

Ivar Jacobson and Alistair Cockburn

While the software industry is a fast-paced and exciting world in which new tools, technologies, and techniques are constantly being developed to serve business and society, it is also forgetful. In its haste for fast-forward motion, it is subject to the whims of fashion and can forget or ignore proven solutions to some of the eternal problems that it faces. Use cases, first introduced in 1986⁶ and popularized later,^3,7 are one of those proven solutions. Ivar Jacobson and Alistair Cockburn, the two primary actors in this domain, are writing this article to describe to a new generation what use cases are and how they serve.

We believe there are many expert developers, analysts, and test specialists in the world today who are seeing shortcomings in their current ways of working, and are looking for a concise but robust way to describe and communicate requirements to their stakeholders. Use cases continue to solve a remarkable set of problems in a simple way, because they accomplish the following:

Make it easy for sponsors to see what they are getting.

Give business analysts a thought structure for investigating tricky business rules.

Give developers a context for what they are programming.

Give testers a scaffold for their function testing.

Keep the entire organization aligned with the value of the system being developed.

Capture a concise "permanent record" of the system, which is easy to update whenever the functionality of the system evolves.

Slice into increments and user stories to support agile software development practices.

And this is not even a complete list of benefits! Since use cases define the sequence of actions and interactions with actors, they can also drive user experience design and domain-driven design, enable business modeling and value stream analysis.

The "Why" of Use Cases

Use cases serve to bind an organization to its offering or declared intention. For example, the use cases of self-driving cars specify or describe what extra functionality these cars should have. Use cases could describe a brand-new product or service, or an improvement to something that already exists. They are understood easily and liked by users, stakeholders, business analysts, and test specialists.

This concept is so popular that the term use case has even become a dictionary entry and yields 111M matches on a Google search today (user story returns 3.4M hits). The reason for such a big number is that use cases are used in all domains: self-driving cars, big data, IoT (Internet of Things), cloud computing.

Even a mediocre use case will provide significant benefits to sponsors, analysts, developers, and testers; it is not necessary to refine them to the nth degree to unlock this value. There is also a beautiful precision about use cases; when the international standard UML (Unified Modeling Language) is used, you can have a seamless transition from use cases in requirements to their realizations in design, to implementation, and all the way to tests.

Unfortunately, one important community has forgotten about—or rejected—use cases in their work: the new generation of software developers. Many people still do not yet understand how easy it is to adopt use cases as an integral part of an agile development process. The result? Use cases may well be created, maintained, and deliver significant value to many parts of an organization, but then developers incorrectly believe there is an impedance mismatch between use cases and the user stories they wish to work with. Indeed, once we heard a developer say to a business analyst, "If you show up in our room with use cases, we won’t read them!"

Happily, we are now seeing a renaissance of use cases. Business analysts, even in agile projects, are using them to hold their business requirements together. A recent (2021) State of DevOps report also reinforced the importance of use cases:

"Document critical use cases for your products and services. What you document about a system is important, and use cases allow your readers to put the information, and your systems, to work."¹

What Does a Use Case Look Like?

The OMG UML specification⁹ defines use cases as follows:

"UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors."

Each use case contains these key elements:

The name of the use case is the goal the primary actor wishes to achieve.

The main scenario describes who does what, so that goal is achieved in a straightforward manner.

The alternative conditions name all the things that can go wrong, or indicate how an alternative path to success might occur.

The alternative flows describe how each of those conditions is handled, either patching up the flow to success or ultimately failing.

An actor defines a role that a user can play when interacting with the system. A user can be an individual or another system. The primary actor is the one for which the use case is prevalent. This is the reason for the use case. Very often, this actor is also the one that raises the event. Secondary actors are often needed to help the system achieve the goal of the primary actor. The magic of the use case is how simply all this is accomplished.

Here is a sample use case from an actual project to illustrate.

Place an order

Primary actor: Clerk

Main scenario:

1. Clerk identifies customer, item, and quantity.

2. System accepts and queues the order.

Alternatives:

1a. Low credit & Customer is ‘Preferred’: System gives them credit anyway.

1b. Low credit & not ‘Preferred’ Customer: Clerk accepts only prepayment.

2a. Low on stock: Customer accepts raincheck: Clerk reduces order to available stock level.

Note this example is a very simple, textual description of what has to happen, with no GUI (graphical user interface) described. It is so easy to read that any busy executive can scan it at a glance to see that key conditions are taken care of. At the same time, it is so complete that business analysts can investigate corner cases before the developers discover them. It provides the structure needed by testers to test completeness of the system’s functioning.

This readability is what makes use cases magical. Even a casually written use case provides the key values just outlined. The beauty of use cases is that they can be very effective when captured in structured text.

UML (the modeling standard language) can also be used to communicate key elements of the use case static view—a picture says more than a thousand words. Figure 1 shows a system called Warehouse Stock in which an actor Clerk has interactions with the use case Place an order, which in turn interacts with an actor Customer.

UML also allows us to describe the dynamic behavior and the interactions between actors and the use cases by applying sequence diagrams, collaboration diagrams, or activity diagrams if required.

The Benefits of Use Cases

At the highest level—what we might call "the $100,000 level," a use case can outline what is going to be delivered in a way that everyone in the organization can read. Binding the organization together in intention is worth hundreds of thousands of dollars. A few hours spent in a use case brainstorming session can help all participants gain a common understanding of the proposed solution and produce an easy-to-understand set of Use Cases.

In the previous example, further discussion about the work of the Clerk clarifies the role of that actor and of the system in a number of uses cases: perform regular audits of the stock, place an order for the customer, restock products when required, and help the delivery agent unload products in the warehouse. The UML diagram now provides a simple, clear, permanent record of the use cases affecting the state of the system and the actors we have identified using that system. Figure 2 shows a Warehouse Stock system with more actors and use cases.

As mentioned earlier, binding the organization together in intention is literally worth hundreds of thousands of dollars.

Story: Almost a year after one use case training class at a large company, its CTO said in a public seminar that use cases had saved his project. When the use cases were inspected, they were ridiculously, preposterously simple—much simpler than the example provided here.

When asked how such simple use cases could possibly have saved the project, the executive said, "What normally happens is that the business asks dev to produce something. The developers then go away for a long time, get distracted by various interesting but irrelevant topics, and deliver something else.

In this case, the business asked for these simple things, the developers stayed on track and delivered exactly those. Those simple use cases made our project successful for a change."

At the next level down, what we might call "the $10,000 level," the use case provides a scaffold for the business analyst to discover difficult corner cases and investigate and find an answer to them before the developers and testers ask them awkward questions they can’t answer.

Story: The Place an order use case example in this article is from an actual project. Alternative 1b was not in the original use case; there was only 1a, written as: "1a. Low credit & Customer is ‘Preferred’: System gives them credit."

Oddly, no one had asked, at the beginning, what should happen if the customer was not preferred. Finally, someone asked about this. It might seem strange, but omissions happen this way quite often. In this example, it took several days of investigation for the answer to show up.

This lack of inquiry into corner cases happens a lot in real-world situations—and it is likely that a simple question like this may take days to get answered. But imagine the cost to the business if the system had been developed and delivered without that case being handled.

No other functional requirement format—not numbered requirements, not shalls and shoulds, not user stories, not story maps—provides this value.

At the next level down, what we might call "the $1,000 level," the use case provides a wonderful specification to both the developers and the testers. It names each scenario and what should happen in each case.

The point is that the top-level value of use cases is in aligning the entire organization to its goal. The detailed writing has very high value, but still orders of magnitude less than the top value offered by even informally written use cases.

Why Did People Stop Using Them?

Three things put use cases on pause: the tendency to make a use case an encyclopedia entry for each functional requirement, that use cases force people to actually think about what they want, and agile’s counterproposal: "user stories."

1. The first mistake is the tendency to make a use case an encyclopedia entry for the functional requirements and collect everything of interest to a use case under the description of that use case. The project manager and business analysts start adding anything into the use case they judge to be important or relevant information. As a result, a once-compact use case becomes a bloated storage space for every bit of information about that topic: UI design, complex business rules, detailed validations, interface definitions, data formats, and so on. They lose the $100,000 value of use cases: being readable to busy people in all parts of the organization. If we had one rule for use cases, it would be this: Every use case description should be easily readable. Be very strict and selective about what is included in the use case. Functional requirements, and only the non-functional requirements relating to the specific use case, should be included (in a concise manner).

2. The second problem that use cases force people to actually think about what they wanted is highlighted by the story about finding out what to do about the non-preferred customers. They require thinking, and time to investigate. As the world has gotten to moving faster and working in the agile way, business analysts are given less and less time to think and investigate. Instead, they are told to just write a place-holder phrase and let the detailed conditions show up during development.

3. The third force causing the move away from use cases is the user story. User stories were originally proposed for small, collocated projects, where the business expert was within short walking distance of the developers. A user story was quite literally "a reminder to have a conversation." The detailed requirements would evolve in a series of conversations as the developer showed the business person the growing function. Detailed specifications were never written down. The user story was never a requirements-capturing format; it was deliberately informal and incomplete.

In a parallel evolution, user stories also eventually became encyclopedias, as use cases once had. They were moved from index cards in small, conversational settings to online requirements and task lists in large, distributed projects. They lost both the advantages of use cases as readable holders of the project’s purpose, and the rapid feedback that permitted them to be incomplete. What they retained was the idea that it was not necessary to think, to think ahead, to think in detail, but only to program. Developers love this.

The combination of heavy upfront thinking, use cases as unreadable encyclopedias, and the alternative of user stories to avoid thinking and planning led to that remark, "If you show up with use cases, we won’t read them."

The Renaissance of Use Cases

Slowly, businesspeople again started finding the need to see their proposed systems in one place, and a new audience is starting to understand the true concept of use cases. They need to "see" their system in front of them and vouch for the consistency and completeness of their requests. Business analysts have started writing in use cases again, just to hold the business in view while the developers move in an agile fashion.

Story: In a recent project, the people knew nothing at all about use cases and little about user stories, and had only just recently heard about user story mapping.

The business analyst got a crash course about use cases, and wrote two of them in a simple, readable style. She also marked the user stories for them (as shown in the next section). Asked to come into the office to discuss the upcoming project, she showed her two use cases to the development lead, who knew nothing of use cases at all. He was pleased and said, "These are good, we can use these." Her business sponsor also liked that she could read them and see what business aspects were being covered by the new system.

The next day, however, the developers said they wanted to write user stories. She went back in and watched them pepper the wall with a random collection of sentences, often saying what they were going to do to the database, or some other internal programming task.

That’s when she said, "You can write user stories, but the ultimate repository of the business needs are in the use cases."

The next week, the developers said they wanted to use story mapping. She went back in and watched them paper the walls with rows and columns of—again—programming tasks.

From that point on, she wrote her use cases to keep her thoughts straight and to show to the other businesspeople. She continued to use those use cases to straighten out the story map, keep the columns oriented to real user needs, and find holes in the story map.

Use Cases Meet Agile Development

Many people think that use cases are at odds with agile development, but they aren’t. The authors of this article, Ivar and Alistair, working separately in the early 2000s, found the same way to incorporate use cases into incremental and agile development. Ivar and his colleagues wrote up their results as "Use Cases 2.0";⁸ Alistair taught a similar technique in his lectures and courses.^4,5

Agile development relies on two things: (1) close collaboration between all specialties of a team; and (2) incremental development.

Keeping the use cases readable, even informal, helps the collaboration. All roles can read what is needed and stay in alignment. This is the easy part, or at least not a mysterious one.

The mysterious part (for many people) has always been how to write a use case in an evolutionary style, so that the first incremental delivery nicely shows the subset of functionality being delivered, while allowing the use case to grow with time and needs.

The answer is to separate the use case into a number of slices, where each slice can be implemented to form a work item that has clear value to the customer. A slice does not need to contain the entire flow and all of its test cases. The first slice might just be the "happy day" path through the main scenario and its test cases.

A practical starting point is to look at the first and possibly last sentence of the main scenario in our use case and implement that as our first slice and user story—a sort of envelope for all the rest to grow from. Later slices may implement alternative scenarios in the same incremental manner. Slices can be made as small or as large as the team prefers.

Here is another example, showing the growth of a use case for registering for college classes. It is from the book Patterns for Effective Use Cases, by Steve Adolph and Paul Bramble.²

First slice:

Register for courses

Primary actor: Student

Main scenario:

1. Student requests to construct a schedule.

2. The system prepares a blank schedule form.

3. The Student indicates the schedule is complete. The system saves it.

In good incremental style, the system does something useful but not yet with any detail. In the first slice, the first user story—which could be written as "Create and save a blank schedule"—will create a well-formed empty schedule in the database.

In the following expansion of the full use case, we label each additional slice with a number (in square brackets e.g. [1]). According to the team’s preferences, they might be done in a different order; this is just one possibility. Note how the first slice [1] captures the opening and closing steps. Note also how step 5 is split into two slices.

Register for courses

Primary actor: Student

Main scenario:

[1] 1. Student requests to construct a schedule.

[1] 2. The system prepares a blank schedule form.

[2] 3. The system gets available courses from the Course Catalog System.

[3] 4. Student selects up to 4 primary and 2 alternate course offerings.

[4,5] 5. For each course, the system verifies that the Student has the necessary prerequisites and adds the Student to the course, marking Student as "enrolled" for that course in the schedule.

[1] 6. The Student indicates the schedule is complete; the system saves it.

Alternatives:

[6] 1a. Student already has a schedule:

System brings up the current version of the Student’s schedule for editing, instead of creating a new one.

[7] 1b. Current semester is closed and next semester is not yet open:

System lets Student look at existing schedules but not create new ones.

[8] 3a. Course Catalog System does not respond:

The system notifies the Student, and the use case ends.

[9] 5a. Course full or Student has not fulfilled all prerequisites:

System disables selection of that course and notifies the Student.

By writing the use case in long form and then cutting it up into slices, the business analyst can keep track of the total context of what is being delivered and at the same time support the development team in working in an agile manner, possibly with user stories and story maps. This is exactly what the business analyst did in the earlier story.

The pictures in figure 3a show how the main scenario of the "Register for courses" use case might be implemented (for example) in five separate slices, with the developer team prioritizing delivery of the main scenario first. "Create and save a blank schedule" is delivered as the first user story. The alternative scenarios of this use case can also be delivered in several slices (four slices are shown in figure 3b).

Depending on the project context, fixed-price bid, or evolutionary system, the use cases might be sketched or drafted at various levels. In the case of a fixed-price bid, they would have to be at least drafted at a complete level to identify interfaces that have to be developed and tricky corner cases that have to be researched.

In the evolutionary context, there might initially be only a brainstorming of the use case names, and a selection of one or two slices to expand for development. Following that, they would be named and drafted as needed, to keep the business in view and development on track.

Recapitulating Key Points

Use cases solve a remarkable set of problems for many stakeholders in a simple way. Some benefits of use cases are:

Business sponsors appreciate the way use cases so clearly communicate how proposed solutions will fit into their businesses or their products.

Business analysts use them to align user and stakeholder needs.

Certain categories of developers enjoy seeing the usage context for each request.

Testers appreciate how they scaffold the functional tests and ensure that the pieces being put together fit together in a coherent way.

In addition, they can be written upfront for fixed-bid projects or written incrementally for evolutionary and agile projects.

The $100,000 value of use cases is showing what is going to be delivered in a way that everyone in the organization can read. Casual, readable use cases are still useful, whereas unreadable use cases won’t get read.

The $10,000 value of use cases is providing a scaffold for the business analysts to discover and investigate difficult corner cases before the developers and testers find them. It is the only technique we know of that provides this benefit.

The $1,000 value is providing a specification to the developers and the testers, giving context and naming each scenario and what should happen in each of those scenarios.

The key to getting those benefits is to keep the writing simple, avoid turning the use cases into encyclopedia entries, and in particular avoid putting UI details in them. Architects and UX (user experience) specialists can certainly take use cases as a key input to drive their own work, but their work outputs should not be added back into those use cases (except to correct the original use case).

Use cases provide a proven method to capture and explain the requirements of a system in a concise and easily understood format. They can be used at different levels: to capture the "big picture" view or describe more detailed requirements for developers or testers. Use cases are liked by businesspeople and provide a simple structure that helps business analysts probe into the corner cases of new requirements. Both Ivar’s use case 2.0 and Alistair’s agile use case method include the user stories and increments required by developers.

References

1. Accelerate State of DevOps 2021. Google Cloud; https://services.google.com/fh/files/misc/state-of-devops-2021.pdf.

2. Adolph, S., Bramble, P. 2003. Patterns for Effective Use Cases. Addison-Wesley.

3. Cockburn, A. 2001. Writing Effective Use Cases. Addison-Wesley.

4. Cockburn, A. 2003. Agile Use Cases; https://web.archive.org/web/20140330015706/ http://alistair.cockburn.us/get/2231.

5. Cockburn, A. 2005. Use Cases for Agile and Traditional Development; https://web.archive.org/web/20140329233851/ http://alistair.cockburn.us/get/2232.

6. Jacobson, I. 1987. Object-oriented software development in an industrial environment. In Conference Proceedings of Object-oriented Programming Systems, Languages, and Applications (OOPSLA 87); https://dl.acm.org/doi/10.1145/38765.38824.

7. Jacobson, I., Christerson, M., Johnsson, P., Overgaards, G. 1992. Object-Oriented Software Engineering—A Use-Case Driven Approach. Addison-Wesley Professional.

8. Jacobson, I., Spence, I., Kerr, B. 2016. Use-Case 2.0. acmqueue 14(1); https://queue.acm.org/detail.cfm?id=2912151.

9. OMG. 2017. OMG Unified Modeling Language (OMG UML), Version 2.5.1; https://www.omg.org/spec/UML/2.5.1/PDF.

A note about the authors

Ivar Jacobson invented use cases in the 1980s, first presenting them to the world in a 1987 paper at the OOPSLA conference.⁶

Alistair Cockburn, while creating a methodology for object-oriented programming projects for the IBM Consulting Group, found that paper in 1991 and flew to Stockholm to learn about use cases from Ivar and his colleagues. Since that time, both authors have written extensively about use cases in separate books and articles.

Alistair, one of the co-authors of the Agile Manifesto in 2001, started adapting them to evolutionary and agile projects.^4.5

Ivar, seeing a similar need, formalized the incremental approach as Use Cases 2.0.⁸ To find more details about "Use Case 2.0" please refer to https://www.ivarjacobson.com/use-case-resources. You can read Alistair’s most recent writings at https://alistaircockburn.com/Publications.

Originally published in Queue vol. 21, no. 5—
Comment on this article in the ACM Digital Library