Requirement Properties

To view or edit a requirement's properties, double-click its Browser or list entry. The property sheet tabs and fields listed here are those available by default, before any customization of the interface by you or an administrator.

The General tab contains the following properties:

Property

Description

Parent

[read-only] Displays the name of the parent requirement. For top-level requirements this is the model name.

Title ID

[read-only] Displays the number expressing the place of the requirement in the requirements hierarchy. For example: 1.3.2.

Title

Specifies the name of the requirement.

Code

Generates a unique code for the requirement. You can override an individual requirement code by typing directly in this field. You can also modify the template used to generate the codes (see Customizing Requirement Codes).

Description

Specifies a detailed description of the requirement. This field is also available on (and synchronized with) the Notes tab.

Keywords

Provide a way of loosely grouping objects through tagging. To enter multiple keywords, separate them with commas.

The Detail tab contains the following properties:

Property

Description

Comment

Provides space for any comment on the requirement.

Stereotype

Extends the semantics of the object. You can enter a stereotype directly in this field, or add stereotypes to the list by specifying them in an extension file.

Type

Specifies the type of the requirement, as viewed from the process point of view. You can specify your own types (see Customizing a List of Values).

Status

Specifies the present validation status for the requirement. You can specify your own status levels (see Customizing a List of Values).

If you change the status of a requirement containing sub-requirements, a message is displayed warning that the change will be propagated to all its sub-requirements. If you change the status of a sub-requirement, it may change the status of its parent requirement, which can only have the lowest status held by any of its sub-requirements.

Priority

Specifies the priority level attached to the requirement. Select a value in the list or type a value. The value cannot be null or negative, and is limited to one decimal (for example: 1.9).

Selected

Specifies that the requirement has been selected to be implemented in the project. If this checkbox is cleared, the requirement is excluded from the project and the sum of workloads.

Risk

Specifies the level of risk associated with implementing the requirement. You can specify your own risk levels (see Customizing a List of Values).

Verification

Specifies the type of testing to be applied to the development of the requirement. You can specify your own verification types (see Customizing a List of Values).

Workload 1-4

Specifies the workloads assigned to four individuals or groups (see Assigning Workloads). Workloads for requirements with sub-requirements are read-only fields calculated as the sums of all sub-requirement workloads.

The following tabs are also available:
  • Requirement Traceability Links - Lists links to design objects, other requirements, and external files (see Linking Requirements with Design Objects and External Files).

  • Related Glossary Terms - Lists terms attached to the requirement (see Glossary Terms (RQM - Deprecated)).
    Note: The RQM glossary terms are deprecated and are replaced by the enterprise glossary model (see Core Features Guide > Administering PowerDesigner > Deploying an Enterprise Glossary and Library).
  • User Allocations - Lists the users and groups attached to the requirement (see Users and Groups (RQM)).