DOORS Partions - Best Practices, Lessons Learned

Although we have remote access to our customer’s DOORS database, we are planning to use partitions to develop our requirements and link them to the customer’s requirement specs. Via periodic exports, synchronizations, and returns we plan to transfer modules between our databases to keep up to date with the changes made in each database.

We have limited experience with DOORS partitions before, but I have experimented with all of the partitioning functions (i.e. Define, Export, Import, Add Data, Synchronize, Return, Rejoin) so I feel that I have a fairly good understanding of how partitions work.

However, based on some problems I originally encountered and based on some comments I have read in the forums, I am concerned about committing our project to using partitions since the inability to Synchronize or Rejoin the partition could make it difficult or impossible to transfer our updated modules in the partition back to the home database.

I would be interested in hearing what other DOORS users have to say about using partitions. What are the “best practices”? What are the lessons learned? What are the most common problems and how can they be resolved when they occur. Thanks in advance. Your advice will be much appreciated.
SystemAdmin - Mon Sep 14 19:27:30 EDT 2009

Re: DOORS Partions - Best Practices, Lessons Learned
sammyc - Mon Sep 14 19:53:56 EDT 2009

I would suggest that you research using the RIF exchange in the latest version of DOORS 9.2. It will support your usage patterns with much more flexibility and reliability.

Re: DOORS Partions - Best Practices, Lessons Learned
Ron_Lewis - Tue Sep 15 11:11:42 EDT 2009

sammyc - Mon Sep 14 19:53:56 EDT 2009
I would suggest that you research using the RIF exchange in the latest version of DOORS 9.2. It will support your usage patterns with much more flexibility and reliability.

Sammyc, how do you proposed to use RIF to clone a module when DOORS 9.2 implementation of RIF does not perserve Object Ids. At least my versions doesn't.

Re: DOORS Partions - Best Practices, Lessons Learned
sammyc - Thu Sep 17 00:39:40 EDT 2009

Ron_Lewis - Tue Sep 15 11:11:42 EDT 2009
Sammyc, how do you proposed to use RIF to clone a module when DOORS 9.2 implementation of RIF does not perserve Object Ids. At least my versions doesn't.

Based on the latest rev of the RIF feature, when you import back to source:

  • Imported module would effectively replace original module
  • All updates made in the target reflected back in the source
  • Original object IDs are preserved
  • New object IDs will diverge between databases
    • To interact with other RM solutions, specific “RIF IDs” used to control data merge

A new release (DOORs 9.2 patch 1) is expected by the end of Sept. It will address RIF 1.2 compatibility and more functionality with creating a RIF package (lock data, modules from different locations inside a RIF-Package,...). I would be glad to help share further technical details if you need - please contact me by private message.