![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Document Management Using DOORS Topic Summary: Created On: 10-Feb-2004 14:47 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Has anybody had any luck using DOORS to do document management? It would seem that, given that many of a company's artifacts (requirements documents, test plans, design documents, etc.) need to be input into DOORS, any changes made to an artifact (Word document) must also be made to the corresponding DOORS module. Thus, two copies need to be change-managed. In an ideal setting, one would like to throw away the Word document once it has been input into DOORS thus avoiding the tedious nightmare of keeping the (living, breathing) document and its corresponding DOORS module in sync. Unfortunately, the DOORS "import" and "export" functions are not exact inverses of each other, so, for example, if a module is exported in order to create a deliverable Word version, it will not have any of the cross-references, colored text, etc. which was found in the original Word doc. So, how does one use DOORS to manage documents, the possibility of which is promised in a DOORS "tip of the day"?
|
|
![]() |
|
![]() |
|
No, you CANNOT keep two copies in perfect sync. Forget about it.
Yes, Export/Import are not mirrors of each other. But all you really need to do is to let go of all those clever MS-Word features that you like. Keep the original in DOORS and when you need an MS-Word version then export it, such as at every baseline. Its understood that [1] the MS-Word version is a copy and you are wasting time if you edit it; and [2] You cannot use all MS-Word features in this manner: not colored shalls, no cross references, but so what. - Louie |
|
![]() |
|
![]() |
|
What I'd like to see is DocExpress/Word or Factory inter-woven into Doors to make it possible to produce a Publishable PDF copy, which can be given to our customer or vendor. That means the integration with Adobe Distiller and MS Project 2000 need to be updated to name a few.
------------------------- Al Minter Edited: 12-Feb-2004 at 22:27 by Alan Minter |
|
![]() |
|
![]() |
|
I agree, forget about what DOORs can't do and march forward. Create a WORD template for exporting. Work on cosmetics in the .doc file and then PDF it. Once your SPECS are structured correctly in DOORs the export clean-up process is easy. There is an attribute in DOORs for Paragraph style. Use this for generating Table of contents and interfacing with your word template.
Work real time in DOORs and release snap shots for approval, or you can try using the change management tool and apply mark-up's only after they have been approved. Watch out this tool has limitations and problems. The former company I worked for tried to create an in-house version that also had limitations and problems. My advice is to look into the tool befroe you implememnt it. Jason |
|
![]() |
|
![]() |
|
Have to agree, time to bite the bullet and move to a doors based repository.
Personally I hate DocExpress, finding that it is hard to use and that it doesn't really do what we want. We plain and simple have a carefully created view that we print to a postscript file using a colour printer driver and then distill to pdf. Works ok as long you have Doors 7 SP1 build 70214 (which resolved some layout issues in printing documents). The distill stage is automated to make life nice and easy. ------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
I am struggling with the same issues.
I have spend many years working requirements but this will be my first forray into DOORS. Let me tell you how I've done work, why I like it, and what I fear about DOORS. Then maybe you guys can point me in the rigth direction. Historically, I'll store my requirements in a database. Which one? Don't care. I have certain fields I like for attributes like one for how this req gets tested, several attributes to allow me to create different views via sort, etc. Then, most of my SRS lives in a document (word, frame, whatever). Only the actual one line requirements go into the database. I use IEEE standard SRS template, but I rip out section 3. Each SRS release, I export the database into a nicely formatted section 3 and suck it in. I love this. I get all the benefits of a database for my requirements, but also all the benefits of the word processor dejour for managing my documents. Tracabilty is done in the database with attributes for whatever I am tracing to... this allows me to autogenerate the raceability matices from the DB. Ok, Now DOORS. It seems like everyone wants the whole document in DOORS. This seems overkill to me, as most of the SRS is verbiage, disgrams, etc. I only really see a need for section 3 in DOORS. Is there some way to manage this more like I am used to? Are there reasons you can all clue me in on as to why we need a document (which is meant to have a word processor as its environment) living in a database? Secondly, it seems like everything we want to link to, needs to be in DOORS also, to make use of DOORS traceability. Is this so? Each project should and can use various tools. OOA/OOD design tools, word processors, etc. for various parts of the project. Is it somehow the intent that each of these should live inside of DOORS also? Or do people just import those into DOORS at various times... It seems that would not work, as how would links be maintained? How do you handle tracability to things outside of DOORS. Just a manual attribute? I'm assuming re-importing of things we link to will not work? How about reimporting something that links to us? Can the link #s be verified on import? Many questions I know and sorry for rambling on. |
|
![]() |
Telelogic DOORS
» General Discussion
»
Document Management Using DOORS
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.