# Requirements Management

## Key Terms

The following figure shows an overview of a requirements structure including all of its elements defined below.

[ fig. rmt_e_a04_01 ]

### Base Requirement

The base requirement represents the top node of a requirements structure (see fig. rmt_e_a04_01 ).

### Client

The person who pays for the development of the product (see also Customer).

### Customer

A person who pays the product (see also Client).

### External Requirement

An external requirement directly originates from a need stated by units outside systems engineering such as the customer or a marketing department. External requirements usually become part of the contractual obligations towards the customer (see fig. rmt_e_a04_01 ).

### Formalized Requirement

A formalized requirement (synonym: Parameter) represents a requirement statement transformed into a computer-processable format. Formalized requirements are attached to text requirements (see fig. rmt_e_a04_01 ). One text requirement may have one or more formalized requirements linked to it.

### Functional Requirement

A requirement that contains one or more requirement statements on what the product to be developed must do to be in accordance with the ideas and expectations of the user, customer or client and their respective business.

### Internal Requirement

Internal requirements are complementary to external requirements (see fig. rmt_e_a04_01 ). Internal requirements usually do not become part of the contractual obligations towards the customer. They are defined to fully specify the expected properties and behavior of the product throughout the entire product life cycle not only from the customer's point of view, but also from the company-internal point of view. A requirements structure containing both external and internal requirements is often called 'specification tree'.

### Non-Functional Requirement

A property, or quality, that the product must have, such as an appearance, or a speed or an accuracy property [RoR 99].

### Non-Requirement Text

Non-requirement text is meant to provide background or contextual information on various text requirement. Unlike an explanation given for a single requirement only, non-requirement text can be linked to more than one requirement.

### Parameter

see 'Formalized Requirement' (> Formalized Requirement)

### Requirements Analysis Activity

By means of a requirements analysis activity the generation of new requirements based on yet existing ones (see 'Requirements Derivation') can be supported and documented.

### Requirements Analyst

The person who has responsibility for producing the requirements specification.

### Requirements Baseline

Similar to a configuration baseline the requirement baseline defines something like the staring point in the process of tracking and control of requirements and the product which has to fulfill these requirements. You can understand the set of all specifications with their first released edition –representing the functional structure of a product or system- as the requirement baseline.

### Requirement Decomposition

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.

### Requirement Derivation

Deriving requirements means creating new requirements based on one or more yet existing ones. Unlike for requirement decomposition (> 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. If desired the derivation may be documented by means of a Requirements Analysis Activity (> Requirements Analysis Activity).

### Requirement Set

Requirements sets contain two or more text requirements (> Text Requirement) 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 may furthermore be used to bundle redundant or conflicting text requirements.

### Requirements Specification

A document that contains the requirements and defines the product.

### Requirement Statement

A requirement statement represents a single requirement issue in textual form. A text requirement contains one or more requirement statements. A requirement statement may be formalized and thus transformed into a computer-processable format (see > Formalized Requirement).

### Requirements Structure

A product- or project-specific, hierarchical representation of base, structure and text requirements as well as the relations between them.

### Specification Tree

See Requirements Structure.

### Stakeholder

A person or group with an interest in the product.

### Structure Requirement

On the one hand structure requirements group other structure or text requirements at the inferior levels of the requirement structure and on the other hand establish links to further structure requirements or the base requirement at the superior levels of the requirements structure (see fig. rmt_e_a04_01 ).

### Text Requirement

A text requirement (see fig. rmt_e_a04_01 ) describes in textual form the needs, demands and constraints with respect to the properties and behavior of the future product in any phase of its life cycle. A text requirement contains one or more requirement statements (> Requirement Statement).

### Traceability

Traceability is the ability to identify

- any part of the product that exists because of a requirement, and vice versa
- any requirement that caused a part of the product.

### Use Case

An amount of work as seen from the viewpoint of the user of the product [RoR 99].