Use cases can be documented graphically in a use case diagram. Use case diagrams are easy to use and are well-received by project stakeholders. This article is intended to help you model use case diagrams correctly and effectively. It will cover the most common components.
Why use use case diagrams?
Before you start modeling, you should already have basic knowledge of UML (Unified Modeling Language) or SysML (System Modeling Language). We have many exciting articles on this topic on our blog (read more).
At the beginning of every development process, it is necessary to determine which functions a future product must implement. Often, the stakeholder is not also the developer. In this case, the use case diagram can be used as a communication interface. The use case diagram is also a way of collecting functional requirements for a system. Every use case diagram contains actors, which are represented as stick figures. Actors can be people or external systems. The product to be developed offers services to the environment. A use case is such a service and is visualized using an ellipse. A use case can be connected to several actors. A distinction can be made between passive and active actors. Passive actors, for example, provide our system with data so that the service can be implemented.
Components
Images can be clicked to enlarge.
| symbol | name | Description |
|---|---|---|
 |
actor | Actors are the users of services provided by a system. Actors can be people or other systems. They are represented as stick figures. There are active and passive actors. The symbols do not distinguish between them. |
 |
Use case | A use case describes a function/service of a system. Each use case usually leads to a visible result. Actors use these services actively or passively. Passive means that an actor provides data to the use case so that it can function. |
 |
System boundary | System boundaries are represented as rectangles. Use cases of a system are located within these boundaries. They belong to the system. Actors, on the other hand, are located outside the system boundaries. They are not part of the system but interact with its services. |
 |
Use relationship | A line represents a connection between an actor or external system and a use case. It means that an actor uses a use case. |
 |
Generalization | Following the same principle as in object-oriented programming languages, use cases can be generalized. The use case is generalized in the direction of the arrow. It is specialized in the opposite direction. |
Example
Figure 1 shows an example of a use case diagram. The system represents a simplified defibrillator. Medical experts can configure it. Parameters that can be set include the shock energy and the patient type. The patient type refers to whether the patient is an adult or a child. The patient represents another actor. However, this is a passive actor. They are required to implement the "deliver shock" service. Medical experts trigger these shocks.
Tool for creating use case diagrams
MEDtech Ingenieur uses the Enterprise Architect tool. Enterprise Architect is a paid tool from Sparx Systems and can be used to create diagrams in SysML, UML, and other modeling languages. The tool is very well suited for systems development [1]. Documentation can be generated automatically. The tool is available here as a free trial version. downloaded and bought here You can find more exciting articles on the topic of Enterprise Architect and modeling here.
Model additional diagrams
[1] Creating system architecture correctly with UML and SysML: https://medtech-ingenieur.de/system-architektur/ and https://medtech-ingenieur.de/sprechen-sie-sysml/