Requirements Engineering as a
Co-operative Inquiry: A Framework

The distinctive feature of the co-operative inquiry method is a cycle (Figure 1) consisting of separate phases for thought and for action. Orderly and effective processes carefully separate these. Who has not sat through a review meeting where it was not clear whether the task was to review a previous action, to plan future actions, or even to work on the next action? From the CI point of view, each person in that meeting was speaking in the phase which they personally had reached. Chaos resulted, as no attention had been paid to the process.

Traditional software life-cycles (in particular) have formalized some activities into constructive stages and review stages. For example, the European Space Agency's PSS-05 standards [Mazza 1994] call for a Software Requirements Phase, containing the writing of a document followed by review as its main activities.

The CI framework offers the possibility of extending this kind of structure so as to involve users intimately in all aspects of requirements engineering. The CI cycle contains four discrete phases:

In the first phase, any member of the CI group can make a proposal for action. For example, a user may suggest that an area of concern should be investigated and modelled. This can be challenged, modified, added to, and debated by the CI group. The phase ends when the group reaches a decision, ideally by agreement across the group. A group can of course use a CI cycle to agree a decision procedure, such as by show of hands. Reaching agreement can take time with a new group but can become very rapid in an experienced team.

The second phase consists of taking whatever action was agreed. The action may be something that the whole group can do, or it may be specialized, calling for individual action. During the action phase, the group stands back from making proposals, reviewing, or criticizing, as these can interfere both with the decision that was taken and with the action that is under way. This suspension of criticism allows the group to immerse itself in the action.

The third phase consists in reacting to the product of the action phase. Reaction may mean reviewing a document or model, or it may quite simply mean allowing members of the group to express their 'gut reactions'. That may not sound very constructive, but by providing a time at which such expression is accepted, it effectively avoids long periods of destructive complaint and criticism, and enables everyone in the group to feel that other people have heard what they have to say.

The fourth phase consists of making sense of what has happened. This can mean reflecting on what a model shows (or does not show), what ought to be thought about next, what the results so far imply. If documents are produced, they are likely to be technical notes which discuss meanings, implications and perhaps theoretical underpinnings. A definite phase for reflection in each cycle prevents people from rushing from action to action (such as by following a Standard rigidly, with over-tight deadlines) without checking to see if the process is meeting the users' needs.

The cycle can be terminated at this point, if the results are satisfactory; a particular cycle can be repeated, if there is a case for proposing further action; or the cycle may lead naturally to another cycle, where the work needs to be deepened, as happens when a clearly expressed User Requirement leads on to a System Requirement.

A CI cycle with a simple action can be completed in a single meeting; other cycles may take weeks or months. Some managers in industry think that democracy is a slow process. CI strives to be totally democratic, but it can be very quick once people are familiar with the method. Time is saved because people know they will get a chance to speak if they need to; everyone listens; and what is said can be dealt with promptly, instead of hanging around as a problem and dividing the team. The bigger picture is that getting requirements right, that is, grounded in experience but accurately expressed, saves much time by avoiding misunderstandings and rework.

CI is nothing if not a practical method. Here is an example of what can happen. The described activities are not necessarily recommended practice.

For the sake of example, a CI meeting could begin by agreeing (phase 1) to Alison's proposal to start to identify the goals of a new project by brainstorming. This proposition could be acted on (phase 2) by having Ben write down all the suggested goals, uncritically.

After ten minutes or so when the flow has dried up, the group could express its immediate reactions (phase 3) to what is on the screen, perhaps by marking a tick, a cross, a question mark or a comment against an item, without argument, to indicate what each person thought of each item that they cared to comment on.

The group could then sit back and discuss (phase 4) the relative importance of each goal, aiming to converge on a preliminary list of priorities. Further cycles could then be planned, to organise the goals into a hierarchy and to check they were complete and realistic.

Sometimes, a CI group member becomes distressed by the process. For instance, Charles may be upset that his first goal is being given bad marks by several people in the group. Diana notices that he is looking uncomfortable and proposes to the group that it takes the time to resolve his discomfort (creating a small special-purpose cycle, incidentally, within the 'goals' cycle).

Charles explains why his goal mattered to him and how other users want it also. On being questioned, he describes how he felt it was unfair that the group seemed to be picking on his contribution. Alison asks what could be done to resolve the issue, and Charles suggests that the goal could be divided into two parts. Ben writes these on the board and Emma checks that Charles is happy with the result. The group agrees to reconsider the priorities and resumes the 'goals' cycle.

The meeting proceeds quietly – too quietly? Ben asks the group whether it might not be avoiding something – perhaps the real issue is that the goal suggested initially by the Director is unrealistic, but nobody feels like challenging it. The group votes to consider if this is so, and collects and summarizes arguments for and against. Everybody gives their gut reaction to the arguments, and the group then reflects on the problem.

The outcome is that the group sees that the goals need to be adjusted to be less ambitious. A meeting is arranged with the Director to present the group's findings. A major failure a few months down the line has been averted.

In Cycle 1 (Figure 2), the users, together with consultants, discuss and assess the problem area. They also get to know each other, and learn the CI method. The consultants may interview the users or conduct workshops to study the problem and prepare a structured description of the problem area. This can be a task or goal model, or any other representation which does not make assumptions about the nature of the solution.

A task model has several advantages for co-operative identification of problems. It is easy to understand; can be animated to show how it works, to check for errors, and to generate operational scenarios; and it can be transformed readily into either a conventional process model, or into the heading structure of a user requirements document. I have created a tool specially for this purpose [Alexander 1997, 1998].

In cycle 2 (Figure 3), given a properly worked out and agreed document structure in which the problem can be defined, user requirements for each class of user can be phrased quickly and easily.

Cycle 1 established a CI framework in which requirements engineers can work closely together with users, and a document structure, possibly based on a hierarchy of goals or user tasks. In Cycle 2, engineers and users co-operate to draft, review and revise the user requirements.

The cycle is concluded when the team has agreed the scope and prioritised the requirements. A requirement with so low a priority that it will not be worked on (at least in the foreseeable future) is naturally out of scope.

Using a problem identified with a task model, I treat the problem definition cycle as consisting of populating the task or goal headings with requirements for each of the actors involved.

For example, a task called 'Evaluate Risk' might have a functional requirement 'The project manager shall be enabled to calculate the financial risk in launching the product', as well as a security constraint 'The risk evaluation shall be available only to authorized users'. In other words, once the users have agreed what tasks are involved, the shape of the problem is known and definition consists of filling in the details.

I find this easiest with a requirements tool, such as DOORS, which supports a hierarchy of headings and an outliner with which to view and edit them.

The third cycle (Figure 4) defines the envelope within which any acceptable solution must lie. The developers draft the system requirements by transforming the user requirements into specific demands on the system, complete with constraints and system attributes such as whether a requirement is safety-related and how it is to be verified. The users review the requirements and validate them by checking that they satisfy all aspects of the problem (within the scope). Finally, the users adjust the scope to ensure that they can afford the (first) solution and give the go-ahead, in the form of a plan, schedule, and budget for development. I find a requirements tool which supports attributes and traceability very helpful for these purposes.

Probably little need be said about the fourth cycle (Figure 5). The users present the developers with an agreed budget and timescale, and ask for a solution which meets the requirements. The developers design and build a solution as usual: there is no reason why this should not be by means of an evolutionary life-cycle that involves repeated deliveries for user reaction, but that is not our concern here. The cycle, and the framework, are completed when the users have validated the solution and decided whether further work is called for.

At the end of this paper I venture some broad predictions about the general effect of applying the CI Framework. Here I need only point out, very briefly, some immediate effects within the process.

Users are central throughout the life-cycle. This does not prevent developers from being delegated to go away and make a model, or a program, but it keeps the responsibility for decision-making (such as changing a requirement) firmly with the CI group, which includes the users. In other words, developers as well as users may propose, but users decide. The framework depends totally on co-operation between users and developers, a human process which can be assisted with technology but which is not driven by it. Design decisions are postponed until needed. This actually increases the freedom of the developers to consider alternative design solutions. Validation is (virtually) continuous, as users and developers together have the opportunity to examine and reflect on each phase of action during regular CI-style meetings.

Each individual meeting can, and should, be treated as a CI cycle in its own right, with a few minutes at the start to agree a proposition, a phase of action such as presenting a design document, a phase of reaction in which everyone says what they feel about the ideas presented, and a final phase of making sense of the meeting's discussion, with decisions and plans for further work and the next meeting.

Importantly, errors are never allowed to grow because the whole group focuses its attention on the results or products immediately they are available. In other words, action is always balanced by review.

"Participation … is the very expression of permanent discomfort"

John Ralston Saul, The Unconscious Civilization

The role of the requirements engineer in a CI framework is facilitative, as it should always be. Some aspects of this could include allowing time to find out what the users want; making the effort to discover differences of opinion on scope, and alternative approaches; having the patience to hear what everyone has to say; and maintaining a firm determination not to be rushed into solutions, very possibly in the face of management or peer pressure.

There is a severe problem in all collaborative methods: of staying in balance. Professionals are always in danger of 'living in an ivory tower' with special knowledge which separates them from users. At the other extreme, engineers who enthusiastically dive in to the users' problems run the risk of 'going native' and losing their perspective [Flick 1998].

The CI answer is to cycle between total (if possible) immersion in action and reflection on that action. Ideally the requirements engineer and the users participate totally in the action so they can reflect on their own immersive experience [Heron 1996]. This is a subtle balance. The experience in the action phase is fully grounded, but not reflective. The reaction and reflection phases are detached, but are grounded in reality through the recent memory and experience of the group. Alternative approaches such as ethnography do not achieve this result.

The related question, of how far it is possible or desirable for engineers to experience the users' domain, is a difficult challenge, supplying material for much future work.

I personally have found the journey from controlling to participating and facilitating very rewarding so far. I am sure I have much further to go, but I hope that by thinking out what I am trying to do, other practitioners may be stimulated to take these ideas further, put them into their practice, and so contribute towards a practical and sound theory of co-operative requirements engineering.

Few life-cycle models involve users to any depth. For example, ‘Spiral’ and ‘Evolutionary’ Models typically have one cycle per product version (not 4). If each version is a prototype or 'early working model', then the time between each user specification and each delivery may be shorter than in traditional life-cycles such as the waterfall [e.g. Mazza 1994]. In contrast, the CI framework attempts to establish continuous co-operation between users and developers.

The Dynamic Systems Development Method [DSDM 1998] is a fully-worked out approach for 'rapid application development' (RAD). It seems to combine both evolutionary and co-operative methods:

"The project should … identify all the classes of users who will use the end result so that knowledgeable representatives can participate throughout the life of the project and provide coverage of the views of all the user classes. DSDM calls these representatives 'Ambassador Users' … ".

DSDM provides some guidance on the choice of users: they should be experienced and knowledgeable. It seems likely that good DSDM projects in fact use some of the techniques of CI informally. For example it is mentioned in a case study that an Ambassador User not only "had an overall knowledge of the business areas involved, but also had a good understanding of computer systems" and there is a reference to a "give and take attitude". Interestingly, the study also mentions the value of a cooling-off period "for the team to regain their energy and enthusiasm". If this was more than just a rest, it might imply a period of reflection on the actions so far accomplished, leading to planning of the next phase: but this was not stated. CI may well be valuable in DSDM and similar approaches in formalising the place of users, and the way the team interactions can be managed. The effect should be to bring more projects up to the level of the best.

Ed Yourdon [e.g. Yourdon 1989] has proposed a structured approach including up to four models, in a scheme which presages the four cycles of the CI framework, though without necessarily implying particularly close collaboration with users. The limited range of modelling techniques formerly available, combined with the once generally weak perception in industry of the importance of users, has probably been responsible for the poor response to this kind of approach.

The DERA System Engineering model [Stevens 1998] explicitly involves User Requirements at each level (subsystem) of a hierarchical system, and requires user review of each phase. One thing that is clear from Stevens' work is that the early stages in the life-cycle - modelling of the problem domain and of the user requirements - can be completed quite rapidly and at low cost, provided there is a commitment from managers to get the job done. Modern tools also help. The first two CI cycles in the framework may therefore be less daunting than Yourdon's modelling phases.

User involvement is gradually becoming accepted as necessary in industry, e.g. in BPR and Kai-Zen. Checkland's Soft Systems Methodology (SSM) [e.g. Checkland 1990] makes this explicit, using representations which avoid analytic methods, favouring human views of the problem. SSM is not itself a development approach, though it has been incorporated as the first part of the Multiview method [Avison 1990]. Multiview pays commendable attention to obtaining viewpoints from different classes of user before building system models. It also emphasizes 'participative design' based on Enid Mumford's pioneering ETHICS method [Mumford 1985, 1996], not only involving users but reflecting their needs. Co-operative inquiry is a fresh take on requirements engineering, but it may well be that methods such as those advocated in Multiview are suitable for it.

Colin Potts' Inquiry-Based approach [Potts 1994] involves an inquiry cycle, which can be matched with the CI cycle as a particular application (interpretation for a specific purpose, centred on the requirements document) of a co-operative inquiry. The Potts cycle takes a document, allows the inquiry to challenge it (CI phase 3, Reaction), conducts a reasoned discussion (CI phase 4, Reflection) involving questions, answers, and reasons, which lead to a decision (CI phase 1, Proposition) on how to evolve the requirements. This leads to a change (CI phase 2, Action) to the requirements document, where the Potts cycle repeats.

The approach presented in the current paper proposes four major CI cycles, supported as needed by cycles of other types, and distinguishing the collection of goals and scenarios (cycle 1) from the writing of user requirements (cycle 2), and system requirements (cycle 3), but it is interesting that Potts has in effect 'rediscovered' CI in a specialized form.

As it happens, I also believe [Alexander 1998] that the place for putting together scenarios is a goal model, which is then used to organize the requirements, rather than trying to organize already-documented requirements by analysing use cases, as suggested by Potts and others. But all these processes are iterative.

Approaches which involve users include Linda Macaulay's Co-operative Requirements Capture [Macaulay 1993], developed at UMIST and well tested on business systems with the User Skills Task Match method (USTM). She advocates identifying and including 'stakeholders', but argues that in addition

"two further components are needed. Firstly a mechanism for focussing the discussion of the 'team' and encouraging sharing of views and concerns. Secondly a structure is needed which will enable the team to address all the important issues…"

USTM provides a detailed structure of meetings, each planned and debriefed, and each with a prescribed set of tasks leading to prescribed outputs. The users actively share in these tasks but are not involved in designing the task structure itself. That said, Macaulay permits the agenda to be updated co-operatively. The method is not formally a Co-operative Inquiry, though it has some of its attributes.

It is likely that a USTM meeting when led by an experienced facilitator comes close to executing a CI cycle; whereas if USTM or any other method is applied relatively rigidly, there is a risk that the predefined structure itself may put up barriers to effective co-operation. Macaulay explicitly admits that USTM places the responsibility for detecting and diagnosing any problem in the group, designing a solution, and intervening to address the problem. The USTM 'facilitator' thus has the power to control the group, whereas CI always attempts to share this power. The CI facilitator may be more experienced in the method than other participants, so strict equality is probably unattainable. The point is, perhaps, that the CI facilitator's experience is more likely to be applied by holding back or by asking a question than by direct intervention.