I got the same feature request from a customer as well.

Hi Tony,

I believe the need that you describe can be addressed in a couple of different ways, but I'd like to ensure that I understand your solution constraints before recommending a configuration. Could you please answer the following questions?


1. If a requirement is contained in a software-project project and the same requirement is to be used for a software-product project, will the requirement be the same, as it is represented in both projects?

2. By REQ, do you mean RequisitePro, or do you mean a project that holds requirements for a specific product, without regard to the tool in which the requirement is stored?

3. What tool are you using to manage your requirements today?

Dwayne

Can one RRC project be linked with multi REQ projects?

The scenario is:

1) use RRC to manage software-project requirements;
2) use REQ to manage software-product requirements;
3) because one software-project can modify many software-products;
4) so the requirements in one RRC project belongs to different software-products should be synchronized to differenct REQ projects;

RRC should have such feature if it hasn't, because many times clients ask for this 2 level requirement management.

Thanks

Tony

Hi Tony, Thanks for clarifying your scenario.

Where RRC is used with ReqPro, one requirement can be synchronized with one ReqPro project. To achieve your need to reuse requirements from software-project projects in multiple software-product projects, I recommend that you reuse the requirements in your software-project projects by reference. So instead of copying a requirement into multiple projects, you would be referencing the requirement, which is contained in a single project, from multiple projects.

This reuse-by-reference scenario can be achieved in both RRC and ReqPro, though it is easier to implement in RRC. For instance, you may have a list of requirements in Sofware-Project-Project-A (RRC-Software-A) that need to be reused in Software-Product-Project-1 (RRC-Product-1) and Software-Product-Project-2 (RRC-Product-2). You can simply create documents in Product-1 and Product-2 that contain either links or live embeds of to requirements in RRC-Software-A (in addition to the requiremnts that are unique to RRC-Product-1 and RRC-Product-2.

I know, I should have supplied a picture with this :-)

On the ReqPro side, you could have projects that correspond to your RRC projects. To create documents that bring all of the requirements of ReqPro-Product-1 and ReqPro-Product-2 together in a single document, you would use SoDA or Rational Publishing Engine to generate the documents from requirements in the database.

In the aforementioned scenarios, ReqPro and RRC have separate repositories, where the requirements are synchronized between projects in the ReqPro and RRC repositories, respectively. Over the next year, we are working to bring ReqPro function (and more) onto the RRC server architecture. In that scenario, you would have three projects, as opposed to six, there would be no synchronization, and reuse of requirements for software-project projects and software-product products will be greatly simplified. You scenario exemplifies some of the greatest advantages we seek to achieve by moving ReqPro onto Jazz.

I hope this makes sense without pictures... even if you have to read it two or three times :-)

Dwayne

Hi Tony,

It's attractive to transfer ReqPro features to RRC, I guess the functions transfered that have high priority should be 1) manage requirement traceability; 2) integration with CQ(currently), right?

The short answer to your question is "yes". Perhaps I should say a little more about this process of ReqPro coming onto the Jazz platform with RRC.

You will see some of these capabilities in RRC 2.0. For instance, traceability between RRC requirements, RTC plans and work items, and RQM plans tests will be conveniently achievable. You will be able to make these connections between requirements and their other lifecycle artifact counterparts and see, for instance, what tests are associated with a requirement via dashboards provided by the respective tools. For many teams, this level of traceability is enough. Others need a finer level of specificity in their traceability relationships, and they need views to show those variations in specificity. For this level of traceability specificity, ReqPro is needed. In a future release (beyond 2.0), you will also see this level of control supported directly on the Jazz platform, as you implied in your response.

It would be great input to us if you would be willing to tell us more about the way that you use traceability to help you manage the application lifecycle.

Regards,

Dwayne