Using Cognitive Mapping for Problem Analysis in Information Requirements Determination

  • Judy McKay
  • Peter Marshall
Conference paper


This research grew out of concerns that information systems projects (defined here to include both in-house development, and the acquisition, modification and implementation of externally-produced package software) often result in less than satisfactory outcomes, with stories of failure and disappointments with respect to information systems (IS) being relatively common in both professional and academic literature (Montealegre and Keil, 2000; Keil and Robey, 2001). An analysis of the literature considering these failures suggests that there are repeated concerns that the analysis conducted at the early stages fails to pay sufficient attention to human and organisational issues, and that the subsequent requirements specification developed fails to accurately reflect the real needs of users and organisations (Martinsons and Chong, 1999). Failure to adequately determining requirements almost certainly indicates that the implemented system will disappoint or fail in use (Korac-Boisvert and Kouzmin, 1995; Ewusi-Mensah, 1997).


Cognitive Mapping Information System Problem Analysis Shared Understanding Strong Agreement 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. Checkland, P. B., Systems thinking, systems practice, Wiley, Chichester, 1981.Google Scholar
  2. Eden, C., Using Cognitive Mapping for Strategic Options Development And Analysis (SODA), in: Rational Analysis for a Problematic World, J. Rosenhead, ed., Wiley, Chichester, 1989, pp. 21–42.Google Scholar
  3. Eden, C., On the Nature of Cognitive Maps, Journal of Management Studies, 29: 3, May 1992, 261–265.CrossRefGoogle Scholar
  4. Eden, C. and Ackermann, F., Making Strategy: the Journey of Strategic Management, Sage, London, 1998.Google Scholar
  5. Ewusi-Mensah, K, Critical Issues in Abandoned Information Systems Development Projects, Communications of the ACM, 40: 9, September 1997, 74–80.CrossRefGoogle Scholar
  6. Ewusi-Mensah, K. and Przasnyski, Z. H., Factors Contributing to the Abandonment of Information Systems Development Projects, Journal of Information Technology, 9: 3, March 1994, 185–201.CrossRefGoogle Scholar
  7. Fiol, C. M. and Huff, A. S., Maps for Managers: Where are We? Where do We Go from Here?, Journal of Management Studies, 29: 3, March 1992, 267–285.CrossRefGoogle Scholar
  8. Flowers, S., Information Systems Failure: Identifying the Critical Failure Factors, Failure & Lessons Learned in Information Technology Management, 1: 1, 1997, 19–29.CrossRefGoogle Scholar
  9. Flynn, D. J., Information Systems Requirements: Determination and Analysis, 2nd ed., McGraw-Hill, London, 1998.Google Scholar
  10. Flynn, D. J. and Arce, E. A., A CASE tool to support critical success factors in IT planning and requirements determination, Information and Software Technology,39(5): 311–321.Google Scholar
  11. Goldkuhl, G. and Rostlinger, A., Joint Elicitation of Problems: Important Aspects of Change Analysis, in: Human, Organizational and Social Dimensions of Information Systems Development (A-24), D. Avison, J.E. Kendall, and J. I. DeGross, eds., Elsevier Science, North Holland, 1993, pp. 107–125.Google Scholar
  12. Hepworth, J. B., Vidgen, G. A., Griffin, E. and Woodward, A. M., The Enhancement of Information Systems through User Involvement in Systems Design, International Journal of Information Management, 12: 2, June 1992, 120–129.CrossRefGoogle Scholar
  13. Jackson, M. C., Systems Approaches to Management, Kluwer Academic/Plenum Publishers, New York, 2000.Google Scholar
  14. Keil, M. and Robey, D., Blowing the Whistle on Troubled Software Projects, Communications of the ACM, 44: 4, April 2001, 87–93.CrossRefGoogle Scholar
  15. Keil, M., Cule, P. E., Lyytinen, K. and Schmidt, R C., A Framework for Identifying Software Project Risks, Communications of the ACM, 41: 11, November 1998, 76–83.CrossRefGoogle Scholar
  16. Korac-Boisvert, N. and Kouzmin, A., IT Development: Methodology Overload or Crisis?, Science Communication, 17: 1, September 1995, 57–89.CrossRefGoogle Scholar
  17. Limayem, M. and Wanninger, L. A., The Use of a Group CASE Tool to Improve Information Requirements Determination, Document de Travail, 93–33, Université Laval, Quebec, Canada, 1993.Google Scholar
  18. Martinsons, M. G. and Chong, P. K. C., The Influence of Human Factors and Specialist Involvement on Information Systems Success, Human Relations, 52: 1, January 1999, 123–152.Google Scholar
  19. Montealegre, R. and Kcil, M. De-escalating Information Technology Projects: Lessons from Denver International Airport, MIS Quarterly, 24: 3, June 2000, 417–447.CrossRefGoogle Scholar
  20. Siddiqi, J. and Shekaran, M. C., Requirements Engineering: the Emerging Wisdom, IEEE Software, 13: 2, March 1996, 15–19.CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media New York 2004

Authors and Affiliations

  • Judy McKay
    • 1
  • Peter Marshall
    • 2
  1. 1.Monash UniversityMelbourneAustralia
  2. 2.Mt Eliza Business SchoolMelbourneAustralia

Personalised recommendations