Hi all,
It would help me to understanding in more general terms how folks are linking requirements to MS Word.
All our requirements are written in DOORs but the technical teams work in Word generating specs/tests/results. When it comes to traceability I either have to enter a manual document reference so someone can go find the Word document or I import the spec/reports into DOORs and link up properly.
Both ways are flawed though as manual references get out of step if the doc is updated and Word imports into DOORs dont format very well (i.e. referencing of text to graphs) and I have to make all the links every time I re-import the Word docs...
I'm sure many people are facing this type of problem and would really like to hear if anyone has a neat solution....?
Thanks.
Mark.
Mark E - Sun Oct 25 20:00:54 EDT 2009 |
|
Re: Linking MS Word to DOORS
SystemAdmin - Sun Oct 25 22:44:46 EDT 2009
Can I ask a silly question - why don't your technical teams work within DOORS and only print to MSWord when it's really really necessary?
DOORS does not have a native round trip export\import\synch feature for MSWord. IBM's other RM tool, RequisitePro, does kind of have such a feature but it's restricted to only keeping the requirements text in synch between the two tools and no other attribute data. What's more, the ReqPro-MSWord integration tends to be a little fragile and not very forgiving if users get too medieval with the editing features of MSWord. As a result, you see users trying to manually copy-n-paste attribute data from the ReqPro DB into the MSWord document which just leads to bad tempers and tears as it's chronically error prone.
The shift in thinking required here is that DOORS needs to be viewed as the master content repository for the body content of your specs. What I mean by "body content" is just the headings, text, graphics and attributes - in other words, all of the important bits that need to be closely managed. All editing, linking, versioning, analysing etc is performed in DOORS.
MSWord needs to be relegated to being an external read-only export option for the purposes of exporting a selected pre-defined DOORS View into a formal corporate template in preparation for formal review and sign-off. If it's only a draft level print job that you need, just use the DOORS built-in print features for less formal publications such as giving vendors\customers something to look at and comment on.
Life is too short to let MSWord be the tail wagging the dog.
Paul Miller
|
|
Re: Linking MS Word to DOORS
sammyc - Sun Oct 25 22:55:34 EDT 2009 SystemAdmin - Sun Oct 25 22:44:46 EDT 2009
Can I ask a silly question - why don't your technical teams work within DOORS and only print to MSWord when it's really really necessary?
DOORS does not have a native round trip export\import\synch feature for MSWord. IBM's other RM tool, RequisitePro, does kind of have such a feature but it's restricted to only keeping the requirements text in synch between the two tools and no other attribute data. What's more, the ReqPro-MSWord integration tends to be a little fragile and not very forgiving if users get too medieval with the editing features of MSWord. As a result, you see users trying to manually copy-n-paste attribute data from the ReqPro DB into the MSWord document which just leads to bad tempers and tears as it's chronically error prone.
The shift in thinking required here is that DOORS needs to be viewed as the master content repository for the body content of your specs. What I mean by "body content" is just the headings, text, graphics and attributes - in other words, all of the important bits that need to be closely managed. All editing, linking, versioning, analysing etc is performed in DOORS.
MSWord needs to be relegated to being an external read-only export option for the purposes of exporting a selected pre-defined DOORS View into a formal corporate template in preparation for formal review and sign-off. If it's only a draft level print job that you need, just use the DOORS built-in print features for less formal publications such as giving vendors\customers something to look at and comment on.
Life is too short to let MSWord be the tail wagging the dog.
Paul Miller
Having used both tools, like yourself, you have stated the different aspects of the Word interaction very well. Now breaking the Word "crutch" is always the biggest challenge for organizations to fully adopt formal requirements management activities.
|
|
Re: Linking MS Word to DOORS
llandale - Mon Oct 26 14:33:07 EDT 2009 SystemAdmin - Sun Oct 25 22:44:46 EDT 2009
Can I ask a silly question - why don't your technical teams work within DOORS and only print to MSWord when it's really really necessary?
DOORS does not have a native round trip export\import\synch feature for MSWord. IBM's other RM tool, RequisitePro, does kind of have such a feature but it's restricted to only keeping the requirements text in synch between the two tools and no other attribute data. What's more, the ReqPro-MSWord integration tends to be a little fragile and not very forgiving if users get too medieval with the editing features of MSWord. As a result, you see users trying to manually copy-n-paste attribute data from the ReqPro DB into the MSWord document which just leads to bad tempers and tears as it's chronically error prone.
The shift in thinking required here is that DOORS needs to be viewed as the master content repository for the body content of your specs. What I mean by "body content" is just the headings, text, graphics and attributes - in other words, all of the important bits that need to be closely managed. All editing, linking, versioning, analysing etc is performed in DOORS.
MSWord needs to be relegated to being an external read-only export option for the purposes of exporting a selected pre-defined DOORS View into a formal corporate template in preparation for formal review and sign-off. If it's only a draft level print job that you need, just use the DOORS built-in print features for less formal publications such as giving vendors\customers something to look at and comment on.
Life is too short to let MSWord be the tail wagging the dog.
Paul Miller
We had some sucess at a previous company keeping DOORS the source yet preserving the entrenched procedures for approving and controlling word documents. At the end of the day, the DOORS module had the MS-Word Document number and revision inside it, and the MS-Word document had the exact DOORS module and baseline with which it was synced. Getting to the end-of-the-day was awkward, since we had to export the module in anticipation of which Baseline it would be, incorporate last minute Word tweaks the final review board always added, and THEN baselined the module. MS-Word comparison was essential. Module was therefore locked down during the review process.
Made a feeble effort at a MatchUpAndUpdate.dxl script that attempted to line up two modules; the old one that has all the links and attributes with the new one recently imported, figuring to update the text of the old to match the modified text of the new; then purge the new. It worked fairly well, which was 'good enough' since the source of the Requirements was MS-Word and it didn't matter if DOORS was exactly the same.
|
|
Re: Linking MS Word to DOORS
Mark E - Tue Oct 27 18:26:59 EDT 2009 SystemAdmin - Sun Oct 25 22:44:46 EDT 2009
Can I ask a silly question - why don't your technical teams work within DOORS and only print to MSWord when it's really really necessary?
DOORS does not have a native round trip export\import\synch feature for MSWord. IBM's other RM tool, RequisitePro, does kind of have such a feature but it's restricted to only keeping the requirements text in synch between the two tools and no other attribute data. What's more, the ReqPro-MSWord integration tends to be a little fragile and not very forgiving if users get too medieval with the editing features of MSWord. As a result, you see users trying to manually copy-n-paste attribute data from the ReqPro DB into the MSWord document which just leads to bad tempers and tears as it's chronically error prone.
The shift in thinking required here is that DOORS needs to be viewed as the master content repository for the body content of your specs. What I mean by "body content" is just the headings, text, graphics and attributes - in other words, all of the important bits that need to be closely managed. All editing, linking, versioning, analysing etc is performed in DOORS.
MSWord needs to be relegated to being an external read-only export option for the purposes of exporting a selected pre-defined DOORS View into a formal corporate template in preparation for formal review and sign-off. If it's only a draft level print job that you need, just use the DOORS built-in print features for less formal publications such as giving vendors\customers something to look at and comment on.
Life is too short to let MSWord be the tail wagging the dog.
Paul Miller
It's a fair question... and the answer is related to the culture (not supportive) and the scope.
Just considering the scope: We'd like DOORs to include everything from Design Input to Design Output which for us crosses a dozen disciples and as many software packages (CAD, Simulation, Stats, Test tools etc). Hence it is difficult (even with motivated people) to find a way of managing all that information in one place.
I will continue my quest to make DOORs accessible to the masses.
Thanks,
Mark.
|
|