Defines a role with its responsibilities, tasks and requirements. Roles are incorporated by stakeholders who take interest in the project. The are also used to define the audience for documents.
A role document instance defines the role of a person, system, or organisation that an actor in a use case may hold.
Our use of the term role is based on the following definition:
role, n. any part played by something (e.g. a person, piece of equipment, or organization)Donald G. Firesmith, Sally Shlaer and Stephen Mellor
A role captures the purpose of something, the position it holds, or its capacity, job, or viewpoint.Donald G. Firesmith
An actor in the Unified Modeling Language (UML) "specifies a role played by a user or any other system that interacts with the subject." Anonymous. Wikipedia
Information provided by Roles
Use this document type to describe the role's
- tools it works with
- requirements it imposes on the product
- consequences for the project
For more information on this, please refer to Uwe Friedrichsen Wer hat Angst vor dem Betrieb?.
The document will automatically
- list all uses cases the role plays a part in.
- list all quality scenarios the role is mentioned as a stimulus.
- list all user characters that hold this role.
- list all stakeholders that hold this role for this project.
Thishelps to find relevant information for a given role in your wiki easily.
The document type role provides the following properties:
Please note that only information about specific properties is provided here. Common document property used by all document types are documented by Document Properties.
Besides the standard document properties, this doctype provides no specifics properties.
The document type provides the following sections.
A general description of the role.
The responsibilities of the role describe what stakeholders, holding this role, have to do or care for. This allows to identify which tasks a role has to perform.
Describe the tools a role uses or requires to perform its tasks. This allows to identify interfaces the system under development has to provide to communicate with the role's current tool set.
List the requirements the role imposes on the system under development. List functional and non-functional requirements.
Describe the implications the role has on the design of the system under development. This may be in the form of a bullet list, references to individually subdocuments with more detailed information or to complete design documents.
We would suggest to use design documents and place them as children to the role document. If the design is relevant to more than one role, move it to the design document section. But there is nothing wrong to start with a small bullet list, but keep in mind that those collections may be less easy to find.
Lists automatically the subdocuments of this document type.
It is assumed that every subrole is more specific than its parent roles. That is, it uses the same tool set and has the same, but maybe more specific responsibilities.
It is usually advantageous to have a limited number of roles. Try to find the essential roles of your project. Organize them hierarchically to keep the number of base roles (those without a role parent) small. This reduces complexity.
If you can think of subroles you have no user stories or use cases for, you might want to mention them in their own section on the parent role's document first.
If you have a set of roles that may take part in a use case, but not all of its siblings, you may be about to discover a yet unnamed role that is relevant to your project.
Lists automatically the use cases where actors holding this role act as
- secondary, and
This role is referenced as a primary actor in the use cases listed here.
This role is referenced as a secondary actor in the use cases listed here.
This role is referenced as a supporting actor in the use cases listed here.
Different Kind of Roles
There is only this one document type that captures all kinds of roles that are relevant to the system.
Therefore we do not distinguish between project roles that take part to create a product and roles users of the product have. There may also be support roles, like first-level support, operators, system administrators that may or may not require to be considered for the project.
Stakeholder and Person
A stakeholder is a person with interest in a project or the result of a project. A stakeholder therefore maps a person to a role within a given project. A person may take part in many projects, but is only represented as a single stakeholder per project. A stakeholder may have many roles in a project.
A user character is an actor within a user story. Typically, if you document a user story, you have a particular role in mind. Therefore user characters and roles often map 1:1. But the actor within a user story may also be a persona (e.g. Personas example @ Atlassian) or an extreme character. Both are creative tools to enhance the quality of your user stories and tighten the understanding of your problem domain.
Therefore there is a need to separate the roles from user stories by the notion of a user character. If you do not want to use personas, extreme characters or user characters that have several roles, you might want to skip user characters and edit your user story template to refer to roles instead of user characters.