Describing the System's Use Cases

Use the use case diagram to describe a system's external behavior from the view of the system user. The use case diagram is suited for displaying the behaviors available for all classifiers (e.g. classes, interfaces, components); this is why it belongs to the behavior diagrams since UML 2.

Displaying User Requirements for the System

A use case diagram shows the relationships between actors and a set of use cases enclosed by a system limit. The individual use cases are described in text form with specifications (implementation of functional and non-functional requirements).

Use cases can be specified in greater detail with activity diagrams.

Elements in use case diagrams can be linked by means of relationships (interaction, generalizations, include or extend dependencies).

Examining a system's use cases is one of the first things to be done in a project. Use cases answer the question of what a system should achieve for the user. A use case diagram describes the system context and refines the functional requirements on the system.

The use case diagram shows the users as actors and the individual parts of the system output as use cases and characterizes their relationships to each other.

There is no order when creating model elements.

Tips for Text Descriptions about Use Cases

You have created a graphic depiction for requirements with the 's elements; these should conform to the system. When naming use cases, it is a good idea to use a construction made up of a noun and a verb (e.g. Log-in Student).

A text description of the model element is indispensable when creating a meaningful document which forms the basis when creating other systems. Innovator provides its own text editor for descriptions(see "Editor for Specification Texts").

Note:

Description of use cases often forms the basis of a discussion and decision points during talks with customers and operating departments. Ensure that you use the language used by the customer here. This avoids misunderstandings or enables you to see them earlier on and smooth out any issues.

UML does not make any specifications for which aspects should be taken into consideration during the description of use cases. However, it is a good idea to take one of the following points into consideration in the description.

Brief description: lists the targets in the current use case in a few words.
Brief glossary: special terms from the use case's field of application help with communication.
Precondition: requirements should be listed here so that the current use case's tasks can be carried out (e.g. successful log-in to the system).
Normal flow: describes the standard case for the current use case. It's a good idea to have a numbered enumeration of the individual activities here.
Alternative sequences: if other tasks also lead to the desired target, these can be listed here.
Error cases: all events recognized by the system that should lead to a certain system reaction are listed here.
Open questions, decisions etc.: there's space for notes about the current status of the course of the project.

This chapter contains the following topics:

Creating a Use Case System

Creating a Use Case

Assigning a Use Case to a Use Case System

Creating an Actor

Creating an Association Between Actor and Use Case

Creating a Dependency Relationship

Creating a Generalization Relationship