Identifying Use Cases

A use case represents a function that the system performs. Alternatively, a use case can be thought of as a goal that some actor can achieve with the system.

An actor association is an arrow connecting an actor to a use case. This arrow represents a conversation between the actor and the system component responsible for executing the use case.

 

A conversation can be viewed as an exchange of messages. For example, the system might send a message to the user by displaying a dialog box. The user might reply to this message by clicking a button on the dialog box. Conversations can be long or short. The initiator of the conversation is indicated by the direction of the arrow, which points from the initiator to the responder.

Primary actors, such as users, always initiate conversations. Secondary actors, such as servers, always respond to an initiating use case.

The optional system boundary helps to remind us that use cases are internal to the system and actors are external.

Examples

A Database Browser

 

An E-Store

Notice that we do not attempt to show structures (like items or the cart) nor the flow of control (e.g., search items, add items, checkout, then check status) in a use case diagram.

An ATM Machine

Notice that we do not include a use case for validating the account holder's identity (read card, read PIN, validate PIN, etc.) While these are functions that an ATM performs, they are not actor goals. In other words, no one uses an ATM machine simply to see if their PIN is valid.

Notice that the system boundary is optional. Just remember: use cases are inside the system. We are responsible for implementing them. Actors are outside the system. We are only responsible for talking to them.

A Word Processor

Notice that related use cases, like related classes, can be grouped into packages. These packages might correspond to the menus on a menu bar while the use cases correspond to the menu items.

Notice that we try to use domain-specific names for actors. In the above example "Author" is domain-specific name for the user of a word processor.

Notice that the names of use cases and use case packages tend to be verbs rather than nouns.

We can describe each package using a separate use case diagram. For example, here are the persistence use cases:

Elaborating a Use Case

A use case diagram by itself is useless. Each use case should be associated with a use case elaboration. A use case elaboration consists of the following information:

ID: Should be a descriptive unique name
Actors: The associated primary and secondary actors
Description: One or two sentences describing the function or goal
Priority: high, medium, or low
Risk: high, medium, or low
Scenarios:
   Main: this is usually the main scenario
   Alternate 1: an alternate scenario
   Alternate 2: another alternate scenario
   ...

ID

Every use case should have a unique identifier. For example:

UC.1
UC.2
UC.3.1

Priority

Priority measures the importance of a function: high, medium, and low. High priority indicates that the function must be present in the next release or the system will be useless. Medium priority means the function should be available as soon as possible. Low priority means that at some point in the future it would be nice to have.

Risk

Risk combines two measurements into a single factor called the risk magnitude indicator:

the probability that some problem will occur

the severity of the problem

Examples of problems include:

loss of resources: personnel, money, equipment

unanticipated complexity

In these lectures only three risk levels are identified:

High, Medium, or low

Some texts list five risk levels:

high, significant, moderate, minor, and low

Balancing priority and risk can be tricky. As a general rule of thumb, all of the risk should come at the beginning of a project. If the project fails, let it fail before large commitments of time and money have been made.

Scenarios

Scenarios describe possible interactions between actors and the use case. These will be described in the next section.

Example:

UC.1: Transfer Funds
Actors: Account Holder, Bank Server
Description: The account holder transfers a specified amount of money from a specified source account to a specified destination account.
Priority: high
Risk: medium
Scenarios:
   Main: Funds are transferred successfully
      ...
   Alternate 1: Insufficient funds in source account
      ...
   Alternate 2: Source or destination accounts are in use
      ...
   Alternate 3: Invalid PIN
      ...