Artifact: Actor |
Domains: Requirements
Purpose
This artifact captures details of the actors which are important to understanding the relationship and interaction between a use-case and the system boundary.
Relationships
Fulfilled Slots | [Technical Specification]
Container Artifact | Use-Case Model
Roles | Responsible: Analyst | Modified By: Analyst
Tasks | Input To: Design Performance Test Design the Solution Detail Component Model Develop Test Cases Envision the Architecture Establish Performance Test Goals Organize Requirements Outline Component Model Plan Project Analyze Target Define Test Strategy Detail the Design Develop Security Test Policy Document Architectural Decisions Identify and Outline Requirements Identify Test Ideas Plan Iteration | Output From: Identify and Outline Requirements
Description
Main Description | Actors represent different types of users. An actor is anyone or anything that exchanges data with the system. An actor can be a user, external hardware, or another system. The difference between an actor and an individual system user is that an actor represents a particular class of users, rather than an actual user. Several different individual users can play the same role, which means that they can be represented by the same, single actor. In that case, each individual user constitutes an instance of the actor. However, in some situations, only one person plays the role modeled by an actor. For example, there may be only one individual in the role of system administrator for a rather small system. The same user can also act as several actors (that is, the same person can take on different roles).
Brief Outline | For each actor identified, document the name and a brief description.
Notation | UML Representation: Actor The actor may have the following properties: Name: The name of the actor. Brief Description: A brief description of the actor's sphere of responsibility and what the actor needs the system for. 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. Relationships: The relationships, such as actor-generalizations, and communicates-associations in which the actor participates. Diagrams: Any diagrams local to the actor, such as use-case diagrams depicting the actor's communicates-associations with use cases. 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.
Illustrations
Templates | Actors (formal)
Key Considerations
This artifact concentrates on the classes of person and other systems that interact with the system under consideration. Not every role in an organization becomes an actor. However, work products that describe organizational roles may be useful sources for coming up with actors.
Tailoring
Impact of not having | If you do not use this artifact, you will not develop a comprehensive view of whom and what can interact with the system. Important stakeholder perspectives and interactions of the roles and systems may not be taken into account. This will result in a system where some classes of person who need to interact with it have not been identified or a solution that does not meet all users' interaction needs. It can be very difficult, if not impossible, to assess the completeness of the set of use cases without the context provided by the associated actors.
Reasons for not needing | If you have chosen a non-use case approach, or you have captured the information elsewhere, or there is no human interaction with the system, or it is possible to capture the interaction with other systems solely through architectural artifacts, then you may not need this artifact on your project.
More Information
Checklists | Actor
Concepts | Actor
© Copyright IBM Corp. 1987, 2009. All Rights Reserved. © Copyright ABC Corp. 2009. All Rights Reserved. Includes materials licensed from IBM and Eclipse. See IBM copyright and Eclipse copyright .