In RMsis, Requirements can exist only at the leaf level. However, when a Requirement is Indented, the previous requirement becomes it's Parent.

A Parent:

signifies a collection of Requirements.
currently does not support versions.
does not possess many of the Attributes specific to Requirements.
can have dependencies and links, but may not reflect the same at the (child) Requirement level.
does not have any dependency relationships with its child requirement, nested parents.

A child / leaf level Requirement

does not inherit any of it's parents attributes, dependencies and links.
does not have any dependency relationships with its ancestors.
the attributes, dependencies and links of children are not aggregated with it's parent's.

In the current implementation, there are constraints, like:

committed or versioned Requirements cannot be converted to Parents / Containers.

A requirement turning into a Parent is counter-intuitive to the user and hence an alert is given at this point of time.
Internally, this issue is being taken up at high priority. However, the time to resolution may be significant.
Meanwhile users are advised to predefine a hierarchy for the Requirements and then insert Requirements as leaves within this structure.

Selecting Parents and Children

Context menu options "Select Children in Filter/ Deselct Children" can be used to select/ deselect children of a parent.

Since the following operations do not work on parents, warning will be shown for these operations, whenever parent is also selected:

Mark for Baseline
UnMark
Link to Baseline
Unlink from Baseline
Create Baseline
Commit Version(s)
Create Version(s)
Uncommit Version(s)
Move to Unplanned

Context menu operates only on a single row of the table.

Classifying Requirements

With the introduction of Hierarchical Tags in Custom Fields, it is now possible to tag Requirements with Hierarchical Labels, while maintaining a flat Requirement Structure.

Browser not supported