Artifact: Actor
| Defines a coherent set of roles that users of the system can play when interacting with it. An actor instance can be played by either an individual or an external system. | |
| Other Relationships: | Part Of Use-Case Model Extends: Software Requirement |
| Role: | Requirements Specifier |
| Optionality/Occurrence: | Found and related to use cases early in the Inception phase. |
| Templates and Reports: | - Report: Actor Report - |
| Examples: | |
| UML Representation: | Actor |
| More Information: | - Guideline: Actor - Checklist: Actor - Report: Actor Report - |
| Input to Activities: - Design the User Interface - Prototype the User-Interface | Output from Activities: - Find Actors and Use Cases |
Purpose
Different stakeholders use this artifact for different purposes:
- System analysts - to define the system boundaries.
- User-interface designers - to capture characteristics on human actors.
- Use-case authors - to describe use cases and their interaction with actors.
- Object analysts - to realize use cases and their interaction with actors.
Properties
| Property Name | Brief Description | UML Representation |
|---|---|---|
| Name | The name of the actor. | The attribute “Name” on model element. |
| Brief Description | A brief description of the actor’s sphere of responsibility and what the actor needs the system for. | Tagged value, of type “short text”. |
| Characteristics | For human actors: The physical environment of the actor, the number of users the actor represents, the actor’s level of domain knowledge, the actor’s level of computer experience, other applications the actor is using, and other general characteristics such as gender, age, cultural background, and so on. | Tagged value, of type “formatted text”. |
| Relationships | The relationships, such as actor-generalizations, and communicates-associations in which the actor participates. | Owned by an enclosing package, via the aggregation “owns”. |
| Diagrams | Any diagrams local to the actor, such as use-case diagrams depicting the actor’s communicates-associations with use cases. | Owned by an enclosing package, via the aggregation “owns”. |
Timing
Actor artifacts are found and related to use cases early in the Inception phase, when the system is scoped. It is a good practice to describe and baseline the characteristics of the Actor are before the user interface is prototyped and implemented.
Responsibility
The Requirements Specifier role is ultimately responsible for managing the artifact. Although both requirement specifier and user-interface designer roles will update the detailed information about each actor, the Requirements Specifier is responsible for ensuring that each Actor:
- defines a cohesive role and is truly an independent classification from the others.
- has the correct communicates-associations with the use cases with which it participates.
- is part of the correct generalization relationships.
- the artifact captures the necessary characteristics that will act as requirements on the user interface.
- the local use-case diagrams describing the artifact are readable and consistent with the other properties.
Tailoring
Decide which properties to use and how to use them. In particular, you need to decide at which level of detail the “Characteristics” property needs to be described.