Page 97 - Software and Systems Requirements Engineering in Practice

l
i
3
:
t
i
c
i
a
p
C
h
r

t
e
m
e
r
e
s
C h a p t e r 3 : E E l i c i t i n g R e q u i r e m e n t s 67 67
n
t

R
n
g
u
i
e
q
need for post-session reviews. Three subject matter experts in
the same session may or may not be effective, depending on
their interpersonal dynamics.
To summarize, conducting elicitation sessions may require a
significant planning effort, depending on the scope of the project.
Furthermore, if any needed standards, procedures, and tools are in
place prior to the start of the elicitation sessions, rework will be
minimized and the sessions will proceed more smoothly.
3.7 Requirements and Cost Estimation
A strong correlation has been found between function point counts
and requirements [Jones 2008]. With proper planning, it is possible
to generate function point counts from sets of requirements or an
analysis model. For example, if use cases are annotated with the
appropriate information, a function point count estimate can be
generated by walking the directed graph of the underlying model.
Software requirements automation can play an important role in
software requirements estimation. The Bachman Analyst Workbench
developed in 1991 and the Texas Instruments Information
Engineering Facility (IEF) developed in the early 1990s both
provided automatic derivation of function point metrics from
software requirements.
3.8 Requirements Elicitation for
Incremental Product Development
It was mentioned in Chapter 1 that Capers Jones reported that less
than 25 percent of the requirements for typical applications are new
or unique [Jones 2007]. For projects that are not new, two situations
typically exist:
• A well-defined RE process was used to define the initial
requirements. In this situation, elicitation and analysis can
be a continuation of previous efforts, with new requests
and requirements recorded using the appropriate database
attributes to permit partitioning of the requirement sets.
• An enhancement to a legacy system is to be built, with prior
requirement set(s) either incomplete or missing completely.
The latter situation tends to be quite common; e.g., enhancements
to systems are often done with no prior requirement specifications or
documentation to refer to. When this occurs, it may not be feasible to
reverse-engineer a full requirement set, but rather, only the new
requirements can be captured. In this case the old system and its
functions may have to be treated as a set of legacy requirements;