Requirements Change Management with RRC?
We have an environment with RTC and RRC and are trying to define a use model for deal with requirements change.
We are using the work item type "Change Request" to map any necessary changes in the requirements. Our idea was to associate each CR with the affected set of requirements so that the development team can view what changes need to be implemented. But we have found many obstacles to do so.
We tried to create alternatives using Formal Reviews, Artefact history and Collections, but we have not reached a solution.
Does anyone have any idea how to do this?
Our difficulty is the most basic possible, given a change to a requirement how the developement team knows exactly what they have to implement?
We are using the work item type "Change Request" to map any necessary changes in the requirements. Our idea was to associate each CR with the affected set of requirements so that the development team can view what changes need to be implemented. But we have found many obstacles to do so.
We tried to create alternatives using Formal Reviews, Artefact history and Collections, but we have not reached a solution.
Does anyone have any idea how to do this?
Our difficulty is the most basic possible, given a change to a requirement how the developement team knows exactly what they have to implement?
2 answers
Part of the problem of mapping a work item to a requirement is being able to address the specific requirement revision. If it is always the latest then it is fine as the linking from the work item to the requirement will work whether it is part of a formal review or a collection.
So how do you reference a specific version (revision) - here are some ideas that might help.
1. For every milestone/iteration copy the requirements that will be changed by the request so that development can reference a specific revision copy - the copy of the requirements can be identified either via attributes or a collection name, and with maybe a link back to the original.
2. Alternatively from the artifact history copy the URL that contains the #revision extension at the end of the URL address and paste into a rich text document as a hyperlink. This rich text artifact could represents the requirements for a release or milestone, similar to a vision document. The change requests would be made to the document.
3. Again from the artifact history use the revision URL but paste it explicitly in the change request rather than using the OSLC linking capability.
Now in regards to the future there is a concept called VVC that is being looked at that should help:
https://jazz.net/rm/resources/_oAktwNvCEeGAVYhYLFXCkg
So how do you reference a specific version (revision) - here are some ideas that might help.
1. For every milestone/iteration copy the requirements that will be changed by the request so that development can reference a specific revision copy - the copy of the requirements can be identified either via attributes or a collection name, and with maybe a link back to the original.
2. Alternatively from the artifact history copy the URL that contains the #revision extension at the end of the URL address and paste into a rich text document as a hyperlink. This rich text artifact could represents the requirements for a release or milestone, similar to a vision document. The change requests would be made to the document.
3. Again from the artifact history use the revision URL but paste it explicitly in the change request rather than using the OSLC linking capability.
Now in regards to the future there is a concept called VVC that is being looked at that should help:
https://jazz.net/rm/resources/_oAktwNvCEeGAVYhYLFXCkg
Here's another, simpler approach (if you are using RRC v4): you can move the requirements to a read-only folder when they are finished/approved. Then you have a controlled set of the "final" requirements for release 1. Then for the next release you would copy the requirements that you want to use again (or evolve) -- with or without copying their links at the same time, depending on your process and needs.
This approach has some advantages:
This approach has some advantages:
- It's easy to explain
- All required actions are done through "normal" user interface activities
-
Links between requirements and work items "just work" -- no special considerations required (except when deciding to copy the artifacts for release 2)