Use Cases

A use case describes how an actor interacts with the system to achieve a goal. An actor is any role, human or system, that takes part in that interaction: a user such as an author is an actor, and so is an outside system such as the identity provider.

A use case records the actor’s actions, the system’s responses, and the alternative paths that may occur. A scenario is one path through that interaction. The main success scenario records the expected path to the goal. Alternative scenarios record other valid paths and situations that prevent success. Together, these scenarios form the use case.

Example: Submit a post for editorial review

  • Goal: Put an author’s draft into the editorial review process.
  • Primary actor: Author.
  • Preconditions: The author is signed in, and the post already exists as an editable draft owned by that author.
  • Trigger: The author asks HopPress to submit the post for review.

Main success scenario:

  1. The author requests submission of the post.
  2. HopPress confirms that the author owns the post and that the post is an editable draft.
  3. HopPress changes the post from draft to submitted.
  4. HopPress makes the submitted post available to editors.
  5. HopPress confirms the submission and shows the new state to the author.

Success postcondition: After the interaction, the post is in the submitted state, waiting for editorial review. Readers cannot see it, and the author cannot publish it directly. An editor can publish it or return it for revision.

Relevant alternatives:

  • The author does not own the post. HopPress refuses the request and leaves the post unchanged.
  • The post has already been submitted or published. HopPress reports its current state and does not submit it again.

Use cases vs. functional requirements

A use case is a helpful way to describe a functional requirement in greater detail.

The preconditions and trigger are the same “under what conditions” and “who or what initiates the action” questions from the earlier section From Needs to Functional Requirements. A use case gives them names and expands them into a full interaction, with a main path and its alternatives.

A use case should include detail when that detail settles a real question about the required interaction. It should not include design decisions, such as how the system stores information or what the user interface looks like, as part of those details. A use case is a way to describe the required behavior, not how to implement it.

Use cases vs. user stories

A user story and a use case serve different purposes. A story such as “As an author, I want to submit a draft so that an editor can review it” helps the team plan a small unit of useful work. Its acceptance criteria clarify when that work is complete. A use case follows the interaction through its main and alternative paths. The two can describe the same area of behavior, but they do not have to match one to one.