Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Updating High-level Requirements Documents
Topic Summary:
Created On: 18-Jan-2007 21:49
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 18-Jan-2007 21:49
User is offline View Users Profile Print this message


Kelley Miles

Posts: 9
Joined: 15-Dec-2005

I currently have three high-level requirements documents feeding requirements to my SSS. One of the documents is about to be updated to version 2.0 and I will need to update it in the DOORS database. What is the best methodology for accomplishing this? All of the links trace through the 'Requirements' link module. I am considering importing the new document and linking to the SSS. then I would try to reroute the links to the old document to isolate any traces to it. This would preserve the information. Would using baselines work better? How would I get the new information, delete old information, etc? Any suggestions would be greatly appreciated. Kelley Miles
Report this to a Moderator Report this to a Moderator
 19-Jan-2007 18:53
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Its real tough to keep DOORS up to date when the Source of the document is elsewhere. The best way to do that is to import the doc, then export it to Excel featuring an "Object Identifier' column, the let the other folks edit that. Importing would be easy since you've got the mapping of new text to specific Objects.

There is no getting around the fact that you must associate new text with old text inside existing objects.

In your case, re-importing the document into a separate module and then redirect old links to the new document will work, but that's rather a pain. I'd export the old document featuring ObjIDs, Obj Heading, Object Text, lets say to MS Word table. Then add two columns, New Heading and New Text. Then start copying the new document paragraph-by-paragraph into this empty column insuring the new text 'matches' the old text (not exact in content, but in context). You may need to add a new row every now and then. Do not delete unneeded rows, but instead inserted DELETED into the new Text field. When that's done, remove the Old Heading and Text columns and you are left with Existintg Obj IDs and new heading and Text, which can be imported.

- Louie
Report this to a Moderator Report this to a Moderator
 22-Jan-2007 08:54
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

If the changes are relatively few then it may well be quicker to just edit the current module. As an alternative if you can get hold of the TREK tool (needs a license, try your DOORS rep) that has dxl routines to compare modules and automatically copy links.
Report this to a Moderator Report this to a Moderator
 22-Jan-2007 18:06
User is offline View Users Profile Print this message


Don Fowler

Posts: 12
Joined: 28-Jun-2005

Tsk, tsk, Still doing requirements management in Word, are we?...

I have this same argument at the beginning of each new project, and loose it most of the time.

The specification document (a Word file if you will) represents the full configuration of the requirements, and is controled by configuration management. A DOORS module represents some of the data contents of the specification, the reqirement baseline. It is controled by engineering through the change control board. Note the difference: configuration control and change control.

Change control is part of the requirements management process in which incremental changes are proposed, analyzed for impact, approved or rejected and incorporated into the requirements baseline. Once all the incremental changes to the baseline are accomplished, the configuration is changed or generated. Note the difference: requirements baseline and configuration.

The problem occurs when in our sloppy way we begin using module and document, change control and configuration control, and requirements baseline and configured document interchangeably.

Once we become thoroughly confused, we begin use the configuration item (the document) to make and change the baseline, then force DOORS to reflect the configured document. When we do this, we are really doing requirements management in Word (a word processor) and using DOORS as a configuration management tool. DOORS works well as a requirments management tool, because you in fact can do all the things I mentioned above, but as seen by the previous posts, really does not work well as a configuration management tool. If you are doing requirements management in Word, there is really no need for DOORS. Just admit you are not really doing requirements management and just go with the Word document and be done with it.

Excuse my tirade, but it is a sore point with me.

Don
Report this to a Moderator Report this to a Moderator
 22-Jan-2007 19:12
User is offline View Users Profile Print this message


Kelley Miles

Posts: 9
Joined: 15-Dec-2005

Save the lecture. I do requirements management the way my customer asks for it with little choice. The documents are produced by the government and it is my job to track the requirements from them using DOORS. They produce a new document and I have to update the information in DOORS. Help me or ignore me. Don't talk down to me. I asked for suggestions on the best way to handle the problem and until now, received helpful information.
Report this to a Moderator Report this to a Moderator
 22-Jan-2007 23:25
User is offline View Users Profile Print this message


Don Fowler

Posts: 12
Joined: 28-Jun-2005

I appologize. I am truely sorry that you found my rantings offensive. I meant no disrespect by it. My rantings are generally directed at mindless internal processes.

That said, as a sugestion, you might try taking a partition of the project giving the customer RMCD rights to the module. Assuming that they use DOORS to track their requirements, they could then input their requirements into DOORS and return a synch file to you which you could import into your database to update requirements, including additions and deletions. I do this quire successfully with a customer who is also in DOORS and it keeps the administrative effort low for updating each time a new rev. comes out.

I hope this is really helpful. And again I am sorry.

Don
Report this to a Moderator Report this to a Moderator
 23-Jan-2007 15:12
User is offline View Users Profile Print this message


Kelley Miles

Posts: 9
Joined: 15-Dec-2005

Apology accepted. Believe me, this isn't the way I'd have it if I could. Thanks for the suggestion but the people that write these documents are so far removed from me that providing them the module would be impossible. Kelley
Report this to a Moderator Report this to a Moderator
 23-Jan-2007 15:37
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

It is possible to update a DOORS module from a word document. I know because I have implemented a tool to do just that. Unfortunately I am not at liberty to share it.

There is however a workable solution using built-in doors functionality.

From the new Word document, export to doors, creating a new module.
From the new module run the module comparison wizard and compare the new module with the one you wish to update.
This tool creates links between matching objects and shows the differences in a layout DXL column.
You can then use these links to copy changes across - some DXL will be required here.
Once you have copied the changes, delete the links and baseline the module.

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 23-Jan-2007 19:37
User is offline View Users Profile Print this message


Don Fowler

Posts: 12
Joined: 28-Jun-2005

That is the other way to do it. In fact as I said earlier, I loose the argument more often than not, so I have the DXL you talk of here.


This is actually a dxl to copy any attribute from a source module. It will create the attribute if it doesn't exist, and display the damage ina collumn at the end. It also checks to to make sure there are no other inlinks from a differnet module than the one specified.

The settings are the full name of the source module, the full name of the link module, and the name of the attribute in the source module to be coppied, in this case it is just "Object Text". Best of luck.
Don
Report this to a Moderator Report this to a Moderator
 23-Jan-2007 19:47
User is offline View Users Profile Print this message


Kelley Miles

Posts: 9
Joined: 15-Dec-2005

I do have a DXL script similar to this. This sounds like a very viable solution. Thanks, folks!
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.