# Requirements Management

## Key Features

Requirements Management defines and manages the first structured description of the product and ensures that all design modifications fulfill the original product requirements as expected by the customer.

Creating the Requirement Hierarchy:
A requirements hierarchy consists of the following types of requirements:

- Base Requirement
- Structure Requirement
- Text Requirement

To be able to create a hierarchy with structure or text requirements, the user needs to have write access for the parent element!

### Base Requirement ()

A base requirement is the root element for a requirements hierarchy. A base requirement depicts the collector for all other requirements referring to the product to be developed or changed, or components of it. The base requirement can have describing documents assigned and any number of structure and text requirements. Base Requirements are always assigned to a project.
It is not permitted to drag&drop a Base Requirement in the sub-list of any requirement, nor to select a Base Requirement in the select widget of any other "Structure" sub-list.

### Structured Requirement ()

A structure requirement is the link to other structure or text requirements at subordinate levels of the specification hierarchy. It acts like a chapter for requirements with similar contents. The structure requirement can have describing documents and several structure and text requirements assigned.
For an existing base requirement or structure requirement, the sub-list "Structure" allows to insert a structure requirement via the button or menu selection "Insert Structure Req.".
If the Structure Requirement belongs to a different higher-level requirement already (this may be true if an existing requirement is assigned via drag&drop), the system will check if the corresponding base requirement is different from the current one.
It is not permitted to drag&drop a Structure Requirement in the sub-list of a text requirement. Text requirements can only be structured by decomposing or deriving.

### Text requirement ()

A text requirement describes in textual form the needs, demands and constraints with respect to the properties and behavior of the future product. For an existing base requirement or structure requirement, the sub-list "Structure" allows to insert a text requirement via the button or menu selection "Insert Text Req.". If a text requirement is copied via drag&drop into the sub-list of a text requirement (or selected from the select widget in insert mode), this relation is implicitly treated as a requirement derivation. The text requirement contains the actual functional or non-functional requirement statement. Further text requirements as well as describing objects (e.g. items, documents etc.) can be assigned to the text requirement. Text requirements can be grouped in sets. Parameters are linked to a text requirements to formalize it. Since a text requirement may contain more than one statement, several parameters may be linked.

Requirements can be characterized as functional and non-functional requirements:

- Functional Requirements
  Contain a statement on functions the product must have regarding the customer needs.
- Non-Functional Requirements
  Contain a statement on properties or qualities a product must have.

A text requirement should be composed of the following elements:

- A requirement number (unique identifier, automatically created)
- The requirement priority, expressing the importance of the requirement for the satisfaction of the client
- The requirements content in terms of one or more (requirement) statements
- A rationale, i.e. the reason behind the requirement’s existence
- The source (describs where the requirement originates from)

Decomposed or Derived Text Requirement

- Decomposed:
  During decomposition a text requirement is broken down into two or more text requirements whose total content is equal to the content of the former requirement - just expressed in more detail, i.e. at a higher level or granularity. The decomposed requirement is replaced by the resulting requirements, therefore becomes obsolete, but remains in the system. The type of this relation is DCM (decomposed).
- Derived:
  Deriving requirements means creating new requirements based on one or more yet existing ones. Unlike for requirement decomposition, the statements of the newly created requirements are different from those of the existing ones. Consequently, the input requirements do not become obsolete. The type of this relation is DRV (derived).

Decomposed or derived text requirements can be created without having write access for the parent element. This is because decomposed or derived requirements specify the existing text requirement in more detail!

If the text requirement is decomposed, it is not possible to derive requirements and vice versa!

In addition to the relations established through the specification hierarchy, requirements may be related to each other due to given dependencies (requirements impacting each other) or may be put into a requirements set as a result of a quality analysis activity (e.g. set of redundant or even conflicting parameters).

### Organizing Requirements

Defining Requirement Dependencies

Individual structure requirements or text requirements can be related with other ones (typically within the same requirements hierarchy). Related in this context means, that some sort of - non-hierarchical - dependency does exist. These requirements can be linked with each other in the Related With tab of the respective requirement mask. The relation can also be viewed in the Referenced From tab.

Dependencies between Base Requirements do not make sense and should not be created!

Structure or text requirements can also be linked with each other in a network-like structure (they do not belong to the same requirement hierarchy).

Assigning Describing Documents

A text requirement contains a short and comprehensive textual description. In many cases it is helpful to assign additional text, which may contain background information, examples or a more detailed description (assignable to all requirements). Such text needs to be stored in documents, which can be assigned to the text requirements.

Only documents of specific type (typically "Office" and "Text") should be assigned. Most other document types (e.g. "3D Model") do not make much sense to further detail a requirement.

Creating Requirement Sets

Before requirement sets can be created, requirement set types have to be defined.
Requirement Set Types

Requirements sets contain two or more text requirements interrelated to each other according to a certain aspect. This aspect may be a temporal or logical constraint, an equation, an alternative, etc. Requirement sets can also be used to bundle redundant or conflicting text requirements. Requirement sets can contain requirements that belong to different hierarchies.

### Detailing a Text Requirement with Parameters

A text requirement can be further detailed by assigning parameters. Parameters are primarily used to define quantitative / measurable aspects of a text requirement. They can not be assigned to base requirements or structure requirements.

The relation of a text requirement and a parameter is further detailed by a defined equation and value (e.g. less than 2).

### Affected Objects

Affected Product Structure Elements <> Product Component

A conceptual product structure (modular or neutral) consists of product structure elements (which point to a product component). (For reasons of simplification, the used term in the masks is Components). A product structure element may need to be in line with one or several text requirements.
In a technology driven innovation process, the conceptual product structure may have been defined (at least as a draft) before a detailed requirement definition has been executed. In this case a user may want to assign (new) requirements to an (existing) product structure element - describing which requirements need to be obeyed.

In a market/customer driven innovation process, the requirements definition is usually pretty complete, before a Conceptual Product Structure is created. In this case a user may prefer to assign (new) product structure elements to an (existing) requirement - describing how the requirement will be fulfilled.

In order to assing the correct text requirement to the respective product structure element, the connection should be created by drag and drop. Ideally this is done by opening the multilevel structure explosion of the one entity, and dragging individual objects to the structure sub-list of the other entity. The connection can be established in both ways, depending on what was created first.

It is only permitted to create a relation with text requirements.

Affected Items

The definition of an item may need to be in line with one or several text requirements. Ideally this is done by opening the multilevel structure explosion of the one entity, and dragging individual objects to the structure sub-list of the other entity. Alternatively the objects can be selected from the select widget in insert mode.

Affected Documents

The definition of a document may need to be in line with one or several text requirements. Ideally this is done by opening the multilevel structure explosion of the one entity, and dragging individual objects to the structure sub-list of the other entity. Alternatively the objects can be selected from the select widget in insert mode.

### Verification Process

For a text requirement, verification tests can be defined. Requirements define a "should-be" situation. At some point in time it is necessary to check if the "as-is" situation complies with the requirements. One or several test should be defined for a requirement, so that the fulfillment of the requirement can be verified.

Verification methods have to be defined before verifications test can be created.

- Verification methods
  Describe all possible test scenarios that can be conducted (e.g. "Vibration test", "Heat chamber").
- Verifications
  A verification test is based on a verification method (defined in a lookup-table).
  - Verifications can be created with a structure to break down a verification test in several smaller tests.
  - Documents can be assigned to verifications to describe for example the individual verification procedure in detail.
  - A verification test can be applied to a specific item.

Several text requirements can be verified at the same time when they are all assigned to the same verification!

Confirming Fulfillment of a Requirement

The fulfillment of a text requirement needs to be documented. This is managed by individual attributes (user, date, result), along with an entry in the history.

Only released text requirements can be regarded as stable. Accordingly it is only possible to confirm successful verification of a requirement, if the later is released.

If verification tests have been assigned to a text requirement, the results of all these verification test must be available.

### Lifecycle

Requirements have their own lifecycle, allowing to change their state e.g. from "in work" to "Approved" or "Released".
Once a requirement has been approved, it can typically not be changed. Similar to items or documents, requirements can be revisioned however. By means of this it is possible to track changing requirements and examine their impact ("Moving Targets") while preserving the original requirements.