Organizing Requirements

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

A Container:

• 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 container's 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 container's.

In the current implementation, there are constraints, like:

• committed or versioned Requirements cannot be converted to Containers.

Selecting Containers and Children

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

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

1. Mark for Baseline
2. UnMark
3. Link to Baseline
4. Unlink from Baseline
5. Create Baseline
6. Commit Version(s)
7. Create Version(s)
8. Uncommit Version(s)
9. Move to Unplanned

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.