When your first outline of the actors is complete, the next step is to look for the system's use cases. The first use
cases are very preliminary, and you will doubtless have to change them a few times until they are stable. If the
system's vision or requirements are deficient, or if the system analysis is vague, the system's functionality will be
unclear. Therefore, you must constantly ask yourself if you have found the right use cases. Furthermore, you should be
prepared to add, remove, combine, and divide the use cases before you arrive at a final version. You will get a better
understanding of the use cases once you have described them in detail.
The best way to find use cases is to consider what each actor requires of the system. Remember the system exists only
for its users, and should therefore be based on the users' needs. You will recognize many of the actors' needs through
the functional requirements made on the system. For each actor, human or not, ask yourself the following questions:
What are the primary tasks the actor wants the system to perform?
Will the actor create, store, change, remove, or read data in the system?
Will the actor need to inform the system about sudden, external changes?
Does the actor need to be informed about certain occurrences in the system?
Will the actor perform a system start-up or shutdown?
The answers to these questions represent the flows of events that identify candidate use cases. Not all constitute
separate use cases; some may be modeled as variants of the same use case. It is not always easy to tell what is a
variant and what is a separate and distinct use case. However, it will become clearer when you describe the flows of
events in detail.
Other than requirements, an enterprise model of your organization (also called a business model) is a valuable source
of input for determining use cases. The enterprise model describes how the information system might be incorporated
into existing operations and so gives you a good idea of the system's surroundings. You will also find concepts that
need to be defined in the enterprise model because it contains the "business objects" of the enterprise. If you have
followed the Business Modeling workflow, you will have a business use-case model and
a business analysis model to use as input.
A system can have several possible use-case models. The best way to find the "optimal" model is to develop two or three
models, choose the one you prefer, and then develop it further. Developing several alternative models also helps you to
understand the system better.
When you have outlined your first use-case model, you should verify that the use-case model addresses all functional
requirements. Scrutinize the requirements carefully to ensure that all the use cases meet all the requirements.
For more information on what a use case is and how to find them, see Guideline: Use-Case Model and Guideline: Use Case.
Name and Briefly Describe the Use Cases You Have Found
Each use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may
have to be several words to be understood. No two use cases can have the same name. See also the section Name in Guideline: Use Case.
Define each use case by writing a brief description of it. As you write the description, refer to the glossary and, if
you need to, define new concepts. See also the section Brief Description in Guideline: Use Case.
Outline the Flow of Events
At this point, you should also write a first draft of the flow of events of the use case. Describe each use case's flow
of events as brief instants of performance, but do not go into detail. The person who will later specify the use
case-even if it is you-will need this step-by-step description. Start by outlining the basic flow of events, and once
you have agreed on that add alternative flows.
The initial step-by-step description of the flow of events of the use case Recycle Items in the Recycling-Machine
System might look like this:
The customer presses the "Start" button.
The customer inserts deposit items.
The system checks the type of the inserted deposit items.
The system increments the day's total of the types of items received.
The customer presses the "Receipt" button.
The system prints out the receipt.
Collect Additional Requirements
Some of the system's requirements cannot be allocated to specific use cases; collect these in the Supplementary
Specifications (see Artifact: Supplementary Specifications).