role, n. any part played by something (e.g. a person, piece of equipment, or organization)

A role captures the purpose of something, the position it holds, or its capacity, job, or viewpoint.

For more information on this, please refer to Uwe Friedrichsen

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

• primary,
• secondary, and
• supporting.

Lists automatically the quality scenarios that refer to this role.

Lists automatically the user characters that hold this role.

Lists automatically the stakeholders that hold this role.

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.