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.
- 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.
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 IBM® Engineering Workflow Management 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.
| 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. |
| 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:
| 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
| 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 IBM Engineering Requirements Management DOORS® Next 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 DOORS Next 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 DOORS Next Contributor or Analyst client access license or any client access license that allows read-write capabilities. |
| Configuration Lead | A configuration lead can manage project baselines. A configuration lead must have a DOORS Next Analyst client access license or any client access license that allows read-write capabilities. |