Information Technology Reference
In-Depth Information
• Promotes communication and understanding between customers and users;
• Allows the developer to determine whether the expressed requirements are
implementable; and
• Lets
quality
assurance
teams
verify
that
an
implementation
meets
these
requirements.
The stakeholder communities may be multilevel. More specifically, the
involved parties may be in managerial positions within a contributing organiza-
tion; gathering information of this variety can be a difficult task. System devel-
opers and requirements analysts may have limited knowledge of the application
domain, while the system users may not know design methods for the development
of systems with a significant software component. The customer may not under-
stand what can be done to solve a given problem, nor have a full appreciation for
the difficulty involved with getting the analyst and developer to understand the
problem in the customer's domain. The analyst is often ignorant of the customer's
problems, goals, and wishes. Requirements elicitation starts with inherently
informal knowledge and typically involves people not literate in software-inten-
sive systems. To avoid misunderstandings due to terminology differences,
requirements have traditionally been expressed back to the elicitation communities
using natural language text. Requirements, therefore, may be difficult to under-
stand by the elicitation communities because of the sophisticated form used to
express the requirements. Requirements are typically not the product of a single
person's work, but, rather, they are the result of many peoples' expressed needs
across a multitude of different communities. These multiple and often varying
inputs present problems in regards to redundancy of data, inconsistency, and point-
of-view. Each particular different group involved in requirements elicitation have
different interpretations of what the requirements say and different expectations of
what a system built to these requirements will deliver.
Requirements may also be misunderstood because of their large size. Often times
this is because requirements are so complex that the client and practitioner may have
difficulty focusing attention on one single aspect at a time. This can lead to issues
with perceiving interactions between requirements, or problems with the specified
system being impossible to visualize from the resulting specification. Problems in
understanding results from the necessary involvement of requirements analysts,
sponsors, developers, and end users in requirements elicitation are common and can
lead to many issues if not properly handled. The requirements are produced and
interpreted by people with vastly different experience levels and backgrounds. The
form in which the requirements are expressed and the size of the system described
by the requirements also affect understanding. If the participants in elicitation do not
adequately understand the output of the process, then the resulting requirements
may be ambiguous, inconsistent, and incomplete. The requirements may also be
incorrect not fully addressing the true needs of the elicitation communities. In
summary, good communication among users, customers, and developers is very
important in solving pragmatic system problems, an issue too often overlooked
when system analysis is approached only from a pure computer science standpoint.
