'Branching' an SRS for a new phase?

Hi - Our projects will often move from an initial implementation project (R1) to subsequent implementation phases (R2+). Our approach is to build on the initial spec for the new phase i.e. rather than a standalone spec. Prior to using Doors, teams would copy the R1 spec to 'branch' it for R2 - R2 then gets its new reqmts as well as needing to take in (retrofit) any R1 changes that happen in parallel. While more effort, this has the advantage of R1 and R2 not making conflicting changes in common areas of functionality, as well as having a 'total spec' in place post R2.

In Doors, we could replicate this approach, but this still means the effort of retrofitting, and the retrofitted reqmts ending up with different ids. There are probably better ways to do this in Doors e.g. in a single doc with R2 reqmts tagged (so that you can output an R1- or R2-only spec by filtering on those tags). However the main challenge I see with something like that is that you can't then baseline R1 or R2 independently as they are a single module in Doors.

This is in essence a common project/IT scenario and I'm wondering how other people handle it in Doors, or indeed if people have other ideas from a more general process perspective.

Kieran
kierant - Fri Aug 21 11:19:24 EDT 2009

Re: 'Branching' an SRS for a new phase?
SystemAdmin - Fri Aug 21 12:31:24 EDT 2009

Hi Kieran,

This is an interesting question and I'm glad you asked it. You're right that this can be accomplished with multi-value attributes, and that's the method I've seen most often. It can also be done by copying a module, maintaining a parallel version, and then manually merging the changes later - though this can be tedious when you're dealing with a huge number of requirements.

A few years ago Telelogic Italy developed an elegant Branch/Merge capability for a complex systems customer. It's since evolved into a more generic add-on that' pretty easy to use, but it's not a regular tool you can download. It has to be purchased through Rational Professional Services. If that's an option you think would be worth pursuing, try getting in touch with your IBM sales rep. I'm not sure how widely known add-on is. If the rep doesn't know anything about it feel free to send me a message and I'll get you in touch with the right people.

Re: 'Branching' an SRS for a new phase?
abrosnan - Mon Dec 07 22:52:42 EST 2009

SystemAdmin - Fri Aug 21 12:31:24 EDT 2009
Hi Kieran,

This is an interesting question and I'm glad you asked it. You're right that this can be accomplished with multi-value attributes, and that's the method I've seen most often. It can also be done by copying a module, maintaining a parallel version, and then manually merging the changes later - though this can be tedious when you're dealing with a huge number of requirements.

A few years ago Telelogic Italy developed an elegant Branch/Merge capability for a complex systems customer. It's since evolved into a more generic add-on that' pretty easy to use, but it's not a regular tool you can download. It has to be purchased through Rational Professional Services. If that's an option you think would be worth pursuing, try getting in touch with your IBM sales rep. I'm not sure how widely known add-on is. If the rep doesn't know anything about it feel free to send me a message and I'll get you in touch with the right people.

Hi Justin

I am very interested in the Branch/Merge addin tool produced by the Italians. Can you please provide more information on the tool and possible an IBM contact in Italy that can provide more information of this tool. The company I work for is looking to see if there is a tool that will allow requirements branching and merging in DOORS. My concern is that if this tool exists that this has not been communicated within IBM Internationall as IBM Australia does not know that it exists.

Cheers

Andre Brosnan

Re: 'Branching' an SRS for a new phase?
kierant - Tue Dec 08 05:34:51 EST 2009

abrosnan - Mon Dec 07 22:52:42 EST 2009
Hi Justin

I am very interested in the Branch/Merge addin tool produced by the Italians. Can you please provide more information on the tool and possible an IBM contact in Italy that can provide more information of this tool. The company I work for is looking to see if there is a tool that will allow requirements branching and merging in DOORS. My concern is that if this tool exists that this has not been communicated within IBM Internationall as IBM Australia does not know that it exists.

Cheers

Andre Brosnan

Hi Andre - Since originally posting we built a home-grown solution as follows, in case you are interested. It is based on the separate docs scenario (for baselining reasons, as outlined) and uses a simple approach of reserving a number range to contend with the IDs problem mentioned (i.e. to ensure that an object retrofitted from R1 to R2 retains the same ID).

There are two steps/scripts, attached:
1. Reserve a set of object IDs. At point of branching, R2 should run this script to set aside (via create and delete) nominal range of 1000 object IDs.
2. As new objects are added to R1, the retrofit script can be run to copy over created objects (to those IDs set aside in step 1) and put them in position. It won't retrofit modifications, as the same object may also have been modified in R1, hence it just marks up changes for manual working instead.

It's a fairly simplistic solution with obvious constraints (e.g. 1000 object ceiling, cannot execute a purge in R2) and has some tailorings for out configuration (e.g. intended to be run from a view that summarises changes in a particular R1 version, and driven off an attribute called 'change indicator' also attached), so it won't be as sophisticated as IBM PS one mentioned. Also, the scripts were built off some of the libarary scripts Doors provides but, given my rudimentary DXL skills, I'm sure this could be done better. However, feel free to use/adapt if you wish (or contact me via profile if you would like to discuss further offline).

Kieran
Attachments

attachment_14414856_retrofitting_utils.zip