Roles and Activities > Analyst Role Set > System Analyst > Find Actors and Use Cases
Finding actors is one of the first steps in defining system use. Each type of external phenomenon with which the system must interact is represented by an actor. To find the actors, ask the following questions:
Any individual, group or phenomenon that fits one or more of these categories is a candidate for an actor.
To determine whether you have the right (human) actors, you can try to name two or three people who can perform as actors, and then see if your set of actors is sufficient for their needs. For more on what constitutes an actor, see Guidelines: Actor.
It may be difficult at first to find the most suitable actors, and you are not likely to find all of them immediately because you have not found all the use cases. Working with the use cases is the only thing that gives you a deeper understanding of the system's environment and how it interacts with the system. When you have progressed that far, you may want to revise your original model, because there is a tendency at first to model too many actors. Be careful when you change actors; changes that you introduce can affect the use cases as well. Remember that any modification to the actors constitutes a major alteration in the system's interfaces and behavior.
If you have developed a business use-case model and business object model, see also Guidelines: Going from Business Models to Systems for more guidance.
The actor's name must clearly denote the actor's role. Make sure there will be little risk at a future stage of confusing one actor's name with another.
Define each actor by writing a brief description that includes the actor's area of responsibility, and what the actor needs the system for. Because actors represent things outside the system, you need not describe them in detail. See also the section Brief Description in Guidelines: Actor.
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:
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 object model to use as input. For more information, see Guidelines: Going from Business Models to Systems.
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.
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 Guidelines: 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 Guidelines: 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:
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).
Because it is important to show how actors relate to the use case, you should, on finding a use case, establish which actors will interact with it. To do this, you must define a communicates-association that is navigable in the same direction as the signal transmission between the actor and the use case.
Signal transmissions usually go in both directions. When this is the case, you must let the communicates-associations be navigable in both directions. Define, at the most, one communicates-association for each actor-and-use-case pair.
You should also briefly describe each communicates-association you define.
For more information on communicates-associations, see Guidelines: Communicate-Association.
If the number of actors or use cases becomes too great, divide them into use-case packages to simplify the maintenance of the use-case model. This also makes the use-case model easier to grasp, and simplifies the assignment of responsibilities in the use-case model by letting developers be responsible for packages of use cases or actors.
Some alternative ways of packaging use cases together is if they:
There are also other ways; however, to keep the model intuitive, it is important that you use a clear strategy when you do the packaging.
For more information on use-case packages, see Guidelines: Use-Case Package.
You can illustrate relationships among use cases and actors, as well as among related use cases, in diagrams of the use-case model. These diagrams might contain any of the following:
Each diagram should be owned by an appropriate package in the use-case model.
For more information on use-case diagrams, see Guidelines: Use-Case Diagram.
In your description of the Survey Description of the use-case model, include the following:
See also the section on Survey Description in Guidelines: Use-Case Model.
You should check the use-case model at this stage to verify that your work is on track, but not review the model in detail. You should also consider the checkpoints for the use-case model while you are working on it. See especially checkpoints for Actor, Use Case and Use-Case Model in Activity: Review Requirements.
It is important that people outside the development team (for example, users and customers) approve the use-case model at this stage. Therefore, you must involve the users and the customer in reviewing the use-case model before you finish this activity. You can use the Use-Case-Model Survey report and its use-case diagrams as a guide in your discussions.
The interested parties will have to determine:
For more issues to review, see checkpoints for actor, use case and use-case
model in Activity: Review Requirements.
Rational Unified Process