Use Cases Identification

Use cases can be identified in two methods: actor-based and event based. Functional requirements document is the main source of information needed. Interviews with potential users of the system can also be one source of getting use cases. In some cases Joint Requirement Planning Workshops (JRP) can be used where all people interested in a system being developed come together to give their view of what the system needs to do. Liu, state that identifying use cases involves reviewing existing documents of requirements specification:

i. Use case identification on actor-based: method 

(a) Find and specify all the actors by looking at which users will use the system and which other systems must interact with it. 

(b) For each actor, identify the processes they initiate or participate in by looking at how the actor communicates/interacts with (or uses) the system to do their work.

ii. Use case identification on event-based method 

(a) Identify the external events that a system must respond to. 

(b) Relate the events to actors and use cases.

For the POST application the following potential use actors and use cases as in Table 3.5 can be identified and the two can be presented in a use case diagram as shown in Figure 3.6:

Table 3.5: Actors and Use Cases of POST System

Actor Processes to Initiate
Cashier Log In, Log Out, Cash Out
Customer Buy Items, Refund Items
Manager Start Up, Shut Down
System Administrator Add New User




Figure 3.6: Partial Use Case Diagram for POST System Use Case descriptions


Each Use Case contains a full set of textual details about the interactions and scenarios contained within it. Use cases are described in order to understand more on its functionality. Table 3.6 shows the template for a Use Case description:

Table 3.6: A Template for a Use Case Description

Use Case: Use Case name
Actors: Role names of people or external entities initiating and participating in the use case
Short Description: A brief description of the Use Case
Pre-Conditions: A description of the conditions that must be satisfied before the use case is invoked, i.e. what must always be true before beginning a use case scenario.
Post-Conditions: A description of what has happened at the end of the use case, i.e. what must be true on successful completion of a use case.
Main Flow: A list of the system interactions that take place under the most common scenario. For example for "withdraw money", this would be "enter card, enter pin, etc"
Alternate Flow)s): A description of possible alternative interactions
Exception Flow(s): A description of possible scenarios where unexpected or unpredicted events have taken place

In some cases, a high-level use case can be needed to obtain some understanding of the overall process, and then expand it by adding to it with more details. A high-level use case describes a process very briefly, usually in two or three sentences.

Table 3.7: A Template for High-Level Use Case

Use case: Name of use case (use a phrase starting with a verb).
Actors: List of actors (external agents), indicating who initiates the use case
Purpose: Intention of the use case.
Overview: A brief description of the process.
Cross References: Related use cases and system functions.

With reference to a POST case study, the following as shown in Table 3.8 can be a description of a "Pay by Cash" use case

Table 3.8: A "Pay by Cash" Use Case Description

Use case: Pay by Cash
Actors: Customer, Cashier
Short Description: A Use Case allows a cashier to record the cash tendered by the customer
Pre-Conditions: Items to be purchased listed and the total amount already displayed
Main Flow: 1. The Customer presents cash payment to the cashier
2. The Cashier records the cash tendered to the POST system
3. The system shows the balance due back to the Customer if any
4. The Cashier deposits the cash received and extracts the balance due.
5. The Cashier gives the balance due and the printed receipt to the Customer
Alternate Flow)s):
 Item 4: Insufficient cash in drawer to pay balance. Ask for cash from supervisor
Exception Flow(s):
 Item 3. If cash amount tendered is not enough, exception handling

Having been identified and described use cases, a use case model can be created which describes how use cases relate to each other and to the actor. A use case diagram describes part of the use-case model and illustrates a set of use cases for a system, the actors, and the relation between the actors and use cases

Use cases relationships such as include, uses and extend can be used to reduce the complexity of the model. 

Use cases within a development process 

Activities in the use case analysis can be summarized as follows:

  1. After system functions have been listed, then identify actors and use cases. 
  2. Draw a use case diagram for the system. 
  3. Relate use cases and illustrate relationships in the use case diagram. 
  4. Write the most critical, influential and risky use cases in the use case high-level 
  5. Describe the uses cases using a use case description template