Page 68 - Software and Systems Requirements Engineering in Practice

40 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

“The hardest single part of building a system is deciding what to build…
No other part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.”
—Dr. Fredrick P. Brooks, Jr.

3.1 Introduction
Elicitation is the process of identifying the needs and bridging the
disparities among involved communities for the purpose of defining
and distilling requirements to meet the needs of an organization or
project while staying within imposed constraints. It involves all
aspects of meeting with stakeholders, recording their needs, and
classifying them into a manageable set of stakeholder requests that
will later, through an analysis process, become requirements. There
are many different elicitation techniques that can be used, and many
of these techniques (brainstorming, for example) have been rigorously
described in several texts [Clegg et al. 2007], [Conway Correll 2004],
[Souter 2007]. We differentiate between elicitation and analysis as
follows:

• Elicitation is the interaction with stakeholders to capture their
needs.
• Analysis is the refinement of stakeholder needs into formal
product specifications.

In this chapter, we will describe some of the more well-known
techniques of elicitation from the perspective of what works, what is
important, and how to drive a successful elicitation effort. Rather than
describe any single elicitation technique in detail, we will review some
commonly used techniques, suggest some best practices, and identify
problems that can arise during elicitation and how to address them.
As Dr. Brooks points out in the opening quotation [Brooks 1995],
one of the most difficult parts of the development life cycle is the
identification of key requirements. Analysts can sometimes begin
working on a project with a predisposition or bias that may impact their
work. For example, if software developers are given the task of defining
product requirements, they may start with solutions with which they
are most comfortable, e.g., “Sentence first—verdict afterwards.”
1
Analysts must be trained to separate solutions from requirements when
transcribing client needs and creating requirements specifications.
We start by discussing some of the difficulties in successfully
eliciting the requirements for a product or service, including the
different types of situations that can affect the approach used for
collecting requirements. We then discuss key issues. Finally, we
discuss approaches that can be used to elicit customer needs along
with some metrics that can be used to measure progress.

1 As stated by the red queen in Alice’s Adventures in Wonderland by Lewis Carroll.