Personal tools
You are here: Home 1997 Vol 29, No. 1, January 1997 Workshop: HCI and Requirements Engineering Generating Requirements in a Courier Despatch Management System
Navigation
 
Document Actions

Generating Requirements in a Courier Despatch Management System

Jocelyn Keep and Hilary Johnson

No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.29 No.1, January 1997
Next article
Article
No later issue with same topic
Issue


Introduction

"We need a new system which will provide functions from the old system and additionally some new functions". This request, from the owner/director of a small despatch company, provided the authors with an opportunity to investigate two related research themes; the first was concerned with the adoption of different approaches to data collection, and the second focused on the process of generating requirements throughout the design process. The opportunity was in many ways ideal in that underlying the superficially uncomplicated request was an interesting challenge for any designer of interactive systems. The reality was as follows: i) the task of the company was to provide a courier despatch service which was quick, efficient, competitively priced and at the same time profitable for the company; ii) the existing system was antiquated, ran on an old Amstrad computer, and both the computer and software used for despatch were riddled with problems, and used in a patchy and ad hoc manner by only a proportion of the staff; iii) courier despatch is a very complex real life, time critical domain consisting of a number of highly skilled and pressurized tasks; iv) the tasks undertaken in courier despatch are often interleaved, run in parallel, and in the case of this small company, are undertaken in a different manner by each and every employee; v) the workforce were small in number (approximately four), highly skilled and critical to the successful operation. However, there was in some sections of the workforce a relatively high turnover of staff due in part to the time pressured nature of the tasks, so staff job satisfaction was of paramount importance. The director/owner of the company also undertook many of the different jobs but mostly the tasks related to being the Controller (i.e. the one whose job it was to schedule delivery in time by the most appropriate riders/drivers and by whatever means; cycle, motorbike, car, lorry, armed van, etc.). Not least of the problems was that the long-serving section of the workforce, who were highly skilled, belonged to a population whose values resisted the use of computers in what they considered to be a highly creative task that did not need to be changed at all and least by the use, and introduction of, new technology.

The problem then in the course of improving on the existing system, was to overcome the reluctance of the workforce, increase or at least not decrease job satisfaction and support the workforce in conducting their tasks by allowing positive transfer of existing knowledge wherever possible.

User Involvement in Design and Participatory Design

In the past we have argued (Johnson, Johnson & Wilson,1995a) that an approach to design which included user involvement could be beneficial in that it avoided designers relying on their intuition about users and their work tasks. In the same paper we argued that we are not specifically engaging in participatory design (PD) because our approach to analysing and modelling tasks does not share the underlying philosophy of industrial democracy. Therefore, any increase in user satisfaction is a welcome by-product rather than a primary objective of designing systems that support people in their execution of everyday work tasks. In this case we were neither adopting the underlying philosophy nor specific participatory design methodologies designed to allow users to participate in design. However, users were heavily involved in the design process, (Johnson, Johnson & Wilson, 1995b).

The circumstances of the present case heightened the need for a decision as to what advantages and disadvantages there might be in adopting the underlying philosophy of workers having control over their own destiny as in the PD tradition. According to Opperman, (1984, p157) participatory design, "considers the interests of users and other affected groups ... [and] influence over the development process by the users. By their own efforts these groups will define their specific interests and incorporate these into the goals of system design". For Mumford (1983, p140), "participatory design enables employees to mould their own futures to a degree and create an environment that they find efficient and stimulating. By taking part in a process that is creative yet directed at a specific task-based goal, they acquire the confidence in their ability to contribute to the management of their own change". Mumford further argues that job satisfaction is the achievement of a good fit between what the staff seek from their work and what they are required to do in their jobs.

Daniel and Yeates (1984) indicate that the decision to introduce a new computer system should involve users in both planning and design. This involvement is assumed to provide a mechanism for resolving conflicts of objectives, gives users control over planning and design processes and results in high confidence and understanding because of the user role in design. The expected outcome is that the user group copes better with uncertainty and problems can be worked through and resolved. It may be the case that individual users may still experience uncertainty but it should be easier for them to communicate their problems and resolve them. Moreover, there is a high commitment to the system when it is introduced.

We choose to adopt the principle of PD in order to reduce staff reluctance to the new system, indeed to get the commitment of staff to the new system by involving them continually throughout the design process. One possible disadvantage of using a PD approach is that it may not suit the structure of British organisations, since it requires user (staff) participation in major decisions about the design of a new system. For instance, the approach is not appropriate for UK firms which have very rigid, bureaucratic, hierarchical structures where the managers do not consult staff members and where staff very rarely have the responsibility to make decisions for themselves. Therefore, there is often a conflict of interest between what clients want and what users require. However, the courier company was a very small, friendly firm where the company is owned by a number of partners each having a role within the company. The nature of this company made it possible to adopt the philosophy of industrial democracy because the user interests were mirrored by the clients, as a result of the client's participation and thus equal knowledge of, the user roles.

The approach would only be judged a success if three criteria were met; i) there was a strong user commitment to participation, ii) there was a degree of consensus within the company, so that conflicts could be easily resolved, and iii) the company would allow staff time to participate. The first and third criteria were met due to the close involvement of the first author with the company resulting from employment there during the summer. Meeting the second criteria would only be known to some extent during and at the end of the participation exercise.

The Process of Generating Requirements

Figure 1: A schematic diagram showing the process of data collection, requirements elicitation, and the evolving nature of the requirements

Participatory design could be characterised as having at least three facets; the underlying philosophy, specific methodologies and techniques for ensuring participation and the specific aspects of users and their work to which the methodologies and techniques might be applied, for instance, job satisfaction. In addition, a cursory glance at the different approaches to PD indicates that there are differing roles in, degrees and types of, participation by users with different outcomes. In this courier despatch example we adopted the underlying philosophy by involving users in all decision making throughout the design process, but used data collection methods with which we were familiar from task analysis. The task analytic data collection techniques with which we were familiar were adopted for the following reasons; i) some of the PD techniques have not been used by other than their developers, ii) other techniques such as contextual inquiry were just variants on data collection methods (concurrent protocols -- CP) used in task analysis approaches to gathering knowledge about users' tasks. Moreover, contextual inquiry suffers from the well-known problems of CP and provides little in the way of corroborating evidence for the data collected. iii) Our familiarity with the techniques previously used in task analysis exercises meant that we knew the advantages and drawbacks of each and were able to overcome these by using complementary methods by which to collect the data with the least disruption to the company. Figure 1 shows the process of data collection, requirements elicitation and the evolving nature of the requirements as the users participated in the very early stages of the design process.

The Users Contribution to the Design of the Courier Management System

Six methods of collecting initial data about the domain, tasks within the domain and how these were related and accomplished were employed, (see figure 1). The data were analysed and modelled using Task Knowledge Structures (TKSs). The task models were then validated with the users for the various tasks within roles and along with the good and bad aspects of the current system were the basis for the first set of requirements. Along with a frequently acknowledged problem of how to get from evaluations and task models to requirements, was the problem of the different ways in which the task were undertaken by different employees. The fact that different staff undertook the jobs in different ways was not viewed by us as a problem but as another example of where it is important for designers to be aware that even experienced users may not always adopt either similar or optimal methods or even recognise that their methods were suboptimal. The problem could be solved in a number of different ways each with their costs and benefits, either by providing alternative ways to carry out the tasks on the system to suit different users, or pool all the alternative means of achieving a task goal, ask all users to undertake the task by each method and then reach agreement on the most efficient or preferred methods. The results of the task analysis indicated that the controller role in particular was organised differently by different users in how jobs were allocated to drivers. The negotiation that followed amply illustrated the process of compromise when conflicts arise due to users participation in design and also illustrates the evolving nature of the requirements. The changes to the initial first set of requirements were as a result of this negotiation phase and the result was a refined set of requirements. At this stage another phase of participation arose when the requirements had to be prioritized and agreed by company employees on their ability to meet socio-technical objectives thus emphasizing user job satisfaction.

Initial system design and prototyping (both paper and runnable) then began with the users involved in the evaluation of the prototype and requirements review. Agreed changes to the designs were made at this stage to accommodate changes to the requirements once the users discovered what was or was not possible or what was or was not designed in the way intended as identified by the evaluations. Iteration between prototype, requirements review and evaluation continued until the users indicated that they were satisfied with the resulting design. The system was also walked through by an HCI expert.

Conclusion

The process of generating the requirements for the courier despatch management system was a success in that the users did appreciate being involved in the majority of the decision making that occurred throughout the design process and as a result had greater commitment to the newly designed system. The output of the design exercise, the new system, was on balance judged to be better than the old system, although there were acknowledged to be both good and bad aspects to both systems. Only the long term commitment to and use of the system in the future will indicate whether it is better designed than the old system and in what respects the participation of users in the design process contributed to this.

References

Daniel, A & D.Yeates (1984) Practical systems design.

Johnson, H., Johnson, P & S.Wilson (1995a) Task analysis and participatory design. In Proceedings of CHI95 Basic Research Symposium.

Johnson, P., Johnson, H & S.Wilson (1995b) Rapid Prototyping of User Interfaces Driven by Task Models. In J.M.Carroll (ed) Scenario-based design for human computer interaction. Wiley & Sons, Inc.

Mumford, E. (1983) Participatory design: Successes and problems in systems, objectives, solutions.

Opperman, R. (1984) User participation: Some experience and recommendations in systems, objectives, solutions.

Authors' Address

Department of Computer Science
Queen Mary and Westfield College
University of London
Mile End Rd
London E1 4NS, UK

email: hilaryj@dcs.qmw.ac.uk
tel: +44-171-975-5238

No earlier issue with same topic
Issue
Previous article
Article
SIGCHI Bulletin
Vol.29 No.1, January 1997
Next article
Article
No later issue with same topic
Issue

 

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: