Parallel Development with Requirements Composer
4 answers
There are two options:
1. Use RRC snapshots and collections to define a set of artifacts at specific version levels for a particular sprint/iteration/release
2. Make a copy of the set of requirements for a particular sprint/iteration/release
By searching you can probably find some past discussion of these approaches in this forum (and maybe also in the Workbench for CLM forum).
1. Use RRC snapshots and collections to define a set of artifacts at specific version levels for a particular sprint/iteration/release
2. Make a copy of the set of requirements for a particular sprint/iteration/release
By searching you can probably find some past discussion of these approaches in this forum (and maybe also in the Workbench for CLM forum).
There are two options:
1. Use RRC snapshots and collections to define a set of artifacts at specific version levels for a particular sprint/iteration/release
2. Make a copy of the set of requirements for a particular sprint/iteration/release
By searching you can probably find some past discussion of these approaches in this forum (and maybe also in the Workbench for CLM forum).
Daniel,
Thanks for your answer, considering I'll be using the first approach. How would be the requirements content integration when the release is finished? Is there any diff/merge function that could help me doing this? Or would it should be done manually?
Thank you,
Paulo
Thanks for your answer, considering I'll be using the first approach. How would be the requirements content integration when the release is finished? Is there any diff/merge function that could help me doing this? Or would it should be done manually?
At this point both diff and merge have to be done manually, or diff can be done by generating reports from collections in Word format and comparing the reports to see the differences in Word. Not ideal, not where we want to get to, but where we are for now.
The other thing worth noting is that CLM links in the V3 era do not contain artifact revision information, so if a developer needs to see a particular revision, he/she needs to follow the link to the RRC artifact, open the relevant collection (its reference can be found in the sidebar), and apply the right snapshot. Similar process for testers using RQM. It's these limitations that lead some people to option (2) above.