Information requirements specification I: Brainstorming collective decision-making approach

Informalion Processing & Mmagemenr Printed in Great Britain.

Vol. 24. No. 5, pp. 549-557.

1988 Copyright

0

03064573/88$3.00 + .oa 1988 Pergamon Press PlC

INFORMATION REQUIREMENTS SPECIFICATION BRAINSTORMING COLLECTIVE DECISION-MAKING APPROACH

I:

MOSHE TELEM School of Education, Tel Aviv University, Tel Aviv 69978, Israel (Received 28 August 1987; accepted in final form 21 December 1987)

requirements specification (IRS), although vital for systems design and implementation, constitutes the Achilles heel in the system life cycle (SLC). This article describes a comprehensive, innovative approach integrating brainstorming and Theory Z principles, culminating in a maximal, rapid, and attainable IRS. This is achieved at an early stage of the SLC by consensus among the users themselves with the participation of data processing professionals.

Abstract-Information

1. INTRODUCTION Information requirements specification (IRS) is a cornerstone of the management information system life cycle (SLC). IRS holds a central position in the existing literature on systems development. According to Murdic [l], user failure to provide clear, specific, objectives and information requirements probably accounts for the downfall of more design efforts than any other factor. Particular coverage is given in the literature to the importance of the involvement of users themselves in the process of designing and devel-

oping systems [2-41, indicating that in the undesirable situation in which the manager is unable or unwilling to clarify objectives and information needs, it is likely that the analyst or technician will substitute his or her perceptions of objectives and information needs. Concerning the effects of user participation on system quality and usage, and regarding user satisfaction from the information received, others [5] cite a lack of consistent, empirical evidence, nonsignificant or confounding results, or even negative results. Brownell [6] indicated that moderating variables such as organizational structure, cultural setting, personality variables, and reward schemes may account for the mixed effects of participation on effectiveness. IRS is the Achilles heel of the SLC. Often, the user first encounters the system only on delivery. After the system is delivered, discrepancies are often discovered between what the user wanted and what he/she has received. These discrepancies result from ill-defined requirements and/or misinterpretation on the part of the designer. MIS literature acknowledges the chronic gap in understanding among users themselves, as well as between users and DP professionals. Licker [7], for example, claims that MIS company interaction is usually characterized by little exchange of ideas, few personnel meetings or joint activities, and little mutual understanding. MIS skills have traditionally (albeit voluntarily) been sequestered in the MIS shop. User skills and attitudes traditionally have not been able to permeate the “wall” between MIS and the rest of the company. According to Boar [8], in spite of all the rhetoric to the contrary, requirements definition remains a most important problem that must be solved if productivity is to be improved. This shortcoming negatively affects other SLC stages, and is a dominant cause of MIS failure. Potential damage to the organization due to poor IRS is summarized by Gilhooley [9] as systems that are developed that do not meet users’ needs; are not flexible enough to meet the business needs for which they were designed; are lacking in management approval; are difficult and costly to maintain; do not fit in with long-term business, financial, and computerization plans for the company; and result in a process exceeding original budget and time schedules. This article presents a comprehensive, innovative approach to IRS combining brainstorming and theory Z principles, and culminating in a maximal, feasible, and 549

550

MOSHE TELEM

rapid IRS. This target is realized at an early SLC stage by consensus among the users themselves with DP professionals’ participation. 2. IRS FAILURE

As we have seen, MIS literature highlights a variety of causes leading to failure or hindrance of the IRS stage in the SLC. These causes originate from three sources: (1) The user, (2) the DP professional, and (3) the nature of the organization and type of work [7]. 2.1 The user It is not easy for users to clearly describe their jobs’ specific information requirements. The user often does not fully understand MIS and/or EDP and finds it difficult to adequately define existing objectives and information needs. He/she tends to view each problem as unique, without observing commonalities of information required fl]. The user may be bogged down in paperwork, and operations typically take precedence over systems development. Extensive user participation usually requires a lengthy process of training users to work together in groups, a process that may be measured in terms of months and years rather than days or weeks [IO]. Disagreements among users concerning needs and their priorities often arise, resulting in, or caused by, communication blocks. Low trust or high conflict among users develops. The user is frequently afraid of the intended change, and of becoming dispensable. (For a thorough examination of resistance theories see [ 111.) 2.2 The DP professional The DP expert does not always thoroughly understand the objectives and information requirements of the given organization. Communication blocks often arise between users and DP profession~s. As is often the case with users, the DP professional cannot distinguish the smaller problems from the larger ones, leading to difficulties in characterizing information requirements. The DP professional might attempt to force an undesired system on the user or to frighten the user by implementing inadequate strategies [12]. Sometimes he/she may even involve users as a manipulative symbolic gesture only, invoking a type of pseudo-participation [ 13,141. 2.3 The nature of the organization and iype of work Lack of clear organizational objectives and/or well-defined criteria to measure and evaluate achievement of these objectives at strategic, coordinative, and operating levels [IS], constitutes an additional cause for IRS failure. For example, frequent unannounced managerial changes in requirements and objectives add to the users’ confusion, Lack of MIS leadership as well as inadequate managerial involvement in IRS complicate the situation. The result: users complain that the information system department does not provide what is requested, and the information systems department claims that the users do not know what they themselves really want. Various solutions, such as Licker’s [7] MIS-user job rotation have been proposed. To date, no optimal solution has been found. Furthermore, a basic conflict of interest exists between systems designers and users. Although they work for the same company, they belong to different communities and cultures [16]. Users, for example, may look for cheap software products of predictably high quality, whereas the DP professionals want enhanced occupational status, prestige, and pay through the performance of specialized craftlike services that cannot be routinized, automated, or obtained elsewhere. This conflict of interest may manifest itself in systems that do not meet the users’ needs. Users and managers, on the one hand, and designers, on the other, have different interests in the outcome. If computer professionals control the process, they may try to advance their own aims when they conflict with the interests of users and managers [lo]. 3. FROM

FULL TO PROTOTYPE

SPECIFICATION

IRS strategies change over time. The “traditional” system development life cycle requires full specification of system design features, including IRS prior to system construc-

Information

requirements

specification

551

tion. In many cases (due to reasons originating from users, DP professionals, and the nature of the organization itself), this requirement, although desirable, proves unrealistic. In order to overcome this problem [lo], various development strategies such as heuristic design [ 171, minimum critical specification, evolutionary development, “middle-out” design, and prototyping have been proposed. Characteristics of the strategies relevant to the subject of this article are outlined below. According to Cherns [ 18, lo], the strategy of minimum critical specification implies that a good design should specify only what is essential, eliminating nonessentials. This achieves two benefits. First, it avoids closing off any options that can be left open, allowing people who perform the procedures “enough flexibility to respond effectively to unforeseen circumstances.” Second, “by building discretion, autonomy and self-control into people’s work, this design principle enhances job satisfaction while improving task performance.” The idea behind another strategy, that of evolutionary development [17,10], is that the designer quickly presents users with a limited working system with which they can experiment. Only through hands-on practice can the users and designers “rapidly determine how close the prototype comes to meeting the users’ needs. Necessary refinements can then be made incrementally.” This iterative method “helps users to learn new procedures that they could not have specified in advance. The designer can then capture these learnings and build them into the evolving system.” According to Kraushaar and Shirland [19], the prototyping approach can be used to “reduce the application backlog by producing new systems more quickly and effectively than the traditional approach.” Prototyping views “the final operational system as the desired state, achieved by passing through earlier, less desirable states. The transition from one state to the next can be accomplished by the traditional development process of analysis, design, and implementation, or by other appropriate methods.” Exploration of users’ needs and the identification and experimentation with output components of the prototype in order to create an operational system are vital, inseparable parts of the process. These alternatives to full specification at the earliest stage of the SLC emerged in order to overcome problems in the traditional development life cycle, including IRS. They were proposed as practical alternatives to the demonstrated inability of users to specify their desires, and of designers to decide what the users really need. However, these strategies do not neglect the target objective of a full IRS. In a very real sense IRS inevitably becomes the output of, rather than the input to, the system development process [19]. Ironically, IRS-a weak point of the traditional approach-is also a weak point of the three alternative approaches. Earlier achievement of maximal IRS for these three alternative techniques would provide more effective, successful results. In addition, thorough, maximal IRS in early stages of SLC carries greater importance in large and/or complex organizations, and in cases where management policy dictates full IRS as a prerequisite to further stages of SLC. 4. BRAINSTORMING

COLLECTIVE

DECISION-MAKING

APPROACH

The brainstorming collective decision-making approach (BCDA), to be outlined here, attempts to provide applicable solutions for the aforementioned problems. BCDA organizes and structures the process of IRS, rapidly furnishing maximal attainable IRS in initial stages of SLC. Utilizing the sociotechnical approach to system design [4], BCDA entails extensive user participation; its pivotal axiom is that users know their needs as no one else can. BCDA is employed through collective cooperation among users themselves and between users and DP professionals. Users must have influential, dominating positions [20], should have control over MIS design, and should be included among the main system designers. For achieving maximal user involvement, BCDA utilizes, with necessary adjustments, two accepted tools: brainstorming and collective decision making. 4.1 Brainstorming Brainstorming is a formal system for group creation [21]. Osborn [22] defines a brainstorming session as a [21] group of individuals, usually 5 to 12, developing ideas concerning

552

MOSHE TELEM

a problem, for a period of a few minutes to an hour, under the leadership of a chairperson. The chairperson states the problem as concisely as possible. The group then generates ideas, subscribing to the following rules: (1) Criticism of an idea is absolutely barred; (2) its modification or combination with another idea is encouraged; (3) quantity of ideas is desired; and (4) unusual, remote, or wild ideas are sought. Simple rules have been recommended for individual brainstorming of a difficulty. It is emphasized that a wild and apparently unworkable idea expressed by one participant may spark in another a feasible application or a workable modification. The unconventional ideas, of course, are useful because they open new directions of exploration. Another principal function of a brainstorming session is to feed new, pertinent, perhaps remote associations to the more creative members in a motivating, permissive, achievementoriented environment. A large quantity of ideas provides ample opportunity for quality suggestions. As such, “brainstorming is not a method for solving problems, but a technique for stimulating ideas that will lead to solutions.” Brainstorming creates a situation where solutions are reached in a disciplined manner that is perhaps absent in individual work. It sparks an imaginative person’s ideas and makes him/her think under tension, producing ego-satisfying feelings as the group launches into unknown territory [21]. According to Taylor [23] the group produces more ideas than the individual. However, the group, brainstorming as separate individuals, provides a greater quantity of ideas than when brainstorming collectively. The group working as individuals produces ideas of higher average quality. In group work, a significant departure from usual thinking derives from one mind, then others add the “fairly obvious, until a new, significant thrust in another direction appears” [21]. Brainstorming is criticized as working best in specific, limited, but open-ended questions (i.e., in problems of relatively modest usage). In order to overcome this limitation, to improve group rapport, to enlarge the scope of the brainstormed problems, and to allow incubation, BCDA applies the Taylor principle as well as various new modifications. Among these modifications are extending the brainstorming sessions, eliminating the pressure of time, employing repeat sessions that would allow for incubation and for projects of great size, and integration with the collective decision-making management style. 4.2 Collective decision making Collective decision making is considered a cornerstone of the Japanese management style. This Japanese approach, known as theory Z [24] emphasizes consensus decision making, strong mutual worker-employer loyalty and long-range planning, full knowledge of objectives, interpersonal communication, and habitual modes of thought and behavior arising from participation. Japanese corporate decisions are reached by a tedious process of collective compromise that can sometimes involve as many as 80 individuals, each of whom holds a potential veto. The process of consensus building is slow, but once agreement is reached, no one attempts to sabotage or impede the project completion. The issue of Japanese management style applicability in the field of DP has raised a debate in the literature. However, both supporters and nonsupporters of theory Z apply its principles primarily to programming [25-281. This article applies theory Z principles to system analysis process, adopting Licker’s approach [27] of selective application. Licker claims that we can no longer afford to ignore theory Z’s lessons. “We need desperately to import new management techniques into DP; the old one just are not working and probably never will.” 5. BRAINSTORMING

OF A COLLECTIVE

DECISION-MAKING

TECHNIQUE

BCDA organizes the process of IRS. The technique, the various stages of BCDA, and the results and lessons learned from its application in various organizations are described in detail in a separate article [29]. The following is a summary highlighting its main points. The process begins with a preliminary survey of the system by DP professionals. A user group is designated, representing the sample for which information needs will be defined. Sample members are assembled in a place other than their employment site and divided

Information

requirements specification

553

into preliminary brainstorming groups. A DP professional who is a member of the project team supervises ensuing brainstorming discussions with minimum intervention. Each group chooses its leader to direct its discussions. Each group member defines and prioritizes his or her needs, first individually (Taylor principle) [23], then as part of a group, with respect to the following outputs: definition of objectives for user’s position; user’s major responsibilities and typical decisions; identification of problems and constraints; specification of necessary information; definition of reports including structure, target, and dates of production; definition of data fields needed in each report; designation of fields and their codes in the database. During this process, special attention is also devoted to a variety of items such as frequency and form of reporting (typed, display etc.), reports’ level of detail or aggregation, acceptable levels of reliability and precision of data, security and privacy of information. A collective agreement is reached during the brainstorming discussion. Disagreements, should they arise, are addressed at the next stage, the plenum, which consists of intergroup brainstorming discussions. All preliminary brainstorming group members are assembled at the plenum, with group leaders facing the others. The DP project leader directs discussions until a collective intergroup agreement, including conclusions pertaining to all seven outputs, is finalized. Each member of the preliminary brainstorming group retains the right to participate actively in the intergroup discussion. DP professionals are also actively involved in the process. With management cooperation, they define the representative user sample. In the brainstorming group discussions, they direct user attention to interrelations between their own systems and others existing both within and outside the organization. They prepare the written proposal of information requirements according to the minutes of the brainstorming discussions. This proposal is then distributed by them to each member of the preliminary brainstorming groups for critical feedback and reevaluation by reassembled brainstorming discussions groups. They inform management of every stage of the process. Topics lacking collective agreement in the brainstorming discussions are subjected to management decision. They should be sensitive to both user and management feedback, and integrate it into the IRS process. The process culminates with a final report of IRS. If necessary, users outside the representative sample are also included.

6. BCDA-

AN ANSWER TO IRS FAILURE

The structured relationship between users and DP professionals provided by BCDA is intended to establish a proper climate for system development and facilitate a more successful achievement of acceptable solutions to previously discussed IRS problems. As such, it aims to facilitate achievement of the following benefits: thorough definition of IRS by users themselves, thus eliminating falsely raised expectations; development of user motivation in the SLC process, diminishing the danger of symbolic and/or pseudo participation; stimulated user thought in terms of information needs; better solutions to problems, resulting in new directions of exploration and simulation of ideas revealing possibilities not considered by the individual user alone; design of effective and innovative solutions to work environment problems; construction of systems flexible enough to meet the business needs for which they were designed; improved managerial acceptance of IRS and MIS; application of systems that will adapt to the long-term business, financial, and MIS plans for the organization; improved “interuser” communication providing conflict settlements in a congenial collective decision-making atmosphere; increased coordination in organizational activity via improved integration between MIS subsystems; fortified organizational interrelations with the external environment; enhanced user self-esteem and satisfaction; a user better trained in the use of MIS; improved familiarity with and understanding of organizational needs by DP professionals; strengthened relations between users and DP professionals in the IRS; SLC processes better achieving of projected organizational change; minimized resistance to change; increased user control over operations; and faster, more efficient IRS process (especially in larger and more complex organizations).

554

MOSHE TELEM

As can be seen in a subsequent article 1281, which focuses on the technical characteristics of BCDA and the ramifications of its operation in several different organizational settings, a significant number of the aforementioned benefits have been realized. Only further application and research will verify the assumption that the unique character of BCDA, which integrates theory Z principles and the brainstorming technique, will truly eliminate, or at least minimize, the negative results, as well as the confounding effects (51 resulting from increased user participation.

7. RAMIFICATIONS

FOR IRS AND SLC

BCDA has been tested in some organizations. It was first implemented to specify information requirements in a particularly large, complex and diverse system-a national educational system [30]. Two issues functioned as catalysts toward BCDA implementation in this educational system. First, the project’s steering committee decided that information needs at school, district and national levels should be maximally specified and approved as a prerequisite to the other SLC stages. The second impetus was the challenge of effectively achieving a rapid, maximal, attainable IRS for tens of thousands of users in thousands of schools located all over the country. The lessons learned from the BCDA used in this project, as well as in some smaller organizations, indicated that brainstorming integrated with collective decision making is applicable and valuable in organizations of varying size and type. Precise empirical research is necessary to determine BCDA’s potential contribution to IRS as well as to other SLC stages [5]. The research should systematically investigate each projected benefit described above, and address BCDA ramifications on a variety of research subjects such as: MIS quality and usage; additions SLC stages; extraction of real user problems from the presented problems (i.e., the problem the user believes he/she is facing); user attitudes and satisfaction with the information received [5]; extent of assistance BCDA provides to users in specifying their requirements in total and final detail [8]; significance of users’ participation to the relevance and quality of the analysis and the resulting recommendations; the reiationship of active user involvement and well-defined requirements to the achievement of a better system; the speed of the development process; possibilities of a wider range of system features; increased system reliability and accountability; quality of the system-either defined as “meeting requirements” [31,32], or as fitness for use [33]; assistance in the development of operational procedures; user acceptance and training when the system is ready to be implemented; increased worker involvement; decreased feelings of alienation and powerlessness; improvement of DP professionals’ motivation [34,35]; minimization of resistance to change; encouragement/management of innovation in the organization and maintenance of management’s overall control 1361;overcoming communication barriers and closing gaps between users themselves; overcoming semantic gaps and other communication barriers between the user and the DP professional, where each side will come to understand the rationale of its counterpart, resulting in productive analyst/user communication [7,12,16]; elimination of duplicate efforts; reducing the backlog for new systems development [9]; and improvement of cost/benefit ratio. Research on the ramifications of BCDA application should also investigate the possible limits of BCDA along various dimensions, such as the following: Size and/or complexity: BCDA provides rapid, effective IRS for both large and small MIS projects within allocated timetables [29]. It should be assumed that greater size or complexity of an organization will lead to higher BCDA effectiveness. In a “mini” organization, with few employees, BCDA’s operational technique will be of a much simpler nature. Further research is necessary to substantiate the above and to attempt to identify the appropriate organizational settings for the BCDA. Organizational context: BCDA should be operated and researched in various organizational contexts, such as structure (functional, divisional, matrix, centralized, decentralized), culture (power oriented, cooperative, theory Z), employee type (professional, bureaucratic, semiprofessional), and organizational power and politics [37,381.

Information

requirements specification

555

System type (34E3, DSS, ISIS): BCDA is applicable to both MIS and DSS system types [29]. Research is required to demonstrate the appropriateness of BCDA for EIS as well. Management level: BCDA is appropriate [29] for IRS at the tactical and operative levels [15]. Further investigation should be executed on BCDA’s application for identifying the overall strategic information needs of top management. Top management j~v~~vement: The BCDA technique described in the subsequent article [29], significantly involves top management in the initiation, continuing supervision, and final approval of the suggested information requirements. BCDA application has indicated [29] that top management integrates its own information needs into the MIS systems discussed in the brainstorming sessions. These findings must be further verified in future research. ~esjstanc~ to change: As a result of the fact that BCDA has been shown to reduce resistance to change 1291,research should be dedicated to examining the extent of BCDA’s impact on the axiom that the greater the implied change, the more likely the resistance [11,37-391. The improper operation of any of the eight BCDA stages or of their consecutive operation as a whole may have potential problems and/or dangers. For example, improper training of the brainstorming group advisors might lead to the enforcement of the advisors’, rather than the users’, information needs. organizational cultures/contexts that are not inherentIy cooperative [l 1.,371 might result in the partial or complete paralysis of BCDA or in the warping of its results. The BCDA should not be applied to systems that partially, or totally intend to achieve irrational purposes [ 10,371, or to organizational situations where conflict and low levels of trust exist between the workers and/or between workers and managers [lo]. The conclusion that the same participative approach that is likely to build consensus in a cooperative setting may increase conflict in a hostile situation [IO] also applies to BCDA. Special attention should also be devoted to the ramifications of the early maxima1 IRS on (1) emerging, time-saving, application development tools, such as databases and application generators that bring speed, power, and flexibility to the beginning user as well as to the programming expert; and (2) the two explicit assumptions in prototyping - that an information system will change and grow with use and that users will revise their requirements of the system as their needs change and grow 1401.Only an empirical experiment can verify the potential contribution of integrating BCDA and prototyping techniques to reduce or eliminate earlier, less desirable stages in part or whole prior to the final operational system 1191. Comparative research such as that of Boehm, Gray, and Seewaldt [41] and Boehm 1421 pertaining to prototyping as opposed to a prespecification approach to the same project are imperative. Results along these lines will also help to verify Boar’s [43] assumption, that, aIthough prototyping is becoming fashionable, it could be dangerous if it is followed blindly. It must be adapted to each individuai situation; some situations require the more traditional systems analysis skills of problem definition and prespecification. It is reasonable to assume that the proposed studies will verify our assumptions that early maximal IRS via BCDA will provide increased effectiveness in prototyping techniques. In addition, the larger, more complex and/or more decentralized the organization, the greater BCDA’s potential contribution to integration and coordination between the small prototypes designed and applied throughout the organization.

8. CONCLUDING

REMARKS

In this article we have presented a comprehensive approach integrating brainstorming and theory Z principles into BCDA for a maximal, rapid, early, attainable, and effective IRS. The BCDA appears to be a useful strategy for efficientIy enabling users themselves (with passive, technical cooperation of DP professionals) to identify and define their own needs through collective effort and cooperation. BCDA contributes to a more successful specification of acceptable solutions to the obvious limits of IRS in the traditional development life cycle as well as in new approaches, such as evolutionary develop-

556

MOSHE TELEM

ment and prototyping. These problems originate from three main sources for IRS failure: the user, the DP professional, and the nature of the organization and type of work. The ramifications of BCDA on a variety of SLC stages deserve further research and explanation. However, experience indicates that BCDA can provide rapid, effective IRS in keeping with the organization’s time schedules for both large and small MIS projects. BCDA clearly has the potential to improve IRS as well as SLC, and to contribute to a greater productivity in systems development. BCDA could be a valuable tool for the development of systems in conjunction with the business plans of the organization. It is flexible and innovative enough to enhance the achievement of the organization’s objectives. BCDA should be incorporated into the overall SLC strategy plan, resulting in a totally integrated systems development program.

REFERENCES Cliffs, N.J.: Prentice-Hall; 1980. 1. Murdic, R.G. MIS concepts and design. Englewood of information systems. New York: McGraw-Hill; 1981. 2. Lucas, H.C. The analysis, design and implementation 3. Langefors, B. Discussions of the article by Bostrom and Heinen: MIS problems and failures: A socio-technical perspective. Part 1: The causes. MIS Quarterly 2: 55-62; 1978. perspective. Part 1: The causes.” 4. Bostrom, R.P.; Heinen, S.J. MIS Problems and failures: A socio-technical MIS Quarterly 1: 17-32; 1977. Science 30(5): 5. Ives, B.; Olson, M.H. User involvement and MIS success: A review of research. Management 586-603; 1984. in budgeting, locus of control and organizational effectiveness. The Accounting 6. Brownell, P. Participation Review, 56(4): 844-860; 1986. Systems Management I. Licker, S.P. Breaking down the wall: MIS-user job rotation.” Journal of Information 2(2): 10-16; 1985. prototyping: A life cycle perspective. Journal of Systems Management 37(2): 25-31; 8. Boar, B.H. Application 1986. I.A. Methodology for productive systems development. Information Systems Management 3(l): 9. Gilhooley, 36-41; 1986. Bugs + Features. Boston: Pitman; 1984. 10. Markus, M.L. Systems in Organizations: 11. Kling, R. Social analysis of computing theoretical perspectives in recent empirical research. Computing Survey 12(l): 61-110; 1980. Journal of Information Systems Management 2(4): 54-57; 1985. 12. Weinberg, M.G.; Weinberg, D. Intimidation. and organization. New York: Harper & Row; 1957. 13. Argyris, C. Personality B.; Edstorm, A. Successful information system development projects. Management Science 14. Debrabander, 24(2): 191-199; 1977. and management: A systems and contingency approach (3rd ed.). 15. Kast, F.E.; Rosenzweig, J.E. Organization Tokyo: McGraw-Hill; 1979. Systems Man16. Weinberg, M.G.; Weinberg, D. In deepest darkest corporate America. Journal of Information agement 2(l): 63-66; 1985. T.; Wetherbe, J. Heuristic development: A redesign of systems design, MIS Quarterly 3: 11-19; 17. Berrisford, 1979. design. Human Relations 29(8): 783-792; 1976. 18. Cherns, A. The principles of socio-technical J.M.; Shirland, L.E. A prototyping method for application development by end users and infor19. Kraushaar, mation systems specialists. MIS Quarterly g(3): 189-199; 1985. 20. Longfors, B. Discussions of the article by Bostrom and Heinen: MIS problems and failures: A socio-technical perspective, part 1: The causes. MIS Quarterly 2(2): 55-62; 1978. In Heyel, C. editor. The encyclopedia of management. (3rd ed.). New York: 21. Haefele, J.W. Brainstorming. Van Nostrand Reinhold Company; 69-72; 1982. New York: Scribners; 1957. 22. Osborn, A. Applied imagination. and creativity. Second University of Utah Research 23. Taylor, C.W. Some variables functioning in productivity Conference on the Identification of Creative Scientific Talent, Salt Lake City: University of Utah Press; 1958. 24. Ouchi, W. Theory Z. New York: Avon; 1982. solutions. Datamation 29(l): 135-142; 1983. 25. Couger, J.D. Circulation of the ACM 26(g): 26. Licker, S.P. The Japanese approach: A better way to manage programs? Communication 631-636; 1983a. style might Seuss us just fine. Journal of System Man27. Licker. S.P. On beyond “Z”: Japanese management agement 34(10): 10-14; 1983. style right for DP? Journal of Systems Management 34(3): 28. Chadwin. M.L.: Cross. E. Japanese management 6-9; 1983. ’ . requirements specification II: Brainstorming collective decision-making technique. 29. Telem, M. Information Information Processing & Management 24(5): 559-566; 1988. 30. Telem, M. Conceptual and operational considerations for the planning and implementation of a pedagogical MIS on a national scale. Programmed Learning and Educational Technology 24(3): 187-193; 1987. 31. Crosby, P.B. Quality free: The art of making quality certain, New York: New American Library; 1980. Association; 1982. 32. Burrill, C.W.; Ellsworth, L.W. Quality data processing. Tenafly, N.J.: Burrill-Ellsworth New York: McGraw-Hill; 1974. 33. Juran, J.M. Quality control handbook. and managing computer personnel. New York: Wiley; 1980. 34. Couger, J.D.; Zawachi, R.A. Motivating

Information

requirements speci~cation

557

35. Couger, J.D.; Zewacki, R.A. What motivates DP personnel? Datamation 24(9): 119-122; 1978. 36. McFarlan, W.F.; McKenney, J.L. Corporate information systems management. The issues facing senior executives. Homewood, Ill.: Richard D. Irwin; 1983. 37. Markus, M.L. Power, politics, and MIS implementation. Communication of the ACM 26(6): 430-444; 1983. 38. Keen, PG. Information systems and organizational change. CISR No. 46, Center for information Systems Research, Massachusetts Institute of Technology, Cambridge, Mass.; 1980. 39. Robey, D.; Markus, L.M. Rituals in jnformation systems design. MIS Quarterly S(1): 5-17; 1984. 40. Smith, P.M. A prototyping case study. Information Systems Management 2(3): 20-25; 1985. 41. Boehm, B.H.; Gray, T.E.; Seewaldt, T. Prototyping versus specifying. IEEE Transactions of Software Engineering Se-IO, 1984. 42. Boehm, B.H. Software engineering economics, Englewood Cliffs, N.J.: Prentice-Hall; 1981. 43. Boar, B.H. Application prototyping, New York: Wiley; 1984.