Hello!
We are about to use DOORS (version 9.3) for a project for the first time.
We have had a workshop and a PAW where we got help defining the basic structure. But now that we face a real project, we do not know if this is the right/best structure.
Basically we will have 3 or maybe 4 requirement levels depending on the abstraction level. But on the same requirement level we see that we would like to link between objects. We were told during the workshop/PAW to avoid linking between objects within the same module. We do not recall the exact reason for this but think it is because we can not use the linkset feature to define rules how links are allowed to link. Any other reasons?
To avoid links within a module we could create several modules for the same requirement level but that would probably generate too many modules, making it harder to navigate. Maybe we could find a pragmatic way where we could group some requirements to a limited number of modules.
We would very much appreciate some advice on good practices.
Best regards,
Peter Carlsson
SystemAdmin - Thu Apr 04 08:03:26 EDT 2013 |
|
Re: DOORS Best Practices
SystemAdmin - Thu Apr 04 08:37:56 EDT 2013
Peter, Linking within a module is generally not a good, or necessary, thing to do. If you have a module for hardware requirements and a module for software requirements, both at the same level, then perhaps you would want a 'software requirement depends on hardware requirement' relationship. That would be a good thing. You can draw out the different types of information that you have, and where there are relationships, draw an arrow between them. Put a verb on the arrow to describe the relationship. Multiple modules can be useful, and if you have the equivalent of 10 to 25 pages, then you have a viable module. More than about 100 pages and you probably want to break it up to make it more manageable. Less than about 5 pages and it needs to have a very specific purpose to justify its existence.
If you have links within a module, then you cannot control the direction of those links and the purpose is often unclear to the users.
If you start to think a little more 'database' and a little less 'document' you should find things easier.
|
|
Re: DOORS Best Practices
SystemAdmin - Thu Apr 04 08:37:58 EDT 2013
Peter, Linking within a module is generally not a good, or necessary, thing to do. If you have a module for hardware requirements and a module for software requirements, both at the same level, then perhaps you would want a 'software requirement depends on hardware requirement' relationship. That would be a good thing. You can draw out the different types of information that you have, and where there are relationships, draw an arrow between them. Put a verb on the arrow to describe the relationship. Multiple modules can be useful, and if you have the equivalent of 10 to 25 pages, then you have a viable module. More than about 100 pages and you probably want to break it up to make it more manageable. Less than about 5 pages and it needs to have a very specific purpose to justify its existence.
If you have links within a module, then you cannot control the direction of those links and the purpose is often unclear to the users.
If you start to think a little more 'database' and a little less 'document' you should find things easier.
|
|
Re: DOORS Best Practices
Tony_Goodman - Thu Apr 04 09:52:14 EDT 2013 SystemAdmin - Thu Apr 04 08:37:58 EDT 2013
Peter, Linking within a module is generally not a good, or necessary, thing to do. If you have a module for hardware requirements and a module for software requirements, both at the same level, then perhaps you would want a 'software requirement depends on hardware requirement' relationship. That would be a good thing. You can draw out the different types of information that you have, and where there are relationships, draw an arrow between them. Put a verb on the arrow to describe the relationship. Multiple modules can be useful, and if you have the equivalent of 10 to 25 pages, then you have a viable module. More than about 100 pages and you probably want to break it up to make it more manageable. Less than about 5 pages and it needs to have a very specific purpose to justify its existence.
If you have links within a module, then you cannot control the direction of those links and the purpose is often unclear to the users.
If you start to think a little more 'database' and a little less 'document' you should find things easier.
Peter, I would also recommend creating folders to hold your modules at each level. These can be numbered to control the order they appear. e.g.
01 - System
02 - Subsystem
etc
You will find some good advice on how to control link modules in the following post:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=481293&tstart=15
(ignore the geeking DXL stuff).
Tony Goodman, www.smartdxl.com
|
|
Re: DOORS Best Practices
llandale - Thu Apr 04 14:42:49 EDT 2013
I'm not sure I like the rest of Hazel's response, but this part is stellar:
-
You can draw out the different types of information that you have, and where there are relationships, draw an arrow between them. Put a verb on the arrow to describe the relationship.
-
e.g. draw a circle "SubSystem Reqs" and another "System Reqs", draw an arrow from SubSystem to System marked "Satisfies". Draw another circle "Test Procedures" and draw an arrow to SubSystem marked "Tests". So a SubSystem req can "Satisfy" a System req; and a Test Procedure can "Test" a SubSystem req.
Yes, once you have defined the RELATIONSHIPS you wish to have, THEN start thinking about representing those relationships with directional LINKS.
-
e.g. you need two link modules perhaps "Satisfies Links" and "Tests Links" and set up your Default LinkSets accordingly. Might as well put all your project-approved link modules in the same "\Link Modules" project level folder.
Back to your issue; exactly what relationship are you trying to represent in your intra-module links? Perhaps "References"? "Includes Table/Figure"? "Vaguely Relates To"? You cannot proceed until you answer that question for yourself .. and no doubt your bosses.
Folks everywhere in your project (and in fact the entire DOORS world) need to be thinking "What is the relationship between these Objects" instead of "Is there a link between these Objects".
-Louie
|
|
Re: DOORS Best Practices
CarlssP - Mon Apr 15 17:54:39 EDT 2013
Thanks everyone for all the good recommendations!
What feels good is that our current solution is not too far from your recommendations and as long as we try to avoid the internal links we will be fine.
Best regards,
Peter
|
|