As studies of the user group have shown (see Chapter 2 - ‘The User Group’) the security officer’s job consists of two separate, but related, activities:
Each activity provides its own situation of concern:
The system’s requirements can be summarised in a one sentence statement (Newman & Lamming, 1995, pg17) as follows:
"Design a device that will quickly recall situation-relevant facts for the user with the minimum of prompting, as well as storing an audio-visual record of events for later examination, without occupying the user’s hands or his/her full attention".
Choice of a suitable design methodology is important to the ultimate success of a software system. The traditional approach is often termed the ‘Waterfall model’ (Preece, Rogers, Sharp, Benyon, Holland & Carey, 1994, pg 356), so called because there is a linear flow through the development stages:
Requirements analysis à System specification à Software production
This does have the advantage of predictability - once the requirements analysis is complete there is little new input from the (eventual) users of the system; development can proceed ‘unhindered’. The big disadvantage is a significant risk that the finished system may not actually satisfy the users’ requirements. Worse, the system may not be usable, or may even be dangerous. Newman and Lamming (1995, pg 9) cite the London ambulance service’s ambulance dispatch system as a case in point. What should have been a routine software development project became a crisis from the moment it was first used. The complexity of using the system increased as staff attempted to deal with the information being displayed. After a few days it became clear that it was not possible to use the system in its present form, with ambulances arriving increasingly late, and the multi-million pound system was effectively scrapped.
In order to avert such disasters many software development projects employ user-centred design techniques (Preece et al, 1994, pg 357). The fundamental difference from the traditional approach is the ongoing involvement of the eventual users in the design process. In particular, one or more prototypes are produced, often with increasing detail, for the users to comment upon. This process helps to ensure both user satisfaction with the final system, and the likelihood that it will fulfil the role and expectations for which it is created.
A good model for such a process is Boehm’s 1988 spiral model. The key feature of this model is its iterative nature. The design is presented to users who comment and make suggestions. The users’ input is taken as the starting point for modifications to the design, after which a new prototype is presented to the users for further comment. This process is repeated several times, each time reducing the discrepancy between the design and the users’ requirements.
The ultimate goal of the current project is to produce a saleable memory assistant. While it will be designed for the security industry, there is not yet any specific customer in that industry. It will have to compete for funds with other potential purchases, such as more CCTV cameras. It is therefore essential that the device is effective in its operation, as well as being easy to use and well liked by the users. The use of an iterative user-centred design and development process is therefore highly desirable.
There is, however, a potential problem with using an unbridled iterative development process - the ideal number of iterations can be very large. For example, the messaging system designed for the 1984 Olympics produced over 200 prototypes (Preece et al, 1994, pg360). Often, timescales limit the number of iterations that can accommodated. In the case of this project, there is a fixed deadline of 1 September 1998 by when all user testing must be completed. It was planned to achieve one lo-fi and one hi-fi prototype based iteration in the time allowed. Based on John Harrison’s ‘W’ model (Preece, et al, 1994, pg 359) this can be represented by an ‘E’ model (see Figure 1), where the increasing line length represents the increasing level of detail at each user presentation.
Figure 1 - ‘E’ diagram, representing the project design methodology
The potential tasks involved in attending an alarm activation are here presented in the form of a hierarchical task analysis (Newman and Lamming, 1995, pg 117). This analysis will be used later for specifying the ‘help-me-out’ system. Figure 2 shows the main task analysis, while figure 3 expands the sub-task of ‘Unlock door’.
Figure 2 - Task analysis of dealing with an alarm
Figure 3 - Task analysis expansion of ‘unlock door’ (see Figure 2)
As shown above, the ‘help-me-out’ system can be broken down into discrete stages using hierarchical task analysis. The memory capture system, however, does not lend its-self to such a process for two important reasons:
Thus analysis of the memory capture system will focus on the information to be captured, and the method of presenting this information to the user, rather than the process of recall. A formal method of describing the information to be captured is used in order to maximise the effectiveness of the description. Since the captured information comprises representations of real-world objects (pictures, sounds, etc.) it was decided to use an object-oriented approach. This method examines the real-world objects involved, grouping them into classes and defining the relationship between the classes. The Booch method of notation was chosen (Booch, 1994). The Booch analysis is shown diagramatically in figure 4 (overleaf).
Figure 4 - Recorded events - class relationships using the Booch notation
This analysis was important in designing the prototype software. From the diagram (figure 4) it is clear that two classes (and thus objects) are common to all others - activations and times. In other words, every class is linked to both a time and an activation. Therefore, all information can be displayed in relation to either a list of activations or a list of times. Further, these two ‘common classes’ are themselves related (every activation has a time, but not vice versa). Since a sound has many times (it lasts for several seconds) listing the activations would not be as intrinsically clear as listing the times. Therefore the software was designed around a ‘timeline’ - a list of times
| Next Section | Previous Section | Beginning | Contents | MSc home |