In reference to the questions in this post I am starting a new thread, since this topic is of interest to a wider group.

RRC and DOORS are two (mostly) separate requirements management solutions offered by IBM Rational. They serve different kinds of project/program teams. RRC's strengths lay in helping teams and stakeholders collaborate on requirements and undergo a "journey of discovery" through an iterative/agile development process with automated traceability to development and test activities as part of the Rational solution for Collaborative Lifecycle Management.

DOORS on the other hand excels in complex and high-compliance projects/programs where specifications drive development, contracts often mediate relationships among members of a supply chain, and compliance reporting is a "key competency" of high-performance project teams. DOORS is often used in a solution with Rational Rhapsody, MathWorks Simulink, Product Lifecycle Management vendors, etc. DOORS has a very powerful scripting language that enables requirements engineers to do amazing kinds of analysis, customization, and reporting.

RRC is used mostly in software / IT projects; DOORS is most often used in systems projects involving mechanical, electrical and software aspects.

DOORS participates in solutions involving Change Management (ClearQuest, RTC, Change) using Open Services for Lifecycle Collaboration (OSLC). Quality Management integrations exist with RQM and HP QC. Model based systems engineering is often part of the methodology used by teams employing DOORS. That said, I should point out that many IT shops working in high-compliance environments use DOORS for the reasons summarized above.

Publicly we have demonstrated early code from the development labs showing DOORS and RRC using the same requirements server running in a Jazz Team Server and operating on the same data. Using this approach, over time we expect to enable enterprise-level multi-product co-existence scenarios, modernize DOORS, and gain some development efficiencies of our own.

However we don't believe one RM tool can be optimized to the needs of all types of project/program teams and project methodologies, and we intend to continue developing two RM products with differing audiences in mind.

I haven't mentioned RequisitePro yet in this post, because Requirements Composer is becoming the next-generation ReqPro. You can read more about that in this blog post:

http://jazz.net/blog/index.php/2010/12/10/requirements-composer-beta-2a-big-step-forward/


Hope all this helps.