Information Technology Reference
In-Depth Information
5.4 Common Problems Concerning Requirements
Problems
of
requirement
elicitation
can
be
grouped
into
three
categories
(Christel and Kang 1992 ):
1. Problems of scope in which the requirements may address too little or too much
information
2. Problems of understanding within groups as well as between groups such as
users and developers
3. Problems of volatility, i.e., the changing nature of requirements.
5.4.1 Problems of Scope
Elicitation techniques need to be broad enough to establish boundary conditions for
the specified target system, yet they still should focus on the creation of requirements
as opposed to design activities. Avoiding contextual issues can lead to requirements
which are incomplete, not verifiable, unnecessary and unusable. Focusing on broader
design activities improperly emphasizes developers' issues over the users' needs,
and may result in poorly defined requirements as well. Requirement elicitation must
begin with an organizational and contextual analysis to determine the boundary of
the target system, as well as the objectives of the system. Less ambitious elicitation
techniques not addressing this concern run the risk of producing requirements which
are incomplete and potentially unusable, because they do not adhere to the user's or
organization's true goals for the system. Performing an organizational and contex-
tual analysis allows these goals to be properly captured, and then put to use in
verifying that the requirements are indeed usable and correct. Elicitation techniques
can be overly ambitious as well. Elicitation must focus on the creation of require-
ments, not design activities, in order to adequately address users' concerns and not
just developers' needs. Elicitation strategies which produce requirements in the form
of high level designs run the risk of creating requirements which are overly
ambiguous to the user community. These requirements may not be verifiable by the
users because they cannot adequately understand the intricate design language. Also,
requirements expressed as a design are much more likely to incorporate additional
decisions not reflecting user or sponsor needs, i.e., the requirements will not be
precise and necessary. There are at least three broad categories which affect the
requirements and the requirements engineering process for a proposed system:
• Organization
• Environment
• Project
A number of a restricting assumptions and misunderstandings such as ''the
boundary of the system is ill-defined or the customers/users specify unnecessary
Search WWH ::




Custom Search