Requirements Engineering

, Volume 3, Issue 2, pp 130–137 | Cite as

Engineering as a co-operative inquiry: A framework

  • Ian Alexander


This paper has grown out of my specific dissatisfaction with a view of the world centred on technology, rather than on the people who will use that technology. I have therefore looked for a framework which makes a definite shift of focus towards users, but allowing existing techniques wherever these are helpful. The paper presents a new framework in which requirements engineering is treated as a co-operative inquiry (C1), a general method for reaching shared understanding within a group. The treatment leads to a division of the requirements engineering life cycle into four cycles of co-operation between users and developers. With each cycle, a model (which may be quite conventional) is developed. The approach is compared with existing methods, and some predictions are made about how it may perform.


Co-operative inquiry Facilitation Inquiry cycle Negotiation Requirements engineering User participation 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Stevens R. Systems engineering: coping with complexity. Prentice-Hall, Englewood Cliffs, NJ, 1998 (a modern industrial perspective on systems)Google Scholar
  2. 2.
    Mumford E. Systems design: ethical tools for ethical change. Macmillan, New York, 1996 (an intelligent and reflective text on systems engineering in its social context)Google Scholar
  3. 3.
    Standish Group. Web site at, 1998 (a corporate view of the cost of poor systems development)Google Scholar
  4. 4.
    Heron J. Co-operative inquiry: research into the human condition. Sage, Newbury Park, CA, 1996 (a recent text by one of the founders of CI, with detailed examples and discussion)Google Scholar
  5. 5.
    Reason P. Participation in human inquiry. Sage, Newbury Park, CA, 1994 (a textbook by one of the founders of CI with an academic slant)Google Scholar
  6. 6.
    Mazza C, et al. Software engineering standards. Prentice-Hall, Englewood Cliffs, NJ, 1994 (a terse statement of the waterfall model meant for use on software projects)Google Scholar
  7. 7.
    Alexander I. Scenario Plus user guide, http://www.scenarioplus.-com/, 1997 (a tool designed to assist collaborative working on goals for user requriements)Google Scholar
  8. 8.
    Alexander I. A co-operative task modelling approach to business process understanding. In: Workshop on object-oriented business process modelling, ECOOP 1998 ( (a paper on task modelling using a requirements tool, discussing its application in a CI framework)Google Scholar
  9. 9.
    Saul JR. The unconscious civilization. Anansi Press, Canada, 1995 (an essay on the need for participation by individual citizens in polities)Google Scholar
  10. 10.
    Flick U. An introduction to qualitative research. Sage, Newbury Park, CA, 1998 (an excellent and detailed discussion, among other things, of the issues in observing and/or participating in the users’ domain)Google Scholar
  11. 11.
    Macaulay L. Requirements capture as a co-operative activity. In: IEEE international symposium on requirements engineering (RE’93), 46 January 1993, San Diego, CA (a paper on her approach, discussing both the social process of collaboration and the options for a team structure)Google Scholar
  12. 12.
    DSDM. The Dynamic Systems Development Method,, (a widespread rapid applications development method from a consortium of UK industry)Google Scholar
  13. 13.
    Yourdon E. Modern structured analysis. Prentice-Hall, Englewood Cliffs, NJ, 1989 (an older textbook from an original thinker in software engineering)Google Scholar
  14. 14.
    Checkland P, Scholes J. Soft systems: methodology in action. Wiley, Chichester, 1990 (one of several texts on SSM by its inventor)Google Scholar
  15. 15.
    Avison DE, Wood-Harper AT. Multiview: an exploration in information systems development. Blackwell, Oxford, 1990 (a text on the Multiview method with ideas from Checkland and Mumford)Google Scholar
  16. 16.
    Mumford E., Defining system requirements to meet business needs: a case study example. Comput J 1985;28(2): 97–104 (a paper on her participative design method ETHICS)CrossRefGoogle Scholar
  17. 17.
    Potts C, Takahashi K, Anton A. Inquiry-based requirements analysis. IEEE Software 1994; 11(2): 21–32CrossRefGoogle Scholar

Copyright information

© Springer-Verlag London Limited 1998

Authors and Affiliations

  1. 1.Independent ConsultantLondonUK

Personalised recommendations