It's all about the answers!

Ask a question

Some general usage questions


David Davies (20612713) | asked Jan 21 '10, 5:02 p.m.
Hi there

We have been using RTC for around a year now and I am trying to persuade some of our analysts to give RRC a try.

I'd just like to check my understanding of how the two can be used together before I face them...........

Requirements are created in RRC including user stories. You place a set of requirements into a collection which will allow for user signoffs. This collection is then visible within RTC and I can add RTC stories to a Release Backlog plan referencing the stories within RRC. The developers can then add their own tasks and estimates etc and plan as normal.

Does that sound about right?

I know one of the questions will be what happens if one of the RRC stories changes. Will the owner of the task in RTC be aware of the change?

I would be grateful of any real world examples of how to use the two products.

Many thanks

David

4 answers



permanent link
Robin Bater (3.4k47) | answered Jan 21 '10, 5:47 p.m.
JAZZ DEVELOPER
Hi David,

I would like to point you to my recent Jazz.net blog

http://jazz.net/blog/index.php/2010/01/20/using-rrc-2-in-a-calm-solution/

that might help you with the situation you describe.

Also towards the end of video it talks about C/ALM web viewlet mashup where you can show various information from both tools, and one of the viewlets is recent requirement changes. So a developer can put this viewlet on their web mashup and see recent changes.

I hope this helps

permanent link
David Davies (20612713) | answered Jan 22 '10, 6:56 p.m.
Hi Robin

I had seen that video and it certainly helped to see how they hang together.

I am still curious as to how a change in a requirement is shown up in the other tools. ie will a developer assigned to a task that is using an RRC storey by notified that it has changed and will need to be look at again. SImilar question for invalidating a test script? We used to get this when integrating requisitepro with mercury test director.

Many thanks

David

Hi David,

I would like to point you to my recent Jazz.net blog

http://jazz.net/blog/index.php/2010/01/20/using-rrc-2-in-a-calm-solution/

that might help you with the situation you describe.

Also towards the end of video it talks about C/ALM web viewlet mashup where you can show various information from both tools, and one of the viewlets is recent requirement changes. So a developer can put this viewlet on their web mashup and see recent changes.

I hope this helps

permanent link
Robin Bater (3.4k47) | answered Feb 03 '10, 10:49 a.m.
JAZZ DEVELOPER
Hi David,

At the moment the notification only shows there has been a change in the requirement, via recent requirement view (rich or web client), not its impact on those dependent artifacts.

Now one of the new features we introduced in RRC V2, was Review and Approval, with collections and project snapshots. This changes the dynamic slightly because, if you perform a formal review, gain approval and create a new collection, the particular version of those approved requirement artifacts is stored in the collection. So when we map this collection to a test plan or iteration plan for implementation, even if the requirement artifact changes only that approved version is accessible from the work item - Note: All revisions of a requirement artifact are stored and are accessible via the artifact history.

New work items would need to be created for the updated requirements. This ensures that development and test teams are only working on approved requirements, and do not make a change mid-stream in an iteration. So analysts can work on the next iteration of requirement artifacts without worrying about mid-stream impact on the development and test team.

permanent link
David Moss (171156) | answered Apr 06 '10, 4:46 p.m.

Now one of the new features we introduced in RRC V2, was Review and Approval, with collections and project snapshots. This changes the dynamic slightly because, if you perform a formal review, gain approval and create a new collection, the particular version of those approved requirement artifacts is stored in the collection. So when we map this collection to a test plan or iteration plan for implementation, even if the requirement artifact changes only that approved version is accessible from the work item - Note: All revisions of a requirement artifact are stored and are accessible via the artifact history.

New work items would need to be created for the updated requirements. This ensures that development and test teams are only working on approved requirements, and do not make a change mid-stream in an iteration. So analysts can work on the next iteration of requirement artifacts without worrying about mid-stream impact on the development and test team.


How would you handle the following situation, using the features you describe:

Analyst finishes work on Artifact A, version 1. This "version" of the artifact (I'll call it Av1) will be the one the analyst wants reviewed. The analyst moves on to Artifact B, and begins work. A few days later, Bv1 is also ready to be reviewed.

Meanwhile, a few days pass but the third artifact that is to be part of the collection, Artifact C, is still not complete. A second analyst begins work on "C".

At this point, management is ready to plan out another enhancement to the product. The analysts will put the updated artifacts into a second collection. Both Artifacts A and B will be changed for this new enhancement.

What now? The first analyst is ready to begin modifications on Av1 and Bv1 to bring them up to Av2 and Bv2, but they can't because C is not complete. If a snapshot is to be taken and the first collection pointed at that snapshot, C will not be ready within that point in time snapshot. If a collection of live artifacts is used, then the "intended for v1" collection will end up with v2 changes in it.

We have talked about trying to leverage artifact histories and snapshots--restore all of the proper "historical versions" of an artifact, create a snapshot, point the "intended for v1" collection to that snapshot, then restore what was the most recent version of each artifact and continue working in "live" mode on the next collection. (Hopefully that makes sense).

The problem is that solution does not scale well at all when you will need more than a couple of items in a collection (lots of manual work and risk for error). We also see risk in a multi-user environment where a user may inadvertently see the "old restored version" of an artifact while an analyst is going through everything to prepare for the snapshot. Finally...because historical records of an artifact are created with each save, a diligent user who saves their work often will be creating a massive amount of historical records to guess at when trying to go back and find the "right one" to restore. There is no feature to compare historical records (I see work item 21092 isn't even on the radar yet).

Thoughts or suggestions?

Your answer


Register or to post your answer.