It's all about the answers!

Ask a question

The basic concept of RRC

Yuji Araki (524) | asked Dec 04 '13, 5:03 a.m.
 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.

Ralph Schoon commented Dec 04 '13, 6:16 a.m.

Have you looked at and especially the features and their explanation on that page below the video?

Ralph Schoon commented Dec 04 '13, 6:20 a.m.

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:

Accepted answer

permanent link
Daniel Moul (4.9k1318) | answered Dec 04 '13, 8:26 a.m.
There are two common implementation patterns today:
  1. Emulate branching into a new stream by copying artifacts that need to evolve separately.  
  2. If there are not a lot of projects or product variants making changes at the same time, teams will use attributes to indicate which project or variant a particular requirement is for, or they will use meta-notations in the requirements themselves to indicate this.

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

Yuji Araki selected this answer as the correct answer

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.