Including the User's View in Systems Design

© 1L\C \(all - \lathillt, \'are,,. , Itah, )'!H',

C()p\'l-i~ht

SI S lt'll1S ,

.

INCLUDING THE USER'S VIEW IN SYSTEMS DESIGN M.

J.

Wells

I\ pit/i LOlldOIl Associate,l. -/IJ Stolle/iilis. H'l'h"YII Gardell City. I-/l'I'tjim/,/iill'. L'K

Abstract The use of structured analysis techniques and notation to analyse and subsequently design information systems has provided a powerful cOlTlTlunication tool for use between analysts and end-users. However data flow diagrams provide a model of the system in the data and function domains with little indication of the dynamic aspects of the system as would be represented in a time domain model. This paper develops an approach (~lls, 1984a, 1984b, 1984c) to modelling the usercontrolled dynamic aspects of the proposed system, which can be integrated with the structured analysis notation. This modelling approach has been used to describe manmachine dialogues which can subsequently be entered into a microcomputer based Dialogue Prototyper designed by the author. To summarise, the paper describes a design methodology for the man-machine interface as~cts of a system, which can be integrated with structured systems analysis and deslgn methods. A rractical application of the representation method is ?emonstrated via a computer based Dialogue Prototyper. The paper concludes with an lllustratlOn of the methodology arplied to the design of part of an interactive stock recording system. Keywords

Man-machine systems; systems analysis; modelling; human factors.

INTROoocrICl'J

The use of structured analysis techniques and notation (Gane and Sarson, 1979; DeMarco, 1979) to analyse and subsequently design information systems has provided a powerful communication tool for use between analysts and end-users. The data flow diagrams enable end-users to readily appreciate the functions and input, output and file requirements for the proposed system. Such data flow diagrams provide a description of the system in the 'data and function domains' with no indication of sequence or timing. Such representations are adequate for batch systems, since they eventually provide a static model of the system. However systems are increasingly being designed with at least sane interactive sub-systems. The interaction is typically with end-users who are able to control the sequence of operations. Thus a purely static data flow representation of the system is inadequate. Users should be given the opportunity to assess the dynamic aspects of the system, i.e. its performance in the 'time domain' in terms of the man-machine dialogue. A range of notations for representing man-machine dialogues have been investigated (l-aterman, 1978; Hopgood and Duce, 1980; Feycock, 1977; Edmonds, 1982; Guest, 1982; Alty, 1983) wi th a view to selecting the one most appropriate for incorporation into dialogue simulation and prototyping tools intended for use by human factors research workers.

A state transition notation was adopted. A state is defined as being an output to the user, and transition from a state is caused by an input from the user. At each state different inputs from the user may cause transitions to different states. Thus the notation requires full specification of outputs and inputs from the user. An example of the notation is shown in Fig. 1. DIAL(X;UE 'I(X)I.S

A Dialogue Simulator (OS) was first designed to enable human factors researchers to readily create and execute dialogues that were being considered for inclusion within intelligent products to be developed by a telecOlTlTlunications company. A critical requirement of the DS was to be able to monitor the simulation of a dialogue so that experiments could be conducted with suitable subjects. The monitoring capability of 00 provided objective evaluations of the interaction, in terms of times taken, errors made and routes followed. Before enter ing a dialogue to OS, a diagram similar to that shown in Fig. 1 has to be completed, describing the planned dialogue. One of the very severe limi tat ions to the OS was its inability to allow inputs from the user to affect the displayed outputs. For example, the simulation of a dialogue showing the entry of two numbers and displaying their sum had to be entered according to Fig. 2. It was not possible to relate the output value of X to the two input values.

244

With such a limitation simulations were often unrealistic and subjects had to be warned that they may often see 'sample' results on the screen rather than the actual result based on the data they had input. Thus the notation employed adequately described the behaviour of the system in the time domain, from the user's point of view but the lack of any function descriptions was a clear limitation. To incorporate such functional descriptions, the notation was modified to incorporate a'process' or 'function' domain symbol, as shown in Fig. 3. The revised notation provides the basis for input to a microcomputer based Dialogue Prototyper which enables dialogues with background processing capability to be entered, executed and evaluated at an early stage in the analysis phase of a development project. In parallel with the development of the Dialogue Simulator and Dialogue Prototyper the author has investigated graphical structured systems analysis notation (Gane and Sarson, 1979; DeMarco, 1979) and structured software design notation (Stevens, 1981) with a view to incorporating the dialogue representation notation into a systems development cycle based on these structured methods and techniques. This section outlines the problems associated with an integrated develq:.ment process and the approach taken to integrate the state transition notation with other interactive systems development methods. Information systems are characterised by the data they use, the processes they perform and the order in which processes are carried out. Thus an information system has three dimensions: - function, data and time. This three dimensional nature of systems is one of the fundamental problems associated with systems development since at the analysis stage data and/or functions are specified but the final q:>erational system is very deeply seated in the time domain where program instructions are executed sequentially. Currently no tools are available for the modelling of the three dimensional nature of a system, and indeed if they were available they would probably be too complex to employ. Thus different modelling techniques are used to represent different aspects of the time, data and functional aspects of a particular system. Using the structured systems analysis approach of Tom DeMarco (1979) the logical requirements for a new system are specified in terms of Data Flow Diagrams (DFDs). These DFDs show the processes to be performed, the data flowing between the processes ard the essential data to be stored in the system. For a logical description of a system it is only necessary to specify what is to be done and not how it is to be done.---rhus the processes on a lOgical DFD are either essential business functions or any custodial activities which maintain the essential data. The essential data required to support the processes is devised using the normalisation process of data analysis devised by Ted Codd (1970) . Data both stored and flowing within such a system are defined in a data dictionary using the notation of DeMarco. Such diagrams model the system in the funtion and data domains, with precedence of functions sometimes providing a little insight into constraints within the time domain.

M.

J.

\','e lls Once a logical model of a system has been devised it is necessary to develop the physical aspects of the system which show how the system is to be constructed. This involves considering how input and outputs are to be made and presented; how the files should physically be organised to support processing requirements and what security and controls are to be built into the system. DFDs are again an appropriate method of representing the physical system in its function and data domains. The author proposes that when devising the physical system, the processes required to support inputs and outputs from and to the user, should be considered to be part of an interface system and not part of the logical system. Thus an interface is constructed between the man and machine to enable communication between the user and the logical functions within the system. This interface is represented using DFDs to show the functions and data flows across the interface between the user and the 'logical' system. This model, as with the logical model shows the system in function and data domains with some precedence implied by the data flows. The model does not demonstrate the dynamic aspects of the system, ie. how it will behave when used. These aspects are however, fundamental to the user acceptance of an interactive systems and therefore a time domain model is required to show this behaviour. The author proposes the use of state transition diagram notation as used in the dialogue tools described earlier, to show the dynamic aspects of the interface for a system. Once such a diagram has been constructed, its consistency with the data and function domain model has to be checked. ~hen

consistency has been obtained, the final input and output mechanisms are defined e.g. screen layouts, function keys. These definitions, combined with the time domain state transition model and the data and function domain DFDs, are suitable for input to the Dialogue Prototyper for early user evaluation purposes. This information can also form the basis of the program specifications for the proposed system, and it is possible to produce a structured design chart (Stevens, 1981) defining the program modules required to build the system. AN APPLICATICt-l OF THE METHODOLOGY A sub-system of an elementary stock recording/ ledger system is taken to illustrate the methodology. Figure. 4 shows a logical data flow diagram for the stock ledger system. The diagram shows the essential business functions of '1. Record Issue', '2. Record Receipt' and '3. Produce Requitisions'. The function '4. Maintain Product Details' is a custodial activity required to maintain the PRODUCT and STOCK files. In this particular diagram no precedence, and hence no time domain information, is implied between functions since no process is dependent on obtaining data from another process.

L'ser's View in Systems Design By considerin:.J the user's requirements for the

sub-system 'I. Record Issue', a physical system can be constructed within the interface between the user and the logical 'machine' function of Record Issue. Figure. 5 shows such a possible physical system to support this sub-system. Startin:.J from the requirements of the logical process '1. Record Issue', now double circled am numbered 1.0 to signify its logical nature, the interface is constructed to convert an AT1'EMPI'ED-IS5UE made by the user, into a valid ISSUE. The interface is responsible for checkin:.J to see that the entered PROruCI'--<::ODE exists on the ProDUCI' file and the entered QUANTITY-ISSUED does not exceed the QUANTITY-IN-S'lO:::K as recorded on the S'lo:::K file. A state transition diagram is then constructed to demonstrate the time domain of one physical interface design. Figure. 6 shows an example state transition diagram for the interface described in Fig. 5. The data flows associated with the interface are shown in bold lines and are used to chek the consistency between the data and function domain model am this time domain m:xlel. In situations where additional data flows are identified on the state transition diagram these must be inserted in the physical DFDs for the interface, along with any necessary additional functions. Program modules required to implement 'I. Record Issue' are shown in the structured design chart in Fig. 7. The function of updating the stock file is shown in a double edged box to signify its 'logical' nature. CXlNCWSIONS This paper has described the use of a range of m:xlelling techniques to demonstrate the aspects of a proposed system in the three domains of data, function and time. Used together the diagrams can form the basis for initial discussions between analyst and user, when the analyst is determining requirements. The time--domain m:xlels of the system (state transition diagrams) are suitable for entry into a microcomputer based Dialogue Prototyper designed by the author. The integration of these models with the structured analysis models suggests scope for a computer based modelling facility for all three dimensions incorporating consistency checking between domains, where appropr ia te . ACKNOViIEJ:x;EMENTS

This work has been carried out as part of a higher degree research programme. Acknowledgement is made to George Rzevski, Kingston Polytechnic, who supervised the entire research progranrne, the Engineering Support Centre of ITT (Europe) who sponsored the development of the Dialogue Simulator and Grahame Stehle, Keith London Associates, who advised on the use of structured methods.

ADE -I

245 REFERENCES

Alty, J. (1983). Path algebras - a useful CAI/ CAL analysis technique. Research Report No.125 , University of Strathclyde. Codd, E. (1970). A Relational Model of Data for large shared data banks. Comm ACM , ~ •

DeMarco,T. (1979). Structured Analysis System Specification. Yourdon Press.

and

Edmonds, E. (1982). The man-computer interface: a note on concepts and design. Int. J. Man-Machine Studies 16 231-236. Feycock, S. (1977). Transition diagram based CAI/HELP systems. Int. J. Man-Machine Studies , ~ , 399-413. Gane, C. and T.Sarson (1979). Structured Systems Analysis: Tools and Techniques Prentice Hall. Guest, S. (1982). The use of software tools for dialogue design. Int. J. Man-Machine Studies , 16 , 263-285. Hopgood, F. and D.Duce (1980). A production system approach to interactive graphic program design. In J.Guedj (Ed.), Methodology of Interaction . North Holland Publishing Co. Stevens, ~. (1981). Using Structured Design hiley-Interscience. vaterman, D. (1978). A rule based approach to knowledge acquisition for man-machine interface programs. Int. J. Man-Machine Studies, 10 , 693-71l. .ells, M.J. (1984a). User-Friendliness. In Proceedings of SEAS Spring Meeting , Vol 1, Share European Association, Knokke, Belgium. pp 245-255. .ells, M.J. (1984b). Modelling the user's view of interactive systems. In A. Bytheway (Ed.), State of the Art Report on Structured Methods Pergamon Infotech. pp 116-132. .ells, M.J. (1984c). Representing the User's Model of an Interactive System. In Proceedings of Interact '84 , Vol 1, IFIP, London. pp 145-150

246

1\1.

J.

Wells

Enter first number:

number:

I

non-alpha

alpha

Error: must be numeric

Enter your age:

Process symbol

non-numer le

Figure

1:

The sum o f

the two

numbers 15

'X'

Sample d ia109ue shown us iog state

transition notation

Figure

Revised notation showing processing modules

):

RECEIPT

ISSUE

Enter first number:

\

Enter second number:

\

PRODUCT

RequiSitio ns

DETAIL

Figure

4:

Logical Data Flow Diagram

The sum of the two numbers is X

Figure

2:

Dialogue represent ation for simple calculatio n process MACHINE

INTERFACE

>lAN

ISSUE

STOCKBALANCE;

~

~

~

Warning No product

in stock

I

I ISSUE

Figure

5:

CODE

PRODUCT -

+ QUANTITY

-

Physical DFD for Record Issue

ISSUED

Cser's View in Syslems Design

Figure

Figure

6:

7:

State Transition Diagram for Record tssue

Structured Design chart for Record Issue

247