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.