Is There Only One Systems Development Life Cycle? J. Hedman and M. Lind School of Business and Informatics, University College of Borås, Sweden
[email protected],
[email protected]
Abstract This paper contributes to the literature on information systems development life cycle (SDLC) by presenting an enhanced SDLC model, which integrated three interdependent and complementary, but different SDLCs. It is based on integration of the traditional and well-established idea of custom development with package development and commercially off the shelf (COTS) selection and implementation. Package development includes all software made for a market, whereas COTS selection and implementation refers to the selection and implementation of package software. Although there are many similarities between the life cycles, many differences are important to understand. We highlight both the differences and the intersection between the life cycles and outline an integrated SDLC model, which will be used to discuss future research and curricula issues.
1 Introduction The traditional information systems development life cycle (SDLC) is one of the more influential concepts within the information systems discipline (Avison and Fitzgerald 2006). It has had a tremendous impact on our conceptual thinking and understanding of information systems curricula, research, and practice. It is one of our discipline’s selling points. The SDLC is a process model that describes and prescribes the phases that have to (or at least should) be carried out in the process of developing an information system for specific usage situations. It can be conceived as a generic model or a grand theory. In its purest form it includes five straightforward phases – planning and problem identification, analysis, design, realization, and use and maintenance, and is often referred to as the Waterfall model. This model is the basis of contemporary methods. If we, for example, consider Rational Unified Process (RUP), one of the dimensions for distinguishing increments is the phases according to the Waterfall model. There are several potential strengths of the SDLC. It is simple and easy to understand; it is well established; there exists methodological support; it includes concrete deliverables and milestones, and support tools for each phase (Avision and Fitzgerald 2006). Meanwhile, the SDLC model has been criticized. For C. Barry et al. (eds.), Information Systems Development: Challenges in Practice, Theory, and Education, Vol.1, doi: 10.1007/978-0-387-68772-8_9, © Springer Science+Business Media, LLC 2009
105
106
J. Hedman and M. Lind
instance, Boehm (1988) claimed that the Waterfall model lacked relevance, since information systems and software are not developed through a straightforward stage process. It includes iterations, reviews, and feedback loops. There are several other issues with the traditional SDLC, such as failure to address the needs of management, strong technical emphasis leading to user dissatisfaction, and an assumption of and emphasis on custom development (Avision and Fitzgerald 2006). However, our main argument for writing this paper is that organizations of today are increasingly developing information systems through an acquisition process of packaged software (also so-called Commercially Off The Shelf (COTS), shrink wrap, or application package) (Sawyer 2000; Andersson and Nilsson 1996). These packages are configured and adapted to the user’s requirements or the user has to adapt to the package. This way of developing information systems can be compared with the traditional SDLC (Sawyer 2001; Rosemann 2001; Markus and Tanis 2000). In the beginning, development of information systems only meant one thing – in-house development of solutions from scratch. Hardware and software were uniquely designed and developed for a specific situation for an organization, e.g., Lyons Electronic Office and General Electric’s payroll system (George 2000). Since the first package software was sold, the share of custom (unique) development in the software market has decreased (Sawyer 2000; George 2000). According to Sawyer’s (2000), OECD (1998) estimates the software market in 1998 to $200 billion, of which $140 billion is related to package software. Today, organizations acquire software packages from the market, such as office packages, antivirus program, or ERP systems. We argue that this process is a type of SDLC, which is not sufficiently covered by the traditional SDLC. Whether a consequence of or a precondition for the change in how organizations develop information systems has created a new market or whether it is the market that has changed the way organizations develop information system is up for debate. Regardless of what, a new super market involving the largest software companies, such as Mircosoft, Oracle, and SAP, has established since the mid-1960s. Their core business process comprises also a SDLC, but with a different terminology and goals than custom development or COTS selection and implementation (Carmel and Becker 1995). In sum, there are three interrelated, complementary, and simultaneously existing SDLCs. The first is custom development supporting the process of developing a custom-made information system for specific users. The second is the development of package software. The last is COTS selection and implementation. There are several similarities and differences regarding concepts and terminology used, phases, and goals and outputs between the different life cycles. Sawyer (2000, 2001) and Carmel and Becker (1995) call for further research into the differences and similarities between these three SDLCs. A generic SDLC has several strengths in its potential in giving a good overview. We do however claim that the three processes identified have their own certain characteristics, but at the same time they give an expression for a variance of a more generic SDLC. This level of granularity is important to reach in order to get a comprehensive understanding of what the information systems field is
Is There Only One Systems Development Life Cycle?
107
characterized of today. Thus, the purpose of this paper is to present an integrated SDLC model, including custom development, package development, and COTS selection and implementation. The integrated model will accordingly reflect different SDLCs in contemporary practice, and is to be used for stimulating a broadening of the perspective in the information systems community. The only type of software development that is beyond this paper is embedded systems, i.e., software made for hardware. The structure of the paper is as follows. In the next section we will begin with our legacy, i.e., custom development, followed by package software and COTS selection and implementation. The section is then concluded with a summary where the differences are highlighted. The third section outlines the integrated SDLC model. In the fourth section, we discuss the validity of models. We then conclude the paper.
2 Information Systems Development Processes In this section, we will briefly introduce the three life cycles with an emphasis on distinguishing features (adopted from Sawyer 2000), including industry pressure, labeling of phases in the development process, outcome of the development process, work roles, and degree of methodological support. A note of caution though: The vast number of books, articles, approaches, methods, tools, types of information systems, etc., makes this task close to mission impossible. However, we hope that we are able to highlight some of the main characteristics of each SDLC in order to create a basis for a fruitful discussion.
2.1 Custom Development The history of information systems development (ISD) is about 60 years old, since the first software was developed in the 1940s (George 2000). Today, custom development is carried out by an internal IT department or with the assistance of external software companies (Sawyer 2000) or through a combination thereof (George 2000). A distinguishing aspect of custom development is that information systems are made-to-order for specific users. Sawyer (2000) characterizes custom development as follows: (1) industry cost pressures and focus on satisfaction, user acceptance, and return on investment; (2) the development is done by staff position in support units, user participation is desired, mature development process, separation between design and development; (3) the culture is bureaucratic and less individualistic; and (4) development teams are project focused, people work in many projects, paid by salary, and rely on formal specifications. The process of developing custom-made information system is illustrated by one of many classical SDLC, namely, the Waterfall model. It has five phases that capture the basic structure of a systems life cycle (George 2000). 1. Planning is the first phase and includes the activities that identify the need for a system, such as problem identification and feasibility study.
108
J. Hedman and M. Lind
2. Analysis is the next phase, where the existing systems/IS should be analyzed and the requirements should be specified. 3. The design phase investigates whether a solution can be realized. This involves logical and physical designs. 4. Realization is the fourth phase and this is when the solution is programmed and installed. This is also commonly referred to as roll-out. 5. The use and maintenance phase includes keeping the system up and running and continuous updates. This proceeds until a new life cycle begins. A life cycle perspective on the system means that the introduction of a new life cycle implies a liquidation of the old system. Custom development begins with a decision to develop an information system to solve a specific problem or meet some new requirements. The reason for this decision may vary between organizations and situations, but an underlying rationality is that we can design and build something better than buying the solution from someone else. To support this process, there is a large number of approaches (such as SSM, Speech Act, Decision Support, and Agile), methods (such as RUP, SCRUM, and SSAD), and techniques (such as ER diagram, Use Cases, and EPC models) (Iivari et al. 1998). Systems analysts, systems designers, and programmers do the work, and the output is an information system or software. Many of our legacy systems were built through custom development (Carmel and Sawyer 1998). Today, custom development is common in new application areas, such as e-commerce (George 2000) and m-commerce (Andersson and Hedman 2006), or in certain governmental areas (Sawyer 2000), e.g., defense, customs, and police force. Custom development takes advantage of several components from package development, such as Web browsers for managing user interaction, protocols for managing computer-to-computer interaction, databases, software development tools, operating systems, application-programming interfaces for integration, and custom-developed information systems with package software.
2.2 Package Development Owing to a number of reasons, such as market opportunities, efficiency in development, and economics of scale, the development of tradable software products has continuously grown since the late 1960s. The development of tradable software products includes all types of software that can be bought from a store, vendor, or distributor (Andersson and Nilsson 1996; Carmel 1997; Carmel and Sawyer 1998). There are two broad categories of package software. First, there are system-related packages, for example, operating systems, anti-virus tools, network operating systems. The other category is application packages, which are designed to support specific business problems, such as word processing, financial, human resource, and sales (Sawyer 2000). Sawyer (2000) characterizes package development (compare with custom development earlier) as follows: (1) industry time to market pressures and focus on profit and market share; (2) the development is done by line position, users are not
Is There Only One Systems Development Life Cycle?
109
involved, immature process controlled through coordination; (3) the culture is entrepreneurial and individualistic; and (4) development teams are product focused, incentive systems, and rely on visions as specifications. Most packages are customizable. They can be adapted to a certain degree to specific user requirements (George 2000). The degree of adaptation of the system has to be taken into account in the development of a package (Regnell et al. 2001). When designing a package, the designer must foresee areas in which the package must be flexible in. The output of package development is a generic product that can be used by many users (Hedman 2003). Therefore, requirements specifications are market driven. The phases of package development have different labeling and goals than custom development. Carmel and Becker (1995) and Sawyer (2001) outlined such life cycles. According to Carmel and Becker (1995), the following phases can be distinguished: 1. The first phase is business idea formulation, when a package vendor starts up. The underlying reason for developing the package is a business plan, which is the justification for starting a package-developing firm. The driven forces are technology push/pull or market pull. 2. The second phase is proof of concept (POC), where the initial ideas are translated into some preliminary requirements and technical specifications, followed by prototype building and testing of concept. 3. The third phase is realization, including design, coding, and intermediary testing, followed by final testing. 4. The fourth phase is production, when the software is packaged for distribution. 5. The final phase is sales, i.e., the activities done to sell the package in the market. Termination of this life cycle may occur because of changes in the market demand decreases or because of technology changes. This may lead to a new and improved version or even a totally new package. The process of developing package software leads to some new work roles. The most distinguishing are the business innovator and the sales and marketing staff (Carmel and Becker 1995). These roles are not traditionally covered by IS curricula, but are essential for package development. We can also assume that there is need for requirements on new skills and capabilities of the work force.
2.3 COTS Selection and Implementation We now turn to the point of view of the buyers of package software, i.e., COTS selection and implementation. The selection and implementation of COTS is often based on a strategic or policy decision, which states that the organization should buy software, not build them. There are several reasons for selecting a package software, e.g., technical (replacement of old and outdated IS), integration of disparate IS, business (changes of production mode, e.g., make-to-order vs. make-tostock), organizational (new organizational structure), strategic (to gain competitive advantage), and due to difficulties with in-house development. The user organization configures the package to its requirements or adapts to the logic of the package. Compared with traditional systems development, one of the differences lie in
110
J. Hedman and M. Lind
the initial phases where an evaluation of the functionality takes place instead of a traditional analysis and design phase. Thus, evaluation becomes critical in the process of selecting COTS systems. Research into COTS has mainly addressed Enterprise Systems implementation. There is some research focusing on life cycles (Markus and Tanis 2000), but there are fewer research attempts focusing on the difference between COTS selection and implementation and custom development on one hand or package development on the other hand. Some of the exceptions are Rosemann (2001), Hedman (2003), and Sawyer (2001). Sawyer (2001) labeled the phases as system planning, selection, initiation, needs analysis, function analysis, gap-fit comparison, installation, and support and upgrade. Depending on the type of package software, i.e., system or application, the installation phase can be very different in scope and workload. For instance, the installation of large ERP systems comprehends unique product-specific methods for managing the entire project; configures the package to user requirements, and implements the package in its user context. This type of method is labeled as COTS methods (Hedman 2004). For instance, consulting and package vendors, such as SAP AG and Accenture, provide the package-adopting firm with methods, e.g., AcceleratedSAP (ASAP) by SAP AG, Method R/3 by Accenture (this method is Accenture’s own proprietary method for implementing R/3), and Implex provided by Intentia to implement the Movex system. These methods do not cover the selection, since they are product-specific and thus begin at the design phase. An illustration of this type of method is ASAP, which is based on best practice from a number of implementation projects, primarily in USA (Hedman 2004). It incorporates the knowledge and consulting practices from previous projects and in part from information systems literature. The method is packaged as a computer-based project management and implementation method that comprises five phases: 1. Project preparations, in which project mission and scope are defined. 2. Business blueprint includes a complete and comprehensive analysis of requirements and business processes. 3. Realization when the system is configured and tested. 4. Final preparation includes transfer of data from the old systems and end-user training. This is also commonly referred as roll-out. 5. The go live and support phase is when the actual installations take place. Each of the phases includes a large number of tools and utilities to simplify the work, such as Concept Check Tool for handling data volume conflicts and Implementation Guide for supporting the configuration of the system (Hedman 2004). Third parties, not developers, typically implement COTS. ASAP follows the same overall stages and phases as in the system life cycles described for developing information systems from scratch. However, there is one important exception: the Business Blueprint phase comprises both requirements analysis and system specification and design, but in reverse order. ASAP may in some cases be useful, but it has some limitations. Since the method focuses on installing the system, it is not complete in generating suggestions for use of information technology for supporting organizations and businesses. ASAP is technically oriented and the goal is to
Is There Only One Systems Development Life Cycle?
111
install the system. The steps and procedures of this type of ISD method change, in particular, the requirements specification, which is addressed in the next section. This does however mean that there is also a need for considering how a life cycle for COTS (package) development is to be constituted and intertwined with a life cycle for COTS selection and implementation.
2.4 Distinguishing Features of the Three Life Cycles There are many similarities between custom development, package development, and COTS selection and implementation, including the fact that they all involve a life cycle and are all related to information systems and software. Custom and package developments share the realization phase, and custom development and COTS selection and implementation have the same concluding phases. The obvious intersection point between package development and COTS selection and implementation is sales people and procurer of package software; i.e., the output of package development is the input in COTS selection and implementation. Nevertheless, there are many differences as well, including different industry pressure, phases, overall outcome, work roles, and degree of methodological support. Table 1 summaries the similarities and differences. Table 1. Different characteristics of the three different information systems development processes Industry pressure
Phases
Overall outcome Work roles
Degree of methodological support Custom Cost Planning To solve a prob- System analyst Large development pressure Analysis lem through the System designer Design development of Programmer Realization an information Use and maintenance system To develop and Innovator Some Package Market Business idea sell a package Sales person development pressure Proof of concept Realization Production Sales and marketing Termination NA COTS Initiation To buy and in- ERP consultants Product speselection and Selection and stall a pre-made cific methods implemenconfiguration information systation Implementation tem Use and maintenance COTS commercially off the shelf
112
J. Hedman and M. Lind
3 Towards an Enhanced Model of Information Systems Development Life Cycle On the basis of the above-mentioned review of the widely ramified literature, we would propose an enhanced SDLC model that includes the following interrelated SDLCs, starting with our legacy of custom development, followed by package development to be concluded with COTS selection and implementation. Each of these SDLCs co-exists, but can be studied individually. It is however our intention to put forward that such co-existence also means that there is a need to understand these three SDLCs as parts of development processes in practice. To pinpoint such wholeness, several links between the SDLCs to illustrate both feedback loops and path dependencies are also included. Do however note that all three SDLCs are variances of the more generic SDLC. Figure 1 shows these SDLCs, and dependencies between them are illustrated. The first concerns custom development or the process of developing unique information systems that are typically built for specific users. The second ISD process concerns package software, i.e., activities performed by vendors or suppliers for the development of COTS products. The last concerns the selection, configuration, implementation, and use and maintenance of COTS products. The logic of the expanded SDLC framework is as follows. Information systems are developed and implemented through these three unique, but similar and interdependent life cycles. The first supports the process of solving uniquely identified problems through the design of new information systems from scratch. It begins with planning and problem identification, followed by analysis, design, realization, and use and maintenance. The realized information system can then form the basis for the development of a business idea in package development. Package development begins either as an exploitation process of a previously built customer-unique system or as an identified market opportunity. The package is an offer to the market, among other competing offers, and part of COTS selection and implementation. COTS selection and implementation converts a software package through configuration and implementation to a usable information system. In cases where the package needs modification or customization, new or adjusted functionality is added, using the SDLC from custom development or maintenance activities during COTS selection and implementation. Each of the three SDLCs is built upon the logic that a SDLC comprises several phases managing a task based on a clearly defined input (prerequisite) and output (result). On a generic level we acknowledge that the phases in all the SDLCs could be seen as (1) one (or several) initial phase(s), (2) analysis and design phase, (3) a phase of realization, and (4) a phase of maintenance. We also acknowledge the iterative and incremental steps within a SDLC as identified in the spiral model (c.f. Boehm 1988). This aspect is however not emphasized in this paper since we are more concerned with the identification of, the constituents of, and the relation between three essential SDLCs. Another important foundation for distinguishing between the three SDLCs is that custom development and COTS selection and implementation are aimed
Is There Only One Systems Development Life Cycle?
113
towards particular clients while package development is aimed towards potential clients. Lind (2002) has earlier propagated for such distinction for process definitions. This means that the logic of the ordering and initiation of the work to be performed within the processes differs when the work is performed, in particular, for potential clients. Therefore, package development is more driven by seeing a potential in a future business case rather than specific needs from a client (as the case in custom development and COTS selection and implementation). An underlying perspective in the development of the model depicted in Fig. 1 is the acknowledgment of both a producer (supplier) and a procurer (customer) perspective.
Fig. 1. Three different systems development life cycles and their interrelationships
4 Discussion The validity of the model can be assessed by three particular criteria: the integration of the model (logical coherence), relative explanatory power, and its practical and theoretical relevance. The integration of the model will not be further elaborated here; we refer to the previous section.
4.1 The Extended SDLC Model in Comparison The extended SDLC model is characterized by an integration of custom development, package development, and COTS selection and implementation, and shows the interdependency between the three different SDLCs. There are several competing models, such as Alter’s (1999) generic system life cycle model, Carmel and Becker’s (1995) process model for packaged software development, Sawyer’s (2000) comparison of custom development and package development, Hedman’s (2003) and Rosemann’s (2001) enhanced ERP life cycle models. These papers address only one of the SDLC or two of them. The only paper that discusses or at least acknowledges the existence of all three SDLCs is the one by Sawyer (2001),
114
J. Hedman and M. Lind
who discusses changes in system development from a market perspective. Sawyer (2000) compares traditional SDLC or custom development with market-oriented SDLC, which includes both package development and COTS selection and development. However, instead of our proposed terminology, he uses consumer SDLC for COTS selection and implementation and producer SDLC for package development and does not integrate them. Our proposal, which we find necessary, is to acknowledge the dependencies between the three SDLCs. Furthermore, Sawyer’s (2000) ambition is not to present an enhanced model, but to increase the awareness of market-driven SDLCs. By our acknowledgment of these three similar but different interrelated SDLCs a higher level of precision in stating requirements on methods to be used in the different phases could be achieved. Thus, we strongly object to Alter (1999), who claims that there is only need for one general SDLC. In this paper we have shown that there are different characteristics dependent on the ISD context regarding industry pressure, phases, overall outcome, work roles, and degree of methodological support. These differences in characteristics need to be distinguished in methods in order to stimulate meaningful debates within the information system community about existing phenomena in practice.
4.2 The Practical Implications of the Framework How about the relevance of the proposed framework, i.e., its theoretical and practical usefulness? The framework provides a structure of how different life cycles interrelate to each other by identifying and articulating their similarities and differences. We find that much of the research reported today does not discuss the variety of SDLCs as discussed in this paper. It is, however, an existing phenomenon in practice that different kinds of life cycles do co-exist. We therefore believe that research must reflect upon these phenomena in practice. Consequently, since much of the research reported upon (c.f. Sect. 2) covers SDLC for custom development, there is a great need for research on the two “new” SDLCs. Examples of research questions are as follows: 1. What triggers package development or how does it begin? Is this a process of exploitation or exploration, each with its unique theoretical frame of reference? 2. How should user involvement be handled during package development? 3. What methodological support is desired for selecting packages (as part of COTS selection and implementation)? Furthermore, we should question the proposed model – whether we should strive for a single conception of SDLC or should we expand on those three proposed included in the framework or are even more SDLCs desired? For instance, two types of information systems projects could either be included in existing frameworks or form the basis for new SDLCs as modification or customization on one hand and integration of information systems on the other hand. The second area of implications is related to information system curricula. We will pose some questions with answers that hopefully will stimulate further debate. The first one is, do we need to adopt existing information system courses and
Is There Only One Systems Development Life Cycle?
115
curricula? Yes, we believe so; for instance, courses in introduction to ISD should include the different SDLCs in order to provide the student with a deeper and diversified understanding of information systems development in practice. In addition to that, we foresee new information systems curricula addressing the specific issues involved in COTS selection and implementation and package development. This is motivated by the need for specific requirements for skills and capabilities related to each SDLC. For instance, a person working with COTS implementation needs more knowledge related to business than a person involved in the development of a package does. However, that person needs much more technical skills and capabilities. We probably need to educate people who sell packages. In addition, we need to focus more on requirements specification in general, but also for the specific SDLCs. There is probably a need for more than one IS model curricula, since each of the life cycles requires in part different skills and capabilities of the workforce.
5. Conclusions In this paper, we have presented an enhanced SDLC model that is broader than the traditional conception of SDLC. It is broader in the sense that it acknowledges the different characteristics of three interrelated SDLCs: (1) COTS selection and implementation, (2) package development, and (3) custom development. It is not a radical departure from the traditional conception of SDLC, but offers a broader and more relevant view of the information systems development process. Our stance is that there is a need to acknowledge instances of a generic SDLC in order to achieve a more comprehensive view of systems development of today. The strengths of this model are as follows. First, it is a synthesis of three streams of information systems literature captured in one coherent model that previously have not been integrated, with a few exceptions (e.g. Sawyer 2001). Thus, it is possible to continue to cumulate knowledge in relation to each life cycle as well as to the whole field. Second, it highlights the differences and similarities between the SDLCs, which may be a foundation for formulating new research questions and stimulate curricula development. In relation to research we first suggest that research in particular focuses on the intersection between custom development, package development, and COTS selection and implementation. For instance, integration projects are such a research area. It can be between several packages or between packages and custom-made information systems. A second research area is method engineering along the entire COTS selection and implementation process and in particular to support selection and use, and user involvement in package development. Third, it shows the relationship and interdependencies between the life cycles, which may help practitioners and researchers to reach a common understanding.
116
J. Hedman and M. Lind
Acknowledgements The authors appreciate the helpful comments from the anonymous reviewers.
References Alter, S. (1999) A general, yet useful theory of information systems. Communications AIS 1(13). Andersson, B. and Hedman, J. (2006) Issues in the development of a mobile based communication platform for the Swedish Police Force and appointed security guards. 3rd International Conference on Information Systems for Crisis Response and Management, Newark. Andersson, R. and Nilsson, A. (1996) The standard application package market – An industry in transition? In: M. Lundeberg and B. Sundgren (Eds.). Advancing Your Business: People and Information Systems in Consert. Sweden: EFI, Stockholm School of Economics. Avison, D.E. and Fitzgerald, G. (2006) Information Systems Development: Methodologies, Techniques, and Tools, 4th ed. New York, NY: McGraw-Hill. Boehm, B.W. (1988) A spiral model of software development and enhancement. IEEE Computer 21(5), 61–72. Carmel, E. (1997) American hegemony in packaged software trade and the culture of software. The Information Society 13(1), 125–142. Carmel, E. and Becker, S. (1995) A process model for packaged software development. IEEE Transactions of Engineering Management 41(5), 50–61. Carmel, E. and Sawyer, S. (1998) Packaged software development teams: What makes them different? Information Technology and People 11(1), 7–19. George, J. (2000) The origins of software: Acquiring systems at the end of the century. In R. Zmud (Ed.). Framing the Domains of IT Management: Projecting the Future…Through the Past. Cincinnati, Ohio: Pinnaflex Educational Resources, pp. 263–284. Hedman, J. (2003) On enterprise systems artifacts: Changes in information systems development and evaluation, Doctoral thesis, Department of Informatics, School of Economics and Management, Lund University, Sweden. Hedman, J. (2004) Understanding ERP implementation methods: The case of ASAP. 27th IRIS, Falkenberg. Iivari, J., Hirschheim, R. and Klein, H. (1998) A paradigmatic analysis contrasting information systems development approaches and methodologies. Information Systems Research 9(2), 164–193. Lind, M. (2002) Dividing businesses into processes – Foundations for modelling essentials. In: K. Liu, R.J. Clarke, P.B. Andersen, R.K. Stamper, E. Abou-Zeid (Eds.). IFIP TC8/WG8.1 Working Conference on Organizational Semiotics: Evolving a Science of Information Systems. Boston: Kluwer. Markus, L. and Tanis, C. (2000) The enterprise systems experience – From adoption to success. In: R. Zmud (Ed.). Framing the Domains of IT Management: Projecting the Future…Through the Past. Cincinnati, Ohio: Pinnaflex Educational Resources, pp. 173–207. Regnell, B., Höst, M., Dag och Natt, J., Beremark, P. and Hjelm, T. (2001) An industrial case study on distributed prioritisation in market driven requirements engineering for packaged software. Requirements Engineering 6, 51–62. Rosemann, M. (2001) Requirements engineering for enterprise systems. 7th Americas Conference on Information Systems, Boston, MA. Sawyer, S. (2000) Packaged software: Implications of the differences from custom approaches to software development. European Journal of Information Systems 9, 47–58. Sawyer, S. (2001) A market-based perspective on information system development. Communication of the ACM 44(11), 97–102.
