This chapter frames the requirements definition phase of systems design as a problem of knowledge transfer and learning between two communities of practice: IS designers and system users. The theoretical basis for the proposed approach is Wenger’s (1998) framework for social learning, which involves three dimensions: alignment, imagination, and engagement. The chapter treats the requirements defi- nition task in systems design as a set of activities involving mutual learning and knowledge transfer between two communities of practice (CoP) along these three dimensions. In taking this approach, the chapter maps the results of past research on the systems design process onto this CoP framework and illustrates that the proposed framework encompasses the same activities used by traditional methods of requirements definition. However, this approach focuses attention on the learning that must take place between the two CoPs and thereby helps resolve some of the inherent shortcomings of prior efforts and approaches. The framework provides both a more encompassing conceptual lens for research on improving the requirements definition task and practical guidance for managers who are charged with a systems design project.
TopIntroduction
Requirements definition is a critical step in systems development that requires the identification of information needs and knowledge of a system’s processes (Nelson & Cooprider, 1996; Vessey, 1994). Historically, researchers examined the requirements-definition stage of system design as a process of inquiry (Boland, 1978; Salaway, 1987). Problems with identification, articulation, and communication of information needs have long been identified with the challenges of information system design (Boland, 1987). There have been different approaches in attempting to meet these challenges, but none has completely resolved the issues.
Land (1998) notes that because systems are so different, a contingency approach—using different methods for different types of systems —is appropriate. Others have suggested more structured analyses of the design process itself, establishing metrics for requirements engineering (Costello & Liu, 1995) and developing tools for each aspect of the problem (Nature_Team, 1996). Some researchers have suggested that the process of design must remain flexible and that a management structure that encourages an evolutionary design process is associated with greater effectiveness (Ravichandran & Rai, 2000). In considering software project risk and software quality, organizational issues as well as technical issues are important (Wallace, Keil & Rai, 2004). Others also emphasize the critical nature of human-intensive dimensions of the process (Tamai, 1993). It also has been noted that evolutionary designs are necessary as complexity increases (Mens & Eden, 2005). Larman (2004) argues that an “agile” and iterative design process is key to software development success.
The approach that we want to explore in this chapter emphasizes these human-intensive dimensions of the design process. Although the design process involves many actors (Lamb, 2003), we want to focus on two roles: the designer (who has technical knowledge) and the user (who has knowledge of the application and context of use). The conceptual approach is one that considers requirements definition as an instance of knowledge acquisition (Byrd, Cossick & Zmud, 1992).
Recently, organizations and researchers have begun investigating the potential of knowledge transfer (Alavi & Leidner, 2001) to make organizations more effective when engaging in information intensive work. Such knowledge transfer is necessary because clients are not sure what is possible and are unclear about their needs, and IT designers thus are unable to work toward an outcome that meets clear specifications (as in designing a product for production) (Larman, 2004).
To date, however, conceptualizations of knowledge transfer in software development do not completely capture the complexity and richness of this process by which clients and designers work together. As Polyani (1966, p. 4) says, “We know more than we can tell.” Regardless of how well we articulate knowledge, it always contains a tacit dimension. Hence, simple inquiry is insufficient for the requirements definition process because it is able to access only explicit, leaky knowledge (Von Hipple, 1994). The information transferred through traditional elicitation approaches is only part of what someone knows, and it rarely includes how or why they know it (Lanzara & Mathiassen, 1985).
Because of the tacit dimension of knowledge involved in most tasks and processes, it is difficult, if not impossible, for people to articulate exactly what it is that they need prior to design. Even if they can articulate what they need, the system development effort is hampered if the system developers do not understand why and how users need what they need. With an understanding of the why’s and how’s of information, developers can be more innovative in their delivery of requirements. For example, unless developers understand which information is used together and how it is connected, they will be unlikely to find ways to combine and simplify tasks.