Wikipedia (with help from Ivar Jacobson) defines actors as:
[S]omething or someone which exists outside the system under study, and that take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor.
Ivar Jacobson (1992). Object-Oriented Software Engineering. Addison Wesley Professional. ISBN 0-201-54435.
To further clarify, the OMG in their UML spec describes an actor in the following terms:
Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances.
UML Superstructure Specification, ptc/04-10-02, October 8, 2004, p. 661 – emphasis mine.
I’ve found that it’s easy to identify the actors that are users of the system, but sometimes less evident to identify other systems or non-human participants in the use case dialogue. This can be especially true for those that are new to writing use cases.
I’ve always liked quick, little job-aids that help break down and simplify things. To that point, Miles and Hamilton provide a simple diagram for identifying actors in the book Learning UML 2.0 (Learning). I’ve made some minor tweaks to the diagram and included it below in case it might be of use to some of you:
Interesting look at identifying actors. I’ve not given it any thought in application though to see if it works.
There are some other ideas on identifying these here: http://requirements.seilevel.com/blog/2006/03/people-systems-and-data-analysis.html
For example, people actors definitely fall out of things like org charts (http://requirements.seilevel.com/blog/2007/03/requirements-model-org-chart.html). System actors are certainly identifiable by looking at interfaces. But another way to identify these is to look at data flowing in and out of the system, and the systems those pieces of data come from are probably non-user actors.
Thanks for the post!