There's something else missing here: requirements engineering in changing circumstances of design

There's Something Else Missing Here: Requirements Specification in Changing Circumstances of Work and Design

Andy Crabtree
&
Mark Rouncefield

Centre for CSCW Research
Computing Department
SECAMS Building
Lancaster University
Lancaster LA1 4YR
United Kingdom

Peter Tolmie
&
Jon O’Brien

Xerox Research Centre Europe
Cambridge Laboratory
61 Regent Street
Cambridge CB2 1AB
United Kingdom

John Hughes

Centre for CSCW Research
Sociology Department
Cartmel College
Lancaster University
Lancaster LA1 4YL
United Kingdom



Abstract

This paper is primarily concerned with gathering requirements in the context of work-oriented design, although its methodological ‘recommendations’ are readily applicable in other contexts. We preface those recommendations with a consideration of changing circumstances of design. We suggest that not only are circumstances of design changing but also, and perhaps more importantly, circumstances of work are changing; continuously. How design may gather requirements in the face of continuous change is our central methodological concern. Business process reengineering (BPR) offers one potential, and increasingly influential, solution to the problem in focusing on ‘core’ processes. In considering an ethnographic study of process modelling, we suggest that BPR approaches, while highly relevant, ‘miss’ something in generating requirements. That missing ‘thing’ is the ‘real world, real time’ practices whereby processes are produced and, thus, the actual work that systems must support and transform if they are ‘resonate’ with the practical circumstances of their use. We outline a framework for bringing those practices to bear on the specification of requirements.

Keywords. Requirements, business process reengineering, process modelling, ethnography, instances.

1. Introduction: requirements in changing circumstances of work and design

As demand for IT to be more responsive to human activities increases from all quarters, the production of requirements becomes an increasingly complex and problematic matter. In this paper we are primarily concerned with workplace activities and methods for the production of requirements supporting the integration of emerging technologies with practical circumstances of work. We suggest that the requirements problem has become increasingly complex not only as a result of changing circumstances of systems development (marked by a shift in focus from computer-centred to user-centred design) but also, and perhaps more importantly, by the continuously changing nature of the workplace itself. The transitional character of organisations in action suggests that systems design needs to develop methods supporting the gathering of requirements in the face of continuous organisational change. Placing emphasis on attention to ‘core’ processes, Business Process Reengineering (BPR) offers one potential, and increasingly popular, solution to this aspect of the requirements problem. Ethnographic studies of BPR in action suggest that the descriptive apparatus employed in the production of process maps glosses the situated practices from which processes emerge, and is (thus) insufficient for purposes of requirements specification. In outlining the notion of ‘language-games’ and ‘instances’ of concepts in use, we present an alternate descriptive apparatus and framework of analysis.

2. Changing circumstances of design

Whether conceived as a single phase or a continuous one, requirements specification is that part of the system development process that is concerned with the question: what is to be built or what external functions should the system perform? Over the course of the last thirty years, approaches to requirements specification have become increasingly sophisticated as the system development effort has evolved from little more than a ‘cottage industry’ run by ‘inspired tinkerers’ and ‘management by neglect’, to a large and ever increasing industrial activity (Landes, 1972; Buxton, 1978). The advent of third generation computers in the late 60s evoked widespread interest in commercial sectors and system development found itself confronted by industrial concerns. As demands for large-scale systems came to the fore, the ‘disorganised’ organisation of design came into serious question (Brooks, 1975). Software production could no longer rely on the ‘local guru’ but had to be accomplished through an organisation of work where there was little or none before (Friedman, 1992). The very practical problem to be addressed was how to organise development in general, and requirements specification in particular, on a large industrial scale.

2.1 The waterfall model

The waterfall model was the first systematic attempt at organising system development in an industrial context. A top-down approach, the waterfall model emerged in the early 70s, providing a development structure for organising large projects with a large staff over long periods of time. The waterfall model emphasises the need to proceed systematically, deferring implementation as long as possible and, accordingly, divides the activities of analysis (requirements specification), design and implementation into discrete linear phases. Requirements are gathered through observation and discussion with users and emphasis is placed on ‘front-loading’, iteration and the achievement of ‘sub-goals’ in specifying and testing solutions to requirements prior to implementation in order to avoid expense in error correction. Under the auspices of the waterfall model - and managerial and economic considerations in particular (Boehm, 1976; Agresti, 1986; Heninger, 1980) - requirements specification became an ‘up front’, almost isolated, activity in the development ‘life-cycle’. At the centre of the analysis phase lies the requirements specification document. The requirements specification document spells out in detail what services the system should deliver - an answer to the question: what should be built?

2.2 The emergence of a common problem: user-centred design

At the time of implementing the waterfall model as development orthodoxy, system design was generally conceived of as an activity concerned with delivering a ‘product’. The computer was the central concern, to the extent that entire organisations had to adapt their working patterns around the machine. As demand for the computer to move further into the world of work and organisation increased, emphasis shifted from product to ‘process’ however; people and patterns of work were becoming the central concern (Floyd, 1987).

In shifting focus from computer-centred design to user-centred design, the requirements problem has become ‘wicked’ and ‘complex’ (DeGrace & Stahl, 1990). Specifically, in the service of people in general, and patterns of work in particular, potential solutions are multiple in character and thus, open-ended, under-determined and invariably subject to details of change. In light of changing circumstances of system development, it became apparent that approaches which would enable the more dynamic specification of requirements supporting the design of systems that ‘resonate’ with the practical circumstances of their use were needed. One ‘tack’ or response was to adapt the waterfall model (Boehm, 1988; Yourdon, 1989; Jacobsen, 1992). Another, to reject it altogether (Belady & Lehman, 1976; Floyd, 1984; Budde et al., 1992).

3. Compounding the requirements problem: changing circumstances of work

Whatever ‘tack’ taken, and there are of course many more than the ones cited above (e.g. Mumford & Weir, 1979; Checkland & Scholes, 1990; Carrol, 1995; etc.), the requirements problem has been compounded by the changing nature of organisations themselves. Organisations, as Shapiro (1994) reminds us, are in a constant state of flux, evolving in relation to dynamics which arise from non-technological sources which technology must nevertheless be compatible with. Change does not stop within an organisation simply because a design project is undertaken and requirements must, therefore, be gathered in the face of continuous change. A case from a recent project concerned with the development of a prototype for a global customer service system supporting the activities of a container shipping company serves to illustrate some of the problems here. Customer service in container shipping consists of the interrelated activities: quoting and pricing, export handling, allocation, documentation, and import handling. These activities hold across the board so to speak - that is, throughout the world - although practices for accomplishing these activities differ from region to region as local circumstances dictate. Furthermore, practice within specific regions was evolving and changing as the development project progressed. Take the activity of export handling in Europe for example:

When we first started gathering requirements for export handling we paid attention to how that activity (or, more precisely, family of activities) was accomplished in ‘real-time’, how it was related to or ‘co-ordinated’ with other activities, and what ‘information’ the accomplishment of export handling consisted of and relied on. Glossing matters somewhat for expediency’s sake, our first ‘observations’ of export handling in Europe revealed that work was primarily organised by service line and booking order. Vessels sail on particular ‘service lines’ - Atlantic lines, Pacific lines, Mediterranean lines, Middle East lines, West Africa lines, etc. - and customer service staff delivered services for freight transported on particular service lines. Thus, export handling agents A and B delivered services to customers shipping freight on Atlantic lines G, H and I; agent C, West Africa lines K and L; agents D and E, Pacific lines M, N, O and P; and so on. Export handling agents recorded ‘bookings’ for the shipment of freight on a ‘booking order’. A booking order was nothing more than a plain notepad on which relevant customer and freight details were recorded. Details might consist of customer name, contact number, number and type of containers required, commodity and weight, destination, etc. Details varied according to the export handlers relationship with the customer - export handlers ‘knew’ many of the details of ‘regular’ customers so didn’t need to write them down. Booking orders were usually taken, and details otherwise clarified, over the phone and placed in a ‘pending tray’ awaiting ‘processing’ or input into the computer. Export handlers, like the majority of personnel, rarely used the system during interaction with customers or minimally so if necessary. System use was avoided for two reasons: 1) the system was slow and cumbersome; and 2) details were / are often incomplete and change over time. The system was used, then, to formalise bookings, update changes, and co-ordinate export handling with other activities.

At the same time as we were gathering requirements, the regions were engaged in local and regional business process improvement (BPI) initiatives. Following BPI assessments by management, and some six or seven months into the development project, the organisation of work began to change. Export handling, for example, was beginning to be organised by customer and booking map rather than service line and booking order. Organising work by ‘customer’ meant that small teams were assembled to deal with specific groups of customers regardless of service line. These teams provided all basic export services; specifically, quoting, export handling, allocation, and documentation. Following this reorganisation of the workplace, customer service staff (practitioners not managers) responsible for export handling started to devise and implement routines that were never used before. A ‘booking map’ is a public artifact - a formatted list to be precise - employed as an organisational device in booking’s accomplishment. A booking map is vessel-specific, recording bookings for one vessel only, and basically consists of the following details: mother vessel name and voyage code; customer name; booking number; customer reference (if applicable); destination; container type; feeder details (truck or rail to destination X or feeder vessel and voyage code). While conventions for booking map use were still being ‘agreed’ upon, one further feature was already integral, the recording of contingiencies in the right hand side margin of the booking map, that is, things to check for this particular booking’s accomplishment: special conditions, missing particulars, formalities yet to be achieved etc. When all necessary work for a particular booking is done, then that accomplishment is made publicly visible with a tick. Having completed all the bookings on a whole map, that accomplishment is similarly made publicly visible with a tick in the bottom right hand corner of the map. The very presence of a booking map that is several days old in the workspace indicates that a problem has yet to be resolved for a particular booking or number of bookings on the particular vessel it covers. Bookings assigned to vessels other than the one originally specified are visibly indicated by being crossed through. As before, staff use the maps rather than the system as far as possible, and again for two very practical reasons: 1) ease of use — it is easier, literally, to have such frequently used information ‘ready to hand’ than to navigate the system; and 2) booking maps furnish relevant, frequently used, information ‘all in one place’ in distinction to the system where this information is contained in a number of places. Thus, changes in work - and note these are as much practitioner’s changes as management’s - made work a more ‘effective process’. As one customer service agent described it for example:

"I don’t know what customer service did before we changed to this new system [of working] .. if they had some kind of a booking list [in] each department . or what they did · but we have agreed in our department that each person who . has some responsi . who are responsible for some shippers .. have a booking map . because if I’m not here they can see which bookings I have made and which bookings have to be done"

‘Efficiency’ is a continual ambition in many organisations and appropriate changes are always underway to some greater or lesser extent. We cannot ignore these issues in undertaking design. To be effective, future systems must ‘resonate’ with the practical circumstances they are to be embedded within and facilitate, but if those practical circumstances are always changing, how are we to generate adequate requirements for a future system?

4. Gathering requirements in the face of continuous change: core activities

That organisations are continually changing is not an insurmountable problem in itself. While local practice in container shipping was different and subject to continuous change in different regions, for example, ‘core’ activities nevertheless maintained across the board. Whether in North America, Europe or Asia, the activities (or rather, the family of activities constitutive) of quoting, pricing, export handling, allocation, documentation, and export handling were performed daily, albeit in different ways. They were performed daily in that these activities are what customer service in container shipping is ‘all about’. That is, customer service in container shipping is, to gloss matters again, all about formulating a financial rate for shipping freight (quoting and pricing); planning a transport route (export handling); reserving space for freight on particular vessels (allocation); making legal documentation covering transport (documentation); and tracking and arranging for the release and delivery of freight (import handling). However organised - whether by service or customer, for example - these core activities remain, in that doing these things (and more) is what it takes to get a container from point A to point B. To borrow a metaphor from Wittgenstein (1968), it might be said that customer services in container shipping is a distinct language-game that consists, like any game, in a unique family of categorised activities which ‘define’ the game in their performance and evolution across space and time. Gathering requirements in the face of continuous change thus consists of identifying the ‘defining’ activities of the ‘game’ (Crabtree, 1998). That is, the evolving activities that, in ‘defining’ the game, are ‘essential’ to the game’s continued performance in the face of change. Activities that the ‘playing of the game’ relies upon; that lie at, and constitute in conduct, the ‘core’ of an organisation’s daily business, however contingently organised. The question, of course, is how might we ‘go about’ doing that; how might we ‘go about’ discovering ‘core’ activities and generating appropriate requirements in the face of continuous change?

5. Discovering core activities: business processes reengineering and requirements specification

Business process reengineering or BPR (Hammer & Champy, 1993) is of increasing influence in the world of work and systems design alike insofar as IT solutions are often seen as facilitating ‘radical’ business solutions. As such, BPR provides a focus, direction and putative requirements for future systems in ‘redesigning’ the workplace. Of central concern to BPR are ‘core’ processes. That is:

"processes that the business’s strategic thinking has identified as critical to excel at to meet or beat the competition. They make up part of the company’s set of core competencies." (McHugh et al., 1995: 52)

Obviously, core processes need to be identified in order to redesign work and generate requirements for potential IT support, and the initial stage of BPR is, then, the ‘discover’ phase (8-12 weeks). The ‘discover’ phase consists of high-level workshops organised to create a high-level vision of what the organisation should be like in the future. Creating a high-level vision of the future relies on selecting appropriate processes to reengineer. As Carr & Johansson (1995: 103) point out: ‘doing a process right is not enough - picking the right process is the key’. The problem of course, is how might organisations ‘go about’ picking the ‘right’ process(es) and thereby create suitable visions of the future?

Picking the ‘right’ process(es) and envisioning the future relies on identifying core processes and competencies currently ‘at work’. That is, on identifying the ‘as-is’ activities, practices and skills which support and enhance current core processes. Identifying core processes and competencies currently ‘at work’ is achieved through ‘mapping’ core business processes. Mapping, in this context, consists of assembling ‘quickmaps’ - rough diagrams of the boundaries, connections and workflow constitutive of each process. Quickmaps elaborate the point and purpose of each process; the departments and work units involved; the activities constitutive of the process; and current controls and boundaries. They serve to illuminate the parts of the process that are important, who is involved in the process’s production, and create a ‘fact-based’ performance baseline. They also serve to create a common understanding among participants involved in the task of reengineering.

Quickmaps describe discrete activities constitutive of core processes and in doing so furnish details supporting the ‘search’ for targets for reengineering. That is, as descriptions, quickmaps serve to explicate current activities, thus providing for the formulation of suitable ‘scenarios’ envisioning the competitive position of the company in the future, and designing appropriate processes ‘to-be’. BPR relies, then, on the description of current practice through ‘mapping’. In addressing the issue Carr & Johansson remark:

‘You usually don’t need to map the most minute level of detail (such as fax sent, fax received), but rather should stop at least one step above that level - the activity or transaction level (for example, record customer order). It is important to find the level of activity or transaction at which work is actually done and map to that level.’ (Carr & Johansson, 1993: 139)

Through the formulation of scenarios, ‘as-is’ maps are transformed into ‘to-be’ maps describing, at the same level of description, future processes of work and putative requirements for IT support. This ‘level’ of description has, we believe, profound consequences for requirements specification as an ethnographic study of the production of process maps serves to illustrate.

A managerial preoccupation that came to light in a long-term ethnographic study of a major High Street bank - specifically, in one of its new Lending Centres - was that of process modelling and the production of process maps. The Lending Centre in question was taking on the work of a number of smaller Lending Centres throughout the North West of England. The objective of ‘centralising’ the work was one of ensuring that, for every single process the bank engaged in, there would be a process map so that anyone could come in and do the job in exactly the same way as anybody else. The perception was that there was a definitive way to engage in a particular activity and managers tried to ensure that, for each activity their staff engaged in, there was a process map representing ‘best practice’. In observing the production of process maps, it quickly became apparent that the formulation of ‘best practice’ relies on ad hoc considerations of situated practices of work that nowhere figure in the process maps themselves.

An illuminating example is provided by the case of the manager of the Lending Centre’s ‘sanctioning’ department, who was overviewing the production of a process map by two of his staff. The process in question was a complex one regarding how to eliminate or reduce the level of ‘hard-core’ debt run up by customers using a certain kind of credit card, while simultaneously turning that occasion into an opportunity for what was, effectively, a ‘sale’, by offering the customers loans to clear the debt. In order to achieve this ‘goal’, it was clear that staff from the sanctioning department would have to collaborate with staff from other departments (‘phones’ and ‘monitoring and control’), and the manager in question was therefore obliged to visit the managers of the related departments in order to discuss the best way to lay the process map out. In the following extract from the fieldnotes we find a marked difference in the understanding of the process between two of the managers involved:

LY: What they’ve done is they’ve come up with a three stage process map .. but I don’t think it’s quite there yet .. So what we’ve got is . what we need is . two separate process maps .. we need . one for MAC .. and we need one for Phones . and err . letters . right .. go on . right go on .. fire away

MG: Can I see that?

LY: Can you see that? Yeah . ‘cause .. there’s something else missing here (points to area under decision box on stage 3 process map) . for you

MG: There’s something there that’s wrong as well (puts ‘?’ under box on stage 2 process map)

LY: On what?

MG: It’s alright the si . the simple thing here . what I ‘d like to do is rather than go through it the way . you’re saying Yes or No happens okay

LY: We’ll know all the successes if we get any but we won’t know the ones who er . er comin’ back and sayin’ no thanks . right but we wanna . er r . I need to know those

MG: You will be . because you’ve been declined . if you get a letter in

LY: But uh eh . no . no

MG: No you will

LY: No . for the phone ones . nobody’s gonna tell me

Each manager was concerned to arrive at a model that would best reflect the day-to-day activities that their own particular staff engaged in. Given this, the two managers had to work together at discovering just what might be ‘missing’ from the original model and arrive at some sort of ‘fix’ that would take the ‘missing’ elements into account. In bringing ‘missing’ aspects of work to bear on the process model, the managers engaged in intensive, and sometimes heated, negotiation, sketching out options on scraps of paper, discarding some and keeping others. The end-product was a complex and highly creative design that was heavily informed by their own experience of the day-to-day character of their work, and the work of the staff around them. Furthermore - and more tellingly perhaps - it was clear that each of the managers had a vested interest in gaining the best advantage for their own staff, with neither of them being prepared to approve a model that, while possibly offering some better overall advantage, would result in a greater workload for the people working in their own section.

Ultimately, and in light of their respective ‘relevances’, both managers chose to build a ‘compromise’ solution into the process map that they both felt they could live with:

LY: So here’s another way of doin’ it . we end up with a screen-based log . that you input into daily .. right? ..

Sorta . like . sorta like the date (appends Date Column) . t- t- the date of . er the letter . the account number . and the sort code .. so that ‘s your inputs . yeah? . And then it’s over to us

MG: Mm

LY: As opposed to manual . manual bits of paper . Happy with that?

MG: Yeah I mean as I say there’s two options you can run

LY: Yeah

MG: And it’s either manual log . or somethin’ on there (gestures to Workstation)

None of this is to suggest that the process model they finally arrived at was necessarily a ‘poor’ or ‘inadequate’ representation. However, what we would point to is the way numerous contingent considerations were brought to bear in arriving at that ‘right’ model, with neither of the managers offering an unproblematically ‘clear’ and ‘definitive’ version. Instead they were obliged to negotiate, argue, experiment with, and compromise over different possibilities, embed aspects within their own experience and, indeed, draw upon a huge range of other wholly situated practices, in order to arrive at something that they could put forward as a representation of ‘best practice’.

We can see, then, that a process map is a collaborative production of situated interaction, relying on all of the here and now preoccupations that the parties to it bring to bear. Given this, and to extend Suchman’s (1987) observations regarding the situated and contingent realisation of ‘the sense within the plan’, we might further observe that the very making of the plan, or in this instance the process model and its constituent maps, is a contingent affair relying on situated practices of work. It is just these fine-grained, situated practices that are ‘missing’ from any ‘fixed’ representation of a process. And this, of course, has profound implications for matters such as standardisation in the workplace and the gathering of requirements in system design.

It is not simply the case that the actual achievement of ‘the sense behind’ the standard or process takes a great deal of ad hoc work. The more significant point we would want to make from the above observations is that the very act of arriving at just what might constitute the ‘standard’ or ‘process’ vis-ˆ-vis ‘best practice’ is something that takes a great deal of ad hoc work, relying on undocumented practices of work. There is then, ‘something else missing’ from process maps, that ‘something’ being the ‘real world’ practices which process maps, and their realisation (the ‘real world’ process itself), rely on for their production. A fortiori, there is a clear shortfall in the specification of requirements for future systems of work. That shortfall is, we believe, a consequence of the level of description undertaken in doing business process reengineering which explicitly draws the activity to a close at the level of ‘transactions’ in contrast to practices whereby activities are performed and processes thereby produced.

6. Gathering requirements: documenting undocumented practices of work

We are not ‘damning’ BPR but pointing out that there is an inadequacy in the level of description it proposes for purposes of work redesign in general and requirements specification in particular. As Hughes et al. remind us:

‘It is through social practices that processes are established and, accordingly rooted in socially achieved sets of arrangements.’ (Hughes et al., 1994: 430)

While BPR ‘recognises’ those socially achieved sets of arrangements to some extent, it ‘misses’ the social practices in and through which those arrangements are produced. Thus, it fails to describe the social practices in and through which processes are produced. Recognising the social practices for the production of a process, or collection of processes, is not merely incidental to work and systems design but, as we note elsewhere:

‘In order to support structures and processes designers must provide for the performance of the work from which structure and process emerge. How else could information systems design, indeed any form of design proceed?’ (Crabtree et al., in preparation)

The issue becomes one of how might the performance of work - that is, the social practices in and through which activities of work are achieved and processes thereby produced - be brought to bear on the specification of requirements in changing circumstances of work and design?

Social practices for the production of activities may be ‘discovered’ or explicated through ethnographic inquiry. Ethnography has achieved some prominence over recent years within the fields of Computer-Supported Cooperative Work and Participatory Design. Efforts to incorporate ethnography into the systems development process stemmed from the realisation, mainly among systems designers, that the success of design has much to do with the social context into which systems are placed (Grudin, 1988; 1990a; & 1990b). Systems are used within peopled environments which are, whatever ‘technological’ characteristics they may have, ‘social’ in character. Ethnography, which places an emphasis on the description of interactions in natural settings and participants’ terms, seemed to lend itself well to bringing a social perspective to bear on system design.

The advantage of applying ethnographic methods to date lies in the ‘sensitising’ they promote to the ‘real world, real time’ character and context of social settings, and thus, in the opportunity they provide to ensure system development resonates with the practical circumstances of systems use. That ‘opportunity’ may be brought about through the production of ‘instances’ of concepts in use (Crabtree, to appear). That is, of empirical descriptions of the performance of the discrete, categorised activities constitutive of the ‘language-game’ in question (Section 4). In describing the ‘real-time’ performance of activities, ‘instances’ make visible the social practices for the observed activities’ production (and thus, the situated practices of a process’s production). While activities are performed by individuals, the practices for their production are anything but idiosyncratic. To be sure, individuals may well engage in idiosyncratic behaviour in the course of ‘doing the job’ but that achievement relies on social practices that are tied to the ‘job’ and not to the individuals who perform it. The notion is not at all difficult to appreciate. In learning a ‘job’, or rather, the various activities constitutive of a ‘job’, individuals learn practices for getting the ‘job’ done. In learning to do reading we learn the rules of grammar; in learning to do driving we learn the conventions of the highway; in learning to do programming we learn to ‘cut code’ in standard ways (Cobalt, C++, Beta, etc.). The doing of activities, then, relies on social practices for their production, on specific practices that are tied to specific activities and manifest in their performance. Thus, in observing and describing the ‘real-time’ performance of activities of work, it is possible to explicate the social practices for their production and the production of corollary processes. Insofar as those practices are tied to the activities, or the ‘job’, then we make visible the practices for the performance of the job across current space and time insofar as the same organisation of work obtains. An example of an ‘instance’ of a concept in use is provided below:

The job of ‘allocation’ in container shipping frequently consists of the activity of ‘rerouting’. Rerouting is occasioned for various reasons: bad weather, vessel running off schedule, customer requirements, etc. Rerouting consists in 'reallocating' cargo to a substitute vessel or vessels (there may be several 'legs' and thus different vessels on any particular container's journey). The substitute vessel may be located in a different port to the load or leg port. Furthermore, the destination port of rerouted cargo from a particular vessel may well be different. Thus, the activity of rerouting is all about arranging appropriate transport for cargo going to multiple destinations from some contingent point either to the destinations direct or, failing that, to a point from which cargo can be delivered to its respective destination ports. Instances of rerouting's accomplishment revealed that route alterations occasioned not only changing the first leg of a journey but also the first half of the second leg for instance, or, indeed several legs on a journey. Furthermore, these changes were discovered to be subject to criteria of rerouting, specifically of time and cost: an independent local transporter was specified wherever possible if time allowed, rail failing local transporter, truck failing rail; the local transporter is more cost effective than rail, rail more cost effective than truck although time pressures might necessitate everything being moved by truck. It also transpired that rerouted cargo must be grouped: in some locations reefer containers, used for perishable products in particular, cannot be moved to transshipment points by rail for example (due to concerns of supervision - the temperature of reefer containers must be monitored at regular intervals), cargo for this or that destination must be identified and the criteria applied. More: as a result of ‘hard wiring’ processes in existing technology, rerouting had to be accomplished individually - groups could not be selected and assigned to alternate vessels except in the simplest of cases: 'roll over' or temporal rescheduling to another vessel from the load port. Rerouting is a collaborative activity involving booking agents, capacity management, operations and documentation.

Rerouting is a ‘core’ activity in container shipping - while it may not figure greatly in anyone’s ‘strategic planning’, so long as vessels are in use it is not going to go away (although ‘overlooking’ it may make customers ‘go away’). Though practice may well be changing of its own accord during the course of development, achieving an understanding of ‘real world’ working practice in details of its ‘real time’ performance, affords the identification of intransigent problems of work (rerouting in this case) and situated methods of solution which taken together suggest possibilities for support through design. In other words, in grasping 'what is really going on' in the course of rerouting, 'what is really the problem' of rerouting and thus what rerouting is 'really all about' becomes apparent (Hughes et al., 1992). Thus, the instance delineates a problem-space emergent from practice itself. Furthermore, in illuminating the ways in which staff routinely go about solving the problem through mapping the concept's grammar, the instance delineates a solution-space rich in productional detail providing for the initial formulation of requirements and concrete design solutions. Instances are invaluable resources in grounding design in practice and its constituent details, allowing (as the rerouting example hopefully demonstrates) system design to get 'hands on' with the practical circumstances of system use and generate appropriate requirements in the face of continuous change. The production of instances relies on description at a finer level of detail than that currently advocated by BPR. Ethnographic description does not end with ‘record customer order’, for example, but starts there. That is, ethnography asks and seeks to make visible what ‘recording customer order’ (or ‘rerouting’ etc.) consists of as a practised activity being done. In furnishing instances of such achievements, not only does ethnography furnish a concrete, transformable resource for design but, perhaps more importantly, in doing so it specifies quality criteria facilitating the design of systems that resonate with practical circumstances of their use and (thus) the monitoring of organisational change through technological intervention (Christensen et al., 1998; Crabtree et al., in preparation).

7. Supporting requirements specification in changing circumstances of design and work

We have suggested that the requirements problem, i.e. finding out what to build?, has become increasingly complex. This is partly a consequence of the changing circumstances of design with a move away from a computer-oriented focus and towards a more user-oriented one. However, of equal or even greater significance are the constantly changing circumstances within which people work. We have therefore suggested that what is needed is an approach or, more precisely, a collection of approaches that support the gathering of requirements in the face of continuous organisational change. Business Process Reengineering offers one potential solution to this aspect of the requirements problem by focusing upon ‘core’ processes. However, we have argued that its descriptive apparatus is visibly lacking insofar as that apparatus ‘misses’ the situated practices which, being productive of processes and process maps alike, are essential considerations for design.

We have suggested that one potential solution to the problem of description is to use ethnographic methods which are able to explicate the social practices that activities rely on. Such ethnographic descriptions furnish ‘instances’ which enable the treatment of organisations as language-games with the grammar of the game being mapped through instances of concepts in use. Instances describe the activities, and situated practices for their production, that ‘define’ the game, are ‘essential’ to the game’s continued performance in the face of change; activities and practices that the ‘playing of the game’ relies upon. Such activities and practices lie at, and constitute in conduct, the ‘core’ of an organisation’s daily business, however contingently organised. Instances describe, then, the socially organised ways in which specific activities ‘get done’ and co-ordinated with other activities, thus displaying the situated practices in and through which ‘processes’ emerge. Through this description instances might be seen to circumscribe a problem-solution space for design by displaying practical problems of work and situated practices for their solution. In this way instances can provide for the formulation of requirements and initial design-solutions that resonate with, and at the same transform, the practical circumstances of system use.

It is important to stress here that we are not proposing ethnographic methods to be some sort of ‘panacea’ for design. Rather, the language-game framework may be employed in conjunction with a variety of other approaches including, for example, OO modelling, experimental approaches, and even BPR itself (Christensen et al., 1998; Crabtree & Mogensen, in preparation). Indeed, the purpose of this paper has been to reveal the extent to which it is just this kind of ‘complimentary’ approach to requirements specification that is best able to address the problem of generating requirements in the face of continuous change.

References

Anderson, R.J. (1994) Representations and requirements: the value of ethnography in system design, Human-Computer Interaction, 9 (1), 151-182.

Agresti, W.W. (1986) The Conventional Software Life Cycle Model: Its Evolution and Assumptions, New Paradigms for Software Development, Washington D.C: IEEE Computer Society Press.

Belady, L. & Lehman, M. (1976) A Model of Large Program Development, IBM Systems Journal, vol. 15, 225-252.

Blomberg, J., Giacomi, J., Mosher, A., Swenton-Wall, P. (1993) Ethnographic Field Methods and their Relation to Design, Participatory Design: Principles and Practices (eds. Schuler, D. & Namioka, A.), 123-155, Hillsdale, New Jersey: Lawrence Erlbaum Associates.

Blomberg, J., Suchman, L., Trigg, R. (1994) Reflections on a Work-Oriented Design Project, Proceedings of the 1994 Participatory Design Conference (PDC ‘94), 99-109, Chapel Hill, North Carolina: Computer Professionals for Social Responsibility.

Boehm, B.W. (1976) Software Engineering, IEEE Transactions on Computers, 25 (12), 1226-1241.

Boehm, B.W. (1988) A Spiral Model of Software Development and Enhancement, Computer, vol. 21, 61-72.

Brooks, F.P. (1975) The Mythical Man-Month, New York: Addison-Wesley.

Budde, R., Kautz, K., Kuhlenkamp, K., Zullighoven, H. (1992) Prototyping - An Approach to Evolutionary System Development, Berlin: Springer Verlag.

Button, G. & Sharrock, W.W. (1997) The Production of Order and the Order of Production: Possibilities for Distributed Organisations, Work and Technology in the Print Industry, Proceedings of the Fifth European Conference on Computer Supported Cooperative Work (ECSCW ‘97), 1-16, Lancaster, United Kingdom: Kluwer Academic Publishers.

Buxton, J.N. (1978) Software Engineering, Programming Methodology, New York: Springer-Verlag.

Carr, D.K. & Johansson, H.J. (1995) Best Practices in Reengineering: What Works and What Doesn’t in the Reengineering Process, New York: McGraw-Hill Inc.

Carrol, J. (1995) Scenario-Based Design: Envisioning Technology in Use, New York: John Wiley.

Checkland, P. & Scholes, J. (1990) Soft Systems Methodology in Action, Chichester: John Wiley.

Christensen, M., Crabtree, A., Damm, H.D., Hansen, K.M., Madsen, O.L., Marqvardsen, P., Mogensen, P., Sandvad, E., Sloth, L., Thomsen, M. (1998). The M.A.D. Experience: Multiperspective Application Development in evolutionary prototyping, Proceedings of the Twelfth European Conference on Object-Oriented Programming (ECOOP 98), Brussels, Belgium: Springer.

Crabtree, A. (1988) Ethnography in Participatory Design, Proceedings of the 1998 Participatory Design Conference (PDC ‘98), to appear, Seattle, Washington: Computer Professionals for Social Responsibility.

Crabtree, A. Talking Work: language-games, organisations and computer supported cooperative work, Computer Supported Cooperative Work: The Journal of Collaborative Computing, to appear, The Netherlands: Kluwer Academic Publishers.

Crabtree, A. & Mogensen, P. Intervening: The Relevance of Specifics and the Specifics of Relevance, in preparation, Department of Computer Science, Aarhus University, Denmark.

Crabtree, A., Nichols, D.M., O’Brien, J., Rouncefield, M., Twidale, M. Ethnomethodologically Informed Ethnography in Information Systems Design, in preparation, Computing Department, Lancaster University, United Kingdom.

Floyd, C. (1984) A Systematic Look at Prototyping, Approaches to Prototyping (ed. Budde, R. et al.), 1-18, Berlin: Springer-Verlag.

Floyd, C. (1987) Outline of a Paradigm Change in Software Engineering, Computers and Democracy: A Scandinavian Challenge, 191-210, Aldershot, England: Avebury.

Friedman, A.L. (1992) Four Phases of IT: lessons from the past; insights into the future, CRICT Conference on Software and Systems Practice: Social Science Perspectives 1, Reading: ACM Press.

Gr¿nb_k, K. Kyng, M., Mogensen, P. (1997) Towards a Cooperative Experimental System Development Approach, Computers and Design in Context, (eds. Kyng, M. & Mathiassen, L.), 201-238, Cambridge, Massachusetts: MIT Press.

Grudin, J. (1988) Why CSCW Applications Fail: Problems in the Design and Evaluation of Organisational Interfaces, Proceedings of the 1998 ACM Conference on Computer Supported Cooperative Work (CSCW ‘88), 55-93, Portland, Oregon: ACM Press.

Grudin, J. (1990a) Interface, Proceedings of the 1990 ACM Conference on Computer Supported Cooperative work (CSCW ‘90), 269-278, Los Angeles, California: ACM Press.

Grudin, J. (1990b) The Computer Reaches Out: The Historical Continuity of Interface Design, Proceedings of the 1990 Conference on Human Factors in Computing Systems (CHI ‘90), 261-268, Seattle, Washington: ACM Press.

Hammer, M. & Champy, J. (1993) Reengineering the Corporation, Australia: Allen & Unwin.

Heath, C. & Luff, P. (1992) Collaboration and Control:Crisis Management and Multimedia Technology in London Underground Control Rooms, Computer Supported Cooperative Work: An International Journal, 1 (1), 69-94.

Heninger, K.L. (1980) Specifying Software Requirements for Complex Systems: New Techniques and their Applications, IEEE Transactions on Software Engineering, Special Edition, 6 (1), 2-13.

Hughes, J.A., Randall, D., Shapiro, D. (1992) Faltering from Ethnography to Design, Proceedings of the 1992 ACM Conference on Computer Supported Cooperative Work (CSCW ‘92), 115-122, Toronto, Canada: ACM Press.

Hughes, J.A., Randall, D., Shapiro, D. (1993) From Ethnographic Record to System Design: Some Experiences from the Field, Computer Supported Cooperative Work: An International Journal, 1 (3), 123-141.

Hughes, J.A., King, V., Rodden, T., Andersen, H. (1994) Moving Out of the Control Room: Ethnography in Systems Design, Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work (CSCW ‘94), 429-439, Chapel Hill, North Carolina: ACM Press.

Jacobsen, I. (1992) Object-Oriented Software Engineering: A Use Case Driven Approach, New York: Addison-Wesley.

Kensing, F. Simonsen, J., B¿dker, K. (1996) MUST - A Method for Participatory Design, Proceedings of the 1996 Participatory Design Conference (PDC ‘96), 129-140, Cambridge, Massachusetts: Computer Professionals for Social Responsibility.

Kensing, F. & Simonsen, J. (1997) Using Ethnography in Contextual Design, Communications of the ACM, 40 (7), 82-88.

Knudsen, J.L., L_fgren, M., Madsen, O.L., Magnusson, B. (1994) Object-Oriented environments: The Mj¿lner Approach, New York: Prentice-Hall.

Landes, D. (1972) The Unbound Prometheus, Cambridge: Cambridge University Press.McHugh, P., Merli, G. Wheeler, W.A. (1995) Beyond Business Process Reengineering: Towards the Holonic Enterprise, New York: John Wiley.

Mumford, E. & Weir, M. (1979) Computer Systems in Work Design: The ETHICS Method, London: Associated Business Press.

Randall, D., Rouncefield, M., Hughes, J.A. (1995) Chalk and Cheese: BPR and ethnomethodologically informed ethnography in CSCW, Proceedings of the Fourth European Conference on Computer Supported Cooperative Work (ECSCW ‘95), 325-340, Stockholm, Sweden: Kluwer Academic Publishers.

Rogers, Y. & Bellotti, V. (1997) Grounding blue-sky research: how can ethnography help? Interactions, 4 (3), 58-63.

Rouncefield, Hughes, J.A., Viller, S. (1994) Working with "Constant Interruption": CSCW and the Small Office, Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work (CSCW ‘94), 275-286, Chapel Hill, North Carolina: ACM Press.

Shapiro, D. (1994) The Limits of Ethnography: Combining Social Sciences for CSCW, Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work (CSCW ‘94), 417-428, Chapel Hill, North Carolina: ACM Press.

Simonsen, J. & Kensing, F. (1994) Take Users Seriously, But Take a Deeper Look: Organisational and Technical Effects from Designing with an Ethnographically Inspired Approach, Proceedings of the 1994 Participatory Design Conference (PDC ‘94), 47-58, Chapel Hill, North Carolina: Computer Professionals for Social Responsibility.

Suchman, L. (1987) Plans and Situated Actions: The Problem of Human-Machine Communication, Cambridge: Cambridge University Press.

Suchman, L. (1995) Making Work Visible, Communications of the ACM, 38 (9), 56-64.

Yourdon, E. (1989) Modern Structured Analysis, Englewood Cliffs, New Jersey: Prentice-Hall.

Wittgenstein, L. (1958) Philosophical Investigations, Oxford: Basil Blackwell.



click here to return to the Materials and Publications index


Produced and Hosted by the Center for Digital Discourse and Culture     © Center for Digital Discourse and Culture, Virginia Tech. All rights reserved. The physical campus is in Blacksburg, Virginia, U.S.A. For more information, please contact the Center at cddc@vt.edu