Page 42 - Software and Systems Requirements Engineering in Practice

t
t
n
:
I
h
C
a
e
r
1
d
u
o

r
o
n
i
c
t
p
C h a p t e r 1 : I n t r o d u c t i o n 15 15
Requirements elicitation and analysis are typically done under
project time constraints. Consequently, it is important to prioritize
and identify risks when defining requirements. For example, “If
this nonfunctional requirement is not completely analyzed, what
are the risks to the project, the company, and/or the user?” By
doing a risk analysis, the effort associated with fully defining a
requirement set can usually be balanced against the needs of the
project. Techniques for doing risk analysis of high-level requirements
(e.g., balancing effort against need) will be discussed further in
Chapter 5.
1.8 Requirements and Project Failure
It must be remembered that most systems under development are not
new; i.e., only a fraction of the requirements in the product are new or
unique [Jones 2007]. Yet issues of requirements maintenance and
long-term support are often missing from project plans; e.g., the
project plan is created as though the requirements will be discarded
after project completion. When long-term requirements management
is not planned, requirements creep can cause significant problems
late in a project. Furthermore, Capers Jones reports that the defect
rate increases significantly in requirements that are injected late over
those that are created prior to the start of implementation, and the
most egregious defects in requirements defined or modified late in a
project can sometimes show up in litigation [Jones 2007].
1.9 Quality and Metrics in Requirements Engineering
As was mentioned in connection with the success factors for projects,
project indicators need to be defined in order to have some measure
of project transparency. It is important to be able to answer the
questions “Am I making progress?” and “What is the quality of my
work products?” How does one, for example, determine that a
requirements specification is of high quality?
Requirement characteristics or quality indicators are extremely
important for determining artifact quality. They can be measured by
inspection (metrics), and the reported metrics can then be used to
determine the quality of individual requirements and requirements
specifications. Furthermore, metrics summaries tracked over time
can be used to identify potential problems earlier to permit corrective
actions, and provide guidance as to what type of corrective actions to
take. For example, a high level of ambiguity in a requirement set
might indicate that the analysts creating the requirements may need
additional training in requirements writing. Some of the chapters in
this book provide guidance on how to capture and use metrics to
improve requirements processes.