Organizing Requirements

Owned by Deepak Jangid (Deactivated)
Jun 12, 2019
2 min read

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.
  • A requirement turning into a Container 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 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


  • 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.