Use Case Concepts in Object-Oriented Analysis
Use cases are a powerful way of modeling what the system needs to do. Read this section to learn about use case diagrams and how they capture functional requirements.
3. 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 system being developed come together to give their view of what the system needs to do. Liu,
(2001 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, identifying the processes they initiate or participate in by looking at how the actor communicate/interact with (or use) the system to do his 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