The access controls in DOORS Next are really quite good, however, you need to really think about how you are going to get the best out of them.
Access control is made up of two components; What you can do, and where you can do it.
First lets look at the Project Members and Project Administrators. In ‘Manage this Project Area’ in the Overview section, there are two groups of people. The Project Administrators can set the access rights for the Project Members.
The Project Members are assigned Roles. To manage what you can do, we need to look at the Roles.
By default, you get Administrator, Configuration Manager, Author, Commenter. These are a good starting point, and a small project may never need to go any further.
The permissions are then set against the Roles – this will define WHAT the holders of those roles can do.
Permissions can be set for Configuration management activities, such as delivering change sets; for Dashboards, such as creating project dashboards, for process activities and reports, and for requirements management resources. In the requirements management resources, it is possible to set controls for the modification of individual attributes on requirement types, and creation of link types.
This fine granularity of control is impressive, and should be used with caution. If it is liberally deployed, there will be cries of ‘it won’t let me…’ from users. Over time the knowledge of what has been set will fade, and a legacy minefield of permission chaos will exist. To avoid this, use the fine grained permissions only where necessary to enforce the process, and document it carefully.
The other piece of this access control puzzle is WHERE the permissions apply. We can set a Team Hierarchy in the Project Area Overview.
By default a team is created with the project, and has the same name as the project. We can create teams below this. The parent team inherits all the permissions of the teams below.
I can create a Subsystem Team and assign members to that team. They have the same set of Roles to choose from as already discussed, with the same permissions.
I can assign team ownership to a folder (not forgetting to mirror the assignment to the artifacts folders if these are separated). Now my Authors for the Subsystem Team can do all the author things within that folder, but may only be Commenters in other areas of the project.
My users need to be able to create a change set at the whole project level in order to create a change set that they can use to make the changes to their single folder context.
For larger projects, it might be easier to manage this with different components, or with different projects that are joined in a Global Configuration. For small projects operated by experts in the tool, we can possibly manage with guidance rather than enforcement. We always need to consider who is going to have to manage the complexity of anything we set up. The more control we add, the more there is to manage. The bulk of the end users will want a simple experience, and that means the expert users will have to ensure that the tool is set up and managed with those end users, possibly infrequent, casual users, have an easy experience.