Use Case Description
A Use Case is a people model that describes the interactions between a user/group of users and a system. The Use Case helps us document each step of a task sequentially so that we can identify all of the features needed to support that task. Because the Use Case is typically structured “user does this, system does that,” we can identify the expected system behavior from the user’s point of view, which is incredibly helpful for both design and test planning.
The following template is the one we use when developing Use Cases. It contains all of the relevant information we need to capture in one handy table.
| Name | The use case name. Typically the name is of the format <action> + <object> |
| Id | An identifier that is unique to each Use Case. |
| Description | A brief description that states what the user wants to be able to do and what benefit he will derive. |
| Actors | The type of user who interacts with the system to accomplish a task. Actors are identified by role name. |
| Organizational Benefits | The value the organization expects to receive from having the functionality described. Ideally this is a link directly to a Business Objective. |
| Frequency of use | How often this Use Case is executed. |
| Triggers | Concrete actions made by the user within the system to start the Use Case. |
| Preconditions | Any states that the system must be in or conditions that must be met before the Use Case is started. |
| Postconditions | Any states that the system must be in or conditions that must be met after the Use Case is completed successfully. These will be met if the Main Course or Alternate Courses are followed. Some exceptions may result in failure to meet the Postconditions. |
| Main Course | The most common path of interactions between the user and the system. 1. Step 1 2. Step 2 |
| Alternate Courses | Alternate paths through the system. AC1:<condition for the alternate to be called> 1. Step 1 2. Step 2 AC2:<condition for the alternate to be called> 1. Step 1 |
| Exceptions | Exception handling by the system EX1: <condition for the exception to be called> 1. Step 1 2. Step 2 EX2:<condition for the exception to be called> 1. Step 1 |
Now let’s look at an example Use Case. The scenario below is a familiar one to most of us – saving a product on a wishlist so that we can return to it at a later date. Note that for the user to successfully add an item to a wishlist, they must be logged in (known to us) so that we can correctly process their request.
A common point of confusion in Use Cases is the difference between the main course, an alternate course, and an exception course. The main course is what we sometimes refer to as “happy path,” or the path of least resistance through the process. An alternate course is another viable path through the process, but one that may have more/different steps than the main course. An exception course describes an error condition. Error handling requirements may be derived from an exception course. The example below includes all of these. Note that some of the alternate courses refer to another use case, because login and account creation are complicated enough to be their own use cases, and they aren’t unique to the wishlist process.
| Name | Save item to wishlist |
| Id | UC_001 |
| Description | A user finds an item in the eStore that they want to add to a list so that they can return to the item at a later date. |
| Actor | eStore customer |
| Organization benefits | Increase sales by 30% by making it easier for customers to locate products they are interested in buying. |
| Frequency of use | 20% of site users save items to the wishlist. 50% of wishlist items are purchased within one year of the saved date. |
| Triggers | User selects to save an item to their wishlist |
| Preconditions | The selected item is saved in the user’s wishlist |
| Postconditions | 1. User selects to add an item they are viewing to the wishlist 2. System checks if user is logged on (AC1) 3. System stores the saved item to the user’s wishlist (EX1) 4. System displays “Item saved. View wishlist?” message to user 5. User selects to view wishlist (AC2) System displays the customer’s wishlist with the most recently added item at the top of the list. |
| Main Course | AC1 – System determines user is not logged on. 1. System displays log in or create account option 2. User selects to log in (AC3) 3. System performs UC_02 Log in 4. System returns to Main Course step 3. |
| Alternate Courses | AC2 – User does not select to view wishlist. 1. System continues to display the catalog/product page. AC3 – User selects to create an account. 1. System performs UC_03 Create Account System returns to Main Course step 3. |
| Exception Courses | EX1 – Wishlist app is unavailable or save action fails 1. System displays “item save failed” message. 2. System returns to Main Course step 1. |
For more information:
Learn more about requirements models in our book Visual Models for Requirements.(See Chapter 10 for Use Cases)
For more requirements templates see our BA resources.
