Many teams today treat user stories as the only way to capture requirements. But there is an older, proven technique that scales better and provides something user stories lack: context. It is called Use-Case 2.0, and it deserves a second look, especially in the age of AI-assisted development.

What Is Use-Case 2.0?

Use-Case 2.0 is a practice created by Ivar Jacobson, Ian Spence, and Kurt Bittner. It builds on the original use-case technique that Jacobson introduced at OOPSLA in 1987. The “2.0” is not a UML version update. It is a modernized way of applying use cases that works with agile, Kanban, and even waterfall approaches.

At its core, a use case captures all the ways of using a system to achieve a particular goal for a particular user. That is different from a user story, which captures a single statement of value. A use case groups related stories together and gives them structure.

The Six Principles

Use-Case 2.0 is built on six principles:

  1. Keep it simple by telling stories. You explore use cases through storytelling. The stories become flows (basic and alternative), and each flow gets test cases. The test cases are more important than the narrative itself; they define what “done” means.
  2. Understand the big picture. A use-case diagram shows all the goals of the system at a glance. You can scope a release in minutes by deciding which use cases are in and which are out.
  3. Focus on value. The basic flow is the simplest way to achieve the goal. Alternative flows add options and error handling. You can ship the basic flow first and add alternatives later. This is additive by design.
  4. Build the system in slices. This is the key innovation. A use-case slice is a piece of a use case that is independently implementable and testable. Slices cut through requirements, design, implementation, and test, not just the requirements layer.
  5. Deliver the system in increments. Slices are assembled into increments, and increments into releases. Each increment builds on the previous one.
  6. Adapt to meet the team’s needs. Use-Case 2.0 scales from index cards for small teams to full documents for distributed teams. You start with the bare essentials and add detail only when needed.

Use Cases vs. User Stories

A user story is a standalone item. It has no built-in relationship to other stories. A product backlog of 200 user stories is hard to navigate without additional grouping mechanisms like epics or themes.

A use case is different. It groups all related stories under one goal. It has a basic flow, alternative flows, and test cases. When you look at a use case, you see the full picture of how a user achieves a specific goal, not just a single fragment.

Use-Case 2.0 also introduces use-case slices as a way to break use cases into smaller work items for manual development. A slice references specific flows and test cases, and it can be sized to fit a sprint or Kanban column. This was an important idea for teams that write code by hand and need small, estimable work items.

But as we will see, AI changes this equation. When AI generates the implementation, you no longer need to slice a use case into tiny pieces. You can work with the whole use case at once.

Why This Matters for Modern Development

In my experience with Spring Boot, Vaadin, and jOOQ projects, I see teams struggle with the same problems:

  • User stories lose context. When you read story #147, you do not know how it relates to stories #23, #89, and #201. With use cases, these stories all live under the same use case and reference the same narrative.
  • Test cases come too late. Many teams write acceptance tests after implementation. Use-Case 2.0 creates test cases as part of the use case before coding starts. This is test-first by design.
  • Big-picture thinking is missing. Teams jump into stories without understanding the system as a whole. A use-case model with 10-15 use cases gives you that overview in a single diagram.
  • Grouping is missing. User stories are flat. Use cases group related behavior under a single goal. You always know where a requirement belongs and how it relates to other requirements.

From Use-Case 2.0 to the AI Unified Process

Here is where it gets interesting. Use-Case 2.0 was written in 2011, long before AI coding assistants existed. But its principles are a perfect match for AI-assisted development. In fact, Use-Case 2.0 is one of the foundations of the AI Unified Process (AIUP) that I have been developing.

AIUP is a requirements- and spec-driven development methodology. It keeps requirements at the center while AI handles the implementation. The connection to Use-Case 2.0 is direct: AIUP uses use cases as the primary specification format that drives AI code generation.

Use Cases as AI Specifications

AI coding assistants like Claude Code work best with clear, structured specifications. A use-case narrative with flows and test cases is exactly that. It gives the AI:

  • A clear goal (the use case)
  • A step-by-step flow (the basic flow)
  • Defined variations (alternative flows)
  • Acceptance criteria (test cases)

This is much more actionable than a one-line user story. The narrative tells the AI what the system should do. The test cases tell it when it is done. In AIUP, this is the core loop: write a system use case specification, let AI generate the code, then verify with tests.

The Four Phases Meet the Six Principles

AIUP follows four agile phases: Inception, Elaboration, Construction, and Transition. Inspired by the Rational Unified Process. Use-Case 2.0’s six principles map naturally onto these phases:

  • Inception is where you “understand the big picture” (Principle 2). You create a business requirements catalog and initial use-case diagrams. In Use-Case 2.0 terms, this is the “Find Actors and Use Cases” activity.
  • Elaboration is where you “focus on value” (Principle 3). You write system use case specifications with basic and alternative flows, create entity models, and validate with stakeholders.
  • Construction is where you “build the system in slices” (Principle 4), but with a twist. In AIUP, the unit of work is the whole use case, not a slice. AI generates the complete implementation for a use case specification, including all its flows. Tests protect the behavior. Each iteration improves specifications, code, and tests together.
  • Transition is where you “deliver the system in increments” (Principle 5). User acceptance testing confirms that the use cases fulfill the stakeholders’ needs.

Why Slices Become Optional with AI

Use-Case 2.0 introduced slices because human developers need small, manageable work items. Writing the code for one complete use case with all its flows can take days or weeks. Slicing makes the work predictable.

With AI code generation, this constraint disappears. AI can generate the implementation for an entire use case specification in one go, basic flow, alternative flows, error handling, and all. The use case itself becomes the unit of work. You write the specification, AI generates the code, and tests verify that the behavior matches. No slicing needed.

This simplifies the process. Instead of managing a backlog of slices, you manage a list of use cases. Each use case goes through the AIUP cycle: specify, generate, test, improve.

Test-Protected AI Generation

Use-Case 2.0 says that test cases are more important than the narrative. AIUP takes this further. Tests are the safety net that makes AI code generation reliable. When you regenerate code from an improved specification, tests ensure that existing behavior does not break. This is what AIUP calls “test-protected development”.

The test cases from each use case become the regression suite that protects the system during AI regeneration. You can safely improve a specification, regenerate the code, and trust that the tests will catch any regressions.

Tooling: From Theory to Practice

Use-Case 2.0 is tool-agnostic. You can use post-it notes or spreadsheets. AIUP adds concrete tooling on top: Claude Code plugins that automate the workflow. The aiup-core plugin provides slash commands for creating requirements catalogs, entity models, use-case diagrams, and specifications. The aiup-vaadin-jooq plugin adds technology-specific skills for database migrations, UI implementation with Vaadin, and automated testing with Karibu and Playwright.

This means that the use-case specifications do not just document the system; they actively drive its generation. The specification is the source of truth, and the code is a derived artifact.

How to Get Started

You do not need to adopt the full Use-Case 2.0 practice or AIUP at once. Start with three things:

  1. Draw a use-case diagram. Identify the actors and use cases for your system. This takes 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 alternative flows as names only; do not detail them yet.
  3. Implement your first use case. If you want to try the AI-assisted path, use the AIUP tooling to generate the complete implementation from your specification. If you prefer manual development, you can still slice the use case into smaller work items as Use-Case 2.0 suggests.

You can track use cases on a simple spreadsheet or on post-it notes. No special tooling is needed to get started with Use-Case 2.0. When you are ready to add AI generation, AIUP provides the tools and the process.

The Bottom Line

Use-Case 2.0 is not a replacement for user stories. It is a complement. Use cases give you the big picture and the structure. Test cases give you a clear definition of done. For manual development, slices give you right-sized work items.

AIUP builds on this foundation and adds the AI dimension. It takes the use case, not the slice, as the unit of work. Specifications become the input for code generation. Tests become the safety net for regeneration. The cycle becomes: specify, generate, test, improve.

In a world where AI tools can generate code from specifications, having well-structured specifications matters more than ever. Use-Case 2.0 provides the proven structure. AIUP provides the modern tooling. Together, they show that the best ideas from software engineering’s past are more relevant than ever.

The Use-Case 2.0 e-book by Ivar Jacobson, Ian Spence, and Kurt Bittner is freely available from ivarjacobson.com. Learn more about the AI Unified Process at unifiedprocess.ai.