Issue
Article
Vol.29 No.1, January 1997
Article
Issue
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |
Illustrated within the context of SSADM, a demonstration is described that shows how the task analysis method TAKD can support requirements analysis by improving entity modeling. Entity Life History Matrices are generated directly from TAKD, thus demonstrating one form of method integration. TAKD is shown to be able to support Entity Life History modeling, at a minimum, as a QA process to test the validity of Entity Life Histories.
Keywords: Requirements Analysis, SSADM, Task Analysis, TAKD.
This paper is presented in two main sections. First, an introduction to the research and some background to the methods under study. Second, a demonstration of how task analysis can support requirements analysis via entity modeling.
The work reported in this paper is part of a larger, long term research programme that has the goal of integrating Human-Computer Interaction (HCI) methods with those extant in Software Engineering (SE). This approach is advocated, for example, by Lim and Long (1994). One major strand of this research programme concerns task analysis as an HCI method type and the method Task Analysis for Knowledge Descriptions (TAKD) as one particular example of such HCI methods. The SE approach chosen for this paper's purposes was Structured System Analysis and Design Method (SSADM) and for reasons described below, SSADM's use of entity modeling. While SSADM is this paper's SE context, the results of the research could be equally well be applied to a Jackson Structured Programming (JSP) or Jackson System Design (JSD) approach. The latter might allow TAKD to be used as a task analysis method within the MUSE method for usability engineering (Lim and Long, 1994). The work is also intended to integrate with Object Oriented Design (OOD) methods.
One area of tension between HCI and SE is in the treatment these disciplines give to the real world, including people. Requirements capture is the collection of data about the world that is then subjected to the processes of requirements analysis and requirements specification. The latter is now widely recognised as the basis of system functionality and is therefore critical for successful design. Where SE seems particularly weak is in requirements capture, there appears to be an assumption, not made in HCI, that obtaining the data for requirements analysis is not a problem; such data includes, for example, what is done, by whom, when and for what purpose.
Of the possible SE design methods available, SSADM was chosen on the basis of its proponents claims to its widespread use (e.g. Downs et al., 1988; Ashworth and Goodland, 1990; Eva, 1994; Hares, 1990). Support for the argument that SE is weak at requirements capture, can be illustrated from within SSADM. Sampling SSADM text books, Eva (1994), Hares (1990) and Downs et al. (1988) make no mention of data collection and Ashworth and Goodland (1990) merely give a short list at the level of "interviewing", "circulating questionnaires", "observing the system in practice", etc. A similar criticism can be made of Cameron's (1983) JSP and JSD manual. Ashworth and Goodland say that "These are well-known techniques described in many textbooks (e.g. Daniels and Yates, 1988)". Their claim can be contested, first, because these techniques are not well described and, second, because they are poorly applied in practice. Improving the quality of the data that is used in SE should lead to an improvement in analysis and design if it is the case, as argued above, that the quality of such data is currently poor.
SSADM is large, with many parts and multiple representations that vary both qualitatively and quantitatively with respect to what they model. The approach of this paper's research has been to identify one target representational formalism within SSADM that task analysis can support, particularly by providing better requirements capture and early requirements analysis than is currently available in SSADM.
While SSADM continues to undergo development, Eva (1994) suggests that three features remain constant: (i) three views; (ii) avoid supplier lock-in; (iii) user involvement. The first of these was chosen because it involves the essential computer-centric aspects of SSADM and, of course, the second is inappropriate and the third is where SSADM currently claims to have one of its major HCI components. One way to view the overall goal of this paper's research work is that it is intended to improve the HCI within SSADM's system design strengths, which are its three views. The three views of SSADM are function, structure and sequence and each has a representational form associated with it: Data Flow Diagrams (DFDs), Logical Data Structures (LDSs) and Entity Life Histories (ELHs), respectively. The sequence view was chosen for this work for two reasons. First, ELHs provide a psychologically natural model of the world in that they model things (entities) and what happens to them (events) in contrast to DFDs which have no representation of time, sequence, or contingency. Second, by rejection, LDSs were considered too close to SSADM's database applications and DFDs, while a possible candidate, have been so widely used for so long within the software industry that it may be difficult to change people's usage of them. In addition, as with DFDs, ELHs are used by the software industry outside of SSADM.
Entity models are constructed from a description of entities and events. Eva (1994) defines entities as "Something about which the system needs to hold information" and events as "Something which happens in the world that causes a change in the value or status of a data item or entity in the system." Where SSADM is weak is in its advice on identifying these somethings. TAKD, along with virtually every other task analysis method, has a primary concern with identifying objects (entities) and actions (events).
Entity Life History Matrices. An ELHM consists of a table of events by entities with cells marked positively so that each event has the entities associated with it listed, and vice versa, of course, for entities. The positive cells of an ELHM can optionally contain additional information, rather than just a tick, most commonly the type of event (create, modify, delete, etc.).
Entity Life Histories. In SSADM, an ELH is generated for each entity in an ELHM. An ELH represents the life of each entity in a graphical format. There are three "basic constructs" (Down's et al., 1988) that provide the syntax to an ELH diagram, plus a range of additional, optional constructs. The three basic ones, and the only ones considered in this paper, are sequence, iteration and selection.
An ELH is drawn as a top-down hierarchy with sequence represented from left to right and by depth first traversal of the ELH. Iteration is represented by creating a new non-terminal ELH node and placing a * in it. Selection is indicated by placing a ° at an existing ELH node. The latter two basic constructs modify the actual traversal of the ELH. Iteration causes lower ELH nodes to be repeated and selection, which breaks the sequence syntax, allows mutually exclusive traversals to be represented in an ELH.
The generation of ELHs is a craft skill and legally correct alternatives are often possible for the same entity. ELH generation is usually done in a progressive, decompositional manner by analysts in SSADM.
While many task analysis methods can provide sophisticated analyses of the physical, psychological and information processing aspects of an application domain, these methods generally do not provide such descriptions in a format familiar, or sometimes even understandable, to computer system designers. A notable exception within task analysis is Payne and Green's (1986) Task Action Grammar (TAG) that generates Backus-Naur Form (BNF). The author (Diaper and Addison, 1992) has previously commented that TAG is unfortunately only suitable for application to low level user interface features. Furthermore, BNF is no longer a popular representation for system design work.
This paper will use the author's TAKD method as this paper is part of an on-going research programme dedicated to this method. It is plausible to choose TAKD because it has been used for requirements analysis with a range of system design applications (e.g. Johnson, 1985; Johnson et al., 1985, Diaper, 1989a, 1990a, Diaper and Addison, 1991).
The author (Diaper, 1989b, 1990b) has previously identified the theoretical problem concerning the change of perspectives from an anthropocentric requirements one to a computer-centric design one. Previous work has demonstrated that TAKD is capable of generating formal output, for example, as a temporal version of OBJ (Gikas, et al., 1990) and some progress has been made with Z schema output. This paper describes a continuation of this approach of modifying or extending TAKD to allow it to produce analysis outputs in formats familiar to computer system designers.
TAKD is itself a complex method and will not be described in detail in this paper. Since the author is one of the original developers of TAKD and has used it for more than a dozen years, readers can assume that the TAKD analyses themselves are carried out correctly. As an added safeguard on this in the absence of detailed, long descriptions of the analyses, all of them were carried out using the LUTAKD toolkit (see below) which enforces the stages and main conventions of TAKD. The main stages of TAKD and a few germane points for this research work are briefly described below.
Activity List Construction. An Activity List (AL), sometimes called a task protocol, is a prose description of a set of tasks. There are no constraints on the requirements capture method used to generate an AL, although TAKD has been designed to deal with video recordings of real people doing their usual tasks in their normal environment or setting. ALs based only on task-orientated interviews (Diaper, 1990a; Diaper and Addison, 1991) have been successfully used as input to TAKD and there is no reason why task scenarios (i.e. idealised task descriptions) cannot be the source of an AL. When using SSADM, and particularly during entity modelling, analysts tend to construct for themselves task representations that are really just ALs. They use such task representations when constructing and justifying their ELH structures. It is a weakness of SSADM that analysts are not forced to produce some AL like representation explicitly.
Specific Action and Specific Object Selection. Virtually all task analysis methods have some concept of actions and objects, although the definition of these varies from method to method. In TAKD the Specific Actions (SAs) and Specific Objects (SOs) are the lowest level of data that will be subjected to analysis, hence "Specific". SAs and SOs are selected directly from the AL and TAKD encourages iteration between editing the AL and selecting SAs and SOs. This iteration improves the consistency of the AL, and thus of the data subjected to a complete TAKD analysis, by correcting omissions and the level at which SAs and SOs are described (TAKD has a heuristic that, wherever possible, SAs and particularly SOs are described at an approximately similar level of detail). Examples of this are included in this paper's demonstration. In TAKD's notation SAs are represented by words from the AL in square brackets and SOs by words in round brackets.
Task Descriptive Hierarchy Construction. A TDH is a highly specialised heterarchy and in TAKD, by design, its construction is where task analysts concentrate the application of their craft skill at understanding the tasks they are analysing. The large number of TDH construction rules and heuristics are far beyond the scope of this paper. There are, however, two important points, relevant to this paper's work, about conventional TDHs in TAKD. First, a TDH represents each line of an AL by a single depth first traversal from a terminal leaf node, which must contain at least one SO, to the single top node. Second, that there is no representation of sequence in a TDH. The latter is important because the research described in this paper's demonstration analysis requires that this condition of TAKD is abandoned.
Knowledge and Sequence Representation. The output of TAKD consists of two main analyses. First, the AL can be rewritten in TAKD's standard notation so that the whole task can be viewed at any level of abstractness, generality or generification (TAKD's term). This output consists of sets of Knowledge Representation Grammar (KRG) sentences that describe the single traversal from terminal leaf node to top node described in the previous section. TAKD analyses task sequence from the KRG sentences representing these as Sequence Representation Grammar (SRG) lists of repeated sequences at all levels of generification. Parallel, interrupted or shared tasks are separated by constructing blocks of related AL lines. Adjusting such Activity List Blocks (ALBs) allows the TAKD analyst to produce different perspectives on the same task. ALBs are used in the demonstration to separate out agents such as the computer from the end user, non-computerised task aspects and from other people.
TAKD is supported by the Liverpool University TAKD (LUTAKD) toolkit, one of the few task-analysis software packages currently available. LUTAKD reduces the time it takes to do a manual TAKD analysis by at least 70%, it prevents many classes of analysis error, and by supporting iterative analysis, it overcomes the problem of the method being viscous (Green, 1990) i.e. that as an analysis progresses it becomes increasingly difficult for the analyst to make changes to previous parts of the analysis because of the cost of reanalysis. The generation of the KRG and SRG representations, but not an understanding of their meaning of course, is entirely automatic with the LUTAKD toolkit. Possession of the LUTAKD toolkit is essential for the larger research programme. The analyses included in the demonstration in this paper represent only a couple of the dozen's of TAKD analyses that have been undertaken.
The only purpose of this paper is to demonstrate that TAKD can support SSADM's entity modelling. The required brevity of this paper precludes the presentation of the numerous, detailed analyses that were the history to the work. LUTAKD allowed many different analyses to be carried out to quickly test the feasibility of analysis design options. While not presenting this work here, it consists of three main stages: (i) A demonstration that TAKD can produce SSADM entity models, (ii) The modification of TAKD to provide entity models of a familiar content and structure, (iii) The investigation of TAKD output translation mechanisms to automatically generate ELH constructs. This paper will only demonstrate the second of these. Furthermore, so as not to present pages of repetitive analysis to the reader, the demonstration will involve the analysis of only the computer system components of the task. The reason for this is that it is possible to independently generate typical entity models from the initial task description without using TAKD, as is done in systems analysis today. The target of the research is for TAKD to generate entity models as close as possible to those of current practice. Such a demonstration, however, does not illustrate the reason for using TAKD to generate entity models. TAKD can analyse with equal ease other component systems, for example, people and non-computerised task aspects, and TAKD analyses their interaction. Thus for computer system designers, the advantage of using TAKD to generate entity models is that it would provide them with the capability to analyse and then represent in a familiar way aspects of the world that are currently problematic. These issues are returned to at the end of this paper. The actual nature of the demonstration is shown in Figure 1. The two results of the demonstration are: (i) an improved ELHM and (ii) an improved AL. The latter improves the data on which an ELH is based. Whether SSADM designers would want to change their ELHs on this basis is not the concern of this paper (see the final section on Improving Entity Life Histories).
Figure 1: Stages in the Demonstration of TAKD's Ability to Support Entity
Modelling.
The demonstration application domain is a U.K. high street video hire shop. Such shops typically carry a stock of between 500 and 2,000 videos that may be hired on a daily basis, generally to a geographically restricted population. In the example chosen for demonstration purposes, the particular video shop used for analysis is characterised as having a mixed technology system. The shop has a small Personal Computer (PC) that stores records of customer contact details (name, address, telephone and their identification number) and keeps a record of each video borrowed. In parallel with the PC, the shop keeps a paper record in a log book of each transaction. All cash details are only recorded in the log book. The shop in the example is one of a small chain of such shops. The chain's owners wish to upgrade and unify their shop and central office PC's with the long term intention of providing a real time, interactive, distributed computing environment that will improve customer service and reduce stock replication by being able to identify where a particular video is in any of the chain's shops on a customer request. This target will be approached in several stages by the chain's management. The first stage is improvement of the in-shop, stand-alone application which has, in any case to be carried out, because of pressure from the company's accountants.
The task analysis carried out is part of the early, requirements analysis stage of this project's first stage. The whole, distributive computing project requires a careful analysis of the current system as there would be significant additional costs associated with implementing in-shop, stand-alone PCs if they then require extensive change for the intended distributed services. Such costs involve not only those directly related to software but also to human costs such as staff training. It is a management view that the latter should be minimal, which may be a harsh but realistic view of their business. In the demonstration, a single interaction involving a customer hiring a video is analysed. A full analysis would look at many such transactions. The AL that was created for the demonstration is a tidy example, it is minimal, contains no errors and has been described in neat prose following TAKD's heuristic that an AL should have no more than one action per line.
The current emphasis is on the automation of the logbook functions on the new PC. Looking at many tasks the TAKD analysis naturally concentrates on three major component systems: (i) The current PC system, (ii) The log book, (iii) The employee user. The other component systems identified involve either customer relations or dealing with physical objects not candidates for automation i.e. getting out a video from stock, placing it in a box, etc. Some analysis will be desirable of the employee-customer interaction as it should be a design goal that the new system does not interfere with customer relations. Apart from any sophisticated view about the importance of such social relationships in this market, it is imagined that management policy is to minimise staff levels while not having long queues in the shop (queues lead to loss of video hirings and hence loss of critical turn-over). The overall design approach is to use TAKD to generate ELHs for two systems: (i) The PC-user system, (ii) The log book-user system. The latter will then be redesigned so as to fit PC operations and this redesign will be fitted to the existing PC-user system. The assumption is that this last stage will produce a new PC-user system design that may be structurally different from that of the current system. This, of course, is not intended as a full or adequate description of the design process. It is assumed that if SSADM were being used then its other analysis stages would proceed as usual. Even in some other software development environment, there will be other methods and representations being employed. For the demonstration in this paper, only the PC part of the PC-user system will be subjected to analysis.
The initial Activity List (AL 1) is a prose description of the example target task. Following TAKD's convention, only one action is represented on each AL line. It has not been produced by direct observation, say by making a video record, but follows imagined interviews with end users and management and casual task observation. This initial AL in Figure 2 (AL 1) is claimed to be a fair example of the type of task description that might be produced in an SE context. AL 1 had already been subjected to an initial TAKD analysis that had corrected trivial omissions such as the descriptions being inconsistent (e.g. the device "vdu" was only sometimes specified). AL 1 therefore has a tidy appearance in a format suitable for a TAKD analysis, or for virtually all other HCI task analysis methods. Each line is numbered, this is done automatically by LUTAKD.
1
2 VIDEO SHOP WITH CURRENT COMPUTER -- TIDY DEMO EXAMPLE
3
4 CUSTOMER 1
5
6 customer places empty video box on counter
7 staff asks customer for customer number
8 customer tells staff customer number
9 computer displays main menu on vdu
10 staff reads menu option customer record from main menu
11 staff selects menu option customer record from main menu
12 computer prompts for customer number on vdu
13 staff remembers customer number
14 staff types customer number
15 computer displays customer record on vdu
16 staff selects menu option unreturned videos from customer record
17 computer displays unreturned videos data on vdu
18 staff checks customer record for unreturned videos data
19 staff selects menu option on unreturned videos data
20 computer displays customer record on vdu
21 staff orientates empty video box on counter
22 staff reads video number on box
23 staff gets video tape with video number from storage area
24 staff copies video number from video tape in loans book
25 staff types video number from memory
26 computer displays video title in customer record on vdu
27 staff reads video title on vdu
28 staff types Y for confirm
29 staff reads customer number from customer record
30 staff writes customer number in loans book
31 staff writes payment value in loans book
32 staff gets plain video box
33 staff places video tape in plain video box
34 staff requests payment from customer
35 customer pays correct amount
36 customer takes plain video box
37 staff selects close option on customer record
38 computer displays confirm message in customer record on vdu
39 staff types Y for confirm
40 computer displays main menu on vdu
41
42 CUSTOMER 2
43
44 customer places empty video box on counter
45 staff selects menu option customer record via mouse
46 staff asks customer for customer number
47 customer replies to staff does not know customer number
48 staff asks customer for customer surname
49 customer tells staff customer surname
50...
Figure 3: Initial Entity Life History Matrix (ELHM 1)
| Events | ||||
|---|---|---|---|---|
| Entities | Displays | Prompts | Selects | Types |
| Computer | 9, 15, 17, 20, 2, 6, 38, 40 | 12 | ||
| VDU | 9, 15, 17, 20, 2, 6, 38, 40 | 12 | ||
| Main menu | 9, 40 | 11 | ||
| Customer number | 12 | 14 | ||
| Customer record | 15, 20, 26, 38 | 16, 37 | ||
| Unreturned videos data | 17 | 19 | ||
| Video title | 26 | |||
| Confirm message | 38 | |||
| Staff | 11, 16, 19, 37 | 14, 25, 28, 39 | ||
| Menu option customer record | 11 | |||
| Menu option unreturned video | 16 | |||
| Menu option | 19 | |||
| Video number | 25 | |||
| Y for confirm | 28, 29 | |||
| Close option | 37 | |||
In the interests of brevity this analysis is not described as TAKD has a long history of analysing the type of data in AL 1. The output from this analysis was an enhanced AL that, for example, clearly separated agents such as the user from the computer. As described below, the importance of this TAKD analysis is that it allowed the generation of the initial ELHM.
The two initial entity models, the ELHM and the ELH describe only the current PC part of the example task in AL 1. The two models were produced in radically different ways because the demonstration represents an intermediate stage in the main research programme.
One product of the main research programme is the ability to generate ELHMs directly from TAKD's SA and SO selection stage. This first ELHM is shown in Figure 3 (ELHM 1). The numbers in the cells refer to the AL line numbers automatically generated by LUTAKD.
ELHM 1 was created directly from a TAKD analysis by simply representing TAKD's SAs and SOs as events and entities, respectively. Indeed, the ELHM is a re-representation of AL 1 following SA and SO selection but with a loss of grammar. Thus, for example, line 20 has the event "display" with the entities "computer", "customer record" and "vdu".
20 (computer) [displays] (customer record) on (vdu)
TAKD represents SAs in square brackets and SOs in round ones. While ELHM 1 is a perfectly plausible representation of the task analysed, there are a number of features that make it unsatisfactory. First, the top left quadrant of ELHM 1 represents the ELHM that would be generated if only those AL 1 lines that have the SO, or entity, "computer" in them were analysed. Obviously no one would consider just this quadrant to be a satisfactory ELHM. The problem is that AL 1 confounds the two entities "staff" with "computer" such that computer inputs are represented only by some staff behaviour. This is compensated for in ELHM 1 by including those AL lines that involve "staff" as a computer orientated end user. The events and entities in ELHM 1 have been ordered to reflect this division. This solution is not entirely satisfactory as the entity "memory" in line 25 is obviously not relevant to the computer-centric perspective of the demonstration and has not been included.
To summarise the two important points, first, ELHM 1 demonstrates the ease with which reasonable ELHMs can be directly generated by TAKD. Second, ELHM 1 provides a baseline that can be used for comparison with ELHMs produced from the subsequent analyses in the demonstration. It is important to note that the latter point is dependent on the acceptance that ELHM 1 is a reasonable ELHM similar to what could be expected to be produced in SSADM. In fact, the claim is that ELHM 1 is, if anything, rather better than what might first be produced in SSADM as TAKD assures that all SOs and SAs are identified.
Researching the possibility of automatic ELH production, a target ELH was generated directly from AL 1 (i.e. without using TAKD). The ELH was produced by the author's colleague, Dr. Trevor Bench-Capon, who has considerable expertise at JSP and JSD entity modelling. It took him, with the author's aid, about 20 minutes to produce on a white-board the ELH shown in Figure 4 (ELH 1).
Figure 4: The Initial Entity Life History (ELH1)
The claim is that this diagram represents a fairly typical example of the sort of diagram that might be produced in either SSADM, or JSP/D. Indeed, the diagram is close enough to a JSP diagram that we were able to check the I/O relationships, something that for the analyst gives JSP considerable leverage over JSD. Furthermore, the small size of the example makes JSP probably the preferred approach. While not denying that there are real differences between ELHs and JSP and JSD structure diagrams, their notation is all sufficiently similar and the demonstration task sufficiently small that the differences are minor for this paper's purpose. For convenience, the diagram in Figure 4 will be referred to throughout the rest of this paper as an ELH.
In parallel with creating ELH 1, further TAKD analyses led to an expansion of AL 1 so that the SOs or entities "computer" and "staff" (as end user) were separated. This involved primarily adding new AL lines after an end user action so that the user's behaviour is mirrored by the computer's input specification. These new AL lines have the syntax:
(computer) [takes input from] (input device) (input) (optional context)
For example, line 14 of AL 1 (line 16 of the new AL) is expanded in the new AL thus:
16 staff types customer number
17 (computer) [accepts string] (keyboard input) (customer number)
TAKD supports two main sub-cycles of analysis, the first being the `edit AL - select SAs and SOs - construct TDH' cycle. TAKD assumes that ALs will be modified during analysis. This reflects perhaps the major benefit of using nearly any task analysis method, that is, that doing a task analysis really forces the analyst to understand the tasks. It is important to note that changing the AL is not cheating, in the sense of making up data, but rather the inclusion of data that has been previously omitted. Methods such as TAKD that allow such revision of the captured data are admitting that tasks are hard to describe and that it is rare that anyone manages to describe a task adequately at their first attempt. Again in the interests of brevity, this paper does not include a copy of this new AL. It was used as the input to the new style of TDH analysis described in the next sub-section. The final AL (AL 2+) is shown in Figure 6.
The TDH construction method in TAKD has been modified so that a TDH is drawn that is logically identical to the target ELH 1 (Figure 4). TDHs have previously been represented as being read from left (top) to right (bottom) and keeping with this convention, ELH 2 is rotated 90 degrees anticlockwise from the convention top to bottom representation of ELH's as used in Figure 4 (ELH 1). The consequence of this rotation is that sequence is represented in ELH 2 from the bottom of the figure to the top and depth first traversal therefore proceeds from the node "Start display" to the node "End display". It is merely a matter of layout that ELHs are usually drawn with their box nodes centred whereas TDH's are top justified (i.e. a parent node is always nearer the top of a TDH diagram than its children). Similarly, a + is used to represented iteration in ELH 2 because the more usual * is part of LUTAKD's restricted character set. The terminal leaf nodes are all marked "SO" so as to allow the attachment of SO data from the AL; the attached SOs and SAs have been toggled off in the TDH Editor. One goal of the main research programme is the modification of TAKD so that ELH like structures are automatically produced by the analysis. Figure 5 is the ASCII dump from the LUTAKD toolkit showing the assigned SAs and SOs. For the sake of brevity, only a single SO from each AL line has been assigned. TAKD has no enforced conventions about SA assignment above the level of the terminal leaf nodes which are reserved for SOs. The SAs have simply been assigned to the lowest possible parent node.
Hire video
|___ Main task
| |___ User input
| |___ End display
| | |[51 accepts keystroke]
| | |_______________________ SO
| | (51 Y for confirm)
| |
| |___ Continue task
| |___ Repeat input +
| |___ Display
| | |[49 displays]
| | |[37 continues display]
| | |[33 displays]
| | |[25 displays]
| | |[21 displays]
| | |[18 displays]
| | |[14 prompts]
| | |_____________ SO
| | (49 confirm message)
| | (37 customer record)
| | (33 video title)
| | (25 customer record)
| | (21 unreturned videos data)
| | (18 customer record)
| | (14 customer number)
| |
| |___ Enter
| |___ Delayed entry o
| | |___ Enter
| | | |[48 accepts keystroke]
| | | |[32 accepts string]
| | | |[13 accepts keystroke]
| | | |___ SO
| | | (48 close option)
| | | (32 video number)
| | | (13 menu option customer record)
| | |
| | |___ Display
| | |[46 continues display]
| | |[31 continues display]
| | |[12 continues display]
| | |___ SO
| | (46 customer record)
| | (31 customer record)
| | (12 main menu)
| | |___ SO
| | (46 customer record)
| | (31 customer record)
| | (12 main menu)
| |
| |___ Immediate entry o
| |[36 accepts keystroke]
| |[24 accepts keystroke]
| |[20 accepts keystroke]
| |[17 accepts string]
| |________ SO
| (36 Y for confirm)
| (24 close option)
| (20 unreturned videos option)
| (17 customer number)
|
|___ Start display
|[9 displays]
|_________________________________ SO
(9 main menu)
Figure 5 shows the results of a large number of iterations of the TAKD sub-cycle `edit AL - select SAs and SOs - construct TDH'. This TAKD analysis sub-cycle led to the identification of a number of further inadequacies in the AL. The main result of the analysis was the identification of missing AL lines that allow the basic ELH constructs of sequence, iteration and selection to be correctly supported. These new AL lines concern computer output and were missing because they refer to states where there is little or no change to the output. AL line 37 provides an example of this:
35 staff types Y for confirm
#+250
36 (computer) [accepts keystroke] (keyboard input) (Y for confirm)
37 (computer) [continues display] (customer record) on (vdu)
#-250
38 staff reads customer number from customer record
Line 37 was added to the AL because without it the repeated sequence "Enter" then "Display" is violated. This demonstration chose to change the AL, the alternative would be to change the ELH; this is discussed further in the section on Improving Entity Life Histories.
#%64
1
2 VIDEO SHOP WITH CURRENT COMPUTER -- TIDY DEMO EXAMPLE
3
4 CUSTOMER 1
5
6 customer places empty video box on counter
7 staff asks customer for customer number
8 customer tells staff customer number
#+10
9 (computer) [displays] (main menu) on (vdu)
#-10
10 staff reads menu option customer record from main menu
11 staff selects menu option customer record from main menu
#+200
12 (computer) [continues display] (main menu) on (vdu)
13 (computer) [accepts keystroke] (keyboard input) (menu option customer record) from (main menu)
14 (computer) [prompts] for (customer number) on (vdu)
#-200
15 staff remembers customer number
16 staff types customer number
#+210
17 (computer) [accepts string] (keyboard input) (customer number)
18 (computer) [displays] (customer record) on (vdu)
#-210
19 staff selects menu option unreturned videos from customer record
#+220
20 (computer) [accepts keystroke] (keyboard input) (unreturned videos option) from (customer record)
21 (computer) [displays] (unreturned videos data) on (vdu)
#-220
22 staff checks customer record for unreturned videos data
23 staff selects menu option on unreturned videos data
#+230
24 (computer) [accepts keystroke] (keyboard input) (unreturned videos data) (close option)
25 (computer) [displays] (customer record) on (vdu)
#-230
26 staff orientates empty video box on counter
27 staff reads video number on box
28 staff gets video tape with video number from storage area
29 staff copies video number from video tape in loans book
30 staff types video number from memory
#+240
31 (computer) [continues display] (customer record) on (vdu)
32 (computer) [accepts string] (keyboard input) (video number)
33 (computer) [displays] (video title) in (customer record) on (vdu)
#-240
34 staff reads video title on vdu
35 staff types Y for confirm
#+250
38 staff reads customer number from customer record
39 staff writes customer number in loans book
40 staff writes payment value in loans book
41 staff gets plain video box
42 staff places video tape in plain video box
43 staff requests payment from customer
44 customer pays correct amount
45 customer takes plain video box
#+260
46 (computer) [continues display] (customer record) on (vdu)
#-260
47 staff selects close option on customer record
#+260
48 (computer) [accepts keystroke] (keyboard input) (close option) on (customer record)
49 (computer) [displays] (confirm message) in (customer record) on (vdu)
#-260
50 staff types Y for confirm
#+11
51 (computer) [accepts keystroke] (keyboard input) (Y for confirm)
#-11
52 (computer) [displays] (main menu) on (vdu)
53
54 CUSTOMER 2
55
56 customer places empty video box on counter
57 staff selects menu option customer record via mouse
58 staff asks customer for customer number
59 customer replies to staff does not know customer number
60 staff asks customer for customer surname
61 customer tells staff customer surname
62 ...
One difficulty with demonstrations such as this is that, with hindsight, it is easy to convince oneself that one wouldn't miss such requirements capture data when doing a requirements analysis. There can be no absolute defence against such hindsight powered criticism, but the author's experience is that he missed them, and not just initially, but through many cycles of analysis prior to using the ELH 1 structure. Furthermore, even if this error is caused by the author's foolishness, that the analysis was able to identify these omissions can, at a minimum, thus allow this method to be used as a check for such requirement capture errors. Even as such the method should thus have some value for improving entity modeling.
Figure 7: The Final Entity Life History Matrix (ELHM2)
| Events | |||||
|---|---|---|---|---|---|
| Entities | Displays | Continues Display | Prompts | Accepts Keystroke | Accepts String |
| Computer | 9, 18, 21, 25, 33, 49 | 12, 31, 37, 46 | 14 | 13, 20, 24, 36, 48, 51 | 17, 32 |
| VDU | 9, 18, 21, 25, 33, 49 | 12, 31, 37, 46 | 14 | ||
| Keyboard Input | 13, 20, 24, 36, 48, 51 | 17, 32 | |||
| Main menu | 9 | 12 | |||
| Menu option customer record | 13 | ||||
| Customer number | 14 | 17 | |||
| Customer record | 18, 25, 33, 49 | 31, 37, 46 | 48, 20 | ||
| Unreturned videos option | 20 | ||||
| Unreturned videos data | 21 | 24 | |||
| Close option | 24, 48 | ||||
| Video number | 32 | ||||
| Video title | 33 | ||||
| Y for confirm | 36, 51 | ||||
| Confirm message | 49 | ||||
ALBs are marked in the LUTAKD toolkit in the AL Editor by inserting lines that open and close a block with the convention #+integer and #-integer, respectively; ALBs can be opened and closed as many times as required. After a number of experiments, the ALB convention shown in Figure 6 (AL 2+) opens and closes blocks so that the ELH 2 structure at each level is adhered to. While beyond the scope of this paper because of their complexity, this convention allows LUTAKD's KRG and SRG tools to clearly show the task structure at each level of ELH 2, but only after post-processing the tools' outputs.
A new ELHM was generated from the SA and SO selection stage. Figure 7 shows this (ELHM 2) and the consequences of a TAKD analysis can be examined by comparison with Figure 3 (ELHM 1).
The claim is that ELHM 2 is a better ELMH. The two are, of course, very similar, which must be expected since they are based on similar data: with minor changes the entities are the same and there is a correspondence between the events. To illustrate this the entity "customer record" for ELHM 1 and 2 can be compared.
Figure 8: Initial and Final Entity Life History Matrix Lines for "Customer Record"
| ELH Matrix 1 | Events | ||||
|---|---|---|---|---|---|
| Entities | Displays | Prompts | Selects | Types | |
| Customer Record | 15, 20, 26, 38 | 16, 37 | |||
| ELH Matrix 2 | Events | ||||
|---|---|---|---|---|---|
| Entities | Displays | Continues Display | Prompts | Accepts Keystroke | Accepts String |
| Customer Record | 18, 25, 3, 3, 49 | 31, 37, 4, 6 | 20, 48 | 17, 32 | |
ELHM 2 is first better because of its perspective on the data. ELHM 1 could only be produced by using some of the data assigned from "staff". The event "selects" in ELHM 1 corresponds to "accepts keystroke" in ELHM 2 and while they can be interpreted identically in both ELHMs the confounding of some human behaviours with computer ones makes it difficult for the analyst to hold the appropriate, computer-centric perspective. This was previously illustrated during the construction of ELHM 1 where line 25 had the computer irrelevant SO "memory", referring to the end user's memory. In contrast, line 31 in ELHM 2 uses the "continues display" event to more correctly indicate the computer system state and removes the confusion between user and computer. Furthermore, and more importantly, ELHM 1 fails to indicate the involvement of the "customer record" at this point in the task. Thus the second reason why ELHM 2 is better is that it will allow the production of better ELHs because it represents the entities' history more accurately.
Apart from the claimed improvements in the ELMH following the TAKD analyses, the other claim of this demonstration is that it improves ELH modeling, not by changing an ELH, but by improving the data on which an ELH is based i.e. the AL. In addition, the capability to check the completeness of the entity and event lists using TAKD makes it a candidate as a Quality Assurance (QA) procedure. While it might be tempting to conclude this paper with some description of how using TAKD might modify an ELH, this is deliberately beyond the intentions and scope of this paper. Indeed, a claimed virtue of the work demonstrated in this paper is that TAKD is used as an additional method that supports system analysts' current approach to entity modeling. As such, the work may have greater appeal to professional system analysts than proposals that involve changing, rather than adding to, their current work practices. One reason for this is that adding TAKD in the form described in this paper does not require any unlearning about ELH modeling.
The proposal is that during SSADM, or other, similar SE method, activity lists of task scenarios, at least, are generated and subjected to TAKD's SA and SO selection stage. This analysis is then used to generate an ELHM. ELHs are then constructed in the usual, current fashion and SAs (events) and SOs (entities) are attached. Cycling through these stages of TAKD and entity modeling improves the quality of the activity list and the ELHM and assures the validity of the ELH and its basic constructs with respect to the model of the world represented by the activity list. This paper demonstrates that TAKD can be used to support entity modeling and illustrates how it can be done. The size of the demonstration makes the gains modest; even within the example, this paper probably does not really show the full set of advantages accruing from using the method as many of the errors detected are too embarrassing for the author to admit to. Carroll's work with designers (e.g. Carroll, 1991) suggests that design history is frequently forgotten and many of the discoveries about the task made by the author during analysis suffered from being obvious with hindsight. The research reported in this paper does provide an explicit integration of TAKD's SA and SO selection and ELHM production. By not changing how ELHs are constructed, TAKD is used to validate them i.e. the methods are not integrated. One reason for not attempting full integration in this paper is that there are a wide range of solution options available. These involve the possibility of changing TAKD, ELH construction, both or providing translation mechanisms between them. Current research is focusing on major changes to TAKD's TDH construction rules and heuristics and to the representational format of TDHs. These changes would allow a TAKD analysis to output an ELH directly, rather than in the current demonstration where an ELH was copied into TAKD as a modified TDH. Current research suggests two problems with this goal. First, there are logical problems between the sequence and selection constructs that cause rule induction from TAKD's KRG and SRG outputs to fail. The consequence of this is that rules will have to be hand-crafted. Second, some of the representations TAKD can output that look similar to ELHs are better representations, in the author's opinion, than manually produce ones, but they are not ELHs.
Ashworth, C. and Goodland, M. (1990) SSADM: A Practical Approach. McGraw-Hill.
Cameron, J.R. (1983) JSP and JSD: The Jackson Approach to Software Development. IEEE Computer Society Press.
Carroll, J.M. (1991) History and Hysteresis in Theories and Frameworks for HCI. in Diaper, D. and Hammond, N. (Eds.), People and Computers VI. 47-56. Cambridge University Press.
Daniels, A. and Yates, D. (1988) Basic Systems Analysis. 3rd. edition. Pitman. Diaper, D. (1989a) Task Analysis for Knowledge Descriptions (TAKD): The Method and an Example. in Task Analysis for Human-Computer Interaction. (Ed. Diaper, D.), 108-159. Ellis Horwood.
Diaper, D. (1989b) Bridging the Gulf between Requirements and Design. in Proceedings of the Ergonomics Society Conference on Simulation in the Development of User Interfaces. 129-145.
Diaper, D. (1990a) Analysing Focused Interview Data with Task Analysis for Knowledge Descriptions (TAKD). in Human-Computer Interaction: Interact'90. (Eds.) Diaper, D., Gilmore, D., Cockton, G. and Shackel, B., 277-282. North-Holland.
Diaper, D. (1990b) Simulation: A Stepping Stone between Requirements and Design. in Simulation and the User Interface. (Eds.) Life, A., Narborough-Hall, C. and Hamilton, W., 59-72. Taylor and Francis.
Diaper, D. and Addison, M. (1991) User Modelling: The Task Oriented Modelling (TOM) Approach to the Designer's Model. in People and Computers VI (Eds.) Diaper, D. and Hammond, N., pp. 387-402, Cambridge University Press.
Diaper, D. and Addison, M. (1992) Task Analysis and Systems Analysis for Software Engineering. Interacting with Computers, 4, 1, 124-139.
Downs, E., Clare, P. and Coe, I. (1988) Structured Systems Analysis and Design Design Method: Application and Context. Prentice Hall.
Eva, M. (1994) SSADM Version 4: A User's Guide. Second Edition. McGraw-Hill.
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.
Green, T.R.G. (1990) The Cognitive Dimension of Viscosity: A Sticky Problem for HCI. in Human-Computer Interaction: Interact'90. (Eds). Diaper, D., Gilmore, D., Cockton, G. and Shackel, B., 79-86. North-Holland.
Hares, J. (1990) SSADM for the Advanced Practitioner. Wiley.
Johnson. P. (1985) Towards a Task Model of Messaging: An Example of the Application of TAKD to User Interface Design. in People and Computers: Designing the Interface. (eds.) Johnson, P. and Cook, S., 46-62. Cambridge University Press.
Johnson, P., Diaper, D and Long, J. (1985) Task Analysis in Interactive Systems Design and Evaluation. in Analysis, Design and Evaluation of Man-Machine Systems. (Eds. Johannsen, G., Mancini, G. and Martensson, L.), 123-127. Pergamon Press: Oxford.
Payne, S. and Green, T. (1986) Task-Action Grammars: A Model of the Mental Representation of Tasks. Human-Computer Interaction, 2, 93-133.
Lim, K.Y. and Long, J. (1994) The MUSE Method for Usability Engineering. Cambridge University Press.
Prof. Dan Diaper,
Department of Computing,
School of Design, Engineering and Computing,
Bournemouth University,
Poole House, Talbot Campus,
Fern Barrow, Poole,
Dorset BH12 5BB, U.K.
ddiaper@bournemouth.ac.uk
+44 (0)1202 595571
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |