A Process and Tool for Negotiating and Structuring Upstream Requirement Definition Adrian Mackenzie, Ian Warren, Ian Sommerville Computing Department Lancaster University Lancaster LA1 4YR UK mackenza|iw|
[email protected]
Abstract This paper addresses the problem of eliciting requirements for large scale technical systems with multiple stakeholders, significant technological uncertainties and extended time scales. Attention needs to be paid to conflicting organisational objectives and hidden agendas. For various reasons, it is important that people agree on the problem the system is meant to help with. Many existing RE techniques try to reconcile conflicting requirements after eliciting them. We argue that negotiation over conflicting requirements can productively occur during their elicitation. Hence our focus is on the early, ’upstream’ stage when options and commitment are just beginning to emerge. Decisions made at this point often have profound and unanticipated consequences for the future of such systems. The dynamism of contemporary organisations and the short attention-spans of management suggests that requirement engineering techniques need to be lightweight and distributed. Drawing both on problem structuring methods found in management science and on design rationale techniques, we have developed a hybrid process and accompanying software tool support to facilitate consensual problem definition. Negotiation occurs through a combination of informal group problem structuring (cognitive mapping) and incremental formalisation (design rationale) of requirements. Field trials indicate that parts of the negotiation can be conducted asynchronously, others require group work with a facilitator. The Wisdom process-tool is currently being tested in the domain of high performance computing (HPC) procurement.
1. Introduction Some existing RE approaches view eliciting a set of requirements as a relatively straightforward process. Existing approaches acknowledge that requirements stem from different users, from the operational environment, from the enterprise, and from the availability of new technologies. Reconciling the requirements and implementing them might be logically or technically difficult, but eliciting requirements is
Mark Westcombe, Mike Pidd Department of Management Science Lancaster University Lancaster LA1 4YX m.westcombe|
[email protected] treated as if it were simple, if it is discussed at all (e.g. [1]). In fact, elicitation is often a highly fraught, conflictual undertaking requiring careful and intensive management by project managers and engineers. For instance, consider the requirements for a national high performance computing (HPC) facility. Such a facility involves users from disparate natural, social and applied sciences. It involves a complex operational environment of increasingly networked computer services. Major architectural choices between bespoke processors or processor clusters have to be made and there are attendant issues of code migration from existing HPC facilities. Even the geographical siting of the facility is an open question affecting requirements. These different requirements come together only partially against a somewhat unstable multi-organisational background and against a shifting set of scientific problems for which HPC might be useful. Even assembling the stakeholders in one place at one time poses logistical difficulties. The Wisdom tool-process addresses the primary obstacle in eliciting requirements in situations like HPC procurement: problem definition. This phase addresses how to structure the problem or need which the system will answer. Our basic argument is that at the early upstream stage of eliciting requirements, getting the right information (even from multiple sources) is only part of the problem. Interacting around that information to select options that people will accept is also crucial. Conflicts are inevitable in this phase of negotiation [2]. The Wisdom tool-process negotiates these conflicts using a combination of formal and informal group processes. From the many ways to negotiate conflicts within organisations, we have hybridised two approaches centred on drawing maps and diagrams in groups. Firstly, from management science, we have drawn on negotiating processes and techniques such as cognitive mapping that help groups represent, agree on, and accept plans of action. Secondly from design rationale techniques, we have borrowed and adapted techniques (IBIS – Issue Based Information Systems) that permit incremental formalisation and more fine-grained analysis of issues as formally structured arguments displayed in tree-like structures. The combination of a high-level and
fine-grained processes is, we will argue, important. Both approaches use visual representations, manipulated and retrieved by software, to facilitate interaction around information. In this paper we provide a background account of what the two techniques do and how they complement each other (Section 2), we describe how the Wisdom software system and facilitator-driven process combines the two approaches (Section 3), and discuss some of the issues and questions that arise when attempting to elicit requirements in fluid, complex environments (Section 4).
2. Background Large-scale systems projects such as a metropolitan traffic management system, a mainline railway signalling system, a new military weapons platform or a high performance computer may be developed using a number of different options. There is rarely a unique problem definition from a technical point of view and political, social, economic and environmental factors, as well as organisational strategy, have a significant and often dominant influence on preferred option. The gestation period for projects may be many years and, during that time, the staff involved, the available technologies, the priorities of local and national government and the national and international economic situation may change. Given this situation, a problem faced by procurers and suppliers of these systems is how to manage the options, associated design decisions and establish the requirements. This involves conflict resolution, negotiation, establishing consensus and ensuring commitment to the agreed way forward. Project managers and systems engineers then have to manage and keep track of the design options that are available for a system; the associated costs, risks and value of these options; relate these design options to high-level user requirements; understand the technical and non-technical factors affecting these options; and the effects change orders have on the overall system. Procuring and deciding on the requirements of a High Performance Computing (HPC) is typical of such a large, complex project. As can be seen in Figure 1, it is political in that it requires large sums of public investment and is visible world-wide as a showcase of commitment to scientific research. Its location can be contentious and involve the relocation or disbanding of groups of people with specialist skills. Procurement discussions, both formal and informal, take place over a number of years and the technology, when built, is
expected to deliver services for up to 12 years. This takes place within a very dynamic arena, where the available technology options are radically different and may change several times during the project’s lifetime. In addition it faces many domain specific challenges. The client, or procurement manager, acts as a proxy to a wide range of user groups composed of many stakeholders with different needs, concerns and levels of commitment to and understanding of the project. The environment is changing with the development of GRID initiatives, an increased building of small-middle sized HPC’s and a potential to collaborate with historically distinct HPC agencies. New roles are also being defined with the emergence of eScience and a judgement or analysis has to be made to understand whether scientific needs can be addressed simply by increasing processing capacity. New machines also have to be compatible with the old, so as to allow migration of codes from one to the other. This increases the complexity of judging the processing and memory capacity required. Such problems will be familiar to managers of large, complex projects and the impact of initial, often informal, upstream decisions all too critical. Analysing and agreeing decisions at this stage is fraught with difficulties, none less so than the complexity of modelling these problems when the only data available is soft in nature.
2.1. Modelling soft decisions Cognitive mapping as a problem structuring technique has been introduced into requirements engineering [2]. The design rationale field, while not explicitly focused on requirements engineering, has historical links to the problems of requirements engineering. Design rationale was originally proposed in the context of system design as a means of presenting ’the design alternatives which were considered, the arguments for and against these alternatives and the reason why final design decisions were made’ [3]. This section will provide an overview of these two techniques and describe the process of using them in practice.
2.2. Cognitive Mapping: a problem structuring technique The development and use of cognitive maps within management science maps owes much to the work of Eden [4][5]. The example shown Figure 1 illustrates what a cognitive map looks like. It is abridged and adapted from a map built with a procurement manager for a HPC machine.
Figure 1 Example of a simple cognitive map
The nodes of the map each comprise one idea. The links between nodes are intended to represent the relationship between the causal relationship between the concepts [4]. These links are causal, in that ‘concept A’ may lead to or have implications for ‘concept B’. This linking structures the concepts into a hierarchy which shows the positive or negative cause and effect between individual concepts across the model. A complete model that represents the problem space comprises a series of interconnected maps. The node types used in Figure 1 are distinguished in the map by using different fonts and colour coding for each of goal, strategy, option and issue. Ad-hoc coding of the concepts helps with visualising or navigating the map, as well as analysing it. The Decision Explorer software is available to build and analyse cognitive maps on a single PC. The key to supporting decision making with cognitive maps lies in the Strategic Options Development and Analysis (SODA) [5] process of building maps with groups to share and negotiate problem issues.
2.3. SODA: a process for managing workshops Maps can be built for groups, either by merging individuals'cognitive maps or directly using a facilitator in a brainstorm-type workshop (Eden and Ackermann 1998). These SODA workshops are computer assisted using the Group Explorer software in conjunction with Decision explorer and a networked of PCs [Eden 1998]. The group workshop needs to provide relevant tasks to facilitate group communication, and manage the group dynamics. Its process must demonstrate to participants
that the decision making procedure is sensible - that it is procedurally rational. A SODA workshop usually begins with a relatively free ranging brainstorm prompted by a question such as, "What are the issues facing the organisation over the next x years?" These concepts are clustered and further developed by the group. Links are added between concepts and concepts colour coded according to their type. This problem structuring helps build the big picture and identify key concepts. These key concepts are then ranked by voting to prioritise the issues on which to spend workshop time. The choice of activity at any particular point depends on what the facilitator considers most appropriate to the task. During the course of a typical SODA workshop a group might cycle through several different brainstorming activities and elaborate various key issues through in-depth discussion. Goals, objectives, strategies and options will be established before agreeing actions and a way forward. Commitment to the action plan is achieved through developing shared understanding between participants through participation in the workshop process. Beginning problem definition in this way negotiates conflict upfront, rather than other approaches which try to resolve it after requirements have been articulated.
2.4. Design rationale: capturing rationale IBIS is one of a number of different design rationale approaches with supporting software tools. Most of these have been inspired by the work of Rittel [6] who devised IBIS. Of these, the most expressive is DRL [7], implemented in SIBYL [7]. The expressive power of
DRL stems from a rich polymorphic node type hierarchy and a set of typed relations that can be used to connect node instances. In contrast to DRL, QOC [8] is a much simpler notation which involves three node types: question, option, and criteria. Options can be evaluated in terms of criteria by linking instances of these node types using supports or challenges relationships. IBIS differs from the other design rationale notations in that it is not concerned with evaluating alternatives, but is geared towards the deliberation process. Conklin has further extended IBIS with regard to the process of using it in face-to-face meetings [9]. Buckingham Shum [10] provide a comprehensive introduction to the aims, uses and applications of the principal design rationale notations and presents the realities of using them.
2.5. IBIS: a formal mapping technique The nodes of an IBIS map are labelled as questions, ideas or arguments (pros and cons). A map begins by asking a question around an issue that prompts for ideas. The pros and cons that are raised are added against each idea. A simple example of an IBIS map is shown in Figure 2 which, for illustration purposes, has been adapted from the cognitive map of Figure 2. The links are not causal, rather nodes are connected by links with different semantic types. For example, ideas respond to questions and arguments support or object to these Ideas. The IBIS notation ensures that the map represents the dialogue taking place in the group, rather than representing the decision space.
Figure 2 Example of an IBIS map
2.6. Dialog Mapping: using IBIS with groups The Dialog Mapping process is implicit within the IBIS notation and, unlike SODA, cannot be so readily distinguished from its technique. The IBIS notation represents both the argument and provides a protocol for interacting. The use of questions typifies this. Questions are central to IBIS, particularly when there is disagreement or misunderstanding around an issue. The issue is transformed by the facilitator into a question, which is then explored as part of the map. This diffuses the personal issues that arise from adversarial discussion
and supports collaborative enquiry of the “Yes, and …” rather than “Yes, but …” kind. A Dialog Mapping session does not begin with a wide-ranging brainstorming activity, instead a question is posed that prompts for ideas (options) that directly address the problem. A map is built outwards from this, with parallel maps being added. This initial stage is less wide-ranging than SODA and risks elaborating a side issue in great depth before the true problem is identified [11]. It relies more on the group self correcting itself to identify the real issues. It does however lend itself to
fine-grained analysis of a specific issue and its structure makes it easier to maintain the map over time. Both cognitive mapping and IBIS address different aspects of the problem of eliciting upstream requirements. We have developed a process, and tool support, for exploiting the merits of both approaches that can be applied throughout the respective stages of a project.
3. The Wisdom process-tool The Wisdom process-tool has been developed to address the problem definition phase that precedes requirements definition. For typical systems engineering projects, this upstream phase is essential to generate a sufficient level of understanding of the project. Furthermore, this understanding should be agreed and common to the many stakeholders who have an interest in the project. The need for such knowledge is critical to inform the right set of requirements.
3.1. The process The Wisdom process aims to develop a common and agreed understanding with which to inform the requirements definition phase. The process integrates both the cognitive mapping and design rationale techniques that we introduced briefly in Section 2. While both techniques have been used in isolation by the Management Science and Computing communities respectively, we are not aware of any work that has combined them.
Cognitive mapping activity
Problem defined
Design rationale
Figure 3 The Wisdom process
Figure 3 represents the Wisdom process. Work begins at the core of the model initially where most activity is concerned with cognitive mapping in an attempt to understand the key issues and interests of stakeholders. As a holistic view of the project emerges, particular issues can be discussed, analysed and represented using design rationale maps. The ultimate product is the body of content knowledge that should be used to inform requirements definition. The value of the Wisdom process lies in capitalising on the strengths of both cognitive mapping and design rationale since we view the two techniques as complementary. As reported in Section 2, cognitive mapping is fundamentally used with a group process to support procedural rationality. The result of cognitive mapping is agreement and commitment to a way forward that will likely have involved negotiation. We argue that cognitive mapping is a useful process to understand the diversity amongst stakeholders and to support negotiation during problem definition. During this early phase, cognitive mapping thus gives a macro view of the problem. Design rationale differs to cognitive mapping since its starting point is a relatively narrow issue. Design rationale is more suited to situations where the key issues tend to be known and the focus is a more detailed analysis of these. In addition, design rationale languages are more formal, being based on a typing system with defined semantics. In the context of the problem definition phase, we use design rationale to explore key issues that have been identified during cognitive mapping. The more formal maps enable rigorous discussion and analysis of individual issues. In this way, design rationale maps provide a micro view of particular issues. We suggest that for systems engineering projects, cognitive mapping and design rationale are not just complementary, but necessary. Cognitive mapping naturally promotes divergent brainstorming activities that are necessary to understand the systemic nature of the problem. Furthermore, cognitive mapping avoids groupthink, which is where a single issue becomes the focus of a group. This constrains creativity and impedes divergent thinking. Having identified the key issues, design rationale can be used to explore each issue in greater depth. A design rationale map explicitly captures the arguments that emerge for each issue. In essence, cognitive mapping is better at developing an understanding of the whole, while design rationale enables in-depth and detailed deliberation around particular issues. Combining the two provide a powerful means for managing the problem definition phase. Documentation from the problem definition phase is critical since it determines system requirements. Moreover, personnel who join a project can use the documentation to understand how and why requirements
have been derived. The maps that result from the problem definition phase are the first of many documents that should be held in a project repository. In developing the Wisdom process, we experimented with three design rationale languages: QOC, DRL and IBIS. With DRL, we found that its complex type hierarchy caused people without a background in Computing difficult to use. Given that many stakeholders in systems engineering projects are non-technical, we ruled out the use of DRL. QOC is a much simpler language, but similarly to DRL, is concerned with evaluating options to relatively well-understood problems. Since IBIS has been designed to support deliberation and discussion as opposed to evaluating particular design options, we have found it better suited the problem definition phase. Moreover, its simple and intuitive type system is easy to use by non technical personnel. With cognitive mapping, the effectiveness of a meeting is dependent on the skills of a neutral facilitator. A facilitator is not merely a passive agent who minutes a meeting. Rather the facilitator’s objective is to foster procedural rationality, where stakeholders agree that sensible decisions have been made and commit to them. In practice, a facilitator ensures that a meeting remains focused, that the evolving cognitive map accurately reflects the ongoing discussion, that stakeholders get the opportunity to air their views and that the decision process is sensible. During the problem definition phase, such decisions will have an impact on the subsequent requirement definition phase. It is clearly important that where compromises have been made, effected stakeholders are aware of them and are willing to commit to them. While the need for a facilitator may appear to be an undesirable dependency, the Management Science community (both academic and commercial) has long recognised the value of skilled facilitators. We recognise that stakeholders are likely to be represented by senior personnel from geographically distributed locations. These factors mean that organising meetings is difficult and that they should be as productive as possible. Prior to meetings, we suggest a preparatory activity where all stakeholders are invited to provide initial input. Based on these inputs, a first-cut cognitive map is generated in terms of nodes but without links. This enables the facilitator to gain familiarity with the problem, in terms of issues, and to do initial work such as removing synonym issues. Furthermore, the preparatory activity allows meetings to be constructive more quickly than having to start from a blank sheet.
3.2. Tool support To support the process, we have developed tool support (Figures 1 and 2). Software is essential to manage the scale and complexity of data. For example, it is not uncommon for half-day workshops to generate 300
nodes. Given that the Wisdom process combines cognitive mapping and design rationale, a tool which allows users to work with both techniques is clearly required. Furthermore, for hybrid maps, the use of separate tools for each technique is unworkable. The tool supports facilitated meetings with services to create, edit store and browse cognitive maps, design rationale maps, and hybrid maps. Hybrid maps allow cognitive mapping and design rationale activities to be intermixed where appropriate. For example, where a particular issue is being deliberated using IBIS, inclusion of cognitive mapping elements that relate to the holistic view may be desirable to clarify the context of the specific issue or to resolve uncertainty. The tool allows free movement between the two notations in any one view. Based on initial trials, we have refined the tool in order to minimise its overhead in a facilitated session. A tool which is cumbersome to use is likely to have a detrimental affect on the effectiveness of the facilitator. Indeed, this is consistent with our argument to use cognitive mapping as opposed to design rationale in the early stages of problem definition since the overhead associated with using design rationale may unduly constrain brainstorming work. To promote the tool’s fluidity, we have focused on streamlining the user interface. To address pre-meeting preparation, the tool provides a distributed gather service. Initially, the facilitator uses this service to construct a questionnaire. The tool generates a web-based form which remote participants are then invited to complete. Based on the participants’ responses, the tool generates a cognitive map which comprises a set of disconnected nodes. The facilitator uses this map to prepare for subsequent facilitated sessions. For traceability, the tool stores maps in a database and provides simple reporting facilities in addition to the graphical views. The tool deliberately does not provide any automated support for making the transition between cognitive and IBIS maps. We investigated whether such support is desirable and what form it might take. For the latter, we considered building a set of heuristics that could be used. For example, one guideline involved finding cognitive mapping nodes which are tightly connected to others and make such nodes candidate IBIS questions. In this way, issues would be prioritised. However, based on experiments, it appears that active human involvement in this process is important to maintain a group’s collective cognition of the problem. Furthermore, the transition requires human judgement, experience, and intelligence. More generally, the need to generate more formal representations of maps remains an important avenue of further work.
4. Discussion and evaluation How does the hybridisation of process-centred and argumentation-centred techniques work in practice? The process-tool is just about to enter a comprehensive field trial in a HPC procurement project. To date, we have trialled the combined process and tool in a variety of artificial and ’real world’ environments. These trials have checked the usability and reliability of the tool, and experimented with different problem structuring and design rationale approaches in live group settings. HCI issues have been prominent in these tests. As well as populating the database with a sample set of requirements (for a new computing building design), the field trials completed already include university research planning meetings and, more significantly, a strategic planning session conducted in a UK government office. This last trial was the first major ’real-life’ test of the tool in its current form. Currently, a sequence of gathers, workshops, interviews and presentations is being planned for the HPC procurement project. This sequence will run over six months and constitute a large-scale test of the process-tool. While it is too early to say how the process-tool will deal with a six month process involving roughly a dozen or more different stakeholder groups with divergent perspectives and priorities, we have some evidence of how individual parts of the process work.
4.1. The role of formalisation In bringing two different techniques together, we have been concerned to develop a process-tool that both remained lightweight in relation to organisational decision-making and yet afforded some ways of making the process of decision-making more visible. Studies of organisations have shown that decisions are usually made incrementally [12]. In light of the incremental nature of decisions and negotiations, the process-tool should not try to formalise or solidify group decisions too early. Somewhat paradoxically, one of the side-effects of the methods we are trialling is to prevent decisions being made too quickly. Field trials have borne this last point out. For instance, in a session with government managers involved in re-designing part of their work process, the decisions to be made concerned strategies for ensuring that a report on a re-designed administrative system was accepted by other parts of the organisation. While this problem occupies a different domain to most requirements engineering, it also shares some basic feature. Here too different participants had different objectives, information was incomplete, some aspects of the report were incompatible with other parts of the organisation, and so forth. In addressing the problem, two phases of group work occurred in the session. In the first phase, options, questions and problems were elicited in a fairly arbitrary order. In the second phase, the group chose some key issues to
analyse in more detail. While the first phase was relatively informal and lead to fairly complex and crowded screens on the tool, the second phase produced hierarchically ordered tree-like structures. At the end of the workshop, no decisions had been made, but new issues had arisen and the group as a whole had shifted its own position in certain ways. For instance, a particular issue concerning ’metrics’ for the new administrative system arose. Although we could not claim that any single decision emerged out of the interaction around the maps, a gradual shift occurred in the course of the session. During the first half hour, talk around table passed between people without much attention to the maps projected on the wall. As the meeting wore on, the maps allowed the facilitator to draw discussion back over certain issues repeatedly. Each time this occurred, the maps could be re-ordered to some extent. Nodes would be grouped or linked in ways that showed the emergence of connections significant to the group. As this was done, the focus of the group turned more and more towards the maps projected on the wall. The shifts in attention towards the spatial layout of the maps signifies, we would argue, that something was shifting in the groups perceptions of the issues. Of course, such shifts can and do occur in conversations all the time. But the fact that these usually almost invisible shifts can be tracked visually is important. This increase in visibility can be understood in terms of the notion of incremental formalisation.
4.2. Informal interactions support formal process The notion of incremental formalisation has shaped our approach to automated decision-support features. A formal approach generates representations through the application of rules over some ’vocabulary’ [13]. Ideally, formal models permit clear and comprehensive representation of information. However, evidence from social scientists suggests that successful formalisations rely on a considerable degree of informality or ’play’. As Boden [12] writes: Making the organisation “work” means supporting (not subverting) rules, policies and goals at the formal level through a constant process of considerable informality. We follow Boden's suggestion in trying to ensure that informal interactions can ultimately feed into a more formal representation. While being cautious about formalising requirements too early, requirements engineering ultimately needs formal representations of some kind or other. A requirements specification for instance usually involves a coherent requirements model [14] that maps conceptually onto a description of the problem domain. The requirements elicitation process we have developed not only produces a coherent description of the problem domain, it moves from very informal group interactions around a map towards hierarchically structured representations of key issues. Although we
have not yet experimented with global maps, the database backend allows users to generate text reports of all the issues affecting the system. If, as many organisational sociologists argue, formal plans, representations and policies are supported by informal interactions, the Wisdom process-tool should be able to assist in improving formal plans and requirements by basing them on open and inclusive informal interactions.
4.3. Contemporary requirements elicitation as ’distributed’ process Recent analyses of the increasingly distributed and rapidly changing nature of organisations tend to suggest that requirements elicitation methods must also change. There is a large and constantly growing literature on organisational change, ranging from popular to academic texts [15][12], which stresses how the complexity of organisations undercuts older modes of decision-making and interaction: ’given the momentary attention spans of modern management and workers, successful organisations will be those that recognise and facilitate high levels of interaction and ready opportunities for quick contact’ [12]. Requirements elicitation is directly exposed to this problem. In our case study, users of high performance computing are scattered around the country. They come from universities, research institutions, government organisations and private enterprise. Bringing the principal stakeholders together in one place to discuss requirements constitutes a logistical problem in itself. It happens very rarely that everyone comes to the same meeting. The requirements elicitation for HPC, if it is to address the real issues and to develop a strong consensus between the different groups, has to cope with both ’momentary attention spans’ and very limited opportunities for contact. The face-to-face workshop process has therefore been supplemented by the network (LAN or internet) gather facility described earlier. In the near future, these simple mechanisms for distributed requirements elicitation will be tested at two sites. Firstly, in a teaching laboratory, the LAN-based gather mechanisms will be evaluated. Secondly, in a workshop with corporate managers, an Internet-based gather of issues will be trialled. Pending the outcome of these trials, a number of other possibilities need exploring. Firstly, can participants asynchronously manipulate maps (clustering, linking or coding nodes) in a way that is meaningful to the group as a whole? Secondly, can online voting mechanisms provide a way for participants to structure the issues and to negotiate around contentious points? Finally, will new facilitation techniques be needed to cope with these different kinds of access to the requirements elicitation process?
5. Conclusions In this paper, we have described the problems associated with problem definition, which is an initial project phase that aims to inform subsequent requirement definition. Problem definition, for systems engineering projects, has to address factors such as many stakeholders from different geographically distributed organisations, each with their own agendas and requirements. Conflict is inevitable and the problem definition phase seeks to expose these conflicts and to support negotiation that will lead to a common consensus of the problem. We have presented an overview of a lightweight process which has been developed to support the problem definition phase. Our contribution lies in a hybrid process that integrates two established techniques: cognitive mapping and design rationale. Each technique has been developed with different goals in mind. The former is primarily a group process which promotes divergent brainstorming activity and is concerned with revealing the systemic nature of a problem. In contrast, design rationale is geared towards analysing and arguing around individual issues. In this paper, we have argued that the combination of both techniques is an effective way of supporting problem definition. In essence, the Wisdom process enables incremental formalisation of the problem space by beginning with cognitive mapping activities to understand the key issues, expose conflicts and support negotiation. Once the problem has been defined as a whole, design rationale techniques can be used to refine individual issues and to argue about how they can be addressed. The ultimate goal of the Wisdom process is to develop a body of knowledge from which the right requirements can be elicited. The Wisdom process is necessarily accompanied by tool support. Such support is essential to manage the scale of typical maps and to address the distributed nature of stakeholders. The tool enables maps to be browsed, filtered, and edited. These services, in conjunction with simple reporting facilities help manage sizeable maps. The tool’s database provides a common repository, which coupled with the distributed gather service enables stakeholders to supply information asynchronously in preparation for collocated meetings. We are currently evaluating the Wisdom process-tool in the domain of HPC procurement. Based on these trials, we expect to further develop the process and tool. In particular, to further support distribution, we intend to investigate the role of asynchronous working. While desirable, more work needs to be carried out to determine how this can be supported in a way that adds value to the problem definition phase. Another avenue of interest is support for negotiation over contentious issues. We have suggested the use of voting mechanisms but this remains to be explored.
6. References
7. Acknowledgements
[1]
This papers stems from EPSRC-supported research into Decision Support for Systems Engineering, the Wisdom Project: EPSRC ref GR/M60361.
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12] [13]
[14]
[15]
Stevens R, Brook P, Jackson K & Arnold S, Systems engineering Coping with Complexity Prentice Hall, Europe 1998 Kotonya, Gerald, & Sommerville, Ian Requirements Engineering. Processes and Techniques, John Wiley & Sons, 2001 Monk, S. Sommerville, I. Pendaries, J.M. & Durin, B. "Supporting Design Rationale for System Evolution’, ESEC95 1995, 307-323 Eden CL and Ackermann F. Making Strategy: The Journey of Strategic Management. London, Sage Publications 1998 Eden C and Ackermann F. SODA – The Principles. In: Rosenhead J and Mingers J (eds). Rational Analysis for a Problematic World Revisited 2001. Wiley: Chichester Rittel HJ and Kunz W. Issues as elements of information systems. Working paper 131, Institute of Urban and Regional Development, University of California at Berkeley 1970 Lee J and Lai KC. What's in Design Rationale? Human-Computer Interaction Vol 6, 3&4 pp 251 – 280 1991 MacLean A et al . Questions, Options and Criteria: Elements of Design Space Analysis. HumanComputer Interaction Vol 6, 3 & 4 pp 201 – 250 1991 Conklin J et al. Facilitated Hypertext for Collective sensemaking: 15 Years on from gIBIS. Hypertext'o1 conference. Aarhus Denmark August 14 – 18 2001 Buckingham Shum S. Analysing the Usability of a Design Rationale Notation. In: Design rationale: Concepts, Techniques, and Use. Moran TP and Carroll JM (Eds) Lawrence Erlbaum Associates: Hillsdale, NJ pp 185-215 1996 Westcombe M and Pidd M. Problem Solving Dialogue: Cognitive Mapping and IBIS. Working paper MS01/02. Management School, Lancaster University, UK 2002 Boden, Deirdre The Business of Talk Organizations in Action Polity Press 1994 Bowers, John ’The Politics of Formalism’, Contexts of Computer Mediated Communication, ed. Martin Lea, Harvester Wheatsheaf, 1992 Wieringa, R.J. Requirements Engineering. Frameworks for Understanding, John Wiley & Sons, 1996 Kelly, Kevin New Rules for the New Economy, Fourth Estate, London 1998
