How to Identify Use Cases in UML Modeling
An actor specifies the role played by the user or any other system that interacts with the principal. It may represent the role played by human users, external hardware, or other principals. Actors are always outside the system, interacting directly with use cases by initiating them, providing inputs to them, and/or receiving outputs from them. While a single physical instance may play the role of multiple different actors, actors do not necessarily represent a specific physical entity, that is, the timer that triggers sending E-mail alerts.
Identifying Use Cases — Characteristics of Actor in Use Case Analysis
Simply enumerate the team members’ perceptions of the stakeholders or the targeted users, and it is easier to reach a consensus during the discussion.
- The actors are located outside the system, it does not belong to a certain part of the system, so we don’t need to “build” the “actors”;
- Only those who can use the system, interact with the system, and exchange information with the system are the actors of the system;
- Actors will start and participate in use cases, so finding Actors can guide us to find use cases;
- Although we don’t need to “develop actors”, we need to consider interfaces. The system needs to consider the interface for actors to use (user experience / GUI), or the system needs to obtain data through the interface provided by the actors.
Who are the actors? Ask the following questions:
- Who will use this system?
- Who will install this system?
- Who will start this system?
- Who will maintain this system?
- Who will shut down this system?
- Which other systems will use this system?
- Who will get information from this system?
- Who will provide information to this system?
- When the preset time arrives, will something happen automatically?
- Which systems will be networked with this system?
- Are there any hardware devices connected to this system?
- Which databases will be networked with this system?
- Who in the company will use this system?\
- Who will use this system outside the company?
- When a specific time or event occurs, does this system need to automatically notify who or other systems?
Types of Actor
Many analysts ignore key actors in the use case diagram drawing process because they only identify human actors. Classifying use case actors in this way helps analysts ensure that they do not ignore any key actors in the use case diagram.
There is another way to classify participants. They can be:
- human beings
- System / software
- Timer / clock
A List of Question for Identifying Use Cases
- What kind of functions do participants want from this system?
- Does this system store information? Which participants will create, read, update and delete this information?
- Does the system need to notify participants when the internal state of the system changes?
- Are there any external events that the system needs to know? When this external event occurs, which actor will notify the system?
- Does this system need to perform any operations on a regular basis?
- When some important external events occur, does the system need to automatically perform certain operations?
- Is the name of this use case clear enough? Can the result of this use case be judged directly from the name of this use case?
- Will this use case have multiple results? Or are these results produced at different points in time?