Best practice when setting up DOORS (User, Groups, etc.) Help Needed!!!!!!!

I am trying to determine what the best practice is when setting up DOORS.
• When attempt to limit access to attributes based on User groups.
1) e.g. Engineer full access to all engineering attribute including "Object Text" and Read-only access to IV&V attributes
2) e.g. Read-only for the IV&V group for engineering attributes including "Object Text".

What would be the best approach for implementing the above structure? Does anyone have a DXL and be willing to share for maintaining permissions within DOORS.
Thank you,
Jim
SystemAdmin - Wed Dec 14 21:27:45 EST 2011

Re: Best practice when setting up DOORS (User, Groups, etc.) Help Needed!!!!!!!
llandale - Fri Dec 16 12:43:28 EST 2011

Seems to me the majority of groups are best administered at the project level which would encourage your group names to have a project acronym for the prefix. So maybe you want these groups:
  • XYZ_Admins -- folks given RMCDA to everything in the project, including these groups
  • XYZ_Readers -- folks given R to everything; generally everybody in all the other "XYZ_" groups, and some other untrustworthy folks like "Managers".
  • XYZ_LightSideOfForce -- Engineers who may edit Object Text and other 'Requirement' attributes
  • XYZ_DarkSideOfForce -- IVV who can edit Testing related attributes.

Your "Force" folks could have "RM" access to the project which is generally inherited by the folders and the modules. Each Attr-Def would have specific rights for its values.

It is non-trivial to assign access rights to individual attributes in each module. Better would be to have a series of "Template" modules housing project approved attributes and accesses, and "copyAtts.dxl" those down to the production modules.

I'm tempted to come up with some very clever DXL to perform this massive access-rights chore and keep the access records in a project pristine. Seems to me the Template module could be set up manually and include information as to exactly which production modules are based on this template, and this script could make sure access rights are consistent throughout. this would be VERY handy should you archive-restore a project in some other database; you could re-establish access with a click of a button and 4 hours of processing. Capturing your desire for Folder and for Object specific rights would be trickier.

  • Louie

Re: Best practice when setting up DOORS (User, Groups, etc.) Help Needed!!!!!!!
mtmccor - Mon Dec 19 08:47:06 EST 2011

I agree with Louie that it is non-trivial to assign access rights to individual attributes; furthermore, it is non-trivial to maintain those access rights.

I don't know if I would claim it as a best practice, but what we did for one project where we wanted to separate the access rights and usage between the engineering team and the V&V team is we separated the V&V-specific attributes into a different module. We then set up a link module to go from the V&V module (source) to the requirement module (target), and in our case, we wanted to enforce a one-to-one mapping between the modules, so we created the link module with one-to-one mapping. Finally, we created layout and attribute DXL columns in each module to display attribute information from the other module.

With this setup, we could give the V&V team the RMCD permissions that they needed in the V&V module while they had only read permissions to the requirements module, and the engineers had RMCD permissions in the requirements module and only read permissions in the V&V module. This also kept each team working within its own module, so there was less contention. We had the linking going from the V&V module to the requirements module because the V&V team was responsible for specifying what V&V description mapped to each requirement.

This worked well for our project.

Re: Best practice when setting up DOORS (User, Groups, etc.) Help Needed!!!!!!!
llandale - Mon Dec 19 14:13:44 EST 2011

mtmccor - Mon Dec 19 08:47:06 EST 2011
I agree with Louie that it is non-trivial to assign access rights to individual attributes; furthermore, it is non-trivial to maintain those access rights.

I don't know if I would claim it as a best practice, but what we did for one project where we wanted to separate the access rights and usage between the engineering team and the V&V team is we separated the V&V-specific attributes into a different module. We then set up a link module to go from the V&V module (source) to the requirement module (target), and in our case, we wanted to enforce a one-to-one mapping between the modules, so we created the link module with one-to-one mapping. Finally, we created layout and attribute DXL columns in each module to display attribute information from the other module.

With this setup, we could give the V&V team the RMCD permissions that they needed in the V&V module while they had only read permissions to the requirements module, and the engineers had RMCD permissions in the requirements module and only read permissions in the V&V module. This also kept each team working within its own module, so there was less contention. We had the linking going from the V&V module to the requirements module because the V&V team was responsible for specifying what V&V description mapped to each requirement.

This worked well for our project.

I believe this to be the best approach; even if you had some super Attr access rights script managing access. Its "clean" and easy for users, a little more work for the admins.

Our partners did it, using a nightly script that made sure the side-kick module always looked like the original. They copied the Object Text but displaying it with attr-DXL would have been clearly better. There were issues when the requirement was deleted, they chose to display "DELETED" in the side-kick.

I would argue in favor of putting the side-kick in the same folder as the original, not in some other "IVV" folder off the Project folder. Tomorrow I'll argue the other way.

I hear tell other folks have done this where the Original has locked down attributes and a side-kicks various flavors of not-yet-locked-down attributes; the attributes and the obj-values are moved to the Original when they are locked down.

Exporting requires Attr-DXL support.

I emphasize that the side-kick module is an extension of the original, fundamentally just a new pile of attributes for it. A "test procedures" module would not qualify as a side-kick since there is not a one-to-one relationship of Procedures to Requirements.

-Louie