Page 75 - Software and Systems Requirements Engineering in Practice

:
E
e
e
m
l
i
c
s
n
t
e
t
r
3

p
i
r
u
a
h
R

e
C 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 47 47
q
g
n
i
i
t
create a full requirements specification and to design and build the
product, then, at the very least, the product vision will be described
in an internal document.
Users Misunderstand What Computers Can Do
Stakeholders may ascribe virtues to computer systems that are
futuristic, wishful thinking, or simply impractical. For example,
“We would like the new payroll system to automatically detect the
employee’s marital status from public records.”
It is important for analysts to adjust the phrasing of stakeholder
requests so that a reasonable discussion can be held on whether to
make the requests requirements or not, e.g., feasibility, legality, and
practicality. However, it is a good idea to record cutting-edge requests,
as they may go from cutting-edge to commonplace in short order. For
example, in 1992, we saw the following statement in a requirements
specification:
“As there will never be a need for computers to have more than
one processor, there is no need for a requirement for the new
system to support multiple processors.”
The Requirements Engineer Has Deep Domain Knowledge
If a requirements analyst has strong domain knowledge, there may be
a tendency to minimize communication with stakeholders. That is, the
analyst may try to do it all himself or herself without seeking outside
validation or views. Failure to communicate with external stakeholders
can be especially dangerous in a domain where technology is changing
rapidly (e.g., cell phones).
Stakeholders Speak Different Natural and Technical Languages
When stakeholders are from different domains or speak different
languages, communication can be even more difficult. Problems may
arise in several areas, such as
• Ensuring efficient quality reviews of requirements
• Smoothly running elicitation sessions
• Domain experts understanding the impact of stakeholder
requests made in one area on their area
• Understanding complex needs, processes, or algorithms
Because of the difficulty in getting stakeholders and analysts to
understand and review each other’s work, we recommend wherever
possible using visual techniques, including models, diagrams, and
tables, to communicate important concepts.