Hi All, Rational Quality Manager V2.0X implemented Requirements as a variant of Work Items. As such there were limits to what you can do with them. We hope that RQM 3.X will have a robust Requirement artifact with more flexibility to add attributes, create hierarchies, etc.

DOORS is designed to collect a wide variety of information, not just a generic "requirement". The objects in DOORS modules allow on-the-fly definition of attributes and attribute types (so you can create enum lists, etc). It allows you to separate attrs in one DOORS module from another. So in 1 DOORS module you can have "priority", "comments", "release", "estimated cost", etc. In a separate DOORS module you could have "expected results", "actual results".

Further, DOORS is designed to create links via drag and drop and then 1) present the complete chain of those links from one end to the other in one dynamic view 2) give you alerts if something you depend upon has changed and 3) allow you to ask "what would be affected if I change this requirement/spec/value?
Further, Business People (not necessarily testers or dev) feel at home in the DOORS client since it's designed with Windows and MS/Office look and feel. So startup is faster and easier. Then if you need graphics or OLE embedded stuff, it appears in-line with the rest of the DOORS content.

One clarification:
In RQM 3.0.1, the requirements capabilities are provided by the same RM
application that provides the requirements capabilities for RRC 3.0.1.
In addition, RQM 3.0.1 provides integrations with both DOORS and ReqPro
(see the on-line help sections in the "Integrating" topic, in
particular, the section named "Rational Quality Manager and Rational
DOORS" and the section named "Integrating with Rational Requisite Pro"
(we should probably get the doc folks to be more consistent in their
section naming conventions :-).

Cheers,
Geoff

On 7/8/2011 4:23 PM, dano wrote:

Hi All, Rational Quality Manager V2.0X implemented Requirements as a
variant of Work Items. As such there were limits to what you can do
with them. We hope that RQM 3.X will have a robust Requirement
artifact with more flexibility to add attributes, create hierarchies,
etc.

DOORS is designed to collect a wide variety of information, not just a
generic "requirement". The objects in DOORS modules allow
on-the-fly definition of attributes and attribute types (so you can
create enum lists, etc). It allows you to separate attrs in one DOORS
module from another. So in 1 DOORS module you can have
"priority", "comments", "release",
"estimated cost", etc. In a separate DOORS module you could
have "expected results", "actual results".

Further, DOORS is designed to create links via drag and drop and then
1) present the complete chain of those links from one end to the
other in one dynamic view 2) give you alerts if something you depend
upon has changed and 3) allow you to ask "what would be affected
if I change this requirement/spec/value?
Further, Business People (not necessarily testers or dev) feel at home
in the DOORS client since it's designed with Windows and MS/Office
look and feel. So startup is faster and easier. Then if you need
graphics or OLE embedded stuff, it appears in-line with the rest of
the DOORS content.