Organizing Requirements

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

When a user clicks on the LHS checkbox, the following dropdown appears, which enables the user to select

parent only
children only
or both.

Since the following operations are not selected, warning will be shown for these operations, whenever parent is also selected:

Mark for Baseline
UnMark
Commit Version(s)
Create Version(s)

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.