Page 69 - Software and Systems Requirements Engineering in Practice

e
n
t
m
i
r
e
s
n
g
i
q

R
e
:
3

l
i
c
i
r
h
C
u
a
e
t
p
t
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 41 41
3.2 Issues and Problems in Requirements Elicitation
Eliciting requirements from stakeholders can sometimes become a
painful, drawn-out, and thankless task. Collecting requirements may
be viewed as an afterthought or assigned to junior staff. There may
even be situations where there are no documented requirements until
the project is nearing completion and the staff realizes that requirements
are necessary to create test cases, or even worse, a requirements review
is necessary for client acceptance or payment. A difficult task may
then begin to reverse-engineer requirements for a system that is
already in system test or nearing completion. When requirements are
reverse-engineered from a product under construction purely for
contractual reasons, the finished system may not meet the client’s
needs or be accepted. If the definition of nonfunctional requirements
is delayed until the end of the project, the system may turn out to be
inadequate for the intended purpose; e.g., it may not meet the needed
performance, reliability, or security goals. Typical situations that may
impede or otherwise affect the requirements elicitation process are
described in the sections that follow, along with suggestions for
handling them.
The Missing Ignoramus
Elicitation should be led by senior staff members with experience and
training in requirements elicitation techniques. An elicitation team
composed of a mixture of experienced staff and not-so-experienced
staff enables the mentoring and training of less-experienced members
of the team. Furthermore, it is usually advisable to have someone
involved with the elicitation process who has no domain knowledge,
e.g., someone who is not afraid to ask “what does that mean?” Professor
Dan Berry of the University of Waterloo refers to such an analyst
as a “smart ignoramus” [Berry 1995]. Without such people present,
situations can arise where insufficient information is collected, or
worse, the same term is used to mean different things. On one occasion
one of the authors was the facilitator in a brainstorming session to
gather requirements for a payroll system for automobile dealerships.
During a discussion of contractual issues he asked the simple question
“what is a contract?” Several managers were dumbfounded that he
should ask such a question—after all, it was perfectly obvious what a
contract was. Yet it still took three days for the participants to agree on
a viable definition of contract.
It is beneficial to have the elicitation team ask the question “why?”
When a need is identified, by asking why, you may find legitimate
reasons for the need, or you might find out it is “feature folklore.”
Folklore is something that has been done on every project, but such
features have no value to the customer and nobody knows why they
are there. This can result in the elimination of an unnecessary need
that turns into a requirement that you implement and the customer
does not want.