It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×11,924
×7,383
×5,819
×1,314
×1,211
×157

question asked: Jul 06 '20, 4:31 a.m.
question was seen: 1,505 times
last updated: Jul 10 '20, 12:38 p.m.

Related questions

FAQ - How this Forum works

How to control access to Rhapsody elements, requirement specifications and test information within same global component

0
Ian Dunn (13●1●8) | asked Jul 06 '20, 4:31 a.m.
edited Jul 09 '20, 9:56 p.m. by Muralidhar Rajagopal (101●1●4)

I have a single system that has several sub-systems, each one of which are under the control of different teams. I have a single project within DOORS Next Generation, Quality Manager and Architecture Management for this system

<o:p> </o:p>

What I was thinking of was creating a global configuration to represent the system and this global configuration consists of several other global configurations, where some of them represent a constituent sub-system. Each global configuration that represents a sub-system will have an associated global stream that contains a DOORS Next Generation stream for the requirements, a Quality Manager stream for the associated tests and an Architecture Management stream for the associated Rhapsody elements. <o:p> </o:p>

With this set-up, how can I ensure that only those members of a team associated a particular sub-system do the following: <o:p> </o:p>

  • Edit the DOORS Next Generation artefacts in the DOORS Next Generation stream associated with the global stream linked to the global component that represents the particular sub-system
  • Edit the Quality Manager artefacts in the Quality Manager stream associated with the global stream linked to the global component that represents the particular sub-system
  • Edit the associated Rhapsody elements in the Architecture Management stream  associated with the global stream linked to the global component that represents the particular sub-system
<o:p> </o:p>

<o:p> </o:p>

<o:p> </o:p>

One answer

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
Amit Talwar (56●1●5) | answered Jul 10 '20, 12:38 p.m.

Project Area boundaries in ELM are used for controlling the permission models for component/streams/artifacts at the local domain tool level.  If you are looking to control who has access to edit a sub-system artifact by a specific team, then you would want to create individual RM/QM/AM project areas for those sub-system teams.  The components/streams/artifacts that those teams edit would be associated with those project areas.  You can then build a GC configuration with these stream/baseline contributions across the different domain toll project areas.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.