How to work on different releases with DOORS

Hello, everyone,

I am working on system requirements of a project with DOORS. We have planned several releases. All requirements are written into the same module. For each releases some requirements will be added/deleted/modified. I think it would be difficult and confusing if for the next release I change the requirements that are used for the current release. So I am wondering what are the best practice to work on several releases. Does anyone has advice ( if possible without obligation to purchase new add-on)?

My DOORS version is: DOORS 9.5.1.2

Thank you in advance,

Best regards,

Socrate

Re: How to work on different releases with DOORS
DOORSHAM - Wed Nov 02 13:51:15 EDT 2016

DOORS wasn't designed specifically for Product Line Engineering.

Lot of people have tried to make DOORS do what it wasn't designed to do -- Look at Mike Southerland web page -- he wrote a paper on this.

Google Galactic Solutions --  or http://galactic-solutions.com/GalacticWhitePapers.htm

Doing what you want in DOORS will be painful.

If you continue down this path you will be like the carpenter that uses his level to drive nails -- you will always be a half bubble off.

Better yet might be to contact: Richard_Watson; Product Manager, IBM DOORS & IBM DOORS Next Generation and find out why IBM is not supporting this need without a very expensive add on

Re: How to work on different releases with DOORS
chaseo - Wed Nov 02 21:36:31 EDT 2016

I'm not sure why release mgmt won't be able to be implemented in DOORS. There should be multiple ways to manage that, such as baseline or duplicating a module for each release and so on. 

I think you should be able to find example DXLs as well that can do replication of a module with or without traceability, depends on your requirement. Which one would be better should be dependent on your process. I agree with DOORSHAM that DNG might be difficult to implement some level of requirement mgmt specially if you are doing parallel or variation mgmt. 

Re: How to work on different releases with DOORS
Mike.Scharnow - Thu Nov 03 08:20:12 EDT 2016

My 2 cts...

Regarding DNG: In my opinion one of the advantages of DNG over DOORS is DNGs ability to work with Global Configurations. This feature is designed explicitly in order to allow for reuse / platform / release  etc. So, if you are still in the state of defining your processes / tools you might want to have a look at it.

Classic DOORS has its strengths when it comes to customization and flexibility. So, yes, it is possible to do release management with DOORS  classic but it does not come easily. One approach for release management that I saw several companies applied is the following:
- A requirement is valid for a specific release. (e.g. 1.2)

- A requirement might be valid for several for several releases (e.g. 0.7 to 1.5)

- A requirement might be modified for a later release (Version a is valid from 0.7 to 1.5, Version b from 1.6 up to now)

- A requirement might be removed for later releases

- A requirement might be added for later releases

With this approach you can define the attributes:

- Requirement ID (manually edited)

- Requirement version

- valid from release (empty: from  beginning of the module's lifecycle)

- valid until release (empty: still valid)

And you can enter requirements like this:

Now, if you define valid_form and valid_until as listboxes using related numbers, you can define filters in views to e.g. show and edit all requirements for Release 1.4 using less than (<) and greater than (>) filters.

Note that this approach is meant to support successive development of releases. Variant management will add more complexity. Also, links to other modules will bring in complexity.