Page 47 -

32 FULLER AND DAVIS
and practitioners to better appreciate the capacity of epigenetic requirements elicitation techniques
such as cognitive mapping (Brooks, Davis, and Lycett, 2005; Siau, 2004) to “expand” the com-
munication channel between users and analysts, reducing the likelihood that requirements will be
missed or misunderstood. Likewise, it suggests that for many elicitation processes, it is possible
that a healthy mix of these techniques as opposed to the preponderance of one technique would
provide a richer basis for understanding the development scenario.
The framework briefly outlined here has already proved its diagnostic worth in a number of
organizational settings. However, further empirical research is required to refine it and demonstrate
its utility: such research will be undertaken in the near future. While some research has examined
the use of various elicitation techniques and the resultant information they provide, little compara-
tive research has explored the degree to which the elicitation technique used actually constrains
or limits the understanding or types of understanding that analysts can develop about a business
context. There is an opportunity—particularly across elicitation types (verification, collaboration,
and generation)—for future research to more closely examine the level of understanding that
analysts develop from their use of specific elicitation techniques.
Despite its value, our framework also carries a significant “health warning” for practitioners.
Although superior to traditional techniques in terms of their communication “bandwidth,” the more
collaborative and generative techniques proposed in Table 3.1 are conceptually rather “alien” to
requirements engineers (Lerouge, Newton, and Blanton, 2005). This highlights the need to consider
the development and training issues that face the practitioner community (Bajaj et al., 2005; Kim,
Hahn, and Hahn, 2000). Nevertheless, we believe this is a worthwhile enterprise. Overcoming
some of the mis- and mal-communication in requirements elicitation could substantially reduce
information systems failures, users’ dissatisfaction with systems, and, ultimately, development
costs.

NOTE

1. We use the term elicitation technique to refer to user–analyst communications channels or tools in a
more general sense.

REFERENCES

Alter, S. 2004. Possibilities for cross-fertilization between interpretive approaches and other methods for
analyzing information systems. European Journal of Information Systems: Special Issue: “Interpretive”
Approaches to Information, 13, 3, 173–185.
Bajaj, A.; Batra, D.; Hevner, A.; Parsons, J.; and Siau, K. 2005. Information technology and systems—I:
Systems analysis and design: should we be researching what we teach? Communications of the Associa-
tion for Information Systems, 15, 1, 478–493.
Berry, D.M., and Lawrence, B. 1998. Requirements engineering. IEEE Software, 15, 2, 26–29.
Beyer, H.R., and Holzblatt, K. 1995. Apprenticing with the customer. Communications of the ACM, 38, 5,
45–52.
Boehm, B., and Huang, L. 2003. Value-based software engineering: re-inventing “earned value” monitoring
and control. Software Engineering Notes (ACM SIGSOFT), 28, 1–7.
Bolloju, N. 2004. Improving the quality of business object models using collaboration patterns. Communica-
tions of the ACM, 47, 7, 81–86.
Brooks, L.; Davis, C.; and Lycett, M. 2005. Organizations and information systems: investigating their dy-
namic complexities using repertory grids and cognitive mapping. International Journal of Information
Technology and Human Interaction, 1, 4, 39–55.
Browne, G., and Ramesh, V. 2002. Improving information requirements elicitation: a cognitive perspective.
Information and Management, 39, 8, 625–645.