First and most importantly, I will define what a use case is. A use case is a tactic used in system analysis to identify, clarify, and categorize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users within an environment and related to a particular goal. The use case should contain all system activities that have significance to the users within a given system.

What Use Cases Do

1.    They hold Functional Requirements in an easy to read and tracking format.

2.    They represent the goal of an interaction between an actor and the system.

3.    They are multi-level, one use case can use/extent the functionality of another.

What Use Cases Do Not Do

1.    They don't specify user interface design. They specify the intent, not the action Detail.

2.    They don't specify implementation detail.

Definitions

1.    Actor: An actor is something with behavior, such as a person, computer system, or organization.

2.    Scenario: A scenario is a specific sequence of actions and interactions between actors and the system under discussion; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully using an ATM machine to withdraw cash.

Now that I have introduced what a use case is, what they do, what they do not do, and provided the definition of an actor and scenario, let us look at a complete UML diagram of the ATM cash withdrawal transaction. While this diagram is not all inclusive to actions involved with using an ATM, it should provide the foundation as to how to create a use case diagram and how to interpret its meaning. 

Figure 1: Example UML ATM System Usage Use Case

 

Now that I have covered the definition of a use case, what they do, what they do not do, and provided a sample diagram, we will move into the various sections contained within a use case.

A use case is made up of a variety of sections; not all use cases will have requirements to fulfill each section. These sections are:

1.    Use Case Name

2.    Actors

3.    Summary

4.    Pre-Conditions

5.    Flow Of Events

6.    Error Conditions

7.    Post-Conditions

As an example, I will take the example ATM System Usage Use Case in Figure 1 and break it down into the above sections.

Use Case Name

ATM System Usage

Actors

Custom, Bank ATM

Summary

A customer withdraws cash from the ATM by inserting his bank card into the ATM, entering a correct PIN number to access the system, and selecting and entering the amount to be withdrawn. The ATM then validates the card and PIN, and the funds are available for withdrawal. If the information provided by the customer is valid, then the ATM dispenses the money and returns the customer's card.

Pre-Conditions

1.    The ATM is in working order.

2.    The ATM has cash.

Flow of Events

1.    The customer inserts the ATM card.

2.    The ATM reads and validates the card.

3.    The customer enters the PIN number.

4.    The ATM validates the PIN number.

5.    The user selects and enters the amount to withdraw.

6.    The ATM validates that the funds are available.

7.    The ATM dispenses the cash.

8.    The ATM returns the card to the customer.

9.    The customer removes the card and the cash.

Error Conditions

1.    An incorrect card is entered.

2.    The PIN is incorrect.

3.    The account has insufficient funds.

Post Conditions

1.    The customer's account balance is adjusted

2.    The ATM's cash supply is adjusted

As you can see, there are quite a few actions that happen when a customer wishes to make a cash withdrawal. Keep in mind that there are even more steps you could add, but for the purpose of this article, this should provide the basic idea as to what makes up a use case.

Why is all of this important, you may ask? The answer is quite simple.

Advantages

·         They prevent early design and focus on conditions.

·         They provide tractability.

·         They allow estimating and scheduling work.

·         They are easy to understand by the client, and provide a simple means of communication between the client and the developers.

Disadvantages

·         They do not easily capture non-functional requirements.

·         There may be a learning curve for the developer and/or the client.

In summary, a well-prepared use case is worth its weight in gold. Once the client has agreed with the use case, project managers can plan the schedule, and developers then have a clear insight into what they must develop. From personal experience, while a use case is most beneficial, they are rarely perfect, but they almost always serve a purpose.