Organizing Requirements

Owned by Sanjay Sahani
Last updated: Aug 18, 2018
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 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:

  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.