VOLUME 15 NUMBER 6 1994

A Review of Information Systems Development Methodologies

S.A. Walters, J.E. Broady and R.J. Hartley
Information systems play a central role in libraries, both in terms of service delivery, and their impact on management[1]. Consequently, one of the key areas affecting libraries in the future will be an increasing focus on information systems[2], which provide powerful external forces for change within the organization. Information systems have an impact not only on the strategic and operational levels, but also on human aspects. In addition, over the last decade, information systems have caused library managers to rethink their approach towards[3]: (1) determining objectives and strategies; (2) the planning process; (3) operational structures; (4) productivity and human dimensions. However, the short history of computing shows that technological development does not lead inevitably to successful information systems in organisations and society[4, p. 6]. Therefore, it would seem that library managers, like managers in other organizations, face a difficult task if they are to benefit from using information systems. Thus, it is essential that library managers can derive the maximum potential from their information systems. This can be achieved through the effective and efficient management and development of such systems. One approach that helps to facilitate this is the use of information systems development methodologies (ISDMs). It is the belief of this project that ISDMs are a management approach which, although virtually ignored in the context of libraries, merit closer attention. Hence, this article focuses on the concept of an ISDM, and seeks to provide a synthesis of the subject, establishing a conceptual link between library management and ISDMs. It will be a purely theoretical link at this stage. However, it is hoped that this review will act as the basis for further examination of the potential application of ISDMs to library management.

A Brief History
Early computerized information systems were implemented without the use of an explicit ISDM. Typically, programmers were responsible for the design of these systems, with little or no attention paid to the needs of the users. The usual approach taken was heuristic, with the systems designer relying heavily on previous experience what Veryard believes to be an implicit methodology called tradition and common sense (TACS)[5, p. 33]. In the majority of situations, these systems design projects were seen as short-term solutions to particular problems, or one-off projects, rather than as long-term, planned development strategies. Systems were often finished behind schedule, over budget and in need of much maintenance. In the late 1950s and early 1960s, in partial answer to these deficiencies and to introduce some rigour into the design process, the systems (or software) development life cycle (SDLC) was introduced into the academic community, becoming the systems development tool for the 1970s[6, p. 685]. It was developed in an attempt to produce information systems that were
This article emanates from current research investigating public library use of information systems development methodologies at the Department of Information and Library Studies, University of Wales, Aberystwyth.

Library Management, Vol. 15 No. 6, 1994, pp. 5-19 MCB University Press, 0143-5124

LIBRARY MANAGEMENT

delivered on time, to budget, and closer to the requirements of the user. The SDLC consists of a series of phases, with validation and feedback at each phase. Basic phases consist of analysis, design, implementation and maintenance and review[7, p. 16], although these phases may be split or designated differently. As a multi-step approach, each step or phase should be completed before the next step can begin. This traditional SDLC has a number of advantages over the earlier hit and miss approaches that were used. The use of documentation standards has helped to ensure that system proposals are complete and facilitated communication between users and analysts. The inclusion in the analysis phase of a feasibility study, which attempts to assess the costs and benefits of alternative proposals, has enabled management to make more informed choices. However, the SDLC has numerous problems. Its use has proved to be a costly, troublesome, complex and time-consuming process[6, p. 685], leading to the paralysis by analysis syndrome[8, p. 103], where no information system is developed. The strategy of defining requirements prior to the design phase has also proved to be problematic, and such problems were exacerbated by the encouragement of last minute alterations and changes. In addition, as the SDLC does not provide a means of bridging the gap between analysis, design and implementation, its usage frequently leads to the development of systems that do not meet user or organizational needs. Also, many of these implemented systems either had to be modified substantially before they could be used, or were rejected, sabotaged or never used. This has been attributed to the technological, rather than people, emphasis of the approach taken[9, p. 36]. Furthermore, there has been a tendency to place greater emphasis on the existing, usually manual, system as a basis for the design of the new system. The resultant design would then often be unambitious and not properly reflect the software and hardware available, the solutions that were possible, nor the requirements of the new system [10, p. 22]. As a result of these problems, a number of lessons were learnt by information systems developers and users. First, the use of a life cycle consisting of documentation, control and training procedures is not enough to ensure a successful system. Second, the development of an information system should take an organizationwide view, as failings may be due to the narrowness with which the analyst perceives the information system[11, p. 459]. A combination of

these problems, and the lessons learned, led to the development of the ISDMs in current use.

What Is an ISDM?
ISDMs aim to make the process of developing information systems, whether manual or computerized, as straightforward and as simple as possible. They provide a consistent set of procedures to follow, and tools and techniques to use, thus making the process of managing and developing information systems more efficient and effective. ISDMs also represent a means for the systematic development of information systems, placing emphasis on the accurate identification of user requirements. Definitions of ISDM range from the simple to the complex. Veryard, for example, provides a simple definition of an ISDM as a generalised set of methods and procedures used in projects[12, p. 10]. A more complete definition is provided by Maddison et al., who state that ISDMs are a recommended set of philosophies, phases, procedures, rules, techniques, tools, documentation, management and training for developers of information systems[13, p. 4]. One of the most comprehensive definitions, and the one used here, is that of Avison and Fitzgerald, who define an ISDM as:
a collection of procedures, techniques, tools and documentation aids which help the systems developers in their efforts to implement a new information system ... and also help them to plan, manage, control and evaluate information systems projects[10, p. 8].

In all cases, methodology refers to more than a mere collection of tools, techniques, procedures, and so forth. It also embodies some form of philosophical view, and implies a time-dependent sequence of thinking and action stages. Jayaratna defines methodologies as an explicit way of structuring ones own thinking and action. [They] contain models and reflect particular perspectives of reality based on different philosophical paradigms[14, p. 228]. ISDMs are known by several names, including information systems methodologies[13,15], information systems design methodologies[5,16, 17], systems analysis methodologies[18] or simply methodologies[19]. For reasons of simplicity, ISDM or ISDMs will be used throughout this article to refer to information systems development methodology(ies) respectively. The term development, as opposed to design, has been standardized on in an attempt to illustrate that the process of introducing new information systems into an

VOLUME 15 NUMBER 6 1994

organization is one of greater complexity than merely the designing of a computerized solution. It indicates that a more encompassing process is used, before the decision is taken to implement. The term development is used here to suggest that the resultant information system should reflect more accurately an organization-wide, or holistic, view of the needs of the new system. The requirements of ISDMs identified in the literature provide a good indication of the type of procedures, tasks, and so on, that ISDMs can be expected to perform, in order to be effective and efficient. For example, Wasserman et al. identify 12 requirements, including that the ISDM should cover the entire development process, should enhance communication among all those people involved and should support effective problem-solving techniques[20, pp. 5557]. Boon and Opt Hof[21, p. 183] list a number of similar criteria, including that the system designed should be adaptive within a particular environment. Second, ISDMs should reflect a logical sequence, provide some form of feedback mechanisms and leave details regarding implementation until the latter stages of the design process. ISDMs should provide an organizational framework appropriate to the work required[22, pp. 63-5]. Also, they should have the capability to develop diverse systems, support various tasks during the SDLC, be easy to use, and develop information systems within the estimated time and cost[23, pp. 141-3]. Furthermore, an ISDM should be economical, reproducible, picture driven, and model the organization from the two perspectives which can be categorized thus, as is and to be. The methodology should solve the intended problem, be maintainable, and should have the extra ability to be integrative with other ISDMs[24, pp. 27-8]. However, it should be stressed that many of these requirements are recommended by researchers, rather than by practitioners. In fact, the study by Sakthivel showed that researchers and practitioners do not have the same priorities for some of these requirements[23, p. 147]. Flaatten provides a practitioners view of the requirements of an ISDM. He believes that it is necessary to plan for another generation of methodology[25, p. 223]. Among the requirements that he lists are elements such as addressing quality management, risk management, configuration management, project management, multiple system types, design paradigms, implementation strategies and other characteristics such as conciseness, integration with the tool-set, and integration with training.

Major Themes in Information Systems Development

The following seven themes have been identified by Avison and Fitzgerald[11], and provide a comprehensive grouping of current ISDMs: (1) systems approach; (2) planning approaches; (3) participation; (4) prototyping; (5) formal methods; (6) structured approaches; (7) data analysis. Each theme will now be considered in turn. Systems Approach The systems approach to developing information systems takes its roots from early management theory, and is based on Bertalanffys general system theory (GST)[26]. In terms of systems thinking, system is used to refer to the abstract idea of a whole having emergent properties, a layered structure, and processes of communication and control which in principle enable it to survive in a changing environment[27, p. 22]. Thus, such a view advocates an holistic approach, which considers the system as a whole, instead of looking at the various functions, or parts, of the system in isolation. It causes the systems developer to consider the effect that the introduction of information technology in one part of the system would have on the rest of that system. The application of systems theory to library management has been discussed elsewhere[28, 29]. The concept of system can be expressed in two pairs of ideas emergence and hierarchy, communication and control. The principal methodology based on GST is Checklands soft systems methodology (SSM)[30]. SSM was developed as an alternative approach for coping with a major problem in systems engineering that of soft, or ill-defined, problem situations. It is based on the hypothesis that the only way to develop an information system effectively is by interacting with the real problem situation, and by examining the whats and hows of the problem, before any attempt is made at a solution[27, pp. 15-8]. Thus, because SSM is concerned with discovering underlying reality, as opposed to surface perception, its use improves the understanding of the problem situation during the process of requirements definition. This is particularly so in soft problem

LIBRARY MANAGEMENT

situations, such as those encountered in many libraries, because of the people involved and the nature of the services provided. It is important to take into account the needs of the people who provide that service, as opposed only to considering technological needs. However, SSM does not provide adequate support for the actual design of a new system, or for its implementation. Planning Approaches Planning approaches to the development of information systems stress the pre-planning required in such projects. These approaches involve senior management in the analysis and determination of the objectives and strategies of an organization, commonly referred to as strategic plans. Also, they ensure that all levels of management are involved in information systems planning, thus ensuring that the resultant information system fulfils its requirements. In Hertfordshire, the local authority has made the decision to use business units that define their own sets of business plans within the context of a departmental plan. They are seeking to plan for information as a key resource in a similar way to that in which financial, capital and human resources are planned[31, p. 131]. One of the end products of these plans is an information systems strategy. An example of an ISDM predicated on the planning approach is that of business information analysis and integration techniques (BIAIT)[32]. It provides a means of checking whether the objectives of the organization are being met, and is related to systems theory. Participation In a similar way, participative management styles seek to involve the user in the process of change. Greater user involvement, together with clear job satisfaction objectives, should facilitate the successful development of an information system. The participative approach is based on four important value judgements. First, that financial, human and technical factors in information systems development can and should be treated as compatible; second, that everyone affected by change in the information system can and should be considered in planning it; third, that employees at all levels can and should develop their own information system; and, finally, that the overall approach to systems development should be based on the principle of reducing uncertainty[33, pp. 235, 238]. Utilizing the participative approach to developing information systems facilitates the construction of more readily acceptable solutions, which better meet the organisations

needs[9, p. 37]. It encourages the involvement of all levels of management, from the librarian in a small branch library to the chief librarian, increasing the number of end-user developers working in conjunction with the professional systems developer. This leads to a better understanding of the new system by the people, such as the branch librarian, who will have to use it, and is more likely to ensure successful use. It could also lead to the involvement of library assistants in the development, since they are likely to be the ones who have a lot of contact with the new system. However, the whole process can be abused. The development of the information system can be biased either by those strongly in favour of technology, or those strongly opposed to the introduction of such technology, or by those working to a hidden agenda. There have been several attempts to incorporate the ideals of the participative approach into suitable methods for developing information systems. One such attempt is the ISDM ETHICS (Effective Technical and Human Implementation of Computer-based Systems), which is built around the principles identified above[34]. It is also derived from the sociotechnical approach to developing information systems, the primary purpose of which is to produce technical and social structures that have a high capacity to achieve technical and social goals and which reinforce each other in the achievement of these goals. In ETHICS, for the developed system to be effective, the technology used must provide a close fit with organizational and social factors. Prototyping A further development of the participative approach that advocates user involvement in the process of developing information systems is prototyping. This approach, through high levels of user involvement, attempts to present the user with an early view of the proposed system. Prototyping is good for use in dynamic contexts, such as libraries. For example, it could be used to develop one-off, very specialized systems, such as an online public access catalogue (OPAC) for a collection of non-standard material. The use of prototyping would allow users to try out the prototype in its different evolutions, suggesting ways in which it could be improved, or features that would be useful. However, prototyping is unsuitable if the system to be used is an integrated package, rather than a unique system developed for a particular function. Prototyping has been defined as the process of quickly building a model of the final software system, which is used primarily as a

VOLUME 15 NUMBER 6 1994

communication tool to assess and meet the information needs of the user[35, pp. 119-20]. It encourages the development of better-fit systems that is, information systems that are developed on time, to budget, and which fulfil user requirements[9, p. 4]. Lantz[36], for instance, describes a prototyping methodology which consists of the following seven phases: (1) determine feasibility study; (2) study present system; (3) define prototype; (4) build prototype; (5) exercise prototype (which consists of programming, testing, acceptance testing and user training); (6) conversion; (7) installation of the final information system. The definition, building, exercising and conversion of the prototype are carried out in parallel, thus allowing many iterations in the process of developing the system. Because prototyping embraces higher levels of user involvement, systems are developed more quickly, are easier for users to learn how to use and provide a more flexible systems design[36, pp. 11-13]. However, this high level of user involvement can result in frustration, or in unrealistically high expectations[35, pp. 121-2]. The former is more likely to occur with iterative prototyping, since this type of prototyping involves a delay between the first workable prototype and the final prototype that becomes the finished system. Users may not appreciate this delay, when earlier prototypes appear to be adequate, although they do not necessarily have all the relevant features. Unrealistic expectations can prove to be more of a problem with throwaway (or development) prototyping. In this situation, the final prototype is not identical to the finished system. The prototype, having been developed using a fourth generation language, is used as the specification for the final system which is built using a third generation language. Thus, features may differ between the prototype and the final system. The prototyping methodology is particularly suited to solving unstructured problem situations, and to developing management information systems, decision support systems, executive support systems[37] and knowledge-based systems[38, p. 93]. Formal Methods In contrast, formal methods of developing information systems, such as the Vienna

Development Method (VDM) and Z[39], are based on mathematics. Mathematical notation is used to describe the properties which an information system must have, without unduly constraining the way in which these properties are achieved. Thus, mathematical expressions are used to explain what the system will do (i.e. the logical view), without actually saying how this will be done (i.e. the physical view). The use of mathematical data types to model the data in the system make it possible to reason effectively about the way in which the specified information system will work[39, p. 40].

Mathematical precision enables results to be correctly proven

n
Mathematical precision, which is used during the processes of specification and design, enables results to be correctly proven. However, this is predicated on the assumption that the calculations used, and the mathematics employed in expressing the system, are both accurate and valid, and that they constitute an appropriate means for representing the situation. Formal methods are more suited to developing solutions to hard problem areas, and are generally used to develop information systems in the safety critical sphere. Thus some of the main users of formal methods are the military, who can afford the expense incurred in their use. These costs constitute the major problem with formal methods, which also cannot be used to express all aspects of information requirements[10, p. 52]. For these reasons, formal methods are not suited for use in the library context. Structured Approach The structured approach to developing information systems is based on functional decomposition that is, the breaking down of complex entities into manageable units in a disciplined manner. Thus, for the development of a library information system, the use of the structured approach would ensure that each area, such as management information or circulation control, can be viewed in a manageable way and form. Structured approaches are often used as the standard within an organization; for public libraries, for example, the parent body, the local authority, may decide to standardize on a structured approach for developing information

LIBRARY MANAGEMENT

systems, thereby making the process of such development consistent across the authority. It also ensures that each department, including the public library, uses the same approach. Emphasis is placed on the systematic procedures of analysis and design, which are organized within a framework of steps and stages. Structured methods, such as Yourdon[40] and SSADM (Structured Systems Analysis and Design Methodology)[41], have a number of advantages over other approaches. The step-bystep procedure, from a current physical view of the system to the required physical view, is easier for the human brain to comprehend than are large conceptual leaps. The manageable pieces of information used in this approach provide the systems developer with a well-organized and estimated procedure. It also ensures that each area of the system can be viewed in a manageable way and form. SSADM (version 4 of which was developed under the control of CCTAs PRINCE and influenced by PRINCE concepts) is the standard used throughout the Civil Service, including libraries[42, p. 6/1]. Nevertheless, the use of functional decomposition can cause problems. Areas of the system may be looked at in isolation, thus resulting in any knock-on effects being missed, or ignored. Adherence to a rigid framework creates difficulties in soft problem situations, where it may be necessary to explore areas in the problem situation not catered for in the framework. Furthermore, the greater emphasis placed on the processes involved in the system is often to the detriment of the data used. To a limited extent, structured approaches inherit the problems of the SDLC on which they are based. Thus, they may lead to requirements being set before the problem is properly understood. Structured approaches have been categorized as yesterdays philosophy[43]. Data Analysis The final approach identified is data analysis, which places emphasis on a complete and thorough analysis of the data and their relationships[15, p. 53]. It concentrates on understanding and documenting the data in a system, rather than on the processes involved. It has been argued, in support of this approach, that data represent the fundamental building blocks of systems[10, p. 55]. Data analysis is used to build a data model of the information system that is independent of implementation. This data model is oriented towards the part of the real world that it represents, whether towards the entire organization, or towards a section of that

organization. Data analysis can be used to develop any type of system, whether computerized or manual, and is particularly suited to bridging the gap between an old manual system and the new computerized system which replaces it. Thus, it would be suitable for use in a library which is planning to develop its first computerized information system, such as automating cataloguing, circulation control and providing an OPAC. The production of a good data model through the use of data analysis does not necessarily lead to the development of an information system. It can be both an end in itself, and can be used to gain a better understanding of the organization. Thus, it could be used to garner a thorough understanding of the data used in a library, and the way that data flows through the system, hence improving the overall understanding of how the library operates. Many ISDMs use data analysis as their basis for a number of reasons, viz: (1) The data model is readily understandable by everyone concerned, including the user. (2) It does not show a bias towards a particular user or departmental view. (3) As the modelling processes used are rulebased, the results of any work performed can be assessed and, to a certain extent, proven. However, the use of data models can cause problems, since it is doubtful whether it is possible to model reality in an objective manner; the data model can only be a model of the system, from a particular point of view, rather than the model of the system, which is objective and all-encompassing[44].

Problems
Problems associated with ISDMs fall into two main types: those concerned with the methodologies themselves, and those concerned with the use of ISDMs. Examples of the former type have been considered in relation to the different themes in IS development. However, there are some problems directly related to the concept of an ISDM, including the performance of unnecessary tasks as specified by the methodology, or the non-performance of a necessary task because it was not specified by the methodology. Furthermore, there may be tasks which are incorrectly or inadequately performed as a result of deficiencies in the ISDM. Finally, some ISDMs are too vague and unspecific, too rigid and inflexible, not properly understood or not properly followed, or just not suited to a particular type of project[12, p. 9].

10

VOLUME 15 NUMBER 6 1994

In addition, Benyon and Skidmore believe that the artificial freezing of requirements at some point in time means that ISDMs cannot cope with developing information systems in certain areas[18, p. 2]. First, they cannot cope with rapidly evolving microcomputer hardware and software. For instance, existing ISDMs are not designed to develop systems based on packages, an area that is discussed in more detail later. The increased proliferation of soft problem situations has raised a number of issues relating to the definition of requirements. In particular, it highlights that freezing requirements too early often results in the development of unsuitable systems. Furthermore, current ISDMs are not designed to deal with the development of new and powerful types of software, such as application generators.

Requirements definition and system design are entwined

n
The entire sphere of requirements definition is subject to contention and debate in the information systems community[45-47]. To understand the nature of the debate, it is necessary to elaborate on the approach taken to requirements definition in the systems development life cycle (SDLC), since many of the current ISDMs, although not specifically predicated on the SDLC, follow the traditional waterfall approach to developing information systems[48]. In the SDLC, the requirements act as the unalterable blueprint of the new system. Once defined (or specified), they are signed off by the user, before the process of design can begin. It is these requirements and their definition that are at the heart of the problems with the traditional SDLC. Increasingly, the basic assumption that requirements definition and system development are separate procedures is being challenged. Gladden contends that the approach to requirements definition in the SDLC is fundamentally wrong, resulting in requirements that are improperly defined and usually altered at the last minute, leading to confusion[45]. An extension of this argument contends that requirements definition and system design are entwined users cannot decide on requirements before the system is designed when they do not really know what they want[49]. In addition, the supposedly separate steps of specification and

implementation are seen as inextricably linked[50]. Each specification, or requirements definition, is the implementation of higher-level requirements. As each set of requirements is designed and implemented, new requirements are discovered. This process continues iteratively until the final set of requirements results in the specification of the best system. In this way, it is easier to specify and implement at the same time. Shemer believes that the definition of a problem and its solution (requirements definition and system design) are inter-dependent, making it a mistake to consider requirements specification and systems design independently[46]. Extending this argument, Brooks believes that it is impossible to specify completely, precisely and correctly the exact requirements of an information system without trying out some version of the product first, for example by building a prototype of the proposed information system[47]. These problems with requirements definition do not apply as strongly in some cases; certain problem situations (such as pay-roll systems) are well understood and well documented. In these cases, it is relatively easy to specify requirements before designing a new system. Conversely, in soft problem situations, it is almost impossible to define the requirements accurately before the system is designed. Requirements alter as more is learnt about the needs of the new system. Therefore, they should be considered in conjunction with the design of the new system, and not be defined too early in the process. Jayaratna believes that the problem of capturing the correct user requirements should be addressed explicitly within the ISDM itself[14, p. 230]. Although it is apparent that the place of requirements definition in the SDLC and in many ISDMs requires much consideration, there is, nevertheless, no completely right or wrong approach. However, it is no longer sufficient to advocate a multi-step approach, with requirements and design as two separate steps. Conversely, it is not possible to specify in advance what is required, unless there is prior access to some type of solution. This is a situation to which there is no answer. Although it can be argued that specification and implementation should be performed in conjunction with and parallel to each other, in some cases this approach may not be necessary. The second type of problem is associated with the use of ISDMs. One such is the applications backlog, for which there are numerous causes[9, 46, 51, 52]. For example, the relative cost of hardware is decreasing drastically, whilst the software cost is increasing at a similar rate.

11

LIBRARY MANAGEMENT

Generally, software improvements have not kept pace with improvements in hardware, resulting in relatively crude software being run on more sophisticated, continually evolving, hardware. Another major cause of the applications backlog is the maintenance of developed systems, in terms of cost and time. Maintenance costs are two to four times greater than delivery costs, with the relative cost of fixing post-delivery problems 50100 times greater than for solving pre-delivery problems. These costs can be placed in perspective, when it is known that 45 per cent of problems requiring maintenance are detected only after completion of acceptance tests[46, p. 506]. In addition, solving post-delivery problems impinges considerably on the time and money available for developing new systems. The applications backlog is exacerbated by the incorrect design of information systems, an increasing number of which are developed that fail to satisfy user needs[14, p. 229]. Often, this is caused by the use of the wrong ISDM for developing a particular information system, or by users who do not really recognize their requirements at the time of system development. An illustration of the severity of the problem is provided by Figure 1. Although these figures are not representative of the whole field, industrial evidence does confirm that a significant number of information systems, developed at great cost, fail to meet the needs of users, or have to be revised before they become acceptable[14, pp. 229-30]. Other problems in using ISDMs include the general lack of knowledge about the design process. For example, Boon and Opt Hof believe that information systems designed mainly on an ad hoc basis require very thorough analysis and the most accurate requirements possible, as the costs of developing such systems are prohibitive[21, pp. 180-86]. Additionally, ad hoc
3 per cent (used after change) 2 per cent (used as delivered) 19 per cent (abandoned or reworked) 29 per cent (paid for but not delivered)

information systems are often developed without any thought being given to their integration with current or future information systems, which causes problems in the long term. In turn, this adds to the applications backlog. A further problem associated with the use of ISDMs is that all the variables involved in the design process of information systems development have not yet been properly defined or studied[21, p. 180].

Future Directions
Clearly, ISDMs are not perfect. The discussion of the current themes in information systems development has also shown that no single approach is entirely suitable, without some modification. For example, structured ISDMs can be criticized for ignoring many aspects of accurately determining requirements and for their rigidity. Alternatively, systems ISDMs can be criticized for not addressing properly the design and implementation of the new information system, as they are more concerned with establishing the nature of the problem. Nevertheless, many of these approaches will continue to be of importance. Currently, the common perception is that a series of radical changes in information systems development is at an end, and equilibrium has been reached[10, p. 309]. However, as illustrated by the various problems with the approaches discussed previously, there are a number of areas that future ISDMs need to address to ensure the management and development of the most appropriate and effective system. Future directions for ISDMs fall into five main areas[5, 10, 11]: (1) blended methodologies; (2) the automation of information systems development; (3) the impact of advances in microprocessing and software packages; (4) the requirements of management; (5) the emergence of knowledge-based systems. All of these directions will have an impact on the management and development of library information systems in the future. The viability of these directions will now be discussed. Blended Methodologies Blending methodologies involves the refinement of existing ISDMs, where each ISDM is extended until it incorporates the successful aspects of other ISDMs. Hence, it would permit libraries to follow a framework when managing and developing information systems, while also

47 per cent (delivered but not used)

Source: [14, p. 229]

Figure 1. US Federal Software Projects (Total Software Budget of $6.2m)

12

VOLUME 15 NUMBER 6 1994

allowing them some freedom in selecting the most appropriate tools and techniques to use. It would also facilitate the development of an ISDM specifically for libraries, based on the most appropriate sections of existing ISDMs. However, this strategy is not without its problems. Avison et al.[53] identify problems which fall into two main areas: (1) those related to deficiencies in the design techniques and tools themselves; (2) those related to the environment into which the techniques are being introduced. Blending methodologies leads to three potential types of outcome: first, the development of a single methodology; second, the development of meta-methodologies; and, finally, the employment of a contingency approach. These will now be discussed in turn. Single Methodology Theoretically, a single methodology could be developed which would be suitable for use in all types of problem situation and with all types of information system. Such a methodology would improve the consistency of the strategies used. However, it has been said that the chase for the perfect methodology is somewhat illusory, because different methodologies require different views of the world[54, p. 101]. This is due to the incompatible objectives and fundamental principles on which ISDMs are based. Moreover, as no one methodology could be suitable in every situation[20, 55], such a development is unlikely to occur. Rowley reinforces this, stating that it is unlikely that one methodology will be appropriate in all situations where a library information system is to be introduced or upgraded[56, p. 292]. Furthermore, the competitive marketing of individual ISDMs would appear to preclude the blending of ISDMs[11, p. 462]. Meta-methodology A meta-methodology consists of the blending of two or more ISDMs with different philosophies, objectives and scope. This type of methodology includes a set of phases, techniques and tools that are selected from within a single methodological framework according to the particular problem domain. The employment of such a framework should allow flexibility during this selection process, whilst simultaneously maintaining the advantages of using a common methodological basis. The best known example of a metamethodology is Multiview, which is an explorative structure consisting of a loose framework used to define and develop an

information system[57]. Multiview seeks to incorporate the advantages of a good approach to understanding requirements with a semistructured process for design. It could prove particularly useful for libraries, by supplying a solution to two problems: understanding the soft problem area while also actually developing a system that will help solve this problem. However, in the short term, the appearance of another widely used meta-methodology seems unlikely, for a similar reason to that offered for the development of a single methodology; that is, the competitive marketing of existing ISDMs[11, p. 462]. Contingency Approach The contingency approach was first suggested by Davis[58], and is an approach whereby an ISDM (selected from an approved set of ISDMs) is chosen depending on the particular circumstances to which it applies. Davis suggests that the level of uncertainty in a situation will be critical to this choice. Thus, the methodology adopted will be contingent on the situation according to the complexity of the problem and the levels of user and systems developer competence. However, the disadvantage of such an approach is the loss of the practical benefits of ISDMs, such as common methods, improved control and a single conceptual approach. Nevertheless, it does provide flexibility in the choice of techniques used, rather than limiting the library manager to the tools and techniques provided by one methodology. Episkopou and Wood-Harper[59] suggest a possible framework for choosing ISDMs, or parts of ISDMs, based on a contingency approach. This framework is adapted from Checklands model of a problem-solving content system[30]. The matching system suggested involves identifying and describing the roles in the problem-solving process and the environments in which these roles lie. It enables the systems developer to select the most appropriate approach(es) for developing each information system, to make more sense of the situation and to become less reliant on past experience[59, p. 227]. Although theoretically possible, the contingency approach may have too many problems within its conception to justify it becoming commercially available. Automation of Information Systems Development A characteristic of methodical activities such as ISDMs is that they involve significant amounts of information handling that benefit greatly from computer support. Computerized support of some previously manual tasks has been available since the mid-1980s from software that has been

13

LIBRARY MANAGEMENT

specifically designed to assist in all aspects of information systems development[15, p. 285]. CASE (computer-aided systems engineering) tools, for example, have helped to eliminate some of these time-consuming and mundane manual tasks, such as documentation and maintenance of system consistency, completeness and correctness. They free the systems developer to concentrate on the creative, rather than the rudimentary, work of developing information systems[60, p. 108]. Thus, the developer of a library information system would be liberated from ensuring that the documentation was consistent, and could instead concentrate on developing the best system possible. The automation of information systems development is having a fundamental effect of simplifying the methodologies, by making the various activities involved more consistent. For example, automation has changed existing ISDMs, where the information engineering facility (IEF) has altered the information engineering methodology to the extent that, where feasible, the process of producing programming code based on the specification is automated[61]. Ultimately, it is hoped that ISDMs in general will not need to address the programming side of systems development, as it will have been absorbed into the automated section of the methodology. Automation is also likely to alter the specification for the new system radically. For example, instead of a specification written on paper, often running to volumes, a prototype could be used as the final specification. Flaatten believes that the ultimate ISDM would be to let a knowledge-based system assist the system developer, and actually generate a proposal for a work programme, embodying the selected techniques and tailored to a particular environment[25, p. 228]. In conjunction with this proposition, Flaatten identifies an additional step, where the process of developing information systems could become more responsive by including a number of reusable systems development tools and techniques, such as data flow diagrams and data structures, with the ISDM. In this way, the ISDM would be interactive, and could suggest which tool and technique to use in a particular situation, as well as suggesting a generic solution to the design problem being addressed, based on previous, similar situations. Moreover, the expertise gained from developing library information systems could be used to assist the process of developing future library information systems by providing a basis from which to work, and also highlighting some of the potential pitfalls.

Microprocessing and Packages Over the last decade, there have been significant developments in the microprocessing and packages market namely, the falling cost of microcomputers and their increasing power. Microcomputers are increasingly to be found in libraries, used for a number of tasks, from word processing of documents through to administration uses and access to online searching of both remote hosts and CD-ROMs[62]. In addition, although many turnkey systems are bought, there is an increasing move towards purchasing hardware and software separately[63]. This means that many developers of library information systems will be choosing from a limited number of software packages, as opposed to developing a one-off system[64]. Also, the drive towards open systems means that library managers will not be restricted to using the hardware provided with the software, but will be able to select the hardware that they consider to be most appropriate for all their needs independently of the software purchased. Currently, most ISDMs assume that systems will be developed in-house and tailor-made and do not provide proper facilities to assist the selection and evaluation of packages. ISDMs do not necessarily ignore packages; rather, they do not provide the necessary tools, the exception being the metamethodology Multiview discussed earlier, which has been used mainly for microcomputer applications using existing packages[10, p. 251]. Nevertheless, Flaatten believes that ISDMs should provide for the selection and installation of packaged software[25, p. 228]. Moreover, Launi believes that without a formal methodology for off-the-shelf software implementation, an organisation will find itself forever installing a system that may not even meet its mandatory requirements[65, p. 9]. Therefore it is essential that an ISDM specific to the evaluation and implementation of an off-the-shelf package is developed, or that existing ISDMs address in greater detail the problems of package evaluation and selection. An ISDM that can develop information systems using software packages would be of great benefit to the library. Requirements of Management Future ISDMs will have to pay more heed to the requirements of all levels of management. Particular attention will have to be given to the requirements of senior management involved in decision making and strategic planning. These requirements are met by a particular type of information system namely, management

14

VOLUME 15 NUMBER 6 1994

information systems (MIS). MIS fall into three main types aimed at different levels of management[66, pp. 15-17]: management information systems (MIS), used here in the specific rather than the generic sense used earlier; decision support systems (DSS); and, more recently, executive support systems (ESS). All of these provide managers with accurate, timely and relevant information. MIS, as a form of information system, are a feature of many library housekeeping systems, and provide valuable tools for interpreting internally produced information.

ISDM developed specifically for KBS might be possible

n
However, current ISDMs (excluding prototyping) concentrate on developing information systems aimed for the operational level of management rather than on information systems that will assist the decision makers in an organization. Sprague believes that DSS development requires a different design technique from those used to develop transaction processing systems. He recommends a development process where analysis, design, construction and implementation are combined into a single, iteratively repeated step[67, p. 466]. In addition, Sprague identifies a number of implications that the development of DSS will have on the traditional SDLC, and thus on existing ISDMs. He advocates an adaptive design process which requires a redefinition of systems development milestones and a major modification of project management mechanisms[67, p. 470]. This will result in the involvement of the systems developer in a participative ongoing process where the developer becomes an assistant problem solver rather than a system builder. Knowledge-based Systems Knowledge-based systems (KBS), or expert systems, have emerged in the marketplace, targeted at business, with the recommendation that managers should give serious consideration to using them[68]. They have been defined as systems that contain domain-specific knowledge and mechanisms for manipulating that knowledge in order to produce systems that perform at the level of a human expert[68, p. 421]. KBS could be used in the libraries of the

future to produce an intelligent guide to the library, and also to aid the processes of cataloguing, classification and online searching. The key assumption in knowledge-based systems is that knowledge can be elicited from experts in a practical manner, an assumption which forms one of the main differences between KBS and conventional systems. Other differences that have been identified are differing objectives, ways of representing knowledge, and data structures[68, pp. 416-8]. In addition, KBS development projects, unlike other systems development projects, exhibit non-conformity, where each new system can require the developer to learn a new implementation environment. However, existing ISDMs can be learnt, and then transferred onto other development projects. The knowledge elicitation (KE) process, which West sees as a process of locating and extracting expertise from a human expert[69, p. 31], is one of the most difficult aspects of developing KBS. Typically, a tool-box of techniques, reflecting the technology-driven methods and models of conventional systems development, is used in the KE process. However, West questions the efficacy of such an approach on the grounds that human expertise cannot be represented by such rationalist methods. KE requires a methodology that is developed on sound practical and theoretical foundations. Such an alternative approach is one where the application of KE is an enquiring, rather than extractive, system. Consequently, an increased understanding of the domain of expertise is encouraged, within which the task of knowledge extraction and formalization may be more easily achieved[69, p. 43]. West also suggests that an ISDM developed specifically for KBS might be possible through the application of systems ideas, particularly those referring to inquiring systems. Although it has been argued that prototyping represents a good approach to developing KBS[38, p. 93], it is not used solely for this purpose. What is clear is that the future development of such an ISDM is going to require much thought and research before a workable solution can be proposed. One solution that has been postulated for the practical engineering of KBS is POLITE (productobjectives-logical/physical-design-implementtest-edit). This methodology consists of the traditional waterfall model used by conventional ISDMs, which is combined with the RUDE (rununderstand-debug-edit) paradigm. Thus, the RUDE cycle is augmented so that it becomes POLITE[70, p. 208].

15

LIBRARY MANAGEMENT

Conclusion
There are a number of reasons why ISDMs should be used in the library context. First, the procedures, tools, techniques and concepts found in all ISDMs can be taught to new users. This means that library managers could easily apply ISDMs to the management and development of information systems. Second, ISDMs provide a framework and a set of guidelines that are aimed specifically at the management and development of information systems, thus ensuring that the unique features of library information systems development, for example, are met adequately. Third, consistency in the development process should lead to consistency in the system developed and, hence, in its maintenance. Thus, in theory, it should be relatively easy for new people, irrespective of how much prior experience they may have in using ISDMs to develop library information systems, to join the development project. Fourth, as ISDMs provide discipline in the development process, they reduce reliance on intuition and the need for an experienced systems developer. Therefore, in the library context, this would enable library managers with no prior experience to use ISDMs to develop information systems, and would also widen the scope for involving many different people in the development process. Fifth, the use of ISDMs improves the completeness and quality of the information systems, as the development process and its results are open to checking; hence, the effective and efficient development of the information systems can be facilitated. Finally, the application of ISDMs to systems development helps to minimize user resistance to technological change. The human facet of information systems development is often neglected; people form the unexpected dimension, and ultimately decide whether a system is successful or not. This decision can sometimes be made irrespective of the technical merits of the system, or whether it performs the intended tasks. However, ISDMs particularly systems, prototype and participative ISDMs take into consideration the needs of all users. User dissatisfaction is also reduced, because ISDMs aid effective communication between systems developers and users. This reduces the risk of the new systems being presented to the users as a fait accompli. ISDMs also facilitate more efficient management of projects, and make the resultant system more open to inspection. Furthermore, the use of ISDMs to develop information systems can produce a better end product. This is related to improved documentation control, improved consistency and

the likelihood of improved user acceptance. It could be argued that ISDMs lead to the development of the most suitable information systems for an organization, in that ISDMs were specifically developed to perform such a task. However, this is a statement that is difficult to assess objectively. Despite the problems with ISDMs, they have an important role to play in the development of information systems. The concept of an ISDM providing a consistent process whereby information systems can be developed is potentially suitable for use by libraries. It should bring an ordered approach to the previously haphazard process of development, whilst at the same time encouraging the people involved to produce the best possible system. This article has sought to illustrate the potential relationship between ISDMs and library management, although little is known about this, as evidenced by the limited literature on the topic [29, 56, 71]. Furthermore, very little is known about the actual application of ISDMs in the context of library management and the development of information systems, or if they are used at all. It is hoped that this review will act as the basis for further research into this area.

n
References
1. Batt, C., New Technology in Public Libraries: Preparing the Future, in Harris, C. and Clifford, B. (Eds), Public Libraries: Reappraisal and Re-structuring, Rosendale, London, 1985, pp. 53-65. 2. McKee, B., Public Libraries: Into the 1990s, AAL Publishing, Newcastle under Lyme, 1987. 3. McKee, B., Planning Library Service, Library Association Publishing, London, 1989, p. 38. 4. Fitzgerald, G., Hirscheim, R., Mumford, E. and Wood-Harper, A., Information Systems Research Methodology: An Introduction to the Debate, in Mumford, E. et al.(Eds), Research Methods in Information Systems, Elsevier Science Publishers, Amsterdam, 1985, pp. 3-9. 5. Veryard, R., Future of Information Systems Design Methodologies, Information and Software Technology, Vol. 29, 1987, pp. 33-7. 6. Lee, D.T., Computer Information System Development Methodologies: A Comparative Analysis, in AFIPS Conference Proceedings, Vol. 56, National Computer Conference, AFIPS Press, Reston, VA, 1987, pp. 683-92.

16

VOLUME 15 NUMBER 6 1994

7. Daniels, A. and Yeates, D., Basic Systems Analysis, 3rd ed., Pitman, London, 1988, p. 16. 8. Tozer, E.E., Fourth Generation Development Techniques, in Bytheway, A. (Ed.), Structured Methods: A State-of-the-art Report, Pergamon Infotech Ltd, Maidenhead, Berks, 1984, pp. 101-14. 9. Dearnley, D.A. and Mayhew, P In Favour of .J., Systems Prototypes and Their Integration into the Systems Development Cycle, Computer Journal, Vol. 26 No. 1, 1983, pp. 36-42. 10. Avison, D.E. and Fitzgerald, G., Information Systems Development: Methodologies, Techniques and Tools, Blackwell Scientific, Oxford, 1988. 11. Avison, D.E. and Fitzgerald, G., Information Systems Development: Current Themes and Future Directions, Information and Software Technology, Vol. 30, 1988, pp. 458-65. 12. Veryard, R., What Are Methodologies Good For?, Data Processing, Vol. 27 No. 6, 1985, pp. 9-12. 13. Maddison, R.N., Baker, G.J., Bhabuta, L., Fitzgerald, G., Hindle, K., Song, J.H.T., Stokes, N. and Wood, J.R.G., Information System Methodologies, Wiley Heyden on Behalf of the British Computer Society, Chichester, 1983. 14. Jayaratna, N., Systems Analysis: The Need for a Better Understanding, International Journal of Information Management, Vol. 10, 1990, pp. 228-34. 15. Olle, T.W., Hagelstein, J., Mcdonald, I.G., Rolland, C., Sol, H.G., Van Asscher, F.J.M. and Verrijn-Stuart, A.A., Information Systems Methodologies: a Framework for Understanding, Addison-Wesley, Wokingham, 1991. 16. Olle, T.W., Sol, H.G. and Verrijn-Stuart, A.A. (Eds), Information Systems Design Methodologies: A Comparative Review, North-Holland, Amsterdam, 1982. 17. Olle, T.W., Sol, H.G. and Tully C.J. (Eds), Information Systems Design Methodologies: A Feature Analysis, North-Holland, Amsterdam, 1983. 18. Benyon, D. and Skidmore, S., Towards a Tool Kit for the Systems Analyst, Computer Journal, Vol. 30 No. 8, 1987, pp. 2-7. 19. Kehoe, D.F., Little, D. and Lyons, A.C., Measuring a Company IQ, in Proceedings, Third International Conference on Factory 2000: Competitive Performance through

20.

21.

22. 23.

24.

25.

26. 27.

28.

29.

30. 31.

32.

33.

Advanced Technology, IEE, London, 1992, pp. 173-8. Wasserman, A.I., Freeman, P and Porcella, M., . Characteristics of Software Development Methodologies, in Olle, T.W., Sol, H.G. and Tully, C.J. (Eds), Information Systems Design Methodologies, North-Holland, Amsterdam, 1983, pp. 37-62. Boon, J.A. and Opt Hof, M.S., Methodology for the Design of Information Systems, South African Journal of Librarianship and Information Science, Vol. 58, 1990, pp. 180-6. Daniels, A. and Yeates, D., Practical Systems Design, Pitman, London, 1984. Sakthivel, S., Methodological Requirements for Information Systems Development, Journal of Information Technology, Vol. 7, 1992, pp. 141-8. Mastro, V.A., Three-dimensional Systems Development Enhances Productivity, Data Management, Vol. 24 No. 3, 1986, pp. 26-33. Flaatten, P Requirements for a Life-cycle .O., Methodology for the 1990s, in Cotterman, W.W. and Senn, J.A. (Eds), Challenges and Strategies for Research in Systems Development, Wiley, Chichester, 1992, pp. 221-34. von Bertalanffy, L., General System Theory, Braziller, New York, NY, 1968. Checkland, P and Scholes, J., Software . Systems Methodology in Action, John Wiley & Sons Ltd, Chichester, 1990, pp. 15-18, 22. Gilchrist, A., Systems Design and Planning, in Anthony, L.J. (Ed.), Handbook of Special Librarianship and Information Work, ASLIB, Woking, 1982, pp. 9-35. Underwood, P Managing Change in .G., Libraries and Information Services: A Systems Approach, The Library Association, London, 1990. Checkland, P Systems Thinking, Systems .B., Practice, John Wiley, Chichester, 1981. Dudley, M.P IS Strategies and Libraries: ., The Business Case for Change?, in Auckland, M. (Ed.), Computers in Libraries International, Meckler, London, 1993, pp. 130-4. Burnstine, D.C., BIAIT: An Emerging Management Engineering Discipline, BIAIT International, New York, NY, 1986. Mumford, E., Land, F. and Hawgood, J., A Participative Approach to the Design of Computer Systems, Impact of Science on Society, Vol. 28, 1978.

17

LIBRARY MANAGEMENT

34. Mumford, E. and Weir, M., Computer Systems in Work Design: The ETHICS Method, Associated Business Press, London, 1979. 35. Carey, J.M., Prototyping: Alternative Systems Development Methodology, Information and Software Technology, Vol. 32, 1990, pp. 119-26. 36. Lantz, K.E., The Prototyping Methodology, Prentice-Hall, Englewood Cliffs, NJ, 1986. 37. Palvia, P and Nosek, J.T., An Empirical . Evaluation of Systems Development Methodologies, Information Resources Management Journal, Vol. 3 No. 3, 1990, pp. 23-32. 38. Hart, A., Expert Systems: An Introduction for Managers, Kogan Page, London, 1988. 39. Spivey, J.M., An Introduction to Z and Formal Specifications, Software Engineering Journal, January 1989, pp. 40-50. 40. Yourdon, E. and Constantine, L., Structured Design, Yourdon Press, New York, NY, 1975. 41. Cutts, G., Structured Systems Analysis and Design Methodology, Blackwell Scientific Publishing, Oxford, 1987. 42. Rose, G.B., SSADM: The Open Methodology, in IEE Colloquium on an Introduction to Software Design Methodologies, The Institute of Electrical Engineers, London, 1991, pp. 6/1-6/5. 43. Vidgen, G. and Hepworth, J., Yesterdays Philosophies, British Journal of Healthcare Computing, Vol. 7 No. 7, 1990, pp. 19-20. 44. Kent, W.A., Data and Reality, North-Holland, Amsterdam, 1978. 45. Gladden, G.R., Stop the Life-cycle, I Want to Get off, Software Engineering Notes, Vol. 7 No. 2, 1982, pp. 35-9. 46. Shemer, I., Systems Analysis: A Systemic Analysis of a Conceptual Model, Communications of the ACM, Vol. 30, 1987, pp. 506-12. 47. Brooks, F.P No Silver Bullet: Essence and ., Accidents of Software Engineering, Computer, Vol. 20 No. 4, 1987, pp. 10-19. 48. Boehm, B.W., Software Engineering, IEEE Transactions on Computers, Vol. C-25, 1976, pp. 1226-41. 49. McCracken, D.D. and Jackson, M.A., Lifecycle Concept Considered Harmful, Software Engineering Notes, Vol. 7 No. 2, 1982, pp. 29-32. 50. Swartout, W. and Balzer, R., On the Inevitable Intertwining of Specification and

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

Implementation, Communications of the ACM, Vol. 25, 1982, pp. 438-40. Boehm, B.W., Improving Software Productivity, Computer, Vol. 20, 1987, pp. 43-57. Daly, E.B., Management of Software Development, IEEE Transactions on Software Engineering, Vol. SE-14, 1988, pp. 229-42. Avison, D.E., Shah, H.U., Powell, R.S. and Uppal, P Applying Methodologies for .S., Information Systems Development, Journal of Information Technology, Vol. 7, 1992, pp. 127-40. Avison, D.E. and Wood-Harper, A.T., Information Systems Development Research: An Exploration of Ideas in Practice, Computer Journal, Vol. 34, 1991, pp. 98-112. Saarinen, T., Systems Development Methodology and Project Success: An Assessment of Situational Approaches, Information and Management, Vol. 19, 1990, pp. 183-93. Rowley, J.E., Information Systems Methodologies: A Review and Assessment of their Applicability to the Selection, Design and Implementation of Library and Information Systems, Journal of Information Science, Vol. 19, 1993, pp. 291-302. Wood-Harper, A.T., Antill, L. and Avison, D.E., Information Systems Definition: The Multiview Approach, Blackwell Scientific Publications, Oxford, 1985. Davis, G.B., Strategies for Information Requirements Determination, IBM Systems Journal, Vol. 21, 1982, pp. 4-30. Episkopou, D.M. and Wood-Harper, A.T., Towards a Framework to Choose Appropriate IS Approaches, Computer Journal, Vol. 29, 1986, pp. 222-8. Wrycza, S., The Impact of CASE Tools on Teamwork of Information Systems Developers, in Finkelstein, A., Tauber, M. and Traunmuller, R. (Eds), Human Factors in Analysis and Design of Information Systems, North-Holland, Amsterdam, 1990, pp. 105-21. MacDonald, I.G., Automating the Information Engineering Methodology with the Information Engineering Facility, in Olle, T.W., Verrijn-Stuart, A.A. and Bhabuta, L. (Eds), Computerised Assistance During the Information Systems Life-cycle, Elsevier Science Publishers, Amsterdam, 1988, pp. 337-73.

18

VOLUME 15 NUMBER 6 1994

62. Batt, C., Micros in (Public) Libraries: Past, Present and Future, ITS News, Vol. 26, 1992, pp. 32-5. 63. Heseltine, R., New Directions in the Library Automation Industry: the Prospects for Structural Change, in Auckland, M. (Ed.), Computers in Libraries International 93, Meckler, London, 1993, pp. 125-9. 64. Rowley, J., Making the Right Choice: Strategies and Pointers for the Selection of Library and Information Systems, Managing Information, Vol. 1 No. 2, 1994, pp. 26-31. 65. Launi, J.D., A Structured Methodology for Off-the-shelf Software Implementations, Journal of Systems Management, Vol. 42 No. 10, 1991, pp. 6-9. 66. Senn, J.A., Information Systems in Management, 4th ed., Wadsworth, Belmont, California, CA, 1990. 67. Sprague, R.H., Decision Support Systems: Implications for the Systems Analyst, in Cotterman, W.W., Couger, J.D., Enger, N.L. and Harold, F. (Eds), Systems Analysis and Design: A Foundation for the 1980s, Elsevier North-Holland, New York, 1981, pp. 461-73.

68. Turner, J.A., A Comparison of the Process of Knowledge Elicitation with that of Requirements Determination, in Cotterman, W.W. and Senn, J.A. (Eds), Challenges and Strategies for Research in Systems Development, Wiley, Chichester, 1992, pp. 415-30. 69. West, D., Knowledge Elicitation as an Inquiring System: Towards a Subjective Knowledge Elicitation Methodology, Journal of Information Science, Vol. 2 No. 1, 1992, pp. 31-44. 70. Edwards, J.S., Building Knowledge-based Systems: Towards a Methodology, Pitman Publishing, London, 1991, p. 208. 71. Rowley, J. Computers for Libraries, 3rd ed., Library Association, London, 1993. S.A. Walters is a Postgraduate Research Student, and J.E. Broady a Lecturer, at the Department of Information and Library Studies, University of Wales, Aberystwyth, UK. R.J. Hartley is a Principal Lecturer at the Department of Information and Library Management, University of Northumbria at Newcastle, Newcastle upon Tyne, UK.

19