The ↑process of confirming that an ↑item (a ↑system , a ↑work product or a part thereof) matches its ↑stakeholders’ needs.

1. The degree to which a ↑system can be changed or customized.
   
2. In product lines: The ↑features that can differ among the members of the ↑product line .

One of the possible forms that an ↑item (e.g., a ↑requirement ) may have.

A point in a ↑product line where an element of the product line (typically a variable or a ↑feature ) can be chosen from a set of ↑variants .

1. In general: The ability to establish explicit relationships between related ↑work products or ↑items within work products.
   
2. In RE: The ability to trace a ↑requirement
   (a) back to its origins,
   (b) forward to its implementation in design and code and its associated tests,
   (c) to requirements it depends on (and vice-versa).

The way in which a ↑system reacts to stimuli, changes its state and produces observable results.

A ↑model describing the ↑behavior of a ↑system , e.g., by a ↑state machine.

The process of confirming that an ↑item (a system, a work product, or a part thereof) fulfills its ↑specification .

An occurrence of an ↑item which exists in multiple, time-ordered occurrences where each occurrence has been created by modifying one of its previous occurrences.

The degree to which an ↑item is comprehensible to its intended users.

A conceptual imagination of a future ↑system or ↑product , describing its key characteristics and how it will create value for its ↑users .

1. For a single ↑requirement : The degree to which the specification of a requirement is self-contained.
   
2. For a ↑work product covering multiple requirements: The degree to which the work product contains all known requirements that are relevant in the scope of this work product.