Skip to content

Use case template

Thomas Gohard edited this page Jun 14, 2013 · 3 revisions

français

Return to component reviews index

Table of Contents

Name

The name of the use case. The name should be based on the interaction described by the use case.

Example: Signing in to an application.

Description

A brief, high-level description of the use case from beginning to end.

Example: A user inputs their credentials and signs in to an application.

Actor(s)

A list of the roles or user classes that will participate in the use case.

Example:

  • A user who has previously obtained credentials for signing in to the application.

Preconditions

A list of conditions that must be true before the use case is started. When a condition is linked to a use case, specify the use case.

Example:

  • The user has credentials for signing in to the application.
  • The user is at the sign-in page.
  • The focus is on the page; none of the sign-in form fields are highlighted.

Postconditions (Success criteria)

A list of conditions that will be true after the use case has concluded.

Example:

  • The user is signed-in to the application.
  • A session is active on the application server.
  • The user is at the application home screen.

Ideal scenario

A list of the steps to complete the use case, under ideal circumstances. Each step should describe the user actions and system responses. When a step is described by another use case, reference that use case.

Example:

  1. User puts focus on the username field by tabbing into it; system highlights the username field to show it is in focus.
  2. User types their username using the keyboard; system displays the user’s input in the username field as the user is typing.
  3. User puts focus on the password field by tabbing into it; system removes highlighting on the username field and highlights the password field to show the change of focus.
  4. User types their password using the keyboard; system displays an asterisk character in the password field for each character the user types as the user types.
  5. User puts focus on sign-in button by tabbing to it; system removes highlighting on the password field and highlights the sign-in button to show the change of focus.
  6. User presses the Enter key to activate the sign-in button; system send the form data to the server, verifies the username and password are valid, opens a session on the server and displays the application home screen to the user’s screen.

Alternative scenarios

A list of alternatives to the expected scenario.

Example:

  • User uses a mouse to change the focus between the form elements.
  • User uses touch to change the focus between the form elements and a touch keyboard to input the username and password.

Exceptions

A list of exceptions or errors that can occur during the use case. Each exception should describe the user actions that lead to the exception and the system responses.

Example:

  • User inputs an incorrect username; system does not open a session and returns the user to the sign-in page. The sign-in page displays the error message "The username you entered does not exist" above the sign-in form and highlights the username field in red. The focus is in the username field.

Issues

Issues that need to be resolved with the use case or be the subject of another use case.

Example:

  • The use case does not consider the use of assistive technologies to navigate the sign-in process and input the application credentials.
  • The use case does not consider the use of credentials other than a username and password. For example, an email address and a cryptographic token, or a fingerprint.
  • What if the user has forgotten their username and/or password?
Return to component reviews index
Clone this wiki locally