![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: DOORS first impression / Linking blocks of text Topic Summary: Master document Created On: 27-Jun-2006 10:34 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: See code | |
![]() |
|
My 2 cents: Edited: 29-Jun-2006 at 08:52 by Harald Coeleveld |
|
![]() |
|
![]() |
|
My tuppence:
Congratulations on using DOORS. Yes it is strange to start with, but in my humble opinion it is by far the best requirements management tool on this little planet. An item that is selected in the left hand pane (the explorer tree) is open. DOORS does not allow you to delete things that are open. Windows on the other hand allows you to select the delete option and complains later if the thing is being used! Objects in a formal module can indeed be moved using drag-and-drop. When you drop an object the popup menu gives you the various copy/move options available. Items (folders, projects, modules) and objects must first be soft-deleted before they can be purged. Both the delete and purge operations do work recursively, so you can select a folder, delete it, purge it, and all its descendent items are purged too. Yopu do not have to purge individually. Link management is extremely flexible. This allows you to set up your data model with varying degrees of complexity and control over how you want users to create links. A good data model also facilitates easier and better traceability and impact analysis. There is no "default" action assigned to the right mouse button. The first item on the popup menu is insert (after), not insert below. If you want to insert objects faster then use Ctrl-N or Ctrl-L to insert a new object after or below respectively. WEXP will always be slow because it uses thesystem clipboard in the same way as the builtin word exporter. The phrase "unloaded object" is used to inform the user that the module being linked to is not open. DOORS is not a relational database. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
quote: I have implemented a kind of link-and-embed function whereby objects are copied from the master module into the project specific module. I then use DXL to update the project specific module with information from the master module. Suspect links also help in highlighting changes to the master module that you may want to inherit in the project specific module. This is relatively simple to do and works well, but requires a bit of DXL coding to do it. For this to work, the "inheritance" links must exist in their own link module, i.e. don't use the same link module for other types of links. The link module must have a mapping of one-to-one. The initial copy-and-link (referred to earlier as link-and embed) can be done using the doors GUI. The script to update the project specific module with information from the master module needs to do something like the following: for each object in the project specific module do ... for each outgoing "inheritance" link do ... compare attributes of current object with master object at other end of link if attributes differ then copy values across You will also need some other checking to ensure that objects exist, are not deleted, master module is the correct module etc etc etc ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Thank you for your quick reply and kind words Tony.
There are little use model examples in the documentation how to apply linking, dxl scripts, etc. For now all is well, except for the fact that it requires quite some effort to use something as intuitive as linking chapters from a 'master document' into a subset document.
However, you have addressed most of my questions and provided proper arguments. Over time I will learn to appreciate Doors more but at this time I remain puzzled by it's somewhat non-intuitive behaviour (like the graphical link manager :-)
|
|
![]() |
|
![]() |
|
My advice is to stay away from the all the graphical views. For those to make sense, you have to do more than speak in DOORS; you have to dream in DOORS.
A different way to keep requirements in one module with all the flavors and colors is to create a what I call a "Document Module". The document module is made up of the outline or headings you want in your output document and create links to the headings in the document module. You would then need to create a view of what you want to print using a layout DXL. I use the layout dxl because you can use a skip list to sort the linked data in the order you want it to appear. I personally like this method because you don't need to continuously check the suspect links to update the document. the data are not actually part of the document module. The other advantage is that you can manage your requirements in one location and your document in another.
Just my take. and to show that there are many ways to manage requirements in DOORS.
Don
|
|
![]() |
|
![]() |
|
See code Edited: 29-Jun-2006 at 09:33 by Harald Coeleveld |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.