Page 327 - Software and Systems Requirements Engineering in Practice

289
:
C
n
2
o
e
p
t

1
n
c
C
a
h
r
i
o
s
l
u
C h a p t e r 1 2 : C o n c l u s i o n 289
Pictures generally convey more information than text and so are
easier for professionals to create and manage. Also, model views can
be more easily understood by all stakeholders, and thus they facilitate
more rapid and effective reviews.
The role of the system architect in requirements engineering is the
management of quality attribute requirements (QARs) or
nonfunctional requirements (NFRs) as discussed in Chapter 5. A key
point of this chapter is that nonfunctional requirements need to be
analyzed and managed by senior architectural staff to identify the
architecturally significant requirements (ASRs), starting as early in a
project as possible. Furthermore, the management of nonfunctional
requirements needs to be fully integrated with functional
requirements activities.
In Chapter 6, techniques for handling platform requirements
were discussed. Since platforms can be an integral part of a large
product line, we see that the handling of product line and single
product requirements can differ somewhat; e.g., one can expect that
requirements management for product lines will be a more challenging
undertaking than for single products.
Chapter 7 dealt with requirements management and traceability.
A tracing strategy is a necessary precondition for coverage, impact,
and derivation analysis—the key enablers of proper change
management. One major cause of project cost escalation is
requirements churn, which is why effective requirements
management is important for project success.
A benefit of a well-defined requirements hierarchy is a simplified
test phase. Test plans must derive from requirements. A formal
approach to defining requirements can result in generating sets of
test cases from the requirements model. Chapter 8 describes
techniques for deriving and generating test cases from UML activity
diagrams, which significantly reduces the effort to produce and
perform high-quality tests.
Innovative product development and user interface design often
starts with fuzzy requirements. To make fuzzy requirements more
concrete, there’s a need for a high degree of interaction with all the
stakeholders that cannot be adequately handled with visual models
or textual descriptions due to high volatility and complexity. In such
cases, evolutionary prototyping can be of great value for requirements
visualization and analysis, as described in Chapter 9.
In today’s complex product development environment, the effort
is almost always done by a global project team that is spread across
different sites in different countries. Distribution introduces a new set
of challenges. Chapter 10 describes experiences with distributed
product development and provides some best practices when eliciting
and managing requirements in global projects.
An often overlooked aspect of requirements engineering is that
of dealing with safety-critical and secure systems. While RE staff