task analysis and systems analysis for software development

Interacting with Computers vof 4 no 1 (1992) 124-239

Task analysis and systems analysis for software development

Dan Diaper and Mark Addison

The paper offers a commenta~ on Benyon (1992). It questions the absence of a role for task analysis in the early stages of system development and attempts to refute many of Benyon’s assumptions and criticisms concerning task analysis methods, at least by showing that his criticisms do not apply to all of them. The commentary also questions Benyon’s systems analysis model for software development and suggests that it is unrealistic.

Keywords: human~omputer interaction, task analysis, systems analysis, software devetopment

This paper offers a commentary on Benyon’s paper in this issue of Inferacting with Computers. We believe that Benyon makes a valuable contribution to the field, but we wish to raise three issues:

l The contribution of task analysis to the earliest stages of system development.

l The exaggeration of device independence in systems analysis and its underestimation for task analysis.

l The realism of Benyon’s proposed systems analysis model for software

development.

Overall, Eenyon presents his arguments from the systems analysis perspective. In contrast, this commentary presents the task analysis perspective. Simply because of our own expertise, this commentary will tend to use Task Analysis for Knowledge Descriptions (TAKD) as a typical, sophisticated task analysis method. Benyon also discussed TAKD more extensively than any other task analysis technique.

The first author, as General Editor of Interacting with Computers invites further commentary on Benyon’s proposals and those presented here.’

Department of Computer Science, The University of Liverpool, PO BOX 147, Liverpool L69 3% UK

‘N.B. Interacting with Computers has a policy of allowing authors a reply to commentary papers such as this and we expect Benyon’s repty to be published in the next issue of the journal. We hope to be abIe to make his reply available to others who wish to comment in advance of publication.

124 0953-5438/92/010124-16 0 1992 Butterworth-Heinemann Ltd

Benyon commences his ‘Concluding remarks‘ by saying:

“It is vital that HCI specialists do not expend their energy inventing wheels which have already been painfully discovered by others. The contribution which HCI needs to make is in providing usable, reliable and understandable modelling tools (or task analysis techniques) which will complement the existing methods and tools of (structured) systems analysis.”

We entirely agree with this conclusion, but not with Benyon’s claim which

starts his paper:

“It is the contention of this paper? that existing systems analysis techniques are more effective in the analysis and early design stages of system development than any of the task analysis techniques currently advocated to fulfill this role.“

Benyon presents a four stage systems analysis model for software development which can be summarised thus:

l Stage 1: Context analysis of the computer system with respect to: 0 “the purpose of the system” 0 “the organisational, political and social environment within which the

system must operate” 0 “the characteristics of the user population” 0 “the major (external) tasks which it must support”

l Stage 2: Conceptual or logical modelling, which Benyon claims is most appropriately supported by “data-centred techniques“

l Stage 3: Allocation of tasks and data structure to human and machine l Stage 4: “Physical design and implementation of the system including the

human-computer interface and all the user support such as manuals, training materials etc.”

While this commentary discusses Benyon’s four stages as if they were separate and embedded in something like the traditional waterfall model of software engineering, we recognise that this is a literary convenience and that stages may be carried out partly in parallel or with frequent swappings or iterations between the stages.

Benyon suggests that stages 3 and 4 of this system analysis model of system development can be supported by at least some task analysis methods and, while we might quibble about what is really meant by “cognitive task analysis techniques” (e.g. Diaper and Addison, 1991), the general issue of task analysis’ contribution in these later stages does not appear to be an issue. Nor do we disagree with the value of a data-centred perspective. Even in stage 1 above Benyon recognises that “there are important roles here for high-level task analysis techniques”. Where we disagree with Benyon is on the role and type of task analysis in stage 1.

Benyon ‘caricatures’ the “traditional systems analysis” approach to the capture of data in stage 1 of his model as follows:

2i.e. Benyon’s paper.

Diaper and Addison 125

“The analysts spent time studying how people perform their jobs, the documents

and other objects which they used, the things they did with those objects and how they performed these actions. In short, analysts concerned themselves with how the current system works. The analysts would interview people, search through documents, analyse the content of documents, observe people working and study the relevant literature. As a result the analyst would identify the things which

people were concerned with, what they did with those things, which were critical

to their work and which were most typical, the sequence in which they did things,

and so on.”

The only difference between these activities and those of task analysis are that task analysis, which when done properly includes all of the above, provides a more systematic way of doing this and allows the results of these various activities to be integrated and we discuss this claim below. Thus, there is no disagreement that task analysis is suitable in “traditional systems analysis”.

Whatever claims Benyon makes about the “structured revolution” of systems analysis in the 197Os, we believe that the models and representations employed (ERMs, DFDs, ELHs) must still be dependent on an analysis of the current world. Our position is that within the structured revolution it is still desirable to undertake stage 1 in a thorough, comprehensive and subsequently useful manner.

To illustrate the structured revolution’s failure to capture requirements: in Cameron’s (1983) classic IEEE JSP and JSD manual it is difficult in 100 pages of JSD to find even one page devoted to data capture. The overall impression is that it is sufficient to wander around with the managing director of the “Widget Warehouse Company” (Cameron, 1983: Chapter 4.3), perhaps chat to a few other people, and then start on JSD’s entity/action and entity structure steps. Of three recent books on SSADM (Downs et al., 1988; Hares, 1990; Ashworth and Goodland, 1990) only the latter makes any mention of data capture techniques, although they choose not to describe them further as they are “well-known techniques described in many textbooks”. Our point is that the structured methods have emphasised structured stages with well defined inputs and outputs and the representational notation to be used, but have been much weaker at specifying what analysts do to produce and transform representations.

To the trained psychologist, none of the data capture techniques listed by Ashworth and Goodland that might be used in Benyon’s stage 1 are simple or straightforward. They are all difficult to design and/or carry out, are subject to many forms of bias, and their analysis is difficult and the results frequently unclear and presented in a manner idiosyncratic to the technique employed. Two questions are posed to illustrate the primary technical problems with using a selection of these capture methods:

l How can the results of carrying out such methods be integrated? l How are the results of these methods used by subsequent stages?

The most popular current solution to the first problem is to produce an output from these techniques in natural language. This at least allows some points of apparent agreement to be noted, but is overall a rather unhappy solution as its

126 Interacting with Computers ~014 no 1 (1992)

limited success is achieved by ignoring many of the inconsistencies and conflicts. Where only a natural language representation is provided as input to Benyon’s stage 2 it is easy for the stage 2 analysts to read selectively.

We believe that most task analysis methods do have the non-trivial capability to integrate data from numerous sources and of many types in a representation

that in some cases is an improvement, at least, on natural language alone. Furthermore, as an example of a sophisticated task analysis method, TAKD uses a number of different representations which systematically vary both in content (e.g. whether sequence data is represented) and in generality. The analyst using TAKD is forced to be aware of the decisions he or she is making about different aspects of the world, that he or she needs to understand, to perform Benyon’s stage 1 adequately. TAKD places few constraints on analysts, but it does force a systematic, explicit way of thinking about tasks and their more general context. If TAKD is otherwise limiting, it is in the way that it forces an inherently user-centred perspective, because in TAKD actions are always those of people, not of machines. In the context of HCI we do not see this limitation as anything other than desirable, at present.

Benyon questions the understandability of task analyses’ output, although he is obviously only referring to a subset of available task analysis methods, that include TAKD, when he suggests that:

“the preference for grammars as opposed to diagrammatic models in HCI is disturbing. Grammars offer an appearance of formality, but they are not as user-centred as diagrams . . . users cannot understand them (grammars).”

Benyon generally ignores the many problems associated with diagrams; for example, there is no widely understood grammar or semantics to diagrams.

Diagrams appear understandable, and users can therefore be misled by their interpretations of them if they are not fully conversant with a particular style of diagrammatic notation. This is particularly important with specialised diagrammatic methods such as DFDs. We therefore dispute the claim that diagrams are inherently user friendly and suggest that they have to be learnt, just like other forms of notation.

Many task analysis methods use both diagrammatic and grammatical representations and TAKD is even able to output meaningful sentences in a close approximation to English (e.g. Diaper and Johnson, 1989). The first author’s considerable experience at teaching TAKD to students (Diaper, 1989a; 1990) and the results now appearing from the TOM project3 (Diaper and Addison, 1991) where real commercial designers have been using TAKD, suggests that people do not have any great difficulty in understanding TAKD’s various representations, both diagrammatic and grammatical. Indeed, we have been surprised in

me TOM project (Task Oriented Modelling for Interactive System Design) is a collaboration

between Logica, British Aerospace, University College London, Queen Mary and Westfield College, and the University of Liverpool. It is lead by Logica Cambridge Ltd. and is funded under the United Kingdom’s Government’s Department of Trade and Industry (DTI) and Science and Engineering Research Council (SERC) Information Engineering Advanced Technology Programme (Grant NO. IED1/4/1717). The views expressed in this paper are entirely the responsibility of the authors.


the past how quickly people have been able to understand KRG sentences when we have discussed a particular TAKD analysis with them. Our experience suggests that Benyon is wrong, at least with respect to TAKD.

The second question, which concerns how the results of data capture methods are used by subsequent analysis stages, illustrates what Diaper (1990) has suggested as being the major problem with HCI today. He refers to “the gulf” between anthropocentric-(people) oriented requirements specifications and computer-centric design specifications. At present, he claims, this gulf is crossed by using the personal expertise of the analyst and involves what Long (e.g. Long, 1986; Long and Dowell, 1989) would call “craft” rather than “engineering”. There is a philosophical problem concerning how one converts one representation of the world into another (e.g. Diaper, 1984). In practice one does it and uses ‘common sense’.

Below, we describe some current work with TAKD that explicitly addresses the issue of how a task-oriented representation can be converted into a computer system-oriented one. While the work of TAKD is with formal methods, rather than with structured, diagrammatic methods (DFDs etc.), the principles would be the same and, given the motivation and resources, we think we could get TAKD to output DFDs rather than a formal language representation.

Gikas et aI. (1990) have developed a temporal logic which is similar in format to the algebraic specification language OBJ. Within the TOM project we have shown to ourselves that it is possible to take the output from a TAKD analysis and use it to generate device-centred descriptions in the formal algebra. Current research at the University of Liverpool on a new task analysis method (FaSTA - Fast and Structured Task Analysis - Killip, 1991) is developing a more sophisticated method of using task analysis to represent both people and computer systems using the logical notation of Z. TAG (e.g. Payne and Green, 1986; 1989) has always had the ability to output results in Backus-Naur Form (BNF), although TAG’s scope is generally restricted to low-level interface design issues. Similarly, Walsh (1989) provides one means of integrating HTA with JSD.

While none of the above task analysis methods output DFDs directly, they do suggest that task analysis methods have a potential role in providing input to a data-centred approach within a post-‘structural revolution’ system design method (i.e. used at Benyon’s stage 1, they can provide input to his stage 2). Thereby, this work has the potential to bridge the gulf, referred to above, between the necessary and desirably different perspectives between Benyon’s stage 1 (human-centred) and stage 2, which we would claim is a computer- centric view. The latter claim is important: we believe that relational models, DFDs, etc., are more suited to modelling computer systems than people, tasks and their contexts, and that this is how they are really used in systems analysis.

Benyon’s dismissal of using anything other than “high-level” task analysis methods at stage 1 is ultimately due, we think, to his strong, traditional claims concerning the advantages of device-independent representations. Benyon fails to define device independence, but his meaning is illustrated in the following (concerning the ‘structured revolution’s’ replacement of flow charts by DFDs):

128 Interacting with Computers v014 no 1 (2992)

Figure 1. Level 0 context diagram DFD for a conferencing system

“The flow chart had concerned itself with who did what, where, what the sequence of those processes was and the physical representation of documents and files. The flow chart represented the thinking of the loop and the procedural program. An arbitrary distinction was made between decisions and processes.

The data flow diagram (DFD) by contrast concentrated on data and the

movement of data. DFDs ignore the current sequencing of actions and the distinction between processes and decisions. . DFDs suppress aspects of the

system such as iteration. They shift attention from the control of data to the flow of

data.”

We draw the reader‘s attention to the many recognised problems associated

with data modelling (see, for example, Hares, 1990), but wish to dwell only on the notion of device independence. Definitions, beyond that of programs that will run on alternative hardware (e.g. Collin, 1989), are not common in the literature. Our general interpretation of Benyon’s meaning of device independence with respect to systems analysis, is that a device-independent representation is one that contains some description or specification which is not influenced either by existing technology and current practices, nor by anticipat- ing the systems developed from applying the representation.

The issue of device independence is important because it leads Benyon to a number of erroneous views on task analysis and its suitability for use at his stage 1 of context analysis. The unsuitability of task analysis, Benyon argues, is due to it only being able to analyse existing tasks whereby its analyses are entirely device-dependent (undesirable) and so of little or no use to his device-independent analyses. He says:

“Current practice is always tied to existing technology. It is the device which

causes the practice.”

We do not believe, in the large, that this is a sustainable position. Rather, current practice (i.e. carrying out a task) is done for some purpose and the notion of purpose (or goals, desires, needs, etc.) is central to all task analysis methods. Such purposes are often device-independent, for example, as Shepherd (1989) suggests, particularly when specified at a high level. Indeed, methods such as GOMS (Card, Moran and Newell, 1983) generate goal descriptions that are reminiscent of the titles associated with many DFD process bubbles. For example, in Figure 1, which shows an example level 0 context diagram DFD for a conferencing system, the process bubble is labelled ‘Process message’ and a high level user goal might be expressed as ‘Communicate with the other user(s)‘. In TAKD this high-level goal might be represented as a high-level TDH node (Figure 2).


Use conferencing system

i Communicate with other users --_ i

i ‘--- -__-

Don’t communicate with other users i___,

i___ Don’t communicate deliberately

/ I__-

i Try and fail to communicate --- 1

I ---

. ._ Figure 2. A TDH fragment representing user g~als/~cf~~ns associated wtfh a conferencing system

In addition, Benyon makes a claim that is demonstrably false regarding the inability of task analysis methods to identify problems with an existing system. In summary he makes the foftowing arguments:

The outcome of systems analysis should not be characterised as: “a description of an existing system upon which design can be based,” but should be expressed as: “the problems of the existing system“. We think it more plausible that to understand the problems one also needs to model the system. Thus we propose that this outcome should instead be ‘a description of an existing system and its problems upon which design can be based’.

Benyon then makes the following claim:

* The problem is that task analysis methods cannot deliver. To take one example, what is the process whereby a lengthy, detailed and thorough task description can identify any new functions. It is the process of anaiysing difficulties which will identify requirements for new functions, not by describing current practices.

l T&e answer: To give one example, Diaper (FE@) describes the use of TAKD on task-focused interview data so that design suggestions from the existing system’s several types of expert user, and also from the system designers, could be processed. The sponsoring company was provided with an interface architecture of a totally novel sort and with novel functionality. Diaper claims:

“This task similarity result then led to a proposed interface design for the next generation ATJZ which could take advantage of this finding by providing a single, modeiess type of interface to such ATE.”

Our point here is that Benyon is wrong in his claim that task analysis “cannot deliver”. Indeed, we would think task analysis ideal for identifying problems

130

with an existing system, whether the problems are cognitive (e.g. load, decision, difficulty, etc.), physical ergonomic (e.g. light, noise, size, position, etc.), or with functionality (see later), or usability.

Benyon’s views on task analysis methods’ device dependence and inability to solve problems lead him to make other claims about task analysis which are in error. For example, with respect to:

l hierarchies l perspectives l task flow 0 objects, actions and entities

This commentary will now offer some argument against Benyon’s claims before turning to question just how realistic is Benyon’s system analysis method for software development.

In part, Benyon bases his criticisms that task analysis “fails to deliver” on his understanding that task analysis is necessarily hierarchical. While it may be a common view of task analysis that it is inherently a hierarchical method, we interpret comments such as those of Carroll (Anderson et RI., 1990) who says: “‘Task Analysis’ refers to schemes for hierarchical decomposition of what people do,” as using the term in the weak sense of a decomposition into levels of description (Diaper, 1984). Indeed, Benyon fails to appreciate the difference in TAKD between the hierarchical representation used in its Task Descriptive Hierarchy (TDH) and the real, underlying representation which in graph theoretic terms is that of a directed cyclic graph. The TDH appears hierarchical because it was considered an easier representation for anlaysts to work with, and is exploited as such in some of the TAKD method’s associated heuristics.

Benyon uses his view of task analysis’ hierarchical nature in the following example:

“We must expect our systems to be used by multiple users who have differing views on the entities, tasks and operations in the system. We will have a poor design if this variety is designed out. To accommodate different views, hierarchies must be abandoned as by definition they represent only one view.”

Clearly Benyon is wrong with respect to this multiple user argument. The work of Diaper (1990) looked at multiple users, as does the current work on TAKD within the TOM project where Air Traffic Control is effected by several people: the ATCO, the Flight Chief and a number of other staff. Employing a Popperian, falsificationist argument (Popper, 1979; see Magee (1973) for an introduction), we therefore know Benyon’s criticisms with respect to task analysis being limited, because it uses hierarchical representations which, he claims, allow only one view and which therefore cannot deal with the necessarily different views associated with different people, do not apply to TAKD.

Benyon then makes the claim:

“Task analysis also includes the flow of control. The HTA descriptions are sequenced. Walsh’s (1989) task structure diagrams show iteration and selection


mechanisms. TAKD includes iteration, selection and sequence. Furthermore, TAKD bases its analysis on specific instances of behaviour. The whole thrust of task analysis is to emphasise flow of control.

But in any redesigned system, the flow of contro1 will be different. The control flow is a feature of the device being used.”

The claim about control flow with respect to TAKD is odd, because it is only in

the most recent work that TAKD has been developed to model control flow. All the early work (e.g. Johnson et al., 1984; Diaper, 1988, 1989a; Diaper and Johnson, 1989) did not represent sequences of events. There is no sequence information at all in TAKD’s TDH representation: it is explicitly and deliberately excluded. Just because hierarchical representations, in particular, have been found useful for representing events in time, it does not fotlow that they are always used to do so.

We will, however, concede that there is a level of task description which may be technology-driven, but this has been recognised by TAKD, if not other task analysis methods, previously. Indeed, within TAKD the primary rationale for its generification processes is to remove such technology-driven aspects of the task. As Diaper (1987) says:

“The advantage of TAKD is that it is able to provide descriptions of tasks that are independent of each task’s particular technology. TAKD achieves this because the. . . KRG sentences that are used to redescribe tasks are generalisations of the observed behaviours {Specific Actions) and their associated objects (Specific Objects). Thus tasks are redescribed at a high level such that the particular implementation details of any particular task or computer system are no longer explicitly present in the high level descriptions of TAKD.”

Thus in TAKD there is an explicit mechanism for removing the task dependency that Benyon suggests is a fundamental weakness of all task analysis methods.

Notwithstanding our dispute with Benyon concerning TAKD, our main point is that Benyon is simply wrong that all aspects of sequence (flow) in a task are determined by the task-associated technology. To make our point we direct readers to the original ideas underlying Minsky’s (1975) notion of frames and Schank and Abelson’s (1977) scripts. What, in recent years, has been lost in some of the AI literature is that frames and scripts were temporally sequenced descriptions. Minsky was claiming that there are temporal contingencies in tasks and we would argue that these are central to the task and independent of

any associated technology. We will, however, concede that there is a level of task description which may be technology-driven, but this has at least been recognised by TAKD, if not other task analysis methods, previously.

A classic example used to illustrate Minsky’s frames involves a visit to a restaurant to partake of a meal (Barr and Feigenbaum, 1981). In this case, we have a number of expectations about the objects in a typical restaurant and the sequence of events that are likely to take place. We claim that the following are temporally (i.e. causally) contingent and their order cannot be reversed.

1. The person must know what can be ordered from the restaurant 2. The order can then be placed.

132 Interacting with Computers vol4 no 1 (19921

When we look at customers’ restaurant-associated activities (i.e. if we did some

serious task analysis) we would not, however, find a simple sequence such as:

1. enter restaurant area 2. read menu 3. place order 4. wait 5. eat food 6. pay for meal 7. leave restaurant

Such a sequence, incidentally typical of an AI characterisation divorced from the real world, ignores the fact that many restaurants have menus displayed outside so that steps 1 and 2 may be reversed. Similarly, a telephone order may have been placed before entering the restaurant. Furthermore, for some restaurant types people know what they will order without recourse to a menu.

In this analogy we might consider restaurants, menus, etc., to be devices, or

objects associated with devices.

In summary, we are claiming that some aspects of sequence and thus task flow are properties of the world and quite independent of any particular device. These properties are thus, as far as possible, device-independent and we take it

as self evident that they must be modelled in the system development process. We also believe that at least some task analysis methods are capable of fulfilling this need.

Benyon also attempts to base part of his argument that task analysis is always device-dependent, whereas a data-centred approach is not, on a contrast he makes between objects in task analysis and entities in systems analysis. He claims that:

l Objects are features of the current environment which is dependent on the existing device. In contrast to the concept of an object, the concept of an entity is solid . . ,

l Entities . . . are collections of instances of entities and each instance must be distinguishable from other instances. Importantly, dealing with entities, as opposed to objects relieves us from having to specify hierarchical rela- tionships too early.

Downs et al. (1988) say of entities in the context of SSADM and this, we assume, is the sort of data-centred approach from which Benyon takes his entity definition and properties:

“Unfortunately there is no simple or precise definition of an entity other than an aspect of interest for the application. Entities are determined either from the knowledge of the application or from the dataflow diagrams produced in the systems investigation or from both.”

This quote would seem to contradict Benyon’s claims about the solidity of the entity concept. It seems reasonable to suggest that a specific object, for example, in TAKD can be an example of an instance and that TAKD’s generic objects are

Dinper and Addison 133

collections of these. The TDH construction process is really only a method of systematically classifying such instances into cohections. Apparently, the difference between objects and entities in this context is merely that objects arise from a task analysis of real, current, tasks and are derived in a systematic manner whereas entities have no such necessary history. In summary, we dispute that task analysis, even when starting with device-dependent task descriptions, is incapable of producing output which is, at least partially, device-independent.

Considering the notion of device independence used by Benyon, we have to confess our failure to fully understand it. It seems to us that the claimed device independence of DFDs, for example, is only partial and with respect to only some classes of device, not all devices (and their associated task contexts). Furthe~ore, we suspect that, in general, the size of the set of devices of which a DFD is independent is inversely related to the level of expansion applied to the DFD. Our own analyses, based on the example above involving a conferencing system (Figure l), suggest that we would decompose this level 0, context DFD differently, in terms of both the data dictionaries and the DFDs themselves, if we knew in advance whether we were to develop a telephone conferencing system or a multimedia CSCW one. Otherwise, we feel we miss important differences in data flow. For example, in the multimedia case a video channel may require different flow to a telephone channel because everyone can hear everyone else, but not necessarily see everyone else. Our point is that DFDs must either be able to capture important differences between possible devices and thus at some level possess some device dependency, or they remain truly device-independent and ignore critical differences that can be exploited in design.

One weakness we perceive in Benyon’s systems analysis model of software development is that design is only mentioned at the fourth stage in ‘physical design’. This is contrary to our experience with real commerical designers who consider design options throughout the software development process. Indeed, it is a major challenge to stop design-led development, because design cannot realistically be held off until stage 4. Furthermore, this is the major rationale for the perceived desirability of device independence.

In addition, because Benyon’s stage 3 involves human and machine task allocation, it must be the case that this is necessarily a device-dependent process. Clearly, tasks can only be allocated to system components, whether human or machine, if they have the capability to perform them. In many real world tasks there are task components that can only be performed by people, and the converse is also sometimes true. If Benyon’s stage 2 were really capable of device-independent representation, then it could make little or no conribu- tion to his stage 3 in cases where allocations are made, as they are frequently, primarily on device-dependent properties, including, most importantly, cost. Thus, the main source of data for stage 3 would have to be provided either by the stage 1 analyses or by new analyses. Furthermore, after the initial expense of undertaking a task analysis, subsequent use of the same analysis method is usually easy, fast and cheap because later task performance data can be simply integrated into the existing analysis’ representational structure. We see this as

134 Interacting zuith Computers ~014 no 1 (1992)

yet another argument for the importance of undertaking stage 1 in a sophisticated and thorough manner with powerful methods and appropriate representational forms so that the results can be used throughout the software life-cycle. Task analysis, we believe, provides one of these available methods, and we are unaware of any other methods that are potentially as comprehensive or rigorous.

Benyon appears to assume, partly because of his emphasis on device independence, that design is about novelty. We think it extremely rare, however, for real software engineering projects to involve the design of novel tasks that have no current existence. Even in the more extreme examples when there are to be radical changes in the associated technologies, for example, when wishing to computerise a manual system, we believe that task analysis is an appropriate approach for providing a minimum requirements specification that the new system should meet (Diaper, 1987). We agree that many of the behaviours of the old system’s users will be determined by its technology, but we have already argued that there are invariant, causally related, classes of events which are fairly technology independent and that these general aspects of the world can be modelled by methods such as TAKD. We are therefore less concerned than Benyon with a little ‘design fixation’.

To relegate design only to physical design, as mentioned earlier, seems to us to be unacceptably extreme. We think it is more realistic to recognise that in real software development it is not possible to have complete device independence and that there is a psychological bias for many involved in the process to consider design options. We would suggest that what needs to be developed is a software engineering development process that exploits these facts in a positive manner; perhaps by linking the two so that design alternatives are explicitly recognised as such and knowingly embedded in the various representational structures used at the different stages. Such a development process may lack some of the desirable features and formal properties that might be available to a purer, device-independent, data-centred approach, but it would be realistic for real projects and real developers.

Benyon expresses concern over the expense, in time and effort, of performing task analyses. Diaper (1989a) has already identified the cost problem associated with an initial task analysis, in particular, and proposed the need for dedicated software tools to support task analysis methods. Software tools that support design and software engineering offer several major advantages over methods that exist only as paper documentation:

l reduction in the skill necessary to apply an HCI method; l improved correctness of a method’s application; l faster, less effortful application of a method; 0 improvement of the method’s specification; l increased use of the method.

A task analysis toolkit which supports TAKD (LUTAKD) has been developed as part of the TOM Project at Liverpool University. LUTAKD embodies many of the advantages stated above and significantly reduces the possible data errors and the time taken to perform a TAKD analysis*.


Prototype versions of the LUTAKD toolkit have been used by commercial designers at BAe Woodford in the TOM project and the overall response has been very positive with regard to the sense, usability and cost of using TAKD supported by LUTAKD. We are confident that a toolkit such as LUTAKD brings a sophisticated task analysis technique such as TAKD well within the normal budgets that are currently spent on sound requirements capture methods in current software engineering projects. Indeed, we would claim that LUTAKD gives designers more ‘bangs per buck’ than any other currently available method of which we are aware.

Finally, we address the role Benyon perceives for I-ICI and task analysis in his systems analysis software development model. As he claims that HCI and task analysis methods cannot be used in the earliest stages of system development, he proposes that HCI is concerned with user requirements and that these are composed of:

l functional requirements, l data requirements, 0 usability requirements.

Our analysis of the literature suggests that while there is a view of functionality (e.g. Baecker and Buxton, 1987; Hammer, 1984) which Benyon refers to as the ‘software engineering view’, and which is almost certaimy also an HCI view, that user requirements are functional requirements. However, there remains today a computer-centric view of functionality (e.g. Davis, 1990; Collin, 1989; Blethyn and Parker, 1990; Pfleeger, 1991). For example, Collin provides the following dictionary definition:

‘*Fu~cfjonaf s~ec~~caf~~?~: a specification which defines the results which a program is expected to produce.*’

We would suggest that the concept of functionality needs division to accommodate both views. First, there are ‘human functional requirements’ which concern the achievement of people’s task-related goals and need to be expressed in a manner that is as independent as it is possible, or that it is desirable to be, both of the existing task associated technology and the proposed new computer technology. We have argued that task analysis methods that allow the gener- alisation of task elements and sequences, and which are capable of representing users’ goals, ec., are a suitable type of method to employ for the analysis of these human functional requirements. Second, there are ‘computer functional requirements’ and ‘data requirements’ which should be produced as Benyon advocates. Finally, there are ‘usability requirements’. While we might concede that many aspects of usability may have to be specified in a device-dependent manner, particularly those associated with user interface issues, we suggest that the human functional requirements are pre-eminent and are not so restricted.

‘LUTAKD has been developed as a research tool and is available to researchers, in some circumstances. Researchers interested in obtaining the LLVAKD toolkit, which runs under UNIX and the Xllr4 window system, should contact the authors.

136 interacting with Computers ~014 no 1 (19%)

This commentary has already suggested that systems analysis has had a poor track record at capturing context requirements, as Benyon calls them. Benyon does not appear to offer any great improvement in how systems analysis proposes to carry out and use its techniques for his stage 1. Such system analysis techniques appear to be more primitive versions of available HCI, and task analysis, methods. We believe that if taken seriously, Benyon is advocating a justification for undertaking his stage 1 in a cavalier fashion. We believe that this will lead to yet more unsuccessful, unpopular and unusable systems, of which the world already has too much experience.

In summary, we do not think Benyon’s systems analysis model is adequate as a model for system development because it is unrealistic about where and how design occurs in the process and on what design should be based. In our view there is a need to separate a first stage of requirements analysis (similar to Benyon’s stage 1) from a more computercentric second stage. Both these stages being capable of providing at least partially device-independent descriptions and where the actual degree of device independence will vary according to the overall goals of each project that follows such a methodological approach. We suggest that task analysis methods have the potential to be a major stage 1 tool that can provide appropriate inputs to many subsequent stages, including something like Benyon’s stage 2, data-centred analysis. Given that the same task analysis method is used throughout the design process then the expense of undertaking a task analysis is well within the sorts of budgets that are currently spent on requirements capture methods in software engineering projects, even if a method is not supported by adequate software tools.

As a postscript, we wish to ‘cast the first stone’ at task analysis methods. In general they are: underspecified, difficult to use, not well integrated in software engineering methods, and are not supported by software tools. Even TAKD, after a decade, is still under development and we recognise that within this commentary we have at times referred to task analysis’ potential, rather than its current reality.

Glossary of terms and acronyms

ATC: Air Traffic Control ATCO: Air Traffic Control Officer ATE Automatic Test Equipment BAe: British Aerospace BNF: Backus-Naur Form cscw: Computer Supported Cooperative Work DFD: Data Flow Diagrams DTI: Department of Trade and Industry ELH: Entity Life History ERM: Entity-Relationship Model FaSTA: Fast and Structured Task Analysis GOMS: Goals, Operators, Methods, and Selection rules HCI: Human-Computer Interaction HTA: Hierarchical Task Analysis


IEEE:

JSD: JSP: KRG:

LUTAKD:

SERC: SSADM: TAG: TAKD: TDH: TOM:

Institute of Electrical and Electronics Engineers Jackson System Development Jackson Structured Programming Knowledge Representation Grammar Liverpool University Task Analysis for Knowledge Descriptions toolkit Science and Engineering Research Council Structured Systems Analysis and Design Method Task-Action Grammar Task Analysis for Knowledge Descriptions Task Descriptive Hierarchy Task Oriented Modelling

References

Anderson, R.I., Carroll, J.M., Grudin, J., McGrew, J.F. and Scapin, D.L. (1990) ‘Task analysis: the oft missed step in the development of computer-human interfaces; its desirable nature, value and role’ in Diaper, D., Gilmore, D., Cockton, G. and Shackel, B. (eds) Human-Computer Interaction: Interact ‘90 Elsevier, 1051-1054

Ashworth, C. and Goodland, M. (1990) SSADM: A Practical Approach McGraw-Hill

Baecker, R.M. and Buxton, W.A.S. (1987) Readings in Human-Computer Interaction: A Multidisciplinary Approach Morgan Kaufmann

Barr, A. and Feigenbaum, E.A. (1981) The Hundbook of Artificial Intelligence, Volume 2 Pitman

Benyon, D. (1992) ‘The role of task analysis in systems design’ lnteructing with Computers, 4, 1, 102-123

Blethyn, S.G. and Parker, C.Y. (1990) Designing Information Systems Butterworth- Heinemann

Cameron, J.R. (1983) /SP 6 fSD: The Jackson Approach to Software Deuelopment IEEE Computer Society Press

Card, S., Moran, T. and Newell, A. (1983) The Psychology of Human-Computer Interaction Lawrence Erlbaum

Collin, S.M.H. (1989) The Humlyn Dictionary of Computing Hamlyn

Davis, A.M. (1990) Software Requirements: Analysis and Specification Prentice-Hall

Diaper, D. (1984) ‘An approach to IKBS development based on a review of ‘Conceptual structures: information-processing in mind and machine’ by J.F. Sowa’ Behuv. Inf. Technol., 3, 3, 249-255

Diaper, D. (1987) ‘Designing systems for people: beyond user centred design’ in Softwure Engineering: PYOC. Share European Association (SEAS) Anniversary Meeting, 283-302

Diaper, D. (1988) ‘Task analysis for knowledge descriptions: building a task descriptive hierarchy‘ in Megaw, E.D. (ed) Contemporary Ergonomics 1988: Proc. Ergonomics Society’s Annual Conference Taylor and Francis

Diaper, D. (1989a) ‘Task Analysis for Knowledge Descriptions (TAKD): the method and an example’ in Diaper, D. (ed) Tusk Analysis for Human-Computer Interaction Ellis Hot-wood, 108-159

Diaper, D. (1990) ‘Simulation: a stepping stone between requirements and design’ in Life, A., Narborough-Hall, C. and Hamilton, W. (eds) Simulation and the User Interface Taylor and Francis, 59-72

138 Interacting with Computers VOW 4 no 1 (1992)

Diaper, D. and Addison, M. (1991) ‘User modelling: the task oriented modelling (TOM) approach to the designer’s model’ in Diaper, D. and Hammond, N. teds) People and Compufers V1 Cambridge University Press, 387-202

Diaper, D. and Johnson, P. (1989) ‘Task Analysis for Knowledge Descriptions: theory

and application in training’ in Long, J. and Whitefield, A. (eds) Cognitive Ergonomics and Human-Computer Interaction Cambridge University Press, 191-224

Downs, E., Clare, P. and Coe, 1. (1988) Sfucfured Systems Analysis and Design Mefhod: Applicafior~ and Confect Prentice Hall

Gikas, S., Johnson, P. and Reeves, S. (1990) ‘Formal framework for task oriented modelling of devices’ Queen Mary and Westfield College, Department of Computer

Science, Technical Report

Hammer, M. (1984) ‘The OA Mirage’ Datnmatio~~ (February issue) 36-46

Hares, J. (1990) SSADM for the Advanced Practitioner Wiley

Johnson, P., Diaper, D. and Long, J. (1984) ‘Task, skills and knowledge: task analysis for knowledge based descriptions’ in Shackel, B. (ed) Hlcmart-Computer Interaction:

hferact ‘84 Elsevier, 23-27

Killip, L.T. (1991) ‘Fast and Structured Task Analysis (FaSTA)’ MSc Thesis, University of Liverpool

Long, J. (1986) ‘People and computers: designing for usability’ in Harrison, M. and Monk, A. teds) People and Computers: Designitrg for Usability Cambridge University Press, 3-23

Long, J. and Dowell, J. (1989) ‘Conceptions of the discipline of HCI: craft, applied science and engineering’ in Sutcliffe, A. and Macauiay, L. teds) People nnd Computers V Cambridge University Press, 9-34

Magee, B. (1973) Popper Fontana

Minsky, M. (1975) ‘A framework for representing knowledge’ in Winston, P.H. (ed) Tile PsychoIogy of Conlputer Vision McGraw Hill, 211-277

Payne, S.J. and Green, T.R.G. (1986) ‘Task-action grammars: a model of the mental

representation of task languages’ Human-Computer Interaction, 2, 93-133

Payne, S.J. and Green, T.R.G. (1989) ‘The structure of command languages: an

experiment on Task-Action Grammar’ Int. 1. Man-Machine Stud., 30, 213-234

Pfleeger, S.L. (1991) Soffwure Engineering: The Production of Quality Software 2nd edition, Macmillan

Popper, K.R. (1979) Objective Knowledge: An Evolutionary Approach revised edition, Oxford University Press

Schank, R.C. and Abelson, R.P. (1977) Scripts Plrzns Goals and Undersfnnding Lawrence Erlbaum Associates

Shepherd (1989) ‘Analysis and training in information technology tasks’ in Diaper, D. (ed) Tusk Analysis for Human-Computer Interaction Ellis Horwood, 15-55

Walsh, P. (1989) ‘Analysis for Task Object Modelling (ATOM): towards a method of integrating task analysis with Jackson System Development for user interface

software design’ in Diaper, D. (ed) Tusk AnuIysis for Human-Computer Interaction Ellis Hot-wood, 186-209


task analysis and systems analysis for software development

Documents