Page 49 - Software and Systems Requirements Engineering in Practice

22 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

FIGURE 2.1 Requirement
Requirements
taxonomy System Process
Project
suggested by Requirement Requirement Requirement
Professor Glinz
Functional Attribute Constraint
Requirement
Performance Specific Quality
Requirement Requirement

The difference between a glossary and a taxonomy is that in a
glossary, terms are listed alphabetically and defined, whereas in a
taxonomy, terms are grouped into classifications. To create a glossary,
we recommend starting with a taxonomy of RE terms (e.g., Figure 2.1).
The terms that would then go into the glossary are the leaves of
the taxonomy tree plus any additional domain- or organization-
specific terms.
A complete RE taxonomy would include the classification of all
artifacts associated with a requirements engineering process, not just
the categorization of requirement types. Since the artifacts can change
from organization to organization or project to project, any such
taxonomy would have to be extensible (see the later section “Using
the Artifact Model”).
Taxonomies can be quite extensive. As an example, see the
fragment of the taxonomy for security requirements given in
Figure 2.3 [Firesmith 2005].

Nonfunctional Quality
Requirement Requirement

Nonfunctional Functional
Performance Quality
Requirement Requirement Quality Quality
Requirement Requirement

Luxury
Appearance
Durability Appearance Features

FIGURE 2.2 Two taxonomies illustrating differing representations of the
same concepts