Category Archives: Use Cases

Use cases are the most common requirements model. They are used to define what users do with the product, in order to achieve their goals. There are multiple formats for use cases – we discuss them here.

Prioritization and Value Maximization

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

Read the rest of the article …

Elastic Users, Actors, and Roles

In About Face 2.0, Alan Cooper describes the elastic user as an ill-defined user who’s characteristics change to suit the needs of the developer – sometimes an expert and sometimes a novice. However, some of the otherwise good techniques for managing actors and use cases exacerbate this problem instead of alleviating it. How should we manage use cases while still getting the benefits of Cooper’s insight?

Read the rest of the article …

Use Case Example With Business Rules

In our ongoing exploration of how to meld the worlds of business rules and requirements, we look at an example use case and see how to extract the business rules.

Read the rest of the article …

Benefits of Agile Story Decomposition

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning – from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure – communicating the release schedule internally with your development team.

Read the rest of the article …

Nexus – Use Case Definition for Bundles

Yesterday, we identified the high priority goal for the third release of nexus to be supporting creation of bundles of articles. In this article, we will define the use cases we need to support.

Read the rest of the article …

APR: Mixing It Up With Design And Requirements


With a definition of the important use cases for our agile project, we can move to the logical next step – which is what exactly?

Prototyping.

Read the rest of the article …

APR: Prioritizing Use Cases – Vote Three Times

In our agile project case study we defined corporate goals and user personas, and from our understanding created a list of use case names. We refined those use cases into use case briefs, filtering out some of the use cases (for the first revision) narrowing the list to six use cases. In this article, we propose a prioritization of those use cases and ask you to vote to share your thoughts.

Read the rest of the article …

APR: Use Case Briefs

Each of the use cases defined as part of our use case names post is described at a high level of detail here. The goal is to get a broad view of the domain for our project so that we can focus on the most important elements. This is a key step in using use cases in an agile project. We need to understand enough of the big picture in order to determine what is actually the most important. Then we will work on the more important use cases.

Read the rest of the article …

APR: Use Case Names

In our agile programming case study, we have two corporate goals, but one of them (learn Ruby on Rails) only drives constraints, not requirements. The other goal is to make it easier for people to find and read great content in our niche. This makes the documentation of goal-driven use cases pretty straightforward. All of the use cases support this single goal.

With an understanding of the goals, the next step is to define the use case names.

Read the rest of the article …

The Difference Between Use Cases and Test Cases

People who are new to software, requirements, or testing often ask “What’s the difference between a use case and a test case?” This article answers that question, by building on earlier articles about use cases and use case scenarios. At the soundbite level, each use case has one or more scenarios, and each use case scenario would lead to the creation of one or more test cases.

Read the rest of the article …