Use cases have been around since 1987. In May 2024, Ivar Jacobson, Ian Spence, and Keith de Mendonca published a refreshed guide called Use-Case 3.0. If you read my earlier post on Use-Case 2.0, this is the natural next step. Use-Case 3.0 keeps the same core ideas and adds structure so that use cases fit any modern process.

This post explains what is in Use-Case 3.0 and how to use use cases in practice.

What Is Use-Case 3.0?

Use-Case 3.0 is a scalable, agile practice family. It uses use cases to capture requirements and to drive the incremental development of a system.

The name suggests a new version, but it is not a UML update. A use case is still a use case. What changed is the way we present, manage, and deliver them. The changes are based on more than 30 years of practice across many industries.

The guide describes Use-Case 3.0 as lightweight, scalable, versatile, and easy to use. It works for small co-located teams and for large distributed ones. It also works with your existing practices. It does not tell you how to plan, design, or test. It gives you a structure that your chosen practices plug into.

One important point: Use-Case 3.0 is fully compatible with user stories. It does not replace them. It gives them context and structure.

The Core Concepts

A use case is all the ways of using a system to achieve a goal of a particular user.

That single sentence carries a lot. It includes the happy path, the special cases, and the failures. It is independent of technology and platform. It can be written as text or drawn as a diagram.

Use-Case 3.0 is built on a small set of concepts:

  • System of interest. The system you want to build, analyze, or change.
  • Actor. A role that interacts with the system. An actor can be a person, an organization, or another system. The actor that starts the use case is the primary actor. The actors the system calls on are supporting actors.
  • Goal. The reason the user uses the system and the value they get from it.
  • Flow of events. A use case is a network of flows. Each flow is a path to value. Together they cover all the ways to reach the goal.
  • Use case. The container that collects the flows for one goal.
  • Use-case model. A model that shows all the useful ways to use the system. A use-case diagram is one view into this model.
  • Use-case slice. A part of a use case that gives clear value on its own. This is the key idea, and I cover it below.
  • Work item. A small, actionable piece of work. Common forms are user stories, features, and tasks.

The Ten Principles

Use-Case 2.0 was built on six principles. Use-Case 3.0 builds on the Use-Case Foundation by Ivar Jacobson and Alistair Cockburn and lists ten. The tenth one, “build the system in slices”, is the addition that makes the practice complete.

  1. Universally applicable. Use cases work for businesses, IT systems, physical systems, and any mix of these.
  2. Start with the big picture. Understand the purpose of the system and how it will be used before you dive into detail.
  3. Focus on value. Look at the users’ goals and the best way to reach them, not a long list of features.
  4. Involve your stakeholders. Bring everyone together to agree on the intent and scope of the system.
  5. Tell the whole story. Describe the use case as a story, from the first event to the value delivered or the failure handled.
  6. Trigger conversations. Writing the flows helps you find missing steps and missing cases that others would overlook.
  7. Prioritize readability. The goal is to communicate to everyone involved, so keep the model and the narrative easy to read.
  8. Just enough, just in time. Start with a sketch of the flow and add detail only when you need it.
  9. Implement in stages. Put the key flows in place early. Add the less critical flows later.
  10. Build the system in slices. Develop the system slice by slice. Each slice is one or more paths through a use case, plus the design, code, and tests to make it work.

How to Write a Use Case

The structure of a use case is what makes it useful. You describe two things.

The basic flow is the normal, happy path to value. Write it as a simple list of steps. Each step is the system or an actor doing something.

The alternate flows are the special cases, the optional steps, and the errors. Write them as a list of names first. You do not need the full detail up front.

Here is a short example for a cash machine, the Withdraw Cash use case:

Basic flow:

  1. Insert card
  2. Validate card
  3. Select withdraw cash
  4. Select account
  5. Confirm funds are available
  6. Return card
  7. Dispense cash

Alternate flows:

  • Invalid card
  • Non-standard amount
  • Receipt required
  • Not enough cash in the machine
  • Not enough funds in the account
  • Card stuck

You do not capture all the flows at once. Write the basic flow first. While you do that, you will naturally think of what can go wrong. Note those as alternate flows and come back to them later.

What matters is the accuracy of the flow, not how much you write. A bulleted outline is often enough. You can add detail when the team needs it.

Two more points about writing use cases.

First, the flows are additive. The basic flow must exist for the use case to succeed. The alternates are optional. You can add them one at a time. This is what lets you focus on value and ship small releases that still work.

Second, the test cases are the most important part. A use case is not really defined until you have the test cases. They make the story real. They tell the developer when the work is done.

Use-Case Slices: The Heart of 3.0

A use case is often too big to build in one go. A whole use case can take days or weeks. That is where slices come in.

A use-case slice is a part of a use case that provides clear value. It usually captures one way of reaching the goal.

Each slice has these traits:

  • It is end-to-end. It starts at the beginning of the use case and ends at its end.
  • It traverses one or more of the flows.
  • It is always testable. It comes with its own test cases.

Slices are the best unit for scope and priority. You can apply a scheme like MoSCoW (Must, Should, Could, Won’t) to them. You can order them so the most valuable work comes first.

You do not need to slice the whole use case at once. Pull out the slices you need now and leave the rest. You can even let developers ask for a new slice when they have capacity.

A slice can be as thin as you want. The smallest slice is a single test case through a single path. You might start with one end-to-end path, hard-coded values, and no error handling, just to prove the system works.

There is one idea that is easy to miss. A slice cuts through more than the requirements. It cuts through the design, the code, and the tests too. That gives you traceability from a requirement all the way to the code and the tests that prove it. It also forces you to think about the impact of a slice on the system before you build it.

From Slices to Work Items

Slices are still not the thing you hand to a developer. You turn a slice into work items that fit your team’s backlog.

The two common forms are user stories and tasks.

With user stories, the team gets together and brainstorms the stories needed for a slice. You may add a few technical stories, for example a spike to integrate a supporting system or a story for end-to-end testing of the whole slice.

With tasks, you create a series of tasks per slice, such as screen design, interface code, unit test, integration test, and system test.

Either way, the principle is the same. The slice acts as the team goal. The work items are the steps to reach it. Use-Case 3.0 supports whatever planning and work management style your team already uses.

The Lifecycle States

Use-Case 3.0 gives you simple states to track progress. You do not need a heavy tool. Sticky notes or a spreadsheet work fine.

A use case moves through these states:

  1. Goal established
  2. Flow structure understood
  3. Basic flow enabled
  4. Sufficient flows fulfilled
  5. All flows fulfilled

A use-case slice moves through these states:

  1. Identified
  2. Defined
  3. Analyzed
  4. Prepared
  5. Implemented
  6. Verified

This can look like waterfall, but it is not. You track each slice on its own. Across the set of slices, all the work can run in parallel. One slice is being verified while another is being implemented and a third is being prepared.

The Activities: How the Work Flows

Use-Case 3.0 breaks the work into a set of activities. Some discover and order the requirements. Others shape, build, and test the system. You repeat them as needed, not once in a fixed order.

  • Find actors and use cases. Run a workshop with your stakeholders. Do not try to find every use case. Focus on the ones that deliver the value you need. Order them to support your release plan.
  • Discuss and slice a use case. Build a shared understanding of the use case and pull out the first slices. Do this with your stakeholders so every slice is worth building. Do not slice everything at once.
  • Analyze a use-case slice. Before you code, work out how the slice affects the system. What must change, and what is new? The result is called a use-case realization.
  • Prepare a use-case slice. Get it ready to build. Clarify the narrative, define the test cases, and split it into work items. If a slice has no test cases, it is not prepared.
  • Implement software for a slice. Design, code, unit test, and integrate the pieces that make the slice work.
  • Test the system for a slice. Run the slice’s test cases to confirm it works. Because slices are independent, you get fast feedback.
  • Test the system as a whole. Check that the new slices work together and did not break anything that already worked.
  • Inspect and adapt the use cases. Keep the model up to date. Handle changes, track progress, and tune the size of your slices.

The Practice Family

The biggest change in Use-Case 3.0 is how it is packaged. It is no longer one big method. It is a family of practices that you mix and match.

You start from one or both of the two essential practices:

  • Use-Case Storytelling. Use simple narratives to focus the team on delivering a usable system of clear value.
  • Light Use-Case Modeling. Create a simple visual model that shows the value of the system and how users reach their goals.

Combine these two and you get Use-Case Essentials. This is the common starting point for people new to use cases.

When you need more, you add practices:

  • Use-Case Authoring for detailed, formal narratives. Use it for complex or safety-critical systems, or when a contract needs a full specification.
  • Structured Use-Case Modeling to capture the full system boundary and model releases and options.
  • Use-Case Realization to analyze the impact of a use case on your design with UML.

You can also use Use-Case 3.0 in full, but that is a lot to take on at once. The point of the family is that you take only what you need and add structure later.

What Changed from 2.0 to 3.0

If you know Use-Case 2.0, here is what is new.

  • Use-Case 3.0 is built on the Use-Case Foundation by Jacobson and Cockburn, published in 2024.
  • It adds the tenth principle, “build the system in slices”.
  • It is packaged as a modular practice family, so you can adopt it in small steps.
  • It adds the Work Item concept. This lets you compose use cases with Scrum, Kanban, and larger frameworks such as SAFe and Nexus, or with plain task-based planning.
  • It states clearly that use cases and user stories work together.

The structure you know from 2.0 is still there. The refresh makes it easier to adopt and easier to combine with modern ways of working.

How to Get Started

You do not need to adopt the whole practice on day one. Start small.

  1. Draw a use-case diagram. Find the actors and the use cases for your system. This takes about 30 minutes and gives you the big picture.
  2. Write one use-case narrative. Pick the most important use case. Write the basic flow as a bulleted outline. List the alternate flows by name only.
  3. Slice it and build the first slice. Pull out the most central slice, the one that goes end-to-end. Define its test cases. Turn it into work items and build it.

Track your use cases and slices on a spreadsheet or on sticky notes. No special tooling is needed to begin.

The Bottom Line

Use cases give you the big picture and the structure. Slices give you right-sized, testable units of value. Test cases give you a clear definition of done. Work items fit the whole thing into the way your team already works.

Use-Case 3.0 does not replace user stories or your process. It gives them a home. In a time when clear specifications matter more than ever, that structure is worth a second look.

References