![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Links inside a module vs. links from one module to another Topic Summary: are links inside a module a bad idea? Created On: 30-Aug-2007 15:03 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Thanks for the pros and cons. I decided on having use scenarios in a separate module from the derived requirements, for a few reasons: - as Louie pointed out, it will make it easier to have separate signoffs on the use scenarios vs the requirements - it is easier for users to link across modules using drag and drop than to link inside the same module - I can enforce link direction through module linkset restrictions | |
![]() |
|
We're enlarging the scope of our DOORS usage, and I'm setting up our schema. We are migrating some docs from Word to DOORS.
One of our Word documents contains both use scenarios/user goals, and the requirements which are derived from those use scenarios. We want to use links to let us trace the requirements to the use scenarios. Some users are asking if we can store the use scenarios and requirements in the same module, and let them do the linking from object to object inside the same module. From my DOORS knowledge, I'm thinking that it is much harder to enforce allowed link directions if the links are between objects in the same module. I'm leaning towards having one module for use scenarios, another module for the requirements linked to those use scenarios. My question: is there any DOORS best practice about links between objects inside a module vs. links between modules? If we do allow links between objects inside a module, is there a simple way to enforce which kinds of links are allowed (like from objects we tag as requirements to objects we tag as use scenarios)?
Thanks!
|
|
![]() |
|
![]() |
|
Joseph,
I have seen users do some incredibly strange things in DOORS. In all my years of DOORS work, though, I have never, not once, ever, have I had a problem of someone making internal links in the wrong direction. It just doesn't happen for some reason. Maybe I've just been lucky. Maybe I've been in environments that had better training. I think you're overreacting to this issue a bit. Yes, you could split the modules up, nothing wrong with that. But as long as you let the users know that Requirements link to scenarios, you shouldn't have a problem at all. If you're really paranoid, you can just run a "clean up" script that sets all internal links to be bidirectional (if OBJ Y links to OBJ X then create a link for OBJ X going to OBJ Y) or a trigger that won't allow a save if links are going the wrong direction, or heck, even fix it with the trigger if the problem exists! But again, I have never had this problem. And I've had lots and lots of problem users. I'm here to serve my users, but certian users make my life difficult. And certain users would have definitely done this to me by now. ![]() This is a really low risk item, and nothing that cannot be fixed if someone does something wrong. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
Put the Use Cases in their own module. Their attributes for Reqs and UseCases are differnent and they will tend to have different CM needs and timing.
|
|
![]() |
|
![]() |
|
I agree with Louis - use different modules.
The real issue is how to display all the data that the user wants to see and manipulate. I personally use 2 monitors - 1 for working data and 1 for reference data. I have also created more complex forms where both sets of data (reqr and use cases) are displayed and edited together -- but this has a much higher maintenance load on you. |
|
![]() |
|
![]() |
|
Cliff and Lou,
I agree with your assessments, but sometimes managers are focused on "We want this document to look like it did in Word after DOORS, so we want everything in one module." If Joseph can't make separate modules, and it doesn't seem like he's interested in it, he asked if there is anything wrong with internal links. The answer to that, I believe, is not at all. If you disagree with me, though, do state your reasons so Joseph can make an informed decision...maybe even convince his management to split that document into two modules. Kevin ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
Thanks for the pros and cons. I decided on having use scenarios in a separate module from the derived requirements, for a few reasons:
- as Louie pointed out, it will make it easier to have separate signoffs on the use scenarios vs the requirements
- it is easier for users to link across modules using drag and drop than to link inside the same module
- I can enforce link direction through module linkset restrictions
------------------------- Joseph DUBIN joseph.dubinNOSPAM@freescale.com Freescale Semiconductor, Inc. |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.