BASIC AND ALTERNATE FLOWS IN USE CASE SPECIFICATION

A use case specification is a textual description of a use case that accompanies and compliments a use case diagram. It describes in detail the functionality, pre and post conditions, key scenarios, special requirements, actors, and the basic & alternate paths that an actor can take to complete any given use case.

The basic flow of a use case specification describes the most likely path that can occur for a use case to be successfully completed. Each step is an interaction between an actor and a system, described from the actor’s perspective. This does not include exceptions or failures. Failures are either captured in Exceptions or sometimes in Alternate paths if the Exceptions are not explicitly stated under an “Exceptions” section.

Below is an example of a Use case’s Basic flow.

Basic flow (USE CASE – FIND CUSTOMER)

1. The use case begins with the agent opening the Online shopping application
2. The agent selects the “Track customer” option
3. The system opens the track customer page
4. The agent enters the customer name and phone number and submits
5. The system communicates with the customer registry database to find the customer associated with the customer name and phone numbers entered
6. The system displays the customer data
7. The use case ends successfully

Alternate flows are similar to basic flows in structure, in that they also describe the interaction between the actor and the system, but they consider any and all possible alternate paths for the use case to be completed successfully, including edge cases. Below is an example of alternate paths for the same use case in the above example.

Alternative flow(USE CASE – FIND CUSTOMER)

1. Customer not found

If in step 5, the system does not find the customer in the database that is associated with the customer name and phone number, then it will display the message “Customer not found” and the use case will resume at step 4

2. Invalid name

If in step 4, the agent entered an invalid customer name data type, the system will display the message “Please enter valid name” next to the name field and de-activates the submit button. The use case resumes at step 4. See special requirements WC-1 for valid customer name data type

3. Invalid Phone number

If in step 4, the agent entered an invalid Phone number, the system will display the message “Please enter a valid Phone number” next to the Phone number and de-activates the submit button. The use case resumes at step 4. See special requirements WC-2 for valid phone number data type