Page 73 - Software and Systems Requirements Engineering in Practice

t
p
a
e
3

r
h
e
m
r
t
C
e
n
:
R

g
e
i
u
q
n
i
l
E
c
i
t
i
s
C h a p t e r 3 : E l i c i t i n g R e q u i r e m e n t s 45 45
subject matter expert is available for only limited periods of time. On
a taxation system project that we worked on, for example, the
requirements engineers were informed that the tax accountants and
attorneys were very busy (during tax return preparation season) and
could meet with the analysts only one hour a week.
Once an elicitation cycle is completed, it can be difficult in some
cases to revisit open issues with stakeholders. Therefore, it is important
to collect as much information as possible during elicitation sessions.
One way to do this is to have representatives of development,
manufacturing, and testing present their requirements wishes during
elicitation sessions. We also recommend that access to subject matter
experts be part of the initial planning for a project. Very often the
people who know the most about a topic are those a company may
rely most heavily on, and consequently, their availability may be very
limited.
Requirements Are Too Volatile
Capers Jones and Walker Royce have estimated that for most projects
there is a 1–3 percent change per month in the meaning or interpretation
of requirements [Jones 2008], [Royce 1998]. If needs are changing
rapidly, defining a stable set of product requirements may not be
feasible. It may be necessary to wait until there is some level of
stability before attempting to finalize a baseline requirement set for a
product (Figure 3.2).
System Boundaries Are Not Identified
Several years ago one of the authors worked on the requirements for an
insurance underwriting system. As underwriting systems are used by
35
Percent Requirements Changing 25 Formally Start Capturing
30
Requirements
20
15
10
0 5
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Month Since Inception of Requirements Gathering
FIGURE 3.2 Requirements volatility vs. time