It's all about the answers!

Ask a question

Managing versions and branching requirements in RRC


Brad Middleton (6911010) | asked Aug 19 '11, 10:58 a.m.
JAZZ DEVELOPER
Has anyone thought about how you manage versions and branching of requirements in RRC v3?

Reason: A number of customer are asking about this ability to version control and branch requirements, when they are working on multiple release dates and sometimes the requirement affects multiple releases.

I'm working with a few scenarios:

1. Using Formal Reviews and checking the specific review
2. Embedding a copy of the specific version into a containing artefact.
3. Producing PDF versions (which is not a good workaround)

One answer



permanent link
Brad Middleton (6911010) | answered Sep 01 '11, 7:10 a.m.
JAZZ DEVELOPER
There's a related forum entry which discusses some of this:

http://jazz.net/forums/viewtopic.php?p=61490#61490 and quotes
"As others have stated, the CLM solution does not yet have true support for versioned linking. IMO, the best way to achieve what you desire is to keep separate collections and copies of the requirements for each version you need "frozen". You can use attributes and links on the requirements to relate the copies to each other so that you can identify and trace their lineage. Although copies are not ideal, they allow the type of linking and evolution that you desire. "


Another idea was to:


    1) I would keep everything in one document.
    2) So I would have a main document describing the requirement.
    3) Then I would create sub-items stating what is being considered/implemented in a particular phase/release
    4) and what is implemented in another release.
    5) These as suggested should be children of the main document as a separate artifact so that it can be individually linked.
    6) So each particular implementation of the requirement can be linked to it's own workitem/tasks for implementation and testcases.
    7) Interested parties of the requirement can then look at the document and understand what is being implement in all the releases and how changes will impact the different implementations


My approach would be to have a parent/child relationship. The parent is the requirement and the first child is the first version. That way a test case can be linked to the parent and first version while second version of the requirement is being developed for a future release. This will allowing for parallel working.


http://dl.dropbox.com/u/2677078/RRC/version_control_using_requirement_copy_and_linking_rrc_v3.jpg

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.