Roles

Roles identify the functions of team members. You assign permissions to perform specific operations to roles. Therefore, a user’s role or roles determine which operation the user can perform.
Within a project area, you can assign permissions at the following levels:
  • project area
  • team area
  • timeline
  • iteration type
  • iteration

All users in the repository have the default Everyone role. Even if a user is not a member of a project area, that user has the permissions assigned to the Everyone role for that project area. If you need to restrict users who are not members of the project area from performing certain operations, you must disable that operation from the Everyone (default) role and enable it for one or more other roles. You can add and modify roles in project areas. Team areas inherit the set of roles defined in the project area, but you can also add and modify roles in team areas.

There are roles for Change and Configuration Management, Quality Management, and Requirements Management.

For Change and Configuration Management and Quality Management project areas, you can configure operation behavior (preconditions and follow-up actions). Just as you can assign different permissions to different roles, you can specify different operation behavior for different roles. For example, in a Change and Configuration Management project area, you might configure behavior that requires team members to get approvals before they can deliver change sets. In a Quality Management project area, you might configure behavior that requires all test cases in a test plan to be approved before the test plan can be approved.

You can assign one or more roles to a user in the Edit Process Roles window. The order of the roles for the user reflects their relative priority. When operation behavior is configured for multiple roles, the process runs the behavior that is associated with the highest-priority role for the user. Priority does not affect permissions; users can perform actions that are granted through any of their assigned roles.

The graphic shows the Edit Process Roles window with the Test Team Contributor role selected.

Because the predefined default Everyone role cannot be assigned, removed, or reordered, it does not appear in the Edit Process Roles window. All users in the repository have the Everyone role.

The roles definition includes an identifier, name, description, and a cardinality value, which indicates whether the role is intended to be assigned to more than one user in the project area or team area.

Roles for Change and Configuration Management

In the web client, roles are defined on the Roles tab of the project area editor. These roles apply to the entire project. You can add and modify roles for a team area on the Roles tab of the team area editor.

In the Rational Team Concert™ client for Eclipse IDE, roles are defined on the Process Configuration tab or the Process Configuration Source tab of the project area editor or process template editor. To modify roles for team areas in the client for Eclipse IDE, use the Process Customization tab of the team area editor.

The initial set of roles available in a project area depends on the process template that you use to create the project area.

Table 1 lists and describes the roles in the Scrum process template.
Table 1. Roles available in the Scrum process
Role Description
Scrum master Responsible for the process. This role can modify all aspects of the project area process.
Product owner Responsible for managing the Product Backlog of work items. This role can modify most aspects of the project area process.
Team member A member of the cross-functional team. This role can create and modify artifacts, such as work items, plans, and files under source control.
Stakeholder Represents interest groups whose needs must be satisfied by the project. This role can be played by anyone who is (or potentially will be) materially affected by the outcome of the project. This role is intended for users who will mostly need just read access to most operations.
Table 2 lists and describes the roles available in the Formal Project Management process.
Table 2. Roles available in the Formal Project Management process
Role Description
Analyst Represents customer and end-user concerns by gathering input from stakeholders to understand the problem to be solved and by capturing and setting priorities for requirements.
Architect Defines the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project.
Developer Develops a part of the system, including designing it to fit into the architecture, possibly prototyping the user-interface, and then implementing, unit-testing, and integrating the components that are part of the solution.
Project manager Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives.
Team lead Leads a component team and is responsible for planning and architectural integrity of the component.
Stakeholder Represents interest groups whose needs must be satisfied by the project. This role can be played by anyone who is (or potentially will be) materially affected by the outcome of the project. This role is intended for users who will mostly need just read access to most operations.
Tester Responsible for the core activities of the test effort. Those activities include identifying, defining, implementing, and conducting the necessary tests, as well as logging the outcomes of the tests and analyzing the results.
Release engineer Responsible for software builds and releases. Responsible for the design and development of builds, scripts, installation procedures, and systems including source code control and issue tracking.

Roles for Quality Management

Both the Quality Management Default Process and the Quality Management Legacy Process include these predefined user roles:

Table 3. Project process roles for Quality Management
Project Process Role Description
Test Team Member This role is intended for users who are full participants in the test team and will need both read and write access to many team operations.
Test Team Contributor This role is intended for users who will mostly need just read access to most operations.
Data Migration Administrator You can use this role to allow administrators to create data that is exempt from the normal constraints that are enforced by process advisers. For example, if you need to migrate data into Quality Management via the REST API, then this role would allow you to bypass the process advisors and migrate data that violates the version 4 process constraints. (The REST API lets you read and write data with out using the web interface.) You can combine this role with other roles, but you must place this role in the first position in the list of selected roles.

Depending on your needs, you can create roles for testers, test leads, test managers, and other test team members, based on the Test Team Member role. You can use the Test Team Member role as a model and make slight variations in the operations that are allowed for each role.

Roles for Requirements Management

The requirements management application includes these predefined user roles:
Table 4. Project process roles for Requirements Management
Project Process Role Description
Administrator In addition to the Author and Commenter capabilities, an Administrator can add and remove users in a project; manage templates; manage artifact types, attributes, attribute data types, and link types; access the Administration project page. An administrator must have a Rational® DOORS® Next Generation Analyst client access license or any client access license that allows read-write capabilities.
Author In addition to the Commenter capabilities, an Author can create and delete artifacts such as requirements, sketches, and diagrams; add links to artifacts; create personal and shared tags and apply them to artifacts; create shared and personal filters; move resources between folders; create reviews. An Author must have a Rational DOORS Next Generation Analyst client access license or any client access license that allows read-write capabilities.
Commenter A Commenter can view artifacts such as requirements, sketches, and diagrams; participate in reviews, comment on artifacts; create personal tags and apply them to artifacts; create personal filters. A Commenter must have a Rational DOORS Next Generation Contributor or Analyst client access license or any client access license that allows read-write capabilities.
Project Baseline Administrator A Project Baseline administrator can manage project baselines. A Project Baseline Administrator must have a Rational DOORS Next Generation Analyst client access license or any client access license that allows read-write capabilities.

video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki