June 2010 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material June 2010 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
There are typically several interested parties in the design and construction of systems. These include the clients who commission the development, the designers and developers who design and build the system, and their management who look after the running of the project. These people are primarily interested in what the system should do – its functional requirements. An important set of people who are often forgotten about are the users who will actually end up using the system. In order to build systems which users will find usable we need to consider their needs rather than exclusively concentrating on functional requirements of the system. These non-functional requirements include issues such as the usability of the system and how acceptable it is to the users. Without such considerations systems may be produced which have been designed without considering whether they would be acceptable to users e.g. the introduction of an automated ordering system at a restaurant may not be acceptable to the users (waiters) if it requires them to spend a large proportion of their time interacting with it rather than interacting with restaurant goers. Clearly, if users do not find a system acceptable they will be reluctant to use it and so extensive redesign or user retraining may be necessary costing large amounts of time and money.
The rest of this section looks at approaches which are considered user centred. That is, they focus their attention on the user and their non-functional requirements rather than concentrating solely on functional requirements.
Socio-technical models consider the users within the organisational context that the system will be introduced into. The particular focus is on the interplay between the social and technical issues - hence the term socio-technical. One such approach is CUSTOM which concentrates on identifying who will be involved with the new system, and what their requirements are (not just functional requirements). Once these have been identified the designers of the system should have a better grasp of the non-functional user requirements as well as the organisational structure itself and how this relates to the design. Taking these requirements into account should help designers develop more acceptable and efficient systems.
CUSTOM refers to the people who would in some way be involved with the new system as stakeholders who can be classified in four ways:
Primary – the people who will use the system e.g. the waiters in a restaurant.
Secondary – people who produce input for the system, or receive output from the system, but do not directly use it e.g. the restaurant goers who are presented with a bill produced by the system at the end of their meal.
Tertiary – people who are touched by the success or failure of the system, but are neither primary nor secondary stakeholders e.g. the owner of the restaurant chain.
Facilitating – the people involved in the system’s design, development, and maintenance.
Once the stakeholders have been identified their characteristics are analysed to develop user centred requirements for the system. Dix, in his 1998 book, summarises this process of stakeholder analysis in terms of the following questions:
What does the stakeholder have to achieve, and how is success measured? E.g. waiters have to ensure diners are served at appropriate times and are happy with the level of service (not too intense or too disinterested). One way to measure a waiter’s success may be the size of their tip.
What are the stakeholder’s sources of job satisfaction? What are the sources of dissatisfaction and stress? E.g. for a waiter this may be the pleasure of serving food and providing a pleasant eating atmosphere. They may be stressed by angry customers or a large number of customers to keep happy at the same time.
What knowledge and skills does the stakeholder have? E.g. a chef has extensive knowledge of cooking which the waiters may not.
What is the stakeholder’s attitude towards work and computer technology? E.g. the owner of a chain of restaurants may be a technophile whilst a chef may be a technophobe. This may well cause conflict in the introduction of new technology.
Are there any work-group attributes that will affect the acceptability of the product to the stakeholder? E.g. is there something about people who become waiters that will affect how well they accept the product?
What are the characteristics of the stakeholder’s task in terms of frequency, fragmentation, and choice of actions? E.g. a busy waiter will typically have to perform many fragmented tasks with high frequency in order to keep the diners happy.
Does the stakeholder have to consider any particular issues relating to responsibility, security, or privacy? E.g. waiters may need to be discreet with regular diners who dine each night with a different partner, and may need to ensure that credit card payments are dealt with securely.
What are the typical conditions in which the stakeholder is working? E.g. the chef of the restaurant typically works in a hot and dangerous environment whereas the owner of the chain of restaurants may work in a conventional office environment.
Note how little is asked about the technology and the functional requirements of the new system. The intention is to understand users’ working context and their possible attitudes towards the new system so that it will hopefully be more acceptable.
A bank has asked a systems development company "Cash Machines R Us" to introduce new cash machines into one of their branches. Use the CUSTOM approach to socio-technical modeling to identify who the stakeholders are in the introduction of a new cash machine.
A Discussion on this activity can be found at the end of the chapter.
Soft-Systems Methodology (SSM) takes a broader view than socio-technical approaches by considering the organisation as a whole. From this perspective the stakeholders and technology are components of the larger context. As with other user centred approaches, the intention is to understand the context of the people involved with the system rather than making explicit design decisions. These models of the situation are instead used to inform design and help designers understand the context in which the final system will fit.
SSM involves the development of three kinds of models to help understanding the organisational context. The first kind of model is referred to as the rich picture which provides a detailed description of the problem situation. This includes details similar to the models of stakeholders developed in socio-technical approaches discussed previously – who the stakeholders are, what groups they work in, and what tasks they perform. In addition the organisational structure is modelled where it impacts on stakeholders’ work. As this model provides the context for further models it should be clear and informative for designers. It could be developed from interviews with people in the organisation, observations of their work practices, or more interactive approaches such as workshops in which stakeholders act out situations in order to help explain their work context.
The next stage moves the focus of analysis from the real-world situation to the development of definitions of what stakeholders perceive to be the activities taking place in the organisation. These definitions are referred to as root definitions of the system. There may be several different root definitions – representing different stakeholders’ perspectives – which need to be reconciled at a later stage. Root definitions model the following aspects:
Clients – people who benefit or accept output from the system e.g. in our restaurant example the clients may be the diners who benefit from the restaurant nutritionally and receive output from the system by way of a bill.
Actors – stakeholders who perform activities in the system e.g. the waiters and chefs in the restaurant.
Transformations – what changes the system performs on things in the environment e.g. a system which produces bills in a restaurant transforms diners’ requests for food (conveyed by the waiters) into bills by the end of the meal.
World view – how the system is perceived by a client e.g. a waiter may perceive an automated billing system as beneficial as it reduces the work they have to do in maintaining the bills for multiple diners.
Owner – who the system belongs to, and who can allow changes in the system e.g. the owner of the restaurant chain owns the automated billing system.
Environment – what factors influence the system e.g. a restaurant has to abide by certain health and safety standards.
Finally a conceptual model is constructed which details what the system has to do to meet the root definitions. The most important part of the root definitions are the transformations which are used in the conceptual model to define what is achieved, and how it is achieved. These achievements are usually modelled hierarchically to provide different levels of detail – much as tasks are decomposed in task analysis (see Unit 8). For example, the overall achievement of serving a diner includes successfully finding out what the diner wants, serving them, clearing the table, and ensuring that the food is paid for. Considering the hierarchic structure, achieving payment for the food involves several sub-achievements such as producing the bill, collecting the money, and possibly producing a receipt.
The conceptual model is used to identify differences between the real-world situation and the model of how the stakeholders perceive the system. These differences can then be used to inform change and/ or development of appropriate systems. The key outcome of the whole SSM approach is for designers to have a better understanding of the context in which developed systems are to be placed.
For the example in Activity 1 construct a root definition for the new cash machine from the perspective of a bank customer who wants to withdraw money.
A Discussion on this activity can be found at the end of the chapter.
Discuss the similarities (and differences) between socio-technic and soft systems methodology approaches to understanding user requirements , what sorts of things do they look at, and how can this provide input into design?
Answer at the end of the chapter.
The two approaches we have looked at so far develop user centred models which are typically used in the early stage of system development. In contrast, participatory design aims to keep the whole process of developing a system user centred. This is achieved by including users in the design team rather than treating them as subjects of analysis who remain outside the core design situation. The motivation for this is that users are essentially experts on their work situation – they know full well what work they do, how the organisation works for them, and who they need to work with – and so including them in the design process is essential if the new design is to fit well into their context. Moreover, the introduction of new systems typically changes the work context. For a new system to be acceptable these changes in the work context also need to be acceptable. Having users in the design team should help ensure that these changes do not overly disturb other users.
Participatory design has three main characteristics:
Work focused – design concentrates on improving the workers’ environment and tasks they perform rather than focusing on the system requirements.
Collaboration – the designers and users collaborate on the design so that the users can contribute at every stage.
Iterative – design does not just happen once, the emphasis of participatory design is on several design and evaluation stages which build to a final design.
As participatory design focuses on the collaboration between users and designers it needs to employ various techniques and models to communicate ideas between them including:
Brainstorming – sessions in which users and designers generate a range of ideas which are developed without judgement. These ideas are then fed into other techniques to be developed further or dropped.
Storyboarding – a rough idea of a user’s activities can be presented via a storyboard. The storyboard models user activities as a series of drawings – a little like a comic strip description of the activity. They are simple to develop and help users communicate with the designers about what they do, and how they do it.
Workshops – these provide a forum for discussion in which designers and users can ask each other about their perspectives and so establish common understandings of the design issues as well as focusing their views of the design. Typically they are used to fill in gaps in understanding about the situation. As such the designers usually enquire about users’ work environment, and the users ask about technological possibilities.
Pencil and paper activities – this provides a more interactive way of talking through designs than storyboards. Typically, rough designs are drawn (i.e. possible designs are modeled using pencil and paper) and then users consider how they would use it by moving through the design step by step. Problems with the design can then be identified from trouble the users have as they move through it. These problems can then be addressed in the next iteration of the design.
Participatory design was developed in Scandinavia where it has been widely accepted. However, the time and effort it requires, and reliance of less hierarchically structured organisations (where designers and users are treated equally), has meant that its use is less wide spread outside Scandinavia.
For the example in Activity 1 construct a storyboard of a customer withdrawing money from a cash machine. Imagine that the cash machine has several pages of information which it displays. For any operation the first page allows the user to enter their PIN (Personal Identification Number). If this is correct for the customer's card the machine shows the next page which allows the user to select one of several services on offer. If they select the withdraw cash service they are presented with a page from which they can select a predetermined amount of cash, or can select an option to allow them to determine how much they want. If they select this option they are then presented with a page which allows them to enter a value up to £250. Once the amount of money has been entered (either by selecting a predetermined amount or entering their own amount) the machine returns the card and then the cash to the customer.
A Discussion on this activity can be found at the end of the chapter.
How does participatory design relate to approaches such as socio-technical and Soft Systems Methodology. Concentrate on what they aim to do, and what sort of models they use.
Answer at the end of the chapter.
This section looked at models of user requirements. These are representations of the users’ world which are used to inform the understanding of non-functional requirements such as whether the developed system would be acceptable in the workplace. We looked at socio-technical models which consider who the stakeholders in the development of a system are. We then considered soft systems methodology which takes a broader view as it also models the organisation in which the stakeholders work. Finally we touched on participatory design which includes users in the design process and uses models to help designers and users understand each others’ points of view. All of these approaches involve extra time and effort than simply defining the functional requirements of a system. However, systems need to be developed which take into account users’ needs and work context otherwise they may be unusable or unacceptable to the intended users. It is the effectiveness of user centred approaches to take this into account that makes them attractive to developers.