Hi,

As far as I know, at least ever since the advent of DOORS version 5, there is no way to wind back or alter an allocated baseline number to a DOORS Module. "Tricking" the DOORS system could wreak havoc, particularly if the Baseline Sets feature has been used.

I have been down this path of trying to keep DOORS Module versions in synch with Document versions before - it's a pain because of the very incident that you have encountered. It's easy to get out of synch. 

To decouple from this problem I have been doing the following for many years.

I assume that your documents have a Change History Table of some sort that lists all of the past released versions, date of release and a brief description of change. Assume that the current document version is lets say version 3.0 and the current version of the corresponding DOORS module is lets say version 5.0 - these are clearly out of synch.

When a new version of the document is to be cut we know in advance that the DOORS module will be advanced to version 6.0 and the document will be advanced to version 4.0. 

As a personal preference which you may elect not to follow, I never advance a new major version of a DOORS module until the paper document is fully signed off - it's amazing how many times the document comes back with just "one more change please" and then you have to repeat the process and advance another module version.

After exporting the current working version to MSWord, the Change History Table is modified with an entry for the new version 4.0 of the document. In the Description of Change for version 4.0, I include a version cross reference to DOORS, something to the effect of:

*The content of this document revision has been sourced from the DOORS Requirements Management Tool.*
*DOORS Module Name:* XYZ Specification
*DOORS Module version Used:* 6.0

When the ink is dry on the signatures of the document, I then roll the baseline in DOORS but in the Module Version Description box I also include a version cross reference to the version of the paper document, something to the effect of:

*This version is the source content for the following document*
*Document Name:* XYZ Specification
*Document Number:* ABC-123-XXX
*Document version:* 4.0

So this provides full version traceability - whilst it may seem onerous - it's not - it's just a new habit that needs to be formed and procedurally documented in your Requirements Management Plan.

If this is not for you - then perhaps this is what you need to do as an exception just for this version that your trying to release and then try and get things back into synch for the next version.

One other possibility is just make the document version equal to whatever the version is in the DOORS module. As long as each version number is unique and never goes backwards (e.g: 2.0, 2.0A, 3.1Z etc) you have satisfied version labelling and traceability criteria. However, I have found this is harder to sell as there are many pedants out there who believe that version numbering labels must always be incremental and sequential and never skip a number (e.g: 1.0, 2.0, 2.1, 2.2, 3.0 etc).



-----------------------
Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australiaist
Eu