In addition to the diagrams, it is customary to write each use case in text, sometimes called the Use Case Description. The descriptions are typically in tabular form, but there is no standard form for them.

It is not necessary or desirable to use all the kinds for every project; most projects will need few of them, and the simpler the project the fewer needed. They should be considered as tools in the toolbox, to be used when needed and left in the box otherwise.

Figure 1. Notes

All the diagrams may be annotated with notes. A note may be connected to a specific element of a diagram using a dashed line.

Use Case Diagram

Figure 2. Use Case Diagram nodes

A Use Case Diagram presents:

Actors (human and automated), represented by stick figures, and
Use cases, represented by ovals, and
Relations among them.

Figure 3. Use Case Diagram edges

An actor is labelled with its name under the stick figure, and a use case is labelled with its name in the oval. The relations include:

(Actor, use case) Involvement of an actor in a use case, represented by a solid line.
(Use case, use case) Inclusion of one use case as a step in another, represented by a dashed arrow pointing to the included use case, labelled with the stereotype include.
(Use case, use case) Specialization of one use case by another one that is a special case of the first, represented by a solid arrow with triangle head pointing to the more general use case.
(Use case, use case) Extension of one use case by adding or replacing steps in it to produce another, represented by a dashed arrow pointing to the original use case, labelled with the stereotype extend.

Figure 4. Use Case Diagram system boundary

The use cases may be enclosed within a rectangular system boundary if desired, labelled by the name of the system.

Use Case Description (textual)

The form for Use Case Descriptions is not defined by OMG.

A typical use case description includes:

The title of the use case
A summary of the use case
The actors involved in it (note that this is redundant with the text of the use case steps)
Other use cases related to it (note that this is redundant with a Use Case Diagram for the system)
Preconditions for the events described by the use case
The postconditions if the use case succeeds
The postconditions if the use case fails
The main flow of events for the use case
Other flows of events: typically alternatives, extensions, and exceptions

Steps in the use case are typically numbered. The numbering of alternative steps is usually intended to indicate where these steps fit in with the main flow, what steps if any are replaced, and where each flow terminates; these numbering schemes are often a source of misunderstanding.

Here is a use case from a project in industry:

UC-02: Add / Edit / Clone / Delete Channel
Summary		User creates, modifies, or deletes a channel.
Priority		Essential
User Frequency		Frequent
Direct Actors		Mirth user
Main Success Scenario
1)	User selects "Channels" page
2)	System fetches and displays channel list
3)	User selects between options (Add / Edit / Clone / Delete Channel)
4a)	If delete, skip to last step
4b)	System loads Channel Configuration page
5)	User chooses a channel name, and selects endpoints, filters, and transformations, with a specific order
6)	User submits selections
7)	System updates Configuration Manager
Alternate Scenario Extension
5)	User realizes he/she is missing a component and exits Channel Configuration page
6)	System saves the entered information
7)	User submits the components (other use cases) and returns to [sic]
8)	User returns to Channel Configuration page
9)	Sy[s]tem displays saved information
10)	Process is at step 5 of MSS
Exception Scenario Extension
7)	System updates Configuration Manager
8)	Configuration Manager refuses the channel
9)	System informs user of error