About Sub Requirements and Downstream Requirements

Sub requirements and downstream requirements exist in the context of another requirement or a specification. A sub requirement elaborates on some aspect of the original requirement, but does not provide any new information. A downstream requirement provides new information about the original requirement. Downstream requirements can be either covering requirements or refining requirements. This topic describes:

This page discusses:

See Also
Creating a New Sub Requirement
Adding an Existing Requirement as a Sub Requirement
Running the Downstream Requirements Report
Editing the Status of Links to Downstream Requirements
Editing the Status of Links to Sub Requirements
Removing or Deleting Sub Requirements

Downstream Requirements

You can decompose high-level requirements into individual detailed low-level requirements so that they can be partitioned and allocated to products and features. Downstream requirements allow you to decompose requirements into the necessary levels of detail while retaining complete traceability among the various levels. High-level requirements that are refined into low-level requirements are called covered requirements. A covered requirement might be expressed at the customer level and will be satisfied by lower-level requirements, perhaps at the system and sub-system levels, for example. The lower-level requirements are called refining requirements since they provide additional information about the higher-level, covered requirement.

Sub Requirements

Sub requirements are simple child objects of the parent requirement. They have no covering or refining relationship with the parent requirement.

Parenthood Link Status

It is important to be able to quickly determine the validity of the links between a parent requirement and all of its child sub requirements. Since there can be several sub requirements, each with its own link to the parent requirement, Traceable Requirements Management shows you the worst link status between a parent requirement and all of its sub requirements in the requirements list and on the requirement page. You can view the Overview Page for the specific requirement to see the parenthood link statuses for all sub requirements and downstream requirements. The possible parenthood link statuses for sub requirements are:

  • Valid: This sub requirement adheres to all rules. Green is used to represent a valid link status.
  • Suspect: This sub requirement needs additional work. Yellow is used to represent a suspect link status.
  • Invalid: This sub requirement is invalid and cannot be used. Red is used to represent an invalid link status.

You can quickly determine the status of the parent relationship between a sub requirement and its parent requirement by looking at the color of the sub requirement's 'From' link () in the Parenthood Status column of any page that lists sub requirements. You can edit this link status inline on the requirement page or the specification page.

You can work with the status of the link between a specific downstream requirement and its parent requirement on the downstream requirements report.