How to Create Use Case Description for Your Business Analysis Report

A use case model is a business analysis presentation of the steps defining the interactions between a user (called an actor) and a system (usually a computer system). It details the interactions and sets the expectations of how the user will work within the system.

The use case model consists of two artifacts: the use case diagram, which is a graphical representation showing which actors can operate which use cases, and the use case description (sometimes called the use case narrative), which is the text-based, detailed, step-by-step interactions and dialogue between the actor and the system.

The use case narrative is what people often mean when they say use case. Just remember there are multiple pieces that make up a use case model.

The use case description is a written account of the sequence of steps performed by an analyst to accomplish a complete business transaction. It’s initiated by an actor, provides value to that actor, and is a goal of the actor working in that system. Below, you see a use case description that clearly documents how a student manager approves a training request from a student worker.

Credit: Illustration by Wiley, Composition Services Graphics

Most use case descriptions include the following elements at a minimum:

• Title: The title communicates the goal of the use case. In the example, the Register Student (the title) use case’s goal is for the student to be able to register for a class.

• Actors: These folks are the people or systems who interact with the use case. Some people writing use cases also break down the actors by level within the use case: primary (the actor who starts the use case), secondary (the one who interacts with the use case), and even off-stage (those who don’t interact directly with the use case but are involved from a business rule perspective).

• Preconditions: Preconditions are those things that need to be in place before the use case can start. A precondition for the example is that the student has to have made the training request.

• Postconditions: Postconditions are in place when you finish the use case successfully or unsuccessfully. A postcondition on success indicates what happens when the process completes successfully. A postcondition on failure is the opposite; it specifies what happens when the process doesn’t complete successfully.

• Path: Also called flow or story, the path is the step-by-step action and interaction between the actor and the system. Paths come in three types:

  • Primary path (also known as happy path or main flow): This route is the most commonly taken path to a successful conclusion.

    You can see this path documented on the top of the example: The student manager clicks the link in the e-mail, navigates through the registration system to the training approvals page, sees the request, and approves it, triggering a confirmation e-mail to the student. It happens exactly as it should.

  • Alternate path: This path is an alternate, less-frequented way to get to a successful conclusion.

    In the example, the student manager is already logged in to the system and seeks out the pending training requests instead of accessing the system through an e-mail. After he’s in, he follows the same steps as the primary path. It’s a successful completion; he just didn’t use the most common path to get to it.

  • Exception path: This path is an alternate path that leads to an unsuccessful conclusion. An exception path related to the example can be that the student manager is unable to approve the request because she is no longer assigned as the student’s manager. An error or exception message will be displayed indicating the reason.

You can add additional artifacts to the use case description to fully flesh it out:

• Use case ID: A unique identifier used for tracing.

• Description: A brief textual description of what the use case does. A description for the example would be “This use case description outlines the steps for a student manager to review a student request and approve or deny the request.”

• Created by: The author of the use case.

• Date Created and Revision History: A chronology of the use case, which allows you to see how old the use case is (useful when doing document analysis),

• Priority: An indicator of this use case’s importance, which is helpful in solution planning.

• Frequency of Use: An indicator of how often this use case is executed (also helpful in solution planning).

To actually put a use case description together, follow these steps:

1. Figure out the starting point for the use case.

   This becomes your precondition.

2. Elicit from your stakeholders the steps you expect the user to take and what the system should do (the primary path).

   For each step, document who performs an action and who performs a reaction (or the response).

3. Go back and elicit the alternate ways of accomplishing the process.

   Indicate where each alternate path starts. For instance, in the example, you see that alternate path 3a is taken rather than the primary path 3. Therefore, you need make sure the solution you build provides a way to deny the training request.

   Because the use case is built around the primary path, indicate how you navigate to the alternate and exception paths from that primary path. If you’re using a tool to generate the use case description, it may prompt you for this information; otherwise, including a simple, “This alternate path starts after Step X of the primary path” will suffice.

4. Document the exception flows and error messages until the description is complete.

The finished product is a detailed list of steps the user performs and the expected system response.