Information Technology Reference
In-Depth Information
(a) Involvement and Control: Effective requirements definition requires mutual
control of process by all players. No one likes to feel out of control of their time,
their work activities, or their goals. Team members don't want their activities
dictated to them. Team members really own their processes and have the
desired skills to solve a particular problem. A successful requirements process
includes effective ways to foster a healthy partnership between the customer,
designer, and team members. It must reveal the ownership of the activities of
the design by customers and team members (Holtzblatt and Beyer
1995
).
(b) Client-Developer links: In the software arena these links are defined as tech-
niques or channels that allow customers and developers to exchange informa-
tion. Today, there is a wide variety of links available to software developers. The
tremendous variety of links that are available today represents both opportunity
and a challenge for software development managers. Opportunity is easier to
obtain input from clients and the challenge is deciding on the type of links. By
focusing on links we are able to draw insights on degree of participation that
should be used to engage customers in development process. According to Keil
and Carmel three results can be drawn regarding the links:
1. The more links the better
2. Reduce indirect links
3. Consider links not traditionally used in environment (Keil and Carmel
1995
)
5.2.2 Gathering Information
One concern is how to gain access to information we may need that is hidden in
the minds of users or in the environment. Another concern is how to broaden the
users' perspective in efforts to accomplish the goals (Thayer and Dorfman
1990
).
In traditional methods of requirement elicitation, interviews and questionnaires
were the primary technique of fact finding and information gathering. Interviews
would be either formal or informal interviews. The information collected through
such interviews can address organizational and contextual factors, provided that
the right questions are asked. Likewise, if the right people are interviewed, the
information will represent multiple stakeholders' opinions across a large number
of different communities affected by the development of the proposed system
being elicited. The organization and expression of the information collected
through interviews is a commonly neglected issue. There is a lack of standardized
procedures for structuring information received via interviews: other limitations
with eliciting requirements primarily or exclusively through interviews result from
the tremendous responsibility placed on the requirements analyst. Assuming that
the interview data was collected from the different communities affected by the
system being elicited, the analyst must integrate these different interpretations,
goals, objectives, communication styles, and use of terminology into a single set of
requirements. This integration is a difficult task unless the interviews are structured
in some way. For example, the use of a glossary of system-specific terms may
