Academic journal article Journal of Information, Information Technology, and Organizations

Involving Novice Users in Document-Driven System Requirements Analysis

Academic journal article Journal of Information, Information Technology, and Organizations

Involving Novice Users in Document-Driven System Requirements Analysis

Article excerpt

Introduction

The research question we address in this paper reads: How should a requirements analysis be carried out when novice users are involved? When planning a project for developing an information system (IS), it is necessary to consider many issues, such as time limits, which project members should be participating and whether they are available, and if there is feasible support in terms of methodologies and computer support. The type of project and the experience of the project members have also to be considered. In other words, there is a need for characterising the project conditions.

Members of a development project can have different experiences. Due to high maturity of information technology (IT) in today's organizations, many users are likely to have significant experience with computer use and information systems development (ISD). However, there are still situations where novice users participate in ISD projects. This means that they have a lower degree of experience from interacting with computers and no experience from participating in different different change or development projects. In this research we address the problems of involving novice users in ISD projects. We focus on the analysis phase and some recommendations for the design phase, rather than on a full development methodology (that has other phases such as design, construction, implementation, and maintenance).

There are many competitive methodologies for analysing business processes and business information in order to develop ISes. Sometimes these methodologies also tell us why we should act in one way or another (e.g., Jayaratna, 1994). One of the most popular methodologies today is the object-oriented approach called Rational Unified Process (RUP) (e.g., Kruchten, 1999). What these methodologies do not tell us is how to perform ISD when project members are novices. Introna and Whitley (1997) argue that relying exclusively on methodologies can be risky. Further, they claim that methodologies cannot bring light to all characteristics of the situation that can be discovered. We think that these methodologies are too complex and abstract when an IS is being developed in close collaboration with future end-users that have no or little experience of using computers and participating in ISD projects.

Advocates of the participatory design approach have paid significant attention to the influence of users on the ISD process. They argued for a broad and genuine participation aiming at agreement between ISes and the organization of work (Hagerfors, 1994; Kensing, 2003; Kling, 1977; Mumford & Henshall, 1983). Carlshamre (1994) posited that participatory design was more of a philosophy than a methodology. Although participatory design has included some techniques to facilitate requirements analysis, it lacked a procedural description of how and when to apply these techniques.

Vonk (1990) and Urquhart (1998) argued that there was a communication gap between the professional systems developers and the users. Vonk (1990) maintained that the main problem was a use of different languages. The author advocated a more extensive use of pictures in order to overcome this problem. Vonk (1990) preferred a prototyping approach that would bring more attention to the user interface than traditional ISD methodologies did. Many research efforts have been pursued in the area of user involvement and participatory design. But as Markus and Mao (2004) concluded, while "prior research has offered evidence in support of a link between participation and system success, ... much remains to be understood about how and why participation works" (p. 524). They suggested that research should be refocused toward the practices of IS developers when they facilitate user participation. It is crucial that developers and users work together, rather than just interact in design meetings. The authors add, and we concur, that "it is not the mere fact or quantity of participation that matters, but also the quality of participation" (p. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.