It's all about the answers!

Ask a question

"Frozen" artifacts for releases


0
1
Brian Ronan (211010) | asked Nov 14 '11, 2:29 p.m.
I am currently working in RRC 3.0.1 sandbox, and am wondering if there is a way to "freeze" artifacts in the state they were reviewed in when moving forward to RTC and RQM. The process we use today currently uses MS Word documents to track requirements, flows, etc with tracked changes to let us know which "version" of the requirements were signed-off on due to which release.

Example: We have Unit of Work that will be a part of release 3.2 that went through analysis and was reviewed and is now moving on to development. A different Unit of Work, UoW will be a part of release 3.2.1 and is going through analysis but will reuse or modify some of the requirements from UoW , is there a way to preserve the state that the requirements were in in UoW from the changes that will be made to them in UoW ?

Thank you for any input/advice on this matter,

Brian Ronan
Business Analyst
Accenture

2 answers



permanent link
Chris Horning (2711) | answered Nov 29 '11, 10:17 a.m.
JAZZ DEVELOPER
I am currently working in RRC 3.0.1 sandbox, and am wondering if there is a way to "freeze" artifacts in the state they were reviewed in when moving forward to RTC and RQM. The process we use today currently uses MS Word documents to track requirements, flows, etc with tracked changes to let us know which "version" of the requirements were signed-off on due to which release.

Example: We have Unit of Work that will be a part of release 3.2 that went through analysis and was reviewed and is now moving on to development. A different Unit of Work, UoW will be a part of release 3.2.1 and is going through analysis but will reuse or modify some of the requirements from UoW , is there a way to preserve the state that the requirements were in in UoW from the changes that will be made to them in UoW ?

Thank you for any input/advice on this matter,

Brian Ronan
Business Analyst
Accenture


Hi Brian

In 3.0.1 project snapshots would allow you to "freeze" artifacts in a state and prevent modification. As far as the sandbox, you'd need specific privileges to create snapshots. Formal reviews can also be used - these point to a specific revision.

permanent link
Jared Pulham (32113) | answered Dec 01 '11, 8:47 a.m.
JAZZ DEVELOPER
I am currently working in RRC 3.0.1 sandbox, and am wondering if there is a way to "freeze" artifacts in the state they were reviewed in when moving forward to RTC and RQM. The process we use today currently uses MS Word documents to track requirements, flows, etc with tracked changes to let us know which "version" of the requirements were signed-off on due to which release.

Example: We have Unit of Work that will be a part of release 3.2 that went through analysis and was reviewed and is now moving on to development. A different Unit of Work, UoW will be a part of release 3.2.1 and is going through analysis but will reuse or modify some of the requirements from UoW , is there a way to preserve the state that the requirements were in in UoW from the changes that will be made to them in UoW ?

Thank you for any input/advice on this matter,

Brian Ronan
Business Analyst
Accenture


Hi Brian

In 3.0.1 project snapshots would allow you to "freeze" artifacts in a state and prevent modification. As far as the sandbox, you'd need specific privileges to create snapshots. Formal reviews can also be used - these point to a specific revision.

For RRC 3.0.1.x the snapshot method or an export offline copy method would be the best ways to freeze a copy of your requirements at a particular point in time. As we move forward into 2012 we are working on providing more granular access rights for artifacts that would allow you to control the write ability for users/groups in your project. So there are other methods coming in the near term. Please see the RRC 2012 release plan here on jazz.net fore more details.

Jared Pulham
RRC Product Manager

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.