The basic concept of RRC
![]()
I'd like to understand the basic concept of Rational Requirement Composer.
We can manage our requirement documents on RRC, but I have some concerns about the long-term management of the documents. RRC provides a basic version control feature of the document but it's not enough to manage the chenge sets from the different project to the same system.
Which is the closest to the basic concept of RRC? I'd like to make the requirement development/design/development processes to fit well to the concept of RRC
1. Requirement documents are made for the specific project. Once the requirement had been implemented, requirements would be freezed and archived. If we needed to manage some design documents during the life cycle of the system, documents should be managed on RTC or other configuration management system.
2. Requirement documents are made for the specific system. Documents would be maintained during the life cycle of the system. When we had multiple projects for the same system, we should manage change sets to the same requirement document by using the version control and comment feature of RRC.
|
Accepted answer
![]()
There are two common implementation patterns today:
Requirement change sets, configurations, version control ... we have significant work underway in these areas [1], but in the generally available products today, these capabilities are embryonic. We expect to have more to say and more to show in the new year.
[1] See the RM-VVC plans in the RRC / DOORS NG work item system here on Jazz.net.
Yuji Araki selected this answer as the correct answer
|
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.
Comments
Have you looked at https://jazz.net/products/rational-requirements-composer/ and especially the features and their explanation on that page below the video?
Your question is probably hard to answer. You can map an RRC project to a project or to a complex system. You can baseline requirements. Note, requirements are not a document. On the other hand, if you look for developing for complex systems,you should consider Doors Next, as that is supposed to have richer features you would probably like to have for complex systems development: https://jazz.net/products/rational-doors