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