Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Scenarios_Glinz.pdf | application/pdf | 43.73 KB | English | DOWNLOAD! |
Provides definitions
Summary
The classical notion of requirements quality is problematic in practice. Hence the importance
of some qualities, in particular completeness and unambiguity, has to be rethought. Scenarios,
the description of requirements as sequences of interactions, prove to be a key concept
for writing requirements specifications that are oriented towards such a modified set of
qualities.
In this paper, the potential of scenarios for improving the quality of requirements is discussed.
Furthermore, a concept for systematically representing both single scenarios and the
structure and relationships in a set of scenarios is presented. Using an example, the positive
impact of this style of representation on the quality of the requirements is demonstrated.
Introduction
The classical notion of requirements quality focuses
on Adequacy1, Unambiguity, Completeness, Consistency,
Verifiability, Modifiability and Traceability
(IEEE 1993). In practice however, most requirements
specifications do not meet these qualities. One could
argue that this is only a problem of applying the right
methods and processes and that we should improve
our requirements processes until they yield the desired
qualities. However, a closer look reveals that it
is not so simple. The qualities themselves are part of
the problem.
The notion of completeness leads to waterfall-like
process models, where a requirements specification of
the complete system has to be produced and baselined
prior to any design and implementation activities.
However, customers do not always fully know and
understand what they want. Systems and requirements
evolve. So it is almost impossible to produce
and freeze a complete requirements specification.
Unambiguity requires the specification to be as
formal as possible. However, in the vast majority of
requirements specifications, requirements are stated
informally with natural language or at best semi-formally,
for example with class models or dataflow
models. Thus, unambiguity is very difficult to
achieve. The value of traceability ranges in practice
from irrelevant (many in-house projects) to extremely
important (safety-critical projects).
On the other hand, we also do have process- and
method-related problems. In many projects, customers
are unable to assess the adequacy of the require-
ments because the way that the requirements are represented
does not match the way that customers use a
system and think about it. Moreover, when customers
do not fully know and understand what they want, the
assessment of adequacy becomes even more difficult.
Consequently, we need both a shift in the basic paradigm
of requirements quality and a proper adaptation
of requirements engineering techniques in order to
meet the modified set of qualities. I advocate a requirements
quality model that focuses on adequacy as
the most important quality, views consistency,
verifiability and modifiability as next important but
deliberately lives with incompleteness (that means
with partial specifications) and with some ambiguity.
The weight of traceability should be made dependent
on the project in hand.
..