Information Technology Reference
In-Depth Information
reduce the number of inconsistencies in interviews that subsequently have to be
resolved by the analyst. Even with well-structured interview data, the analyst still
must perform complex tasks such as deciding whether a particular piece of
information is premature design information or a requirement. These tasks require
that the analyst is experienced in both the system domain and with development
techniques; making qualifications for such a position often difficult to satisfy. With
so much decision-making resting with the analyst, the elicitation stakeholders may
not understand how the resulting requirements were derived and may refuse to
share ownership in and approve these requirements. The requirements themselves
may not be easily understood, e.g., if written with a behavioral tone in very domain
specific terms, the users may comprehend everything, however, the developers
could have many issues with fully grasping the terminology. The integration and
decision-making performed by the analyst takes time and given that requirements
are volatile, the longer this process takes the more likely it is that the subsequent
requirements no longer match the stakeholder communities' needs and expecta-
tions. Other techniques can be used in conjunction with interviews to help struc-
ture them and facilitate optimal integration.
5.2.3 Issues in Requirement Elicitation
There are many problems associated with requirements engineering, including
problems in defining the system scope, problems in fostering understanding among
the different communities affected by the development of a given system, and
problems in dealing with the volatile nature of requirements. These problems will
often lead to poor requirements and the cancellation of system development, or the
development of a system that is later judged unsatisfactory or unacceptable, has
high maintenance costs, or undergoes frequent changes. By improving the
requirement elicitation process, the requirements engineering process can also be
greatly improved, resulting in enhanced system requirements and potentially a
much better system.
Requirements engineering can be decomposed into the activities of requirement
elicitation, specification, and validation. Most of the requirements techniques and
tools today focus on specification, i.e., the representation of the requirements.
A list of ten elicitation problems given in one source could be classified
according to the following framework:
• problems of scope
• the boundary of the system is ill-defined
• unnecessary design information is given
• problems of understanding
• users have incomplete understanding of their needs
• users have poor understanding of computer capabilities and limitations
• analysts have poor knowledge of problem domain
Search WWH ::




Custom Search