Page 44 -

REQUIREMENTS ELICITATION TECHNIQUES AS COMMUNICATION CHANNELS 29
these requirements and increase area (a) to the right generally involves the analyst’s attempt to
get at the information that is known by the user (Browne and Ramesh, 2002; Gaines, 2003). To
identify and capture these requirements, it is generally assumed that the analyst can ask the right
questions and prod for more information, and that the user can understand and answer the ques-
tions. It is hoped that such questioning prompts the user’s recognition of unknown (to the analyst)
needs, thereby eliciting these additional requirements.
Finally, a set of communication challenges exists when there are potential requirements (d) that
are not known about by the analyst to ask, and not known by the user to request. These require-
ments are outside the immediate experience of both the user and analyst and represent opportunities
arising from completely new concepts. These requirements are often neither “captured” nor even
realized during typical requirements elicitation, but may be realized later, for example, when the
system has been implemented and is in use. Such unrealized requirements frequently manifest
themselves as change requests, system enhancements, or, euphemistically, as “lessons learned.” To
successfully elicit these requirements demands communication techniques that facilitate mutual
learning or co-discovery (Purao, Storey, and Han, 2003; Siau, 2004). In turn, the enriched com-
munication facilitated by these techniques can result in design innovation and further experiential
learning for both the analyst and user.

REQUIREMENTS ELICITATION TECHNIQUES AS COMMUNICATION
CHANNELS

The prior sections explain that in a given systems development project, the analyst and user will
have some level (higher or lower) of shared understanding of the given business scenario of
interest. Depending on the knowledge that the analyst may have about the business scenario, the
analyst will benefit from certain types of interactions (facilitated through elicitation techniques)
with the user to increase his or her understanding about the business context. However, it is evident
that different elicitation techniques will likely yield different requirements information about the
business scenario (Marakas and Elam, 1998).
From channel expansion theory, we highlight two knowledge bases that are particularly relevant
to the efficacy of elicitation techniques in increasing analyst understanding: the analyst’s experience
with the message topic (application domain) and the analyst’s experience with the organizational
context. These bases directly affect the ability of analysts to articulate the essence of the user(s)
requirements—a mutual understanding of the context-specific focus of the analysis and design
effort. The framework in Figure 3.2 uses these bases to provide a conceptual model of the “loca-
tion” of the requirements elicitation techniques categorized in Table 3.1 (see page 26).
Figure 3.2 elaborates the classification set out in Table 3.1, incorporating the knowledge bases
proposed by Carlson and Zmud (1999). The result is a conceptual model, the horizontal boundaries
of which indicate the interdependence of the analyst’s domain and application experience. The
model highlights the need for balance between the conceptual “repertoires” of analyst and user
in order to elicit mutually understandable requirements. For instance, an analyst with a wealth
of application experience might feel able to reconceptualize users’ wants in terms of previously
delivered systems (or “solutions”). However, if the analyst’s experience with the specific organi-
zational context is modest, there is—as our conceptual model suggests—a need to move out of
the “comfort zone” of the focus on verification. Figure 3.2 highlights the communication tradeoffs
that need to be considered during systems analysis and design in order that requirements are
elicited—rather than usurped—from their context.
Figure 3.2 extends from Figure 3.1 in that it takes the perspective of the analyst in the require-