Business Systems Design

International AdvancedDiploma in Computer Studies

Business Systems Design


Published by:NCC Education Limited

The Towers, Towers Business ParkWilmslow Road, DidsburyManchester M20 2EZ, UK

Tel: +44 (0) 161 438 6200Fax: +44 (0) 161 438 6240

email: [email protected]://www.nccedu.com

© NCC Education Limited, 2002ISBN 1-90234-349-2

All rights reserved. Except for the quotation of short passages for the purposes of criticismand review, no part of this publication may be reproduced, stored in a retrieval system, or

transmitted, in any form or by any means, electronic, mechanical, photocopying, recording orotherwise, without the prior permission of the publisher.

This book is sold subject to the condition that it shall not, by any way of trade or otherwise, belent, resold, hired out, or otherwise circulated without the publisher’s prior consent in any

form of binding or cover other than that in which it is published and without a similarcondition including this condition being imposed on the subsequent purchaser.

First edition published 2002

Mention of any products in this book in no way constitutes an endorsement byNCC Education Ltd.

Typeset in 10 on 12pt PalatinoPrinted by B & Jo Enterprises PTE in Singapore

© NCC Education. All rights reserved. Unauthorised duplication is prohibited.

NCC Education PortfolioOur portfolio includes comprehensive course packages, competence testingand accreditation services.

Academic Awards• English Language Framework (ELF)

• International Foundation Year (IFY)

• Computer Pioneers (CP)

• International Certificate in Computer Studies (ICCS)

• International Diploma in Computer Studies (IDCS)

• International Advanced Diploma in Computer Studies (IADCS)

• International Diploma in eCommerce (IDEC)

• BSc (Hons) in Computing and Information Systems (BSc CIS) –awarded by London Metropolitan University

• International Diploma in Business (IDB)

• International Advanced Diploma in Business (IADB)

• Postgraduate Diploma in Strategic Business Information Technology(PgD SBIT)

• MSc in Strategic Business IT with the University of Portsmouth(MSc SBIT)

• MBA in International Business awarded by Salem International University

Professional Programmes• A+• eCommerce• Multimedia• Developing a Website• C++• VB.NET• Java• Professional Development Diploma in ICT for Teachers• TechMaster Courses• Systems Analysis Certification• Systems Design Certification• Database Design and Development• Project Management• Business Management


Products• Student materials supporting NCC Education courses

• Lecturer materials to support our courses

• Automated Test Software for European Computer Driving Licence(ECDL/ICDL)

• ATS – Automated Test Software, including bespoke versions

• NCC Education PC Competency Test

• NCC Education Skills Profile Test

• NCC Education Recruitment Test

Services• Course Accreditation

• Centre Accreditation


NCC Education

NCC Education was originally the education division of the NationalComputing Centre. The National Computing Centre was set up by the UKgovernment in 1966 to support and promote the use of computingtechnology within industry. As such, it developed strong links with theInformation Technology (IT) industry.

NCC Education Limited became a separate company in April 1997, sincewhen we have introduced many more IT education programmes to ourportfolio. Our mission is to ensure the widespread availability of qualityeducation and training for developers and users of IT.

Experts in our Field

NCC Education is one of the world’s leading IT qualification awardingbodies, with numerous academic and professional educational and trainingcourses being taught in over 30 countries.

NCC Education’s specialists work with government and national bodiesworldwide to devise and implement educational and training projects.NCC Education’s training programmes are recognised internationally asbeing an effective means for students to advance careers in IT.

NCC Education provides comprehensive support from the outset, from theprovision of comprehensive tutor and student training materials tomoderating the process of training delivery and establishing the assessmentmechanism.

Who are our Partners?

Our unique position bridging IT education and industry allows us todevelop partnerships within many different types of organisation. Inaddition to our work with government and national bodies, our academicprogrammes are run in IT and business colleges worldwide, ourprofessional programmes are run in colleges, large companies and ITtraining organisations worldwide and our automated competence tests arerun in companies and IT training organisations worldwide.


ISO 9001: 2000 Quality inEducation

Historically, our aim has been to equip the UK with personnel who arecompetent in using and developing IT in business. As such, qualityassurance is a rigorous requirement of all NCC Education products andpartners.

NCC Education has gained, and continuously maintains, a quality standardthroughout the organisation. Its certificate number 3812/03 was awardedby ISOQAR. The NCC Education Quality manual states:

NCC Education is unreservedly committed to satisfying itscustomers through quality in all NCC Education’s products andservices.

In support of this policy, NCC Education operates a Quality System thatprovides a framework of standards and procedures within which it managesand controls all its project, product and service activities.

The Quality System is based on the requirement of the pertinent parts of theISO 9001: 2000, independently assessed for compliance to the appropriatestandard.

Specifically NCC Education’s quality objectives are:

• To provide the highest quality administration and support to theinternational qualifications allied certification schemes.

• To ensure that NCC Education accredited centres provide courses thatmeet the requirements specified in the NCC Education syllabus andregulations.

• To specify and maintain syllabi and regulations that meet the careerdevelopment needs of users and computer specialists in the ITcommunity.

• To ensure where appropriate that syllabi meet national academicstandards.

© NCC Education. All rights reserved. Unauthorised duplication is prohibited

International AdvancedDiploma in Computer StudiesThe IADCS qualification is part of the NCC Education academic pathway.It is an intermediate level academic programme for people who wish toenhance their basic knowledge of computer studies.

The IADCS gives candidates the ability to ‘pick and mix’ subjects,allowing them the freedom to explore the topics and technologies whichwill be of most benefit in developing their career.

The IADCS is a one-year programme of full time study, comprising of fourcompulsory modules, four elective modules and one practical project.Time is divided equally between lectures, practical exercises and self-study.

NCC Education carries out time constrained written examinations for thecompulsory modules, with the whole process being managed from theUnited Kingdom. Accredited Centres hold responsibility for assessing theelective modules using clear instructions from NCC Education as to howassessment is to be carried out. Assessment of each module may be byassignment, practical project, examination or a combination of these.

Choose four Electives:

Compulsory:

Compulsory:

Business SystemsAnalysis


Enterprise Networking

Database Design andDevelopment

C++ ProgrammingAdvanced Java

Advanced VB .NET

Internet SystemsAdmin.

Internet SecurityComputer Forensics

BusinessManagement

Managing BusinessProjects

Principles of WebDesign

Practical Project

MultimediaAdvanced

ProgrammingInternet Systems Business

Management

9

Contents

Chapter 1 Introduction to system design 1Chapter 2 Planning and preparation for design 13Chapter 3 Systems options and the approach to system design 21Chapter 4 I/O procedures and ergonomics 29Chapter 5 Screen layout and dialogue design 63Chapter 6 Forms design 85Chapter 7 File design 101Chapter 8 Design of coding systems 129Chapter 9 Procedure and program specification 151Chapter 10 Design and documentation of manual procedures 163Chapter 11 System performance and testing 183Chapter 12 Computer security 201Chapter 13 Implementation planning and changeover 237Chapter 14 Systems review 257

Appendix A 269Bibliography 289Index 293

Introduction to system design 1

1Introduction to system design

IntroductionThe work of the systems designer, just as with that of the systems analyst,needs to be seen in the context of the whole systems life cycle. Figure 1.1allows us to revisit the life cycle explained in the book Business Systems Analysis.The designer must also be aware of the way in which the business ororganisation operates.

The systems analyst will pass to the designer the results of extensive analysisof the functionality, data and events within the existing system, together withinformation about volumes and trends. He/she will also have elicited, withthe users, the requirements for the new system, both the functional (what thesystem is required to do) and non-functional (service level attributes) of thenew system. This information will usually be in the form of a structuredspecification, formally agreed by the business and other major stakeholdersin the system. The contents of the structured specification are detailed in thebook Business Systems Analysis but are listed later in this chapter, for ease ofreference.

This chapter sets out the designer’s task by considering the purpose ofdesign, and the planning which must take place at the outset of the designphase of the project. It looks at the designer’s focus on testing and examinesthe link between analysis and design, design objectives, the inputs to designand the development of a technical specification of the detailed physicaldesign. Subsequent chapters then explore the component parts of the physicaldesign.

2 Introduction to system design

1.1 The purpose of systems designSystems design refers to those activities undertaken to produce a technicalspecification of the detailed physical design of the proposed system. This willthen be used as the basis for writing the software (programs, modules) forthe system, and for configuring the required hardware and operating softwareplatform and the necessary communications networks.

The system specification, produced by the analyst, should be a clear andunambiguous statement of what the new system will do. The technicalspecification contains the specification of how the hardware and software willphysically achieve this. Where an incremental approach to development istaken (as in a rapid application development (RAD) approach), the systemspecification may only be completed to a high level (without low-level detailsof what is required) and each increment of functionality to be designed andbuilt may be given to the designer separately, to be built before the nextfunctionality is analysed. Thus the design and analysis phases may overlapconsiderably. In such cases, it is very important for the designer to producean overall, high-level design skeleton before detailed prototyping ofrequirements begins. For each increment of functionality, it is important, evenwhen prototyping requirements, that some level of analysis precedes thephysical design and build.

1.2 The link between analysis and designThe emphasis of systems analysis was on producing a logical statement of theuser requirements for the system. The physical aspects of the system are, as

Figure 1.1 The systems life cycle.


Figure 1.2 Stages in analysis.

far as possible, excluded from the analyst’s consideration until the point atwhich it is necessary to propose alternative solutions to the user. The analysisphase and its outputs are shown in Figure 1.2

The design phase starts with the logical specification or model of the user’srequirements which the user selects from the options presented. The designerthen has various stages to go through before finally producing a good,workable physical design for the system. He/she must consider the objectivesof their design, interpret the specification presented by the analyst, andtranslate the user’s selection into a detailed physical design.

Below we consider:

❏ design objectives;❏ inputs to design;❏ developing the physical design, which is in two parts, process design and

file design.

1.3 Design objectivesThe first step is to set clear objectives for design. The most important objective,of course, is to deliver a system which provides the functions required by theuser in a manner acceptable to the user and at a cost affordable to the business.If the logical model specifies the production of invoices, and the physical


Figure 1.3 Flexibility, performance and control.

system does not produce invoices or produces them incorrectly, then the designis a failure. However, it is possible to envisage many different physical designswhich would achieve the functional and non-functional objectives. How thendoes the designer decide what is the best design? What criteria are used toevaluate the design? What is a ‘good’ design?

In the invoices example above, although failure to produce invoicesdefinitely implies that the design is a failure, the production of correct invoicesdoes not necessarily imply success. If they can be produced and altered atwill by anyone who happens to stumble across a terminal, the design is atfault. If the law requires changes to the invoice and these cannot beaccommodated, the design is a bad design. Finally, if the design provides theperformance, control and flexibility to overcome these problems, but costsmore to run than the user’s business can afford, then again the design hasfailed. A ‘good’ design is one which will perform the user’s required functionsin a way which benefits the user, and is cost-effective (see Figure 1.3).

Thus, the objectives of flexibility, control and performance, which must beconsidered in any design, must also be considered in the light of their valueto the user’s business. These objectives are not always compatible with eachother. Flexibility and performance have been likened to opposite sides of thesame coin. Therefore, their relative importance has to be decided for eachapplication and the question asked of each: ‘How much is it worth?’

1.3.1 FlexibilityHow easy will it be to incorporate future changes in user requirements intothe system? How easy will it be to track down and amend errors? Widely


published figures indicate that, of the total money spent on the software of asystem during its lifetime, the amount devoted to maintenance approaches60 per cent as the system lifetime approaches six years (Boehm, 1976). If thesystem is abandoned before it becomes operational, maintenance costs willbe zero, but this is hardly a solution to the problem of maintenance costs! Ashort system lifetime may in itself indicate that the system did not do whatthe user really wanted, or it was too inflexible to change when requirementswere altered. The point is that maintenance costs as a proportion of total systemcosts are high for most systems. Thus, anything that can be done at the designphase of the project to make the system easier to maintain and more flexibleto change must be worthwhile.

Ways of designing flexibility and maintainability into a system are discussedlater in the chapter on Procedure and Program Specification. They involve thepartitioning of the design so that areas which handle a particular function areeasily identifiable, and are separated from areas handling other functions,such that a change in one area need not affect the whole system. They alsoprovide a neat separation between ideas which are fundamental to the workingof the system and mere details. Thus the underlying details may be changedwithout affecting the system as the user sees it.

1.3.2 ControlHow secure are the system and its data against human error, machinemalfunction or deliberate misuse? In some applications, the data is of anextremely sensitive nature; data in military systems and banking systems fallsinto this area. In such systems the user is prepared to pay a high price toensure that data will be properly controlled. In other applications, the user’sreliance on the system to perform their business may be total; an increasingnumber of systems fall into this category, and again the user will be preparedto pay for high reliability. In most systems, data is protected from error bysuch means as the use of check digits and hash totals. Audit trails must beprovided so that processing done by the system can be controlled and checked.It is also usual to restrict access to authorised persons only, by the use ofpasswords and possibly other means such as magnetic badges or physicallocks. The chapter on Security deals with this aspect of design.

1.3.3 PerformanceHow quickly will the system be able to perform the required functions?Performance, or efficiency is usually measured in terms of:

❏ throughput – the number of transactions processed in a certain time;❏ run time – the time taken to run a particular program or suite of programs

in a batch system;


❏ response time – in an interactive system, this is the time taken for the firstcharacter of a response to appear at a terminal, measured from the timewhen the ‘return’ key is pressed.

Various ways of optimising system performance can be considered, the mainones being:

❏ minimising the number of intermediate files (i.e. temporary work files)within the system;

❏ minimising the number of passes (i.e. complete end-to-end reads) of eachfile;

❏ keeping the number of disk accesses to a minimum;❏ examining the way in which the system swaps programs in and out of

memory, and minimising this;❏ looking at the code used in programs and streamlining this.

However, designing a system to optimise performance is generally lessimportant than designing one primarily for flexibility. Any system designedfor flexibility may demand more hardware to reach its performance targetsthan if it were designed for performance. However, hardware is relativelyinexpensive when compared with labour costs. An inflexible system constantlydemands more and more labour expenditure, for maintenance. Flexibilityand efficiency are opposing aims and generally the more efficient a system ismade to be, the less flexible it becomes. There is always a trade-off betweenthe two. It is much easier, anyway, to tune a system to improve its performanceafter is has been written and tested when the problem areas and bottlenecksare known, than to try and predict where inefficiencies will occur.

1.4 Inputs to the design phaseThe main documents on which the physical design is based are of two types:those which are derived directly from the analysis of the new system’srequirements, and those which provide information on the constraints placedon the system by the users.

When the analysis phase of the project has been completed, a specificationof the user’s new requirements should be available as a basis for design. Inaddition to this, there will be details of the cost justification for the project,which must be revisited, and the systems options which have been consideredand chosen. Below, we consider cost justification and systems options beforepresenting a more detailed discussion of the system specification.

1.4.1 Cost justificationCost justification is the process of identifying financial costs and benefitsassociated with a development project.


Cost benefit analysis takes place at various points in the development lifecycle such as the feasibility study and when making a choice from a numberof business and technical options. The costs and benefits will depend uponthe systems options chosen and the constraints applied.

Cost justification is considered further in the book Business Systems Analysis.

1.4.2 System options and constraintsThe system options can be divided into:

❏ business system options;❏ technical system options.

Business system options allow the analyst and the project team to inform theproject sponsors of the alternative ways in which their system can bedeveloped to meet their requirements.

A decision on the chosen BSO should have been made on entry to the designphase. It should include:

❏ system boundary;❏ levels of functionality (what the system must do and to what level it should

function;❏ cost/benefit analysis;❏ impact analysis on existing information systems, the infrastructure and

the business area;❏ technical considerations of the different options;❏ base constraints.

Technical system options are developed as an elaboration of the selectedbusiness system option.

A decision on the outline of the chosen TSO should have been made onentry to the design phase, but will be elaborated and refined as a result of it.It should include:

❏ technical environment specification (hardware, software, operating system,network communications);

❏ functions to be covered, and how they are to be carried out;❏ the impact of changes to the organisation and methods of working;❏ impact of the development on the organisation, for the remainder of the

project;❏ costs, implications and timescales.

Systems options are considered further in a later chapter of this book, andalso in the book Business Systems Analysis.


1.4.3 The structured specificationThe way in which information about system requirements is presented to thedesigner will depend on the method of analysis used. It may be a lengthynarrative, or a narrative lightly scattered with flowcharts and/or decisiontables. However, structured analysis has gained much respect throughoutthe information technology world in recent years and is increasingly beingused. Therefore, we consider here the output from a structured approach toanalysis (the structured specification). The actual products from analysis willdepend upon the approach used to the whole systems development.

Some of the best examples of well-defined methods for system develop-ment are:

❏ SSADM 4+ version 4.3;❏ Object Orientation (eg UML, OMT);❏ Rapid Application Development (eg DSDM).

These are described further in the book Business Systems Analysis.The designer should have the following at their disposal, as products from

a structured approach to the analysis phase:

❏ data flow diagrams;❏ mini-specifications;❏ a data dictionary;❏ an entity model;❏ data access diagrams;❏ entity/process matrix;❏ entity life histories.

If a Rapid Application Development approach was taken to analysis, but amethod such as DSDM was followed, the above information should still beavailable, where appropriate. If an Object-Oriented approach was followed,the diagramming techniques have different names and symbols, but thecoverage of definition of elements of data, process and events is very similar.Here, for consistency, we concentrate on the structured analysis products.

Data Flow Diagrams (DFDs) consist of a context diagram, giving an overviewof the whole area of the user’s business which has been studied, and a levelledset of DFDs. The context diagram covers a wider area than that expected tobe affected by the new system and should clearly define all data flowing intoand out of processes which may be affected by the new system.

The lower level DFDs provide details of the system’s functions at as manysuccessively lower levels as required for clarity.

Miniature specifications (mini-specs) specify the processes contained in thelowest level DFDs. They provide a concise specification of the process in arigorous form using structured English, decision tables, and occasionallyflowcharts.


A data dictionary builds up progressively during the analysis phase. At thestart of the design phase it should contain a description of all data containedin every data flow and data store illustrated on the DFDs.

The entity model defines the ‘things’ (entities) of most importance to theuser’s business and about which data is stored. It also shows the relationshipbetween the entities. Data access path analysis builds on the entity modeland illustrates the access paths necessary to perform the processes describedin the DFDs. It also provides information on the type and frequency of accessrequired.

The entity/process matrix relates the processes on the DFDs to the entitieswhich they affect, while the entity life histories give a picture of the eventswhich modify an entity over time.

Other documents, from project initiation, with further detail added duringanalysis, contain the constraints such as:

❏ timing constraints and priorities;❏ fall-back procedure requirements;❏ audit requirements;❏ access and security requirements.

These are added to the specification at the end of the analysis phase.Timing constraints and priorities apply to all systems, whether the time by

which a simple batch system has to complete, or the response time expectedfrom an on-line system.

Fall-back procedure requirements provide the designer with the levels of servicewhich must be achieved in the event of various types of failure, and therecovery time acceptable.

Audit requirements may impose additional processing needs on the systemto be incorporated into the design. Similarly the access and securityrequirements have to be built into the system. Both are designed to ensurethe integrity of the system.

1.4.4 Advantages of the structured specificationThe structured specification has many advantages over the traditional wordyreport. It is:

❏ graphic, consisting mostly of diagrams;❏ partitioned, a network of connected DFDs and mini-specs;❏ top-down partitioned, allowing a smooth progression from abstract to the

lowest level of detail;❏ easily maintained, because redundancy of information is minimised and it

is easy to find relevant portions to change them;❏ iterative, enabling small sections to be passed back and forth between user

and analyst to be checked and modified if necessary;


Figure 1.4 Advantages of the structured specification.

❏ easily understandable, being as clear to the user as to the analyst since thejargon which creeps into wordy reports is not present on diagrams whichhave been developed jointly with the user;

❏ a logical model of the new system, avoiding physical considerations untilanalysis is complete;

❏ precise and concise and therefore easier to read.

The last stage in the analysis phase is for the user to select one of the alternativesolutions proposed (or some modification thereof). Once the user has agreedthe logical model of their requirements and has chosen a business systemsoption, defining the scope of the area of change, then the task of detailedphysical design can begin.

1.5 SummaryThe logical design developed during analysis was virtually free from anyconstraints imposed by hardware or software. As the designer moves thesystem specification from the logical to the physical, so this freedom fromconstraints is reduced. The task of the designer, therefore, is to obtain the bestfit of the logical requirements into whatever physical constraints are imposedby the environment in which they are working. The objective of the designphase of a project is to emerge with a physical design which:


❏ performs the required functions to the user’s satisfaction;❏ is cost effective;❏ is a good design, fit for purpose.

The structured approach advocated here provides a disciplined approach toguide designers in their work, and it ensures that they receive all informationneeded for design in a form most useful to the design process, and with theminimum scope for ambiguity.

Exercises1.1 What are the objectives of system design?1.2 What are the inputs to the design phase, from analysis, and from the

original project set-up?1.3 Explain the difference between Business Systems Options and Technical

Systems Options. When is each of these created?1.4 What diagrams/models should be passed to the designer from the

analysis phase?


Planning and preparation for design 13

2Planning and preparationfor design

IntroductionThe project, as it enters the design phase, should have been carefully plannedfrom the outset. A project initiation statement (document) will have been raisedat the start of the project, to clarify:

❏ the project scope;❏ objectives;❏ constraints;❏ resources.

This will have determined the terms of reference for the systems analyst. Thedesigner should revisit this document, and check whether it is still correct, orif it has been modified in the light of the detailed analysis, or due to changesin the business environment. This document, together with any changes, andin conjunction with the agreed system specification, the cost justification andchosen system option, constitutes the terms of reference for the designer.

2.1 Strategic issues and rolesA steering committee for the project will usually have been set up at the outsetof the project, to manage and monitor progress of the project. The chairmanmay have executive authority (as the ‘executive sponsor’ with ultimateresponsibility for the project) or may have easy access to top management toeliminate any potential delays in the decision-making process. The userdepartments affected will be represented on this committee, and the ITdepartment will also be represented.

14 Planning and preparation for design

The steering committee should satisfy itself, through user management,that the project is still viable and desirable as it enters the design phase.Organisational changes planned for the new system, e.g. change of jobspecification or responsibilities, should be discussed and ratified by thesteering committee. The scope of the new system in terms of its impact on theorganisation should be reassessed.

Planning should already be in place, from the analysis phase, to encompassa number of elements related to the introduction of the new system:

❏ Infrastructure requirements: (preparation of offices and buildings toreceive the new system). However, new equipment may still need to beinstalled and tested before system trials can start;

❏ Staff issues: changes in job roles. These may be modified in the light ofphysical design;

❏ Testing: plans will have been made at a high level, but may need to berevised as a result of detailed design;

❏ Implementation: the process of cut-over from the old system to the newone may have been planned in outline. This may affect the options forsystem design. Conversely, the system design may affect the practicality ofthese plans;

❏ Transfer and conversion of data: further software may have to be built toachieve this, and the design of the system must take into account thepracticality of data transfer.

The designer must revisit these plans, since they may place constraints uponthe physical design, or may need modification in the light of it.

Figure 2.1 shows the overlapping tasks within systems design, andemphasises that they are not sequential. Whatever approach to developmentis taken, whether structured, object oriented, or rapid application develop-ment, implementation and test planning must begin as early as possible, sincethe lead times to some of their activities such as hardware and softwareacquisition and set-up can be very long.

2.2 Planning the designA great deal of information is needed to begin design, much of which willhave been collected during analysis. However, the following checklist can beused by the designer when planning for design, in order to assess whatinformation is available and what has still to be collected:

❏ identify the potential users of the proposed system;❏ interview users to establish what experience they have had of systems

development;❏ become familiar with the work environment and establish a rapport with

the users;


Figure 2.1 Overlapping tasks in system development.

❏ obtain constructive user contributions to the design, bearing in mind thebenefits and problems involved;

❏ plan any necessary training;❏ inform all parties of the approach to design that is to be employed and

ensure that they understand and agree with the roles they will have toplay.

2.2.1 Planning for disruptionThe designer should identify any disruptions likely to occur, using thefollowing categories as a checklist:

❏ user contributions to systems design;❏ physical changes to the workplace;❏ training users to operate the new system;❏ systems testing, parallel running and system initiation.

2.2.2 Work situation appraisalThe designer should seek to:

❏ become familiar with the user’s work environ-ment, gain an appreciationof the nature of the work, the pressures, priorities, skills, values and attitudesof the people;

❏ identify the specific human factors information to be accommodated;


2.2.3 User identificationActivities to be undertaken include:

❏ identify potential users by establishing the name and job titles of the usersof the existing system;

❏ develop a ‘map’ of the user population. For example, it will be helpful toclassify future users in terms of primary, secondary or tertiary users toavoid focusing solely upon the main users at the expense of others;

❏ use the ‘map’ as a directory of potential users when user needs andcharacteristics have to be established at various points in the development.

2.2.4 Task demandsThe key activities in this category are as follows:

❏ identify the range and functions undertaken by the users with particularemphasis on the variations in the work;

❏ review techniques for task analysis and select appropriate techniques;❏ conduct detailed analyses of user tasks with emphasis on task differences.

2.2.5 Work role analysisThe designer should seek to:

❏ gain an understanding of the user’s perception of their work, its purpose,value and meaning for them;

❏ gain the user’s views on the rewards and costs of the job;❏ identify the most important aspects of the job for the user.

2.2.6 User readinessActivities to be undertaken by the designer include:

❏ assess users’ previous experience of computer systems;❏ examine users’ attitude to computer use;❏ assess user knowledge of the proposed system;❏ assess users’ willingness to cooperate in system development.

2.2.7 Job designThe key aspects of job design to be considered are:

❏ identify all tasks, old and new, which will undergo change as a result ofthe new system;

❏ generate alternative ways of allocating tasks to jobs by considering, forexample, allocations by function, product or customer;

❏ provide opportunities for user groups to explore job tasks by providingprototypes of the main functions of the new system.


2.2.8 Design procedures for faults and breakdownsThe designers should seek to:

❏ design procedures such that users can take positive action when they areconfronted by a fault or breakdown. Ensure that users are trained in thesemethods;

❏ ask users for their constructive criticism of the above methods which willaffect them;

❏ produce tests for faults and breakdowns.

2.3 The designer’s focus on testingThe designer’s focus on testing is from two perspectives:

❏ he/she must ensure that the system is designed (and subsequentlyconstructed) in such a way that it can be tested, and will usually haveresponsibilities which extend to system testing after the system has beenbuilt/coded;

❏ he/she may use prototyping and limited trials during design, to test thedesign approach for practicality.

The elements of functionality and data identified by a structured approach toanalysis will greatly assist in producing a ‘good’ design. The logical entitiesand elementary processes from analysis will provide a flexible andmaintainable structure. However, performance issues may require this logicalstructure to be compromised. The designer must be aware of the effects ofany such compromises.

The designer’s responsibility for testing is further explored in Chapter 11.

2.4 Planning for system testingSystem testing is carried out to ensure that the system works accurately andefficiently before it is put into live operation. The scope of system testingincludes all clerical and computer aspects, as shown in Figure 2.2.

Testing of the system takes place on several levels and throughout theproject. Programs should be tested individually and then in groups to verifythat all links between programs are correct. Once the programs have beentested and perform correctly in groups, they can be tested as part of thecomplete system.

Similarly, hardware and communications links must be tested separatelyto ensure that they are functioning correctly before being tested as part of thecomplete system.

The final stage of testing, which precedes changeover to the new system, isthe linking together of the previously tested and verified programs, and thetested hardware to ensure that the system works under operational conditions.


Figure 2.2 System testing.

User staff may be involved in the tests, although it is essential that bothhardware and software have been tested as thoroughly as possible beforeusers are asked to take part in the system trials. Otherwise failures, the causeof which may be minor from a computer point of view, can cause confusionand frustration for the user and result in lack of confidence in the system.

2.5 Planning for implementationOnce the chosen technical option is agreed, planning for implementationshould begin. Hardware, stationery and many other aspects required forsuccessful implementation have long lead times. The responsibility forimplementation may fall to the analyst, but the designer should be involvedto ensure that the platform for the design is correctly configured.Implementation is considered further in Chapter 13 of this book.

2.6 SummaryThe design phase must be carefully planned. The project scope, in terms ofobjectives, constraints and resources must be clarified, in conjunction withthe agreed system specification, as the terms of reference for the designer. Thedesigner should also clearly understand the management structure (steering


committee, project team structure) for the project. It is likely that the project’sprogress will be under the auspices of a project steering committee, with userdepartments affected, and the IT department also represented.

Planning should already be in place, from the analysis phase. However,careful planning of the design phase must be carried out, in addition toplanning the testing and implementation phases.

The outputs from design must be sufficient to enable the system to beconstructed, code built and tested, and the system implemented withinacceptable levels of disruption to the business. Later chapters in this bookwill address the detailed tasks of process, file and program design and alsothe ergonomic aspects of the design.

Exercises2.1 What do the terms of reference for the designer contain?2.2 What is the purpose of a project steering committee? What are the roles

within a steering committee?2.3 Make brief notes of the designer’s concerns under the following headings:

❏ Work situation appraisal;❏ User identification;❏ Task demands;❏ Work role analysis;❏ User readiness;❏ Job design;❏ Design procedures for faults and breakdowns;❏ Testing;❏ Implementation.


Systems options and the approach to system design 21

3Systems options and theapproach to system design

IntroductionThe last stage in the analysis phase is for the user to select one of the alternativesolutions proposed (or some modification thereof). Once the user has agreedthe logical model of their requirements and has chosen a business systemsoption, defining the scope of the area of change, then the task of detailedphysical design can begin. This can be subdivided into areas of:

❏ process design;❏ file design.

Each of these will be dealt with in turn, looking at the documents within thestructured specification which give information relevant to each aspect, andat how to use these documents to begin the physical design process. Theintention is to give a summary of what has to be done. Greater details abouthow it should be done are contained in later chapters.

3.1 Process designProcess design incorporates:

❏ system interfaces – the human/computer interface (or machine-machineboundary) and all the equipment, dialogue design, clerical support systemsand form design which may be needed at the interface;

❏ programs and their design.

22 Systems options and the approach to system design

3.1.1 System interfacesThe documents of assistance when defining system interfaces are:

❏ data flow diagrams;❏ data dictionary.

The interfaces of the new system can be seen very clearly by taking theappropriate DFD and drawing in the boundary of the area for computerisation.Take the following simplified example (see Figure 3.1) of a customer-orderprocessing system. It has been decided to computerise only the area marked.

Defining the interface The interfaces to the system can be identified bynoting the points where a data flowline crosses the boundary of the area forcomputerisation. The actual interfaces occur within the processes (rectangles)attached to these data flows, and just inside the boundary of computerisation.The data dictionary should be consulted for full details of the informationcontained in the data flows. Thus, the interfaces are fully and clearly defined.

Supporting clerical systems It can be seen from Figure 3.1 that a supportingclerical system will be needed to validate the order from a manual customerfile so that only acceptable orders from valid customers enter the computersystem. There may be an existing clerical system which performs this function,so it may be sufficient to modify its output to correspond with the inputrequired by the allocate stock function. Alternatively, a completely new clericalsupporting system may have to be designed.

Human/Computer Interface (HCI) An HCI is needed to allow the input ofvalid order details into the allocate stock function. At this point, there is arequirement for some or all of the following, depending on the type of system:

❏ form design;❏ selection of the type of terminals to be used;❏ calculation of approximate number of terminals required and a decision

regarding their locations.

At the other side of the DFD in Figure 3.1, there is an interface to the invoicingfunction. It is not obvious from the diagram how this is performed at present,but such information will be available in the physical description of the currentsystem. In it the analyst recorded that the invoicing function is already acomputerised process. Invoices are produced by a batch processing run oncea week. The details from the currently manually produced despatch notesare keyed to disk daily by data preparation staff. Since it has been agreedwith the users, and is shown on the diagram, that invoicing should remainoutside our new system boundary, all that is needed at the interface between


Figure 3.1 System interfaces.

computer systems is to output despatch details in a manner compatible withthe current invoicing system.

3.1.2 Program and program suite designIt was stated earlier that more money is usually spent on maintaining a systemonce it has been implemented than on developing it in the first place. Thereare certain ways of designing programs and their relationships to each otherwhich can make maintenance simpler, and in the long run, cheaper. Thefollowing features built into the design of a system are generally agreed toprovide a flexible system which is easy to maintain. Figure 3.2 shows thesegraphically.

Top-down design A design is said to be ‘top-down’ if it consists of ahierarchy of modules, each with a single entry and a single exit.

For ease of maintenance and modification of the system, it is essential thata reasonable separation is kept between parts of the system which representits underlying philosophy and parts which are mere details. With a top-downdesign, the philosophy tends to be embedded in the higher level modules,while the details tend to be performed by the lower level modules.

Each module manageably small The smaller a module is, the easier it will beto find an error in the code and to make an amendment to that code. However,this feature has to be offset against the fact that if modules are very small,there will be huge numbers of them within the system, so the time savedamending an error may be lost in trying to locate the correct module in the


Figure 3.2 Program and program suite design.

first place. Additionally, the system overhead of managing a very large numberof modules and their links to one another may become significant andperformance may suffer. Therefore, modules should be small, but not toosmall!

The black-box approach The ‘black-box’ approach implies that a modulecan be looked at purely in terms of its inputs and outputs to find out what itdoes, and that there is no need to look at the code to see this. So, with anygiven input, the output will be totally predictable if the module has beendesigned as a black-box.

This approach makes the system much more easily and quickly readable,and therefore maintainable.

Isolation of function If a module has only one function, and that functionis contained completely within that module, then the modification of anyaspect of that function need only affect one module. It is easy to identify whereto make the change and should be simpler to test and implement. Of course itmay not always be possible to keep one function to one module and still havemanageably small modules, but it should be kept to as few modules aspossible. The less the contents of one module depend on the contents of any


other module, the easier it is to maintain, and the less chance there is of arelatively minor change causing a ‘ripple-effect’ of resulting problemsthroughout the system.

3.1.3 File designFile design is a crucial factor in the performance of a system, both in terms ofsystem timings (either batch or on-line) and the ease with which the systemcan be maintained or modified. A large amount of information relating todata storage requirements has been gathered during the analysis phase. Thisinformation is presented in DFDs, entity models, data analysis records, dataaccess diagrams and the data dictionary. Other documents within thestructured specification such as the mini-specs also contain useful information.

Data stores will be implicit or even explicit in the logical system selectedby the user. The designer now has to take those logical stores and createphysical files (or databases) from them. To remove the guess-work from thistask, answers to the following question are needed, and in each case the mostuseful sources of information are given in brackets:

❏ what data items need to be stored? (data dictionary);❏ which items go in the same record or file? (data analysis, entity model);❏ what are the keys? (data access diagrams);❏ what types of file – temporary? permanent? shared? (data flow diagrams);❏ what links are needed between files? (data access diagrams);❏ how often are accesses made via each link? (data access diagrams, data

dictionary plus calculation);❏ what response times are required? (mini-spec, timing constraints);❏ how volatile is the data on each file? (data dictionaries);❏ how are the files likely to grow? (data access diagram).

The implication of the answers and their effect on file design is very importantand is the subject of a later chapter.

3.2 System optionsSystem options influence the decisions upon how a project will move forward,and on the design which is appropriate. System options can be divided into:

❏ business system options (a view of what is covered by the system)❏ technical system options (a view of how the business option will be

implemented)

3.2.1 Business system options (BSOs)Development of business system options gives analysts and users the


opportunity to explore where the system boundary lies and to view thealternative ways in which their system can be developed to meet theirrequirements. Several BSOs will usually be considered, and one chosen whichwill then form the basis of the system specification of the required system.

3.2.2 Technical system options (TSOs)Technical system options are an elaboration of the selected BSO. They address:

❏ a specification of the technical environment, e.g., provision and distributionof hardware devices; software environment; operating regime;

❏ confirmation of the functions to be covered, and the manner in which theyare to be carried out;

❏ the impact of changes to the organisation and methods of working;❏ the impact on the development organisation and infrastructure for the

remainder of the project.

Technical system options provide specific technical information on a smallnumber of options (no more than six, more usually three) for physicallyimplementing the chosen BSO, including costs, implications and timescales.

The designer’s first task will be to define several technical systems options,containing an outline of the proposed designs, at a high level only, as a basisfor users to decide on the chosen option. Once the chosen TSO is known, thedesigner is able then to ‘flesh out’ this design with full details, sufficient forthe system to be constructed, tested and implemented.

The designer must be careful not to address each TSO in too much detail,since this will ultimately be ‘wasted’ for all but the chosen option. However,sufficient detail in each TSO is needed in order to allow an informed decisionto be made on the advantages, disadvantages, costs, constraints and benefitsof each option.

3.3 SummaryThe logical design developed during analysis was virtually free from anyconstraints imposed by hardware or software. As the designer moves thesystem specification from the logical to the physical, so this freedom fromconstraints is reduced. The task of the designer, therefore, is to obtain the bestfit of the logical requirements into whatever physical constraints are imposedby the environment in which they are working. The objective of the designphase of a project is to emerge with a physical design which:

❏ performs the required functions to the user’s satisfaction;❏ is cost effective;❏ is a good design, fit for purpose.

The structured approach advocated here provides a disciplined approach to


guide designers in their work, and it ensures that they receive all informationneeded for design in a form most useful to the design process, and with theminimum scope for ambiguity.

The designer will usually present several technical systems options forphysical design of the new system, each of which addresses the usersrequirements, but to different extents. These options must provide users withsufficient information on which to make an informed decision on the physicalapproach to take with further systems development. Once a decision has beenmade on which option, or combination of options, to follow, the designer willthen proceed with the fully-detailed design of the chosen option.

Exercises3.1 System design incorporates process design file design. What are the

elements of process design? What are the factors to consider within filedesign?

3.2 What are the elements of program and program suite design which leadtowards a flexible and easy to maintain system


I/O procedures and ergonomics 29

4I/O procedures andergonomics

IntroductionAny computer system is only as good as the quality of data which is input toit and the quality of information that is output from it. Data becomesinformation when presented in the context to which it relates eg 300902 couldrepresent a part code in a stock system or 30th September 2002, the date whenyour boss retires and you may be promoted!!

There are two major factors which will affect the interaction between userand computer and consequently the performance of any new system:

❏ input/output procedures;❏ ergonomics and the user’s environment.

4.1 Input/output procedures and how they are enactedThe input and output requirements of the system are first defined, in outline,in the logical specification of the system. The physical design process takesthese outlines and expands them to a detailed level, checks their practicabilityand their continuing desirability with users and determines the exact mediaand processes for capturing input data and producing output.

The design process begins with an appraisal of the documentation containedin the structured specification, and must be done alongside, and with constantreference to, file and program design. Input and output procedures must thenbe specified not only in terms of the computer aspects but also the clericalhandling required to support it. Clerical procedures are the subject of a laterchapter on manual procedures. Here we shall concentrates on the computer-

30 I/O procedures and ergonomics

related tasks and considerations, taking the design process from theinformation received in the structured specification, through the selectionand design of input and output procedures, to their documentation for usersand programmers.

4.2 Interpretation of the structured specificationThe logical model of the required system is specified in terms of Data FlowDiagrams (DFDs), the Data Dictionary (DD), Access Path Diagrams (AccessProfiles) and miniature specifications (mini specs) further defining theprocesses shown in the DFDs. The information required to identify inputsand outputs is mostly contained within the DFDs and their accompanyingmini specs, although the DD gives useful information regarding data flows,data item formats and the relationship of items to each other. The DD shouldbe consulted to ensure that all required data items are present.

The inputs and outputs required by the system can be seen clearly if theboundary of computerisation is marked on the DFDs as shown in Figure 4.1.

The points at which this boundary crosses data flow lines are the human/computer interfaces and as such are the points at which the inputs and outputsof the system occur. To be more precise it is just inside the rectangles(processes), which lie on the data flow lines intersected by the boundary ofcomputerisation, where the human/computer interfaces occur.

In Figure 4.2 the actual interface is within the process ‘Validate order andcustomer’ and it involves the entry of data into the computer.

Figure 4.1 Boundary of computerisation.


Figure 4.2 Validate order and customer.

The content of the data flows should already have been specified withinthe DD. If program design has been undertaken, the structure chart willconfirm the input and output sites and will specify the program module(s)with which the input and output procedures must interface.

At this point it is useful to look at input and output procedures separatelyand in each case the design is considered under the following headings:

❏ procedure design;❏ definitions;❏ processes;❏ error detection and correction (for input);❏ documentation.

4.3 Input design4.3.1 Input procedure designThe design of input procedures requires careful attention. Often the collectionof input data is the most expensive part of the system in terms of bothequipment used and number of people involved. The point of input is alsothe point at which most errors enter the system. If data going into the systemis incorrect, processing and output will magnify these errors. Thus, thedesigner has a number of clear objectives in input design:

❏ to choose a cost-effective method of input;❏ to provide a method of input acceptable to the user;❏ to trap errors in input data, and as far as possible, prevent such errors from

entering the system;❏ to ensure that the method of input is fully understood by the user.

4.3.2 Input definitionsWhen the points of input to the system have been identified, each input mustbe studied individually to ascertain:


❏ the source(s) of the input;❏ the format in which it arrives at the system;❏ the input flow, i.e. how often and in what volumes it arrives;❏ the appropriate medium and format for its entry into the system.

Then processes must be established to ensure the accurate and timely entryof the data into the system.

Sources of input Input may be external, arriving from outside the organisa-tion, or internal, originating within the company, either from the users of thesystem or from another part of the company.

External input is usually the prime input to the system and may be suchthings as sales orders or invoices requiring payment. A problem with thistype of input is that the designer cannot usually control the format in whichit arrives – that will be determined by the originator. The reader should notethat sales and payments over the Internet do allow the designer to control theformat in which such transactions arrive. Transcription from the input takenfrom an external source onto standard forms can be carried out to create astandard input document. However this is both time consuming and errorprone. Supplying standard forms on which customers can submit their orders(e.g. with mail order catalogues) is useful, but only really feasible where boththe customer base is stable and the customers can see some real advantage tothemselves.

Internal inputs can be grouped into three basic types:

❏ file enquiry and maintenance;❏ systems operation;❏ those arising from other departments.

The designer has varying degrees of control over the format of these inputs.Normally for file maintenance routines the designer has a free hand. Thismay also be true of file enquiry routines, although they may be constrainedby a software package that the company uses. Inputs relating to the operationalaspects of the system such as ‘signing’ or ‘logging on’, the use of passwordsand other security devices and the input of parameters to the system willprobably be subject to company standards. If this is not the case the designeris then free to develop procedures best suited to the user’s requirements.However, they should consider the advantages of a consistent approach,particularly if the user is involved with input to more than one system.

Input from other departments can be either in the form of pieces of paperor in a machine-readable form. If it arrives in a machine-readable form, thedesigner must ensure that it contains all data required. It may then only benecessary to reformat the data. When the data arrives on a piece of paper itwould normally be on existing forms.


Figure 4.3 Input types.

Since the domain of change and the boundary of computerisation havebeen agreed with the user, it must be assumed that the existing forms areoutside the boundary and therefore not subject to change. Therefore thedesigner must produce procedures to accept the existing forms and processthem as necessary.

Format of input Input may arrive at the system as a telephone call, a letter, acustomer’s own form, the organisation’s own standard form, a computerproduced document, a machine readable document or in computerised formsuch as floppy disc, tape, and so on (see Figure 4.3). Some inputs may besuitable for direct entry into the system, others will need to pass through atranscription or translation process first.

Flow of input Input may arrive at random, as with customers’ orders placedby telephone; it may arrive in batches, for example, twice daily in the post, orweekly or monthly. Arrival of data may be evenly distributed over time, ormay occur in seasonal peaks and troughs. These factors have a bearing on theway in which data can be input and the input hardware to be used. If inputarrives at random but immediate processing is not necessary it may be sensibleto batch it and input it daily. Conversely, if immediate processing is requiredfollowed by immediate output response, some form of interactive input isindicated, and this must be able to cope with variations in the levels of data


received for input. Volumes of data must also be taken into account. If largevolumes of input are expected, input procedures must be designed to copequickly and effectively with the data, without allowing an unmanageablebacklog to build up.

The complexity of input is also a factor. If many different types of inputneed to be entered by one user, then dialogues and procedures must bedesigned to avoid confusion and delay between the different inputs.

Input media Input devices can be classified as:

❏ on-line media (e.g. screens, keyboards, scanners);❏ document readers (e.g. Optical Character Recognition (OCR), Magnetic

Ink Character Recognition);❏ source document (e.g. key to disk, key to tape);❏ conversion media.

In order to decide which is appropriate it is necessary to establish:

❏ the frequency, flow and complexity of input data;❏ volumes of data;❏ speed of response required;❏ output requirements (the frequency of requirement of output may affect

input schedules);❏ validation and ease of error correction necessary to the system;❏ the environment in which data is to be collected/captured;❏ cost.

4.3.3 Input processesDepending upon the type of input, volumes and format in which data reachesthe system, it may need to pass through various processes. These may includesome or all of the following:

❏ data recording (the process of collecting data at its source);❏ data transcription (the transfer of data to an input form. This may involve

translation from a customer’s terminology into terms used by the system);❏ data conversion (the conversion of data from a document onto a computer-

acceptable medium);❏ data control (checking, batching and controlling the flow of data to the

computer);❏ data validation and verification (checking input data for errors and

inconsistencies);❏ error correction (correcting errors detected at the input stage).

Not all of these stages need to be present, but some (for example, error


correction) may occur at several stages of input. The designer should recognisethat each process represents a point at which further errors may enter thesystem. Therefore, they should aim to minimise the number of input processesthrough which the data must pass.

Input control Every effort must be made to ensure that data entering thesystem is accurate, that no errors are introduced during transcription ortranslation processes, and that no data is lost, either during data entry, orphysically before documents arrive at the point of input.

Error avoidance. Many errors can be avoided by giving careful attention to theenvironment in which data is prepared and entered into the computer system,the media from and to which it is transcribed, and the clerical procedures setup for its entry. With the increasing use for long periods each day, muchemphasis needs to be placed on the quality of the human/computer interface.Otherwise, inadequate facilities may be provided, systems will be inefficientand users may become tired, bored and prone to making errors. The ergonomicaspects of system design at the human/computer interface must thereforenot be overlooked or treated lightly.

4.3.4 Error detection and correctionHowever carefully a system is designed to avoid unnecessary errors, apercentage of errors will inevitably occur. The earlier these errors can bedetected by the system, the easier they will be to correct. Once erroneousdata has been the subject of complex processing, one error may have affectedmany files and many outputs. Therefore, the aim is to detect errors beforethey enter the system and correct them as quickly as possible.

Error detection and correction in interactive systems will be discussed inthe next chapter. With batch systems, error detection is often possible beforedata enters the system by the application of batch total checks and verificationkeying where the same data is keyed in independently by two people andany discrepancies highlighted. However, if erroneous data slips through thekeying process, correction becomes far more difficult. The usual procedure isto incorporate errors on reports which are sent to the user department. Controlmust be maintained to ensure that corrections are not overlooked. Also, thecorrections themselves are susceptible to error or to the introduction of errorsas they pass through the same processes as the original data.

Interactive systems have definite advantages over other types of system inthe area of error correction, since amendments can be done immediately andthe results can be seen and checked at once to ensure accuracy. Their weaknessis in error detection, since batch checks and verification keying are not usuallypractical. Conventional validation checks can ensure that the correct type of


data has been entered, and that the value of a data item is reasonable andwithin an expected range, but cannot ensure that the data keyed has beentranscribed exactly from the input form or other source. The only safeguardsare the measures outlined under ‘error avoidance’ and training of users torecheck their keying, or the use of some sort of machine readable input.

4.3.5 Input documentationPurpose Documentation of input requirements serves two distinct purposes:

❏ to record an unambiguous definition of the input expected by the users ofthe system;

❏ to communicate to the programmer the details of inputs with which theirprograms must interface.

The forms used for this documentation, and some of the information held onthem, may not be ideal for use in communication with end users. However,with help in interpretation from the designer, it should be possible to ensurethat requirements are accurately and unambiguously recorded. Theprocedures will be further recorded in a form designed for the user, the usermanual.

The documentation of clerical procedures for handling the input, togetherwith the preparation of a user manual will be outlined later in the book. Here,details of what should be recorded are given.

Method Input may exist in document form before being input to thecomputer, in which case the document, and the use of each box in it, shouldbe specified. The information can be input directly into a Data Dictionary.

Figure 4.4 illustrates the type of detail required for input media.Where a screen is used for input, the Dialogue Structure and routes (see

Chapter 5) are part of the documentation (see Figures 4.5 and 4.6). A copy ofeach screen should also be included. The data items should be recorded alongthe lines of the Data Dictionary.

4.4 Output design4.4.1 Output procedure designMost systems produce output in some form; for some users the output froma system is their only contact with that system. Therefore, a system is oftenjudged on the quality and presentation of its output. The purpose of outputwill be one or more of the following:

❏ to communicate the results of processing to users;


Figure 4.4 Type of detail required for input media.

Figure 4.5 Dialogue structure to be used as part of documentation.


Figure 4.6 Dialogue routes to be used as part of the documentation.

❏ to provide documents for communication with customers or clients;❏ to provide hard copy for later reference;❏ to provide documents for re-input to the computer – so called ‘turnaround’

documents where a document is output in a part complete state, therecipient completes the rest and the additional information is input to thecomputer;

❏ to provide (computerised?) data for another system;❏ to provide data regarding the workings and efficiency of the system;❏ to provide copies of data for back up purposes.

4.4.2 Output definitionWhen the points of output from the system have been ascertained from DFDs,each output should be examined and discussed with users to determine:

❏ its destination, whether internal to the company or as output to a customer;❏ the medium and format required (hard copy, screen messages, etc.);❏ output flow, how often and in what volumes it will be produced.

Output destination and type Outputs may be ‘external’, destined for peopleoutside the organisation, or they may be purely ‘internal’, to be received byusers within the organisation. External outputs may be such things as invoices,cheques, and advice notes. Their design and presentation require carefulconsideration since they project the organisation’s image.

The format and/or content of some external outputs may be determinedby law. This applies, for example, in the UK to invoices for goods exported tocertain foreign countries, and to returns to the Inland Revenue. The designermust ensure that final designs for them are legally acceptable.

Internal outputs may be interactive, as with a reply message on a screen,or hard copy, as with management reports. As mentioned above they may be


turnaround documents, destined for re-input to the computer (it is possiblethat turnaround documents could be an external output as for gas andelectricity bills).

Other outputs, either internal or external, may be in computerised form(e.g. on disk or tape) for direct entry into another computer system, or forback up purposes.

Format of output Each data item in the data flows identified on the DFDs asoutput, should have been defined previously in the DD. However, since theformats in which data is held in the computer are not always suitable foroutput, it may be necessary to supply further information regarding dataediting and also to specify certain derived items such as totals required onreports.

The editing features required are usually items such as suppression ofleading zeros, floating ‘£’ signs and the insertion of decimal points.

Beyond the details of editing, the format of output is usually very flexibleat the design stage and can be tailored to meet user needs. The different mediaavailable for the production of output are discussed later in the chapter. Themedium and format must always be discussed with the user and reconfirmedif decisions were made earlier in the system’s life cycle, to ensure that outputsare still appropriate and still required.

Flow of output The flow of output refers to the frequency and size of output.An output may be a report produced every Friday, or at the month end, etc.,a report produced on demand, or a message to a screen displayed a fewseconds after an input. The flow of output depends on:

❏ user (or perhaps statutory) requirements;❏ volume of data to be output;❏ the purpose of the output.

A user will often opt for a 100-page report daily rather than have the sameinformation as a 2000–3000 page monthly report.

The user may not have considered the size of a report when requesting itduring the systems analysis phase of the system. It is better if the designercan foresee which outputs will be large, rather than waiting until afterimplementation when the user receives the first copy of the report deliveredby a fleet of lorries and decides that it is unmanageably long!

Similarly, with certain interactive outputs, the fast responses expected bythe user may not be possible due to data volume. If an enquiry requires end-to-end reading of a large file, followed by sorting of a large amount of extracteddata, the response to the screen may be a matter of minutes. Even this may beacceptable to a user under certain circumstances if it is essential for them tohave the results of that enquiry. However, they should be warned that the


response for that particular feature is likely to be lengthy, since the delay mayrender it useless to them.

Output media In consultation with users, the designer must decide the mostappropriate and cost-effective medium for each output. This will involveconsideration of a wide range of devices including printers, screens, graphplotters, magnetic media, microfiche, CD-R compact disk and DVD-R disk.The choice of medium depends on many factors, the main ones being:

❏ response required (this may be a matter of seconds, hours, daily, weekly,etc.);

❏ the need for hard copy (and the number and quality of copies required);❏ the location of users, and of final recipients of the output, possibly external

to the organisation;❏ the volume of output involved (e.g. large quantities of data may be

impractical to transmit to on-line terminals);❏ purpose of the output (e.g. if it is for entry into another computer system,

magnetic media may be most suitable);❏ software and hardware available;❏ cost.

4.4.3 Output processesThese depend upon the following types of output:

❏ the editing and formatting required for display or printing of data (thesehave already been mentioned);

❏ data transmission (this may be transmission along a communication lineof data destined for a remote computer, or it may be the physicaltransportation of magnetic media or paper);

❏ output control (discussed below);❏ output presentation – the processes required to make output acceptable

and useful to the user department or the customer. This includes processessuch as de-collating carbon from multi-part sets of stationery, guillotining,bursting (splitting into individual documents at perforated joins). Theseprocesses affect design as the designer must allow time for them to beperformed and ensure that the necessary equipment is available.

4.4.4 Output controlIt is generally true to say that insufficient attention is paid to the control ofoutput, yet it requires the same degree of control as any other aspect of asystem (see Figure 4.7). Accuracy of output is largely determined by accuracy


of input, once programs have been thoroughly tested and are known to beperforming their processing tasks correctly.

However, problems may still arise at the output stage, especially withprinted output:

❏ reports should always have numbered pages and include an ‘end’ indicationso that the user can check that they have received the whole report;

❏ single page reports, for example error reports or control total listings, areeasily mislaid. It is a good idea to ensure that error reports and similaroutputs always appear even if there are no errors, so that users know therewill always be a report, and can investigate if one does not arrive;

❏ printer malfunction may cause an occasional character to fail to appear, orto appear illegibly. Sample checking of a few documents from each runshould be routine.

Control is particularly important on output whose destination is external tothe organisation. Certain outputs, such as cheques and invoices, should besubject to strict security and are usually controlled by having seriallynumbered pre-printed stationery, each document of which must be accountedfor.

Figure 4.7 Accuracy of input is key to output.


Control must also be maintained over output which in some way is destinedfor re-entry to the system, or to another computer system, to ensure that re-entry actually occurs.

4.4.5 Output documentationPurpose Having established, in consultation with users, the most appropriateformat and medium for each output, the designer must document theserequirements clearly and accurately in order to:

❏ record the details of outputs to be produced, to be checked by users;❏ communicate the requirements unambiguously to programmers.

Full details on how to use output procedures should be contained in aseparately documented user manual. This will be described more fully in alater chapter.

Method Where output is part of an interactive system and is displayed on ascreen, documentation includes a copy of the screens and Data Dictionaryentries.

Where the output is in computerised form on a magnetic medium, it willstill retain the form of a computer file or database and will be specified in theData Dictionary.

In the case of printed output, the documentation required may consists ofa Print Layout Chart and a copy of the actual output. An example of a PrintLayout Chart is shown in Figure 4.8. Alternatively a screen print previewof an output ‘prototype’ may be captured and included as part of thedocumentation.

The form in Figure 4.8 illustrates the content and format of output to beprinted by the computer. The proposed column headings, sub-headings andsome representative data and totals may be written in their appropriatepositions on the chart. Where variables appear they should be enclosed insquare brackets. Data item lines which will be all, or almost all, variablesneed not be bracketed.

The completed Print Layout Chart/Print Preview gives a detailed pictureof the appearance of the proposed output. It gives the programmer sufficientinformation to format reports and the user a rough idea of the way the outputwill appear. However, it is far better if, before detailed programming isembarked upon, the user can see a simulated version of the output as far aspossible on the actual device and medium proposed. This can be aided by theuse of report program generation software if it is available within theorganisation.


4.5 Ergonomics and the user’s environmentThe ergonomic aspects of system design at the human/computer interfacemust not be overlooked or treated lightly for they will impact the operationof the computer system.

Although we tend to think of technology and its resulting problems as new,many can be avoided by the application of the same common sense principlesthat are appropriate to other, more established types of office machinery. Thisincludes choosing well designed models, ensuring that they are adequatelymaintained and listening to the comments of the people who use them.

The major considerations are:

❏ workplace design – its size, layout and type of furniture and equipmentalready present, quality of ventilation, air conditioning and heating, access,and movement around workplace, noise level and other things such asdustiness, humidity, etc.;

❏ document design – sufficient to say that a confusing form design on adocument used for data input will inevitably lead to slower data entry,frustration of the user, and errors.;

❏ equipment design – detailed discussion below;❏ dialogue design – see chapter on screen layout and dialogue design;

Figure 4.8 Print layout chart.


❏ job design – the system designer must consider the tasks a workstationuser will have to perform, both whilst using the system and doing anythingelse which the job entails.

4.6 Human/computer interactionSystems are developed for users. They should be safe, efficient, functionaland easy and enjoyable to use. The analyst/designer addresses these areasby concentrating on the user, the user’s job and the work environment.

4.6.1 The userUsers are people! They differ in height, weight, mindsets; they are quiet, noisy,motivated, prejudiced, etc. The user should not be expected to ‘fit in’ with thesystem, the system should be developed for the user, and preferably by theuser as far as the user interface is concerned.

You don’t want the situation depicted in Figure 4.9The analyst needs to find out who will use the system and what they will

use it for. The names and job titles of these users should be identified andrecorded.

Figure 4.10 shows an organisation structure for one branch of a CarServicing business. There are several such branches throughout the country.

A description of current user tasks, by job title, is shown on the followingpage. (This is only some of the job titles, not all.)

Figure 4.9 User-unfriendly system.


Job Title Tasks Comments

Branch Manager StaffingBudgetary controlTake service bookingCustomer collects carManagement reports…

Reception Controller Take service bookingCustomer collects carDaily service reportsStaff holiday controlPrepare invoice…

Service Receptionist Take service bookingCustomer collects carPrepare invoice…

Mechanic Carry out serviceRecord time and materialsHandover car…

Actual names can be added to the job titles if desired.The analyst should have acquired a detailed understanding of the users

and their capabilities within the specific area of the organisation. This hasobvious implications in end-user job design. An insight into the skills ofvarious users forms a crucial part of Screen Design since different ‘types’ ofusers have different requirements in the way in which the automated systemis presented to them (see Chapter 5).

The analyst will have collected information about people and their jobs byobservation, discussion, questionnaires and interviewing. The type ofinformation which impacts on design is:

❏ job tasks undertaken by users;❏ goals of individuals and resolution of conflicts between goals;❏ constraints on tasks such as budgets, timescales, staff;❏ performance feedback;❏ sources of help when difficulties are encountered;❏ interruptions and bottlenecks;❏ variations in workload and how these are coped with;❏ differences in work organisation across user locations;❏ flexibility and autonomy for staff organising their own work.


B. MooreBranch Manager

L.ReesAssistantManager

M.Lindsay J.BloorReception WorkshopController Supervisor

3 × Service 8 × Mechanic 3 × Driver 2 × InspectorReceptionist

Figure 4.10 A typical branch structure.

During analysis and design, it is also important for the analyst to haveclassified the users according to:

❏ level of IT capability – are users currently using personal computers forword processing, spreadsheets, electronic mail, etc?

❏ users’ expectations of the new system – high(helpful), low(hindrance). Someusers may urgently require a new system for their work and are fully infavour of it, others may not like the idea regarding it as a threat to their job;

❏ degree of dedication – regular, casual, uncontrolled. Some users will makecontinuous use of the system, others will be casual users, e.g. departmentmanagers may only need to generate reports. Uncontrolled users, such asthe general public when using a Bank Cash Terminal, will need a veryhigh level of help, they must be guided through each step of the operationand allowed to return to a previous step if they make a mistake;

❏ organisation culture and standards – there may be company standards orpractices in place for dealing with the public or customers. These must beadhered to by the designer when developing the system. For example, itmay be that when a member of the public makes an enquiry, their nameand telephone number should always be obtained. The designer will needto design a screen for that part of the system which enables the name andtelephone number to be entered clearly and easily.


Other issues which may be relevant in arriving at a detailed understandingof the users and their environment are:

❏ physical capabilities;❏ language issues;❏ knowledge needed to successfully complete a task;❏ training received (and training needed in the light of the above);❏ organisational position;❏ other systems which will be used at the same time as the new one.

4.7 Visual characteristics of the HCIInformation on a screen should be appropriate to the task, easy to read anduncluttered. If updating information about books in a Library, all book detailscan be presented to the user (see Figure 4.11), or they can locate which bookthey want and have the details presented as in Figure 4.12.

Information can be presented in text form, graphics, video, animation or acombination of these. If graphics are used they should represent what isnormally seen in the way of style and colour as in Figure 4.13.

The style, the way it is drawn, indicates a daffodil as does the colour. Wewould normally expect a daffodil to be yellow.

In the following traffic lights (Figure 4.14), the colours expected to be shownwould be red, amber and green. To use a different colour combination wouldbe unrealistic.

Colour can be used to highlight error messages or differentiate parts of ascreen. Too many colours can be confusing and in some colours text can beillegible. With full colour workstations, the designer may have a very widechoice of colours available for dialogues. The designer should howevermoderate the use of colour to a level which is effective and not confusing orovertiring for a user to look at for long periods. Colour should be usedsparingly and in as meaningful way as can be designed.

In Figure 4.15, similar items have been grouped together to improvereadability. Product details are down the left hand side of the screen, supplierdetails are shown together in the window bottom right and the Categorypull-down menu is kept away from the other information. All text is in black,important text the user needs to see is on a white background, whilst headingsmay, for example, be on a dark green background.

An important aspect of screen displays is compatability. Wherever possibleall should have the same format. This could mean the analyst needs to establisha Style Guide in which details of how screen layouts are designed are recorded.In Figure 4.16 the format of Product Details is exactly the same as in Figure4.15.


Figu

re 4

.11

All

book

det

ails

.


Book no:

Borrower no:

Issue date:

Return date:

Fines:

RETURNS

Find Book

$0.00

03/10/1996

03/10/1996

12

10

Figure 4.12 Selected book details.

Figure 4.13 Style and colour.


Figure 4.14 Traffic lights.

Figure 4.15 Example screen.


Figure 4.16 Compatibility across screen displays.

4.7.1 Attracting the users’ attentionThe designer must consider how to focus attention on information that needs tobe dealt with at a given time, such as error messages, switching tasks, etc. Usecan be made of highlighting, flashing lights, underlining, bold, buttons, etc.

Figure 4.17 shows an error message provided by MS-Access. The messagecould be more specific by referring to the format required in the field,e.g. ‘Day number > 31’. However, the message will stay on the screen untilthe user clicks on the OK button. The incorrect field could have beenhighlighted or underlined.

4.8 Ease of usePeople have difficulty in remembering more than seven items at a time. Forsystems driven by command names, this can be difficult. Some are meaningfulwithin the size of the name – say, 8 characters, e.g.

MOVECOPYFORMATSORT


Others, which are system specific, are not so easy to remember, e.g.

ISAM (Indexed sequential access method)COBHNF (COBOL on-line help)PROPENUMPROC (32-bit pointer to an EnumPropFixedProc

or EnumPropMovableProc callback function!!)

Where names are used they must be as meaningful as possible.Icons, if used, should represent the process to be carried out. The icons

across the top of Figure 4.18 contain both icon and name.

4.9 The learning curve and the evolving userAn inexperienced user will become experienced after a period of time. Novicesand experts need differing amounts of guidance. Novices need plenty ofguidance, verbose prompts, simple instructions, full error messages.Thesewill make the system easier to master. Figure 4.19 shows an excerpt from theMS-Word Help menu. Detailed help facilities are one way of providing thenovice user with guidance.

Figure 4.17 Error message style.


Figure 4.18 Representative icons.

The system dialogue should be designed to accommodate the differentusers of the system (see later in this book). Consideration should be given tohow users may customise the system and/or the user interface by, for example,redefinition of keywords/names, abbreviations or construction of system‘shells’ to hide command macros.

The user should be allowed to set default values for command parameters.For example, a nationwide parcel delivery company wants to automate asmany procedures as possible. The analyst has designed a number of screensfor entering and retrieving data. The company has some 200 depots, each ofwhich have a number of terminals connected to the mainframe at the HeadOffice by a network. At each depot every screen requires the depot name beentered. From the individual depot’s view it is a waste of time entering theirname every time they access the system. Each depot should be able to set itsname up as the default, as in Figure 4.20.

The learner should be provided with informative feedback. People shouldbe trained to use the system by using the system. Examples should be plentifuland practical.


Figure 4.20 Default values.

Delivery Details Input

Depot name:

Customer name:

Address:

Telephone no:

Parcel reference:

Manchester South

Figure 4.19 Help facilities.


Delivery Details Input

Number of Parcels/Books processed 52–––––––––––––

All correct Recheck Help

Figure 4.21 Feedback.

Figure 4.22 Activities.

4.10 System feedback to the userUsers need feedback for error control and psychological comfort. Unless theyknow what is going on, they feel uneasy and no longer in control. Let theuser know that the data entered has been received and/or that processing isproceeding. Also, signal the end of the process and its success or failure (Figure4.21).

System messages must be brief, comprehensible and meaningful. Adequatewarnings should be given before a system closes. Error reports should beimmediate if possible but should not trigger premature closure of a dialogue.


Figure 4.23 The depot manager.

4.11 IT and manual task demandsThe jobs of individuals are designed to achieve particular goals. Systemsanalysis tends to concentrate upon those tasks which will become computerbased and therefore seeks to identify recurrent and quantifiable features oftasks.

The computer system will perform certain functions but the human systemwill have to cope with everything else. If the computer system is intended tosupport and augment the activities performed by people, the functioning ofthe human system should be examined carefully.

Activities which will be left to the human ‘social’ system will be concernedwith (the examples are from the Parcel Delivery Company):

❏ abnormal, unexpected and unusual varieties of activities (Figure 4.22);❏ data that is ambiguous, uncertain or unpredictable (e.g. names and

addresses that are difficult to read);❏ the resolution of conflicts between goals and goal priorities (e.g. trading

off short and long term aims as shown in Figure 4.23);❏ goals that cannot be expressed in quantitative terms (e.g. satisfaction,

aesthetics, aspects of quality, etc. for example the Depot of the MonthAward);

❏ a need to interact with other people during the activity.

The above functions are performed by people, so it is important that thecomputer system supports them.

4.12 User job role analysisUsers’ perceptions of computerisation are frequently coloured by the way


they believe their work will be changed by the proposed development. Jobrole refers to the set of behaviours and activities which characterise a givenjob.

Individuals will often place higher order interpretations on the globalfunctions of their jobs than might be expected from an analysis of thecomponent tasks in those jobs. Thus a job function described by an analyst asa set of routine clerical procedures to facilitate paper-work may be seen bythe job holder as ‘helping the public’ or ‘assisting the sales group’. Theseinterpretations are important human factor considerations because theyindicate the value the job holder places on their work.

The information on the work role should be a major consideration in jobdesign. The impact of a computer system can then be channelled to enhanceand support important aspects of the work role rather than replace them withadditional routine activity.

4.13 Equipment and furnitureThe choice of equipment and the design of the computer workstationdetermine the level of comfort, and hence efficiency of its users. Surprisingly,however, research indicates that operators themselves have little knowledgeof the ergonomic effects of using their equipment, or the optimumarrangements for long-term use. Initially it is a management responsibility toensure that not only is a computer safe to use, but that it is installed to thecorrect ergonomic standards.

4.13.1 The screen (video display unit – VDU)Because of the length of time that computer equipment has been used, mostmanufacturers now produce new equipment which incorporates suggestionsfor improved ease of use. These include, a keyboard which is detachable fromthe screen, with an adequate palm-rest in front of the keys, and which is madeof non-reflective material. The screen should have tilt and swivel capabilities,along with contrast and brightness controls, and have a non-reflective screen.In order to minimise the potential for eye problems, the screen images shouldbe clear and easily legible, stable, and not prone to flicker or movement.

4.13.2 The deskDesks should have ample space for documents, and also sufficient depth toallow the user to move their screen to a comfortable viewing distance (atleast 750mm). Ther e must also be sufficient leg room, with desk height beingbetween 700 and 720mm. Document holders and foot-r ests should beavailable on request.


4.13.3 ChairsIn addition to complying with all relevant safety standards, all chairs used atworkstations should have adjustable seat and back-rest heights (recommendedbackrest height is 500mm above the seat) and an adjustable angle of backresttilt between 90°–120°. Chairs that are used primarily for computer work shouldhave short or no arm rests so that they can be positioned close to the desk.

4.14 The work environmentThe usability of a system can be greatly affected by the environment in whichit is used. An obvious illustration is that a particular screen layout and colourscheme might be easy to use in a dimly lit office, but is almost impossible toview on a brightly lit factory floor. HCI designers cannot control theenvironment but can consider and allow for it when designing the interface.The physical arrangement of desks in relation to lighting and windows canalso affect the comfort of staff using computers.

4.14.1 LightingUsing a computer is very visually demanding. Much eye discomfort is causedby inappropriate positioning or use of the equipment. Wherever possible,screens should be placed so that the direction of viewing is parallel to thewindows, otherwise the high contrast (glare) between the screen, the window(or its reflection) and any documents being used, will produce discomfort inthe short-term and eyestrain if continued over a longer period. The directionof viewing should also be parallel to fluorescent light fittings, again to reducethe effect of reflection on the screen. A compromise has to be accepted overlighting levels appropriate for reading screens, which is usually lower thanthe ideal for reading documents. The use of baffles and diffusers on lightfittings, and the provision of desk lamps, can go some way towards makingconditions suitable for a variety of activities. Care should be taken whenpositioning the workstation that glare sources such as windows and highlyreflective surfaces are outside the field of vision of the operator. Additionally,blinds should be fitted at windows, and shiny surfaces rendered matt.

4.14.2 Temperature and humidityBecause of the fan-based cooling systems incorporated in most computers,using even a single machine in an office can change the temperature andrelative humidity, and create uncomfortable air currents. The resulting lowhumidity can cause a build-up of static electricity on the equipment, which inturn can attract dust particles to the screen, and to the user. This is oneexplanation for the eye irritation and temporary skin rashes that users


sometimes complain of. Anti-static carpets, properly grounded, can oftenalleviate this problem. No other people in the office should be seated wherethey can be directly affected by the air currents output from VDUs.

4.14.3 Office decorationWhen siting computer equipment, or considering the redecoration of an officein which it is already being used, any potential sources of glare, reflectionand high contrast in the colour scheme should be avoided. Neutral colourssuch as beige and cream should be used, and paintwork should be matt. Whiteshould be avoided.

4.15 Health aspectsAlmost everyone involved with workstations has expressed concern over thepossibility of health hazards connected with their operation, heightened bythe sporadic newspaper coverage of the effects of radiation on operators’general health, pregnancy and eyes. The main result has been greater publicity,and more research, but the area is still subject to a great deal of conjecture andthe results are still far from conclusive.

4.15.1 RadiationWhen VDUs were first introduced, the kind of radiation thought to be emittedwas the kind normally associated with nuclear fall-out and medical X-rays.But more recent evidence shows the range to be much wider. However, whentested, the emissions from correctly operating VDUs were found to be withinthe safe levels recommended by the National Institute for Occupational Safetyand Health (NIOSH) in the USA and National Radiological Protection Board(NRPB) in the UK for all measurable types of radiation. There is still a greatdeal of controversy surrounding the effects of long term exposure to some ofthe radiation associated with VDUs, and because of this, few substantiatedrecommendations about safety exist. In practice, the risk that problems canarise from the use of VDUs is greater only when they do not operate inaccordance with their specification. However, tests on new, and used, VDU’shave indicated that the precautions taken to eliminate all known types ofradiation hazard are adequate.

There is one point to bear in mind, however; the level of individualsusceptibility to the effects varies tremendously. What for most people isharmless may cause problems for a small number. This is borne out by muchof the reported evidence, where in most cases the actual numbers involvedare small when compared with the population as a whole. Nevertheless, thisdoes not mean that these cases should be dismissed as insignificant, nor shouldany reports of effects on individuals in the local workplace be ignored.


4.15.2 EyestrainVDU users sometimes experience discomfort to their eyes from prolongedexposure to the screen. No medical evidence exists that suggests long-termdamage to the eyes can result from using VDUs, but eye fatigue among VDUusers can be caused or aggravated by the following:

❏ visual demands of the tube: staring at an object for a long period will causediscomfort if the eye muscles cannot be relaxed by looking somewhereelse. Users should be recommended to look up from their screenoccasionally and focus on something in the distance;

❏ character refresh rate: in VDUs the fluorescent phosphor coating on whichthe characters are displayed begins to break down with age, and the imageput onto the screen by the electron gun fades more quickly. The screenrefresh rate is constant however, so instead of staying bright, each characterfades from light to dark before being refreshed. Also if the refresh rate fallsbelow sixty times per second, the eye muscles that control the size of thepupil will attempt to respond. This can cause discomfort as the pupils adaptto the changes in brightness of the flickering characters on the screen.

The clearer the characters are on the screen, the easier they are to read, soscreens should be correctly adjusted, clean, and not subject to externalreflections or glare.

4.15.3 PostureWhen sitting at a VDU, it is important that the muscles in the back, neck andshoulders are not strained by the posture adopted. Fatigue in these musclesmay show itself as referred pains around the eyes, and understandably beassumed to be eyestrain.

4.15.4 Defective visionIt is estimated that up to a third of the working population have some visualdefect, which under most circumstances would go unnoticed. However,because of the more visually demanding nature of VDU work, the defectsbecome apparent, and are blamed on the VDU.

4.15.5 Screen contact timeThe risks, real or as yet unproven, associated with using VDUs can be reducedby a sensible policy of screen usage. Guidelines from the Trades UnionConference (TUC) in the UK recommend that intensive VDU work should belimited to 50% of the working day, and that breaks of 15 minutes should betaken during each hour of intensive work, and 15 minutes during each twohours of less intensive work.


4.16 Design guidelines for workstationsRecommendations concerning the correct ergonomic design for workstationsare available internationally, but most agreements over use are negotiatedbetween individual employers and their workers. Areas such as eye-testing,the use of VDUs by pregnant women, and the length and frequency of breaksthat VDU users should take are thus subject to wide variation. If resistance tothe use of workstations is encountered on health grounds, then the followingsteps need to be taken:

❏ find out if dissatisfaction over working conditions currently exists;❏ bring worker groups together to discuss and describe the nature of the

dissatisfaction;❏ if the problems are minor, take steps to get them solved;❏ find out about voluntary standards and up-to-date guidelines for using

electronic equipment safely.

4.17 SummaryInput and output procedures are the user’s link with the system and willlargely determine user acceptance or rejection of the system. Therefore, carefuldesign from both technical and human aspects will pay dividends.

On input, the designer must bear in mind the objectives that the proceduresmust be:

❏ cost-effective;❏ capable of trapping errors before they become part of the system’s

processing, and also designed to minimise the occurrence of errors;❏ acceptable and understandable to the user.

Outputs must be accurate, arrive when required and be designed to userrequirements.

Both input and output procedures must be well documented to ensureunderstanding between user and designer of what has been agreed, and toavoid ambiguity in the transmission of these requirements to the programmer.The usability is probably the primary characteristic from which all othersstem. The development of a usable system relies on planned activities of expertdesign, evaluation and corrective action.

The ergonomic aspect of workstation design is not only the responsibilityof the designers of the equipment, but also involves the management whobuy and install it, and the users themselves. Guidelines exist which cover theease-of-use, safety, and health aspects, of which everyone should be aware sothat sensible agreements between managers and users can be negotiated, andthe long-term effect of using the equipment can be monitored.


Exercises4.1 What are the designer’s objectives in designing input procedures?4.2 Inputs may be internal or external. Give three examples of each that might

be found in a company selling electronic components?4.3 The flow of input may be a problem. For example a bank receives most

transactions from customers during the lunchtime period (a two-hourtime-slot) when in fact its own staff are also at lunch, making the situationworse. How could the designer design the system to reduce the loadingon system and staff at this busy time?

4.4. What action can the designer take to reduce the amount of erroneousdata entering the system?

4.5. Outputs may be internal or external. Give three examples of each thatmight be found in a company selling electronic components.

Screen layout and dialogue design 63

5Screen layout and dialoguedesign

IntroductionFor most users of computers the main contact with the computer is throughthe screen. The range of uses to which screens are put is enormous, as is thevariety of screen-based terminals themselves and the styles of using them. Toproduce screen dialogues the designer requires knowledge about:

❏ who will use the system;❏ what it will be used for;❏ the environment in which it will be used;❏ the user’s work practices;❏ what is technically and logically feasible.

5.1 Screen usersThe designer seldom has much power to control the type of user destined tooperate the system. It is essential, therefore, that they find out as much aspossible about this inevitably changing population in order to design dialoguewhich will be practical throughout the life of the system.

The key facts which must be obtained are:

❏ type of user;❏ expected level of intelliegence;❏ level of training desirable or possible;❏ problems related to the user’s working environment;❏ user’s involvement with other systems;❏ response time required.

64 Screen layout and dialogue design

5.1.1 Types of userThere are three main categories of user as illustrated in Figure 5.1. A particularuser may fall into more than one of these classes as they interact with differentaspects of the system.

Figure 5.1 Main categories of computer users.

Casual users and novice users. Many people use systems only occasionally.They may be termed casual users whereas novice users are those not yetfamiliar with a particular screen-based system. This is a stage through whichall users of the system must pass. The problem of casual and novice users aresimilar and may be considered together.

These users generally have no prior knowledge of what is expected ofthem. Most of the time they have no preconceptions of what the computersystem is going to do either. It is essential that they are guided step-by-stepthrough their interaction with the machine and prompted for each responsein as clear a way as possible. The prompting information and any errormessages which may occur must be couched in terms familiar andcomprehensible to the user, and deal in concepts which they are concernedwith and not those of the programmer of the system. As an example, a systemshould prompt ‘ENTER STOCK QUANTITY’ rather than ‘STKQTY?’, and iftoo large a number is entered it should report ‘QUANTITY TOO LARGE –


MAXIMUM ALLOWED IS 65535’ rather than ‘INTEGER OVERFLOW’ or‘ERROR Z5’.

Although casual users do not usually have preconceptions about how asystem will behave, they may have seen something similar before andconsequently have some prior expectations. If there is a widespread idiomfor a particular type of application it should be followed as far as possible.For example, bank customer terminals usually prompt the user before eachaction (‘INSERT CARD’, ‘ENTER PERSONAL NUMBER’, and so on).However, a few require the customer to run their card through a reader, entertheir personal number, and press the select button, before giving any sort offeedback. Despite the fact that the instructions are clearly printed on theterminal, a considerable number of customers may be seen standing in frontof the terminal looking puzzled, their expectations of a banking terminal nothaving been fulfilled.

One factor which makes the design of systems for novice and casual userssomewhat easier is that such users are not too demanding on speed ofoperation. A large amount of the time spent in the dialogue is ‘thinking time’and proportionately less is computer response time. However, there shouldalways be an indication that something is happening, for instance bydisplaying the message ‘PLEASE WAIT’.

Experienced users. Experienced users are not such a clear cut category asmight first be assumed. First, all users have to learn about a system at somestage, during which they are novices. Second, in any but the simplest systemsthere are likely to be areas which a given user does not use regularly. Whenthe user does use these areas, they are a casual user of them. Even if the decisionis made, on grounds of cost or efficiency, to implement a system purelydesigned for experienced users, the varying ability and experience of the actualusers must be taken into consideration and adequate resources provided fortraining and advice.

A user familiar with a system needs little prompting information to guidethem in its use. Too much of some information may indeed be harmful,distracting the user from the data they are entering and slowing down thespeed of response of the system. However, if the user’s memory fails them orthey wish to use an unfamiliar part of the system, the guidance informationrequired should be available on request. This may be achieved either byswitching the system to a ‘verbose’ mode where the prompt information ismuch more detailed and complete, or by the provision of help screens whichmay be consulted before returning to the main dialogue.

Computer professional users. Systems analysts, programmers, and otherpeople whose job involves them with the computer other than simply as atool, may be casual, novice or experienced users of a system, and much of


what has been said about those categories applies to computer professionalsalso.

However, they do present a number of problems which do not apply tonormal application users.

In general, professional users require power and flexibility in their interfacewith the computer. They want a wide range of options to choose from andthey do not wish to be constrained by lengthy fixed dialogues from whichthey cannot escape to carry out some other activity. These requirements aremore easily met by command languages than by menu-driven, question andanswer, or form-filling styles of dialogue. However, it is easy to forget thecommands available and their syntax and therefore a large amount of on-linehelp information, which can be accessed when required, is essential. Thismay take the form of menus of commands from which the required optionmay be selected, bypassing the construction of the actual command on thisoccasion but reinforcing it in one user’s memory for future usage.

A frequent characteristic of computer professionals is their dislike of keying,they are rarely trained typists, and prefer extreme terseness of expression.Although this may be deprecated with regard to, for instance, variable namesin a program, there is no reason to insist on long command names and verbosesyntax in the case of a command language which is only going to be viewedby the computer professional. However, it is valuable if commands have somemnemonic significance and many systems allow abbreviation to the first twoor three letters of a command or to just sufficient characters to identify uniquelywhat is meant.

The development of a system using on-line tools, whether at the systemdesign, programming or testing stage, usually involves the taking of complexdecisions at the keyboard in response to information displayed on the screen.The development process may in fact be more in the nature of experimentationthan straightforward data entry with the user making frequent errors orchanges of direction and wishing to cancel something that they have just done.The ability to backtrack through previously entered commands and cancelthem if required is extremely valuable although not often very easy toimplement.

5.1.2 Level of intelligenceMisjudgement of the capability of users, when designing dialogue, has beenfound to result in hostility towards the system (with users avoiding the useof it wherever possible) and high error rates. Underestimating the user’sintelligence can lead to boredom and frustration. Although it is desirable notto over-complicate a user’s job, making it too simple or too full of promptsresults in lack of concentration especially from experienced users, andincreased error rates. Conversely, over-estimation of the user’s intelligence


and the resultant lack of prompting information and help facilities can causeconfusion and a lack of motivation to use the system properly. Such a usermay see errors in the system’s data but may be unable to understand how tocorrect these immediately and hence may just not bother.

The safest approach if the user population is likely to vary widely inintelligence is to provide a basic dialogue which is not too complex, but onthe other hand, not too full of prompts, and to provide help facilities on-linewhich are easily accessible from the main dialogue, for those who need them.

5.1.3 Level of trainingIf users are expected to use a dialogue effectively with no training whatsoever,then it must be a very simple with many prompts to lead the user passivelythrough its functions. However, having used such a dialogue several times,the same users would find it slow and tedious. A small amount of previoustraining or instruction will allow the designer to provide a less pedestrian,more effective dialogue. Two questions then arise:

❏ what level of training is cost effective?❏ what training is possible?

The first question is most important where a system is to have a dedicatedgroup of users who will, in time, become very experienced in the use of thesystem but initially will have no experience. In these cases, rather thanproviding a slick dialogue with no prompts and trying to train the users in itsoperation, it is often best to provide a simpler dialogue which can be modifiedand streamlined over the months as the users gain knowledge of the system.

The second question applies where the users are a large and widelydispersed population, varying greatly in knowledge and intelligence, suchas members of the public using banking terminals. Although in time, certainmembers of the user group will become experienced in the use of the terminalsand their dialogue, others will always remain infrequent casual users whowill have forgotten from one use of the terminal to the next just how it operates.Training for such a population is virtually impossible; even distributedliterature on the use of the terminal cannot be guaranteed to be read byeveryone. Therefore, dialogues in such cases must be as simple as possible toensure that they confuse none of their potential users.

5.2 The user’s working environment

5.2.1 InterruptionsA major problem affecting the use of a dialogue is the probability ofinterruptions during the course of the dialogue. These interruptions may befrom telephones, customers or members of the public calling in person, or


from other members of the organisation’s staff. They may be brief, or maymean that the user has to leave the terminal for fairly long periods. Ifinterruptions are likely it must be possible for the user to leave any screen atany point:

❏ without loss of the information already keyed in;❏ without the need to remember information no longer displayed;❏ without danger of leaving files locked and inaccessible to other users.

Sometimes the nature of the interruption may necessitate use of the terminalfor another function, for example, an enquiry. In this case, it should bepossible to suspend the current function temporarily in order to make theenquiry and then return to the original task without having lost anyinformation.Some interruptions may not be related to the system at all. However, if the

user is likely to be constantly talked to or harassed by other people whilstusing the terminal, dialogues must take this into account. They should besimple, unconfusing and not rely on the user to remember too much.

5.2.2 Involvement with other systemsThe same operator and terminal may be used for a variety of differentapplications, for example, the clerk responsible for stock recording may alsohave to interface with the production control system. In these situations, it isbest to strive for similarity between the dialogues of the different applicationsand avoid:

❏ annoying and unnecessary differences such as one system requiring thedate in the format 010799 and the other as 01JUL99;

❏ the same function keys being used for different purposes in each system.

5.2.3 Response timeAn important system requirement is the speed of use of the system.

This involves a number of factors including minimisation of keying, carefuldesign of the sequence in which data items are entered, and the responsetime of the system itself. It is the system response time which is the mostimportant factor. This can be defined as the elapsed time between the userpressing the last key in the input sequence and the receipt of the first characterof the response. The components and calculation of system response timewill be examined in the chapter on system performance.

Speed of response. In normal human conversation, a response of some sort(it may be of a non-verbal nature) is expected within two or three seconds. Ina human/computer dialogue a similar speed of response is usually desirable


to maintain the user’s flow of thought and to avoid the frustration of waitingfor each reply. However, the almost instantaneous response times which arepossible from some computer systems can be costly to achieve and are seldomnecessary since they are useful only in the rare cases where the user requiresno ‘thinking time’ between actions. Indeed, the user may feel stressed if theresponse is too fast.

In other applications, extremely fast responses may be wasted because otheractions could be carried out whilst awaiting a reply. An example of this is thepoint-of-sale terminal in certain retail outlets. A fast response is unnecessarywhen there are anti-theft tags to be removed from purchases, and they needto be folded and wrapped.

Consistency of response. Not all responses from a system need to be identical.For example, after completing an order entry cycle, the user will mentallypause before beginning a fresh order. The next order may have to be foundand read before entry begins. Therefore, a response of 5, or even 10, secondsmay be acceptable at this point in the dialogue. When designing systems, thedesigner can take advantage of this and perhaps do the bulk of file processingat the end of the order.

However, although different transactions may be planned to have differentresponse times, the response times for the same type of transaction shouldnot vary too much. Figure 5.2 illustrates two cases, both of which have amean response time of 2.5 seconds. The good case has a standard deviation ofresponse time of 0.5 seconds whilst the bad case has one of 3 seconds. A user

Figure 5.2 Examples of differing response times.


in the bad case will occasionally have to wait 10 seconds for a response, whichwill be very frustrating when they are accustomed to receiving a 2-secondresponse. The user will sometimes wonder if the terminal is working andmay start pressing keys, or taking more drastic physical action against theterminal. As a general rule it is a good idea to design a system so that thestandard deviation of response time is not more than half the mean responsetime.

A large system with many terminals is not usually going to be installedovernight. The first terminals on to the system may have a very rapid responsewhile the system is lightly loaded. This will be faster than the planned responseexpected when all the terminals are operating. The original users will see asteadily degrading service as the other users are changed over. This can bebad for morale and can cause problems throughout the system as people hearhow much better it used to be.

This problem can be overcome by delaying the responses, whatever thesystem load is, so the planned response time becomes the actual responsetime.

5.3 Screen designThe format and content of information displayed on the screen is veryimportant in determining the success of a user’s interaction with a system. Ifthe information is confusing or does not provide the users with what theyneed, their performance will degrade.

5.3.1 How much information should be on the screen?The information on the screen should only be what is necessary for users tocarry out their tasks. Consideration should be given to:

❏ concise wording;❏ data formats familiar to the user;❏ tabular formats with column headings;❏ not too much unnecessary detail;❏ understandable use of any abbreviations.

For example, in a library system, a screen is required to allow the librarian todeal with returned books.

The following points could be applied to the screen shown in Figure 5.3:

❏ There is no requirement for showing previous books issued and returned,only details of books not returned or those with a fine outstanding need tobe visible.

❏ Whilst reservation details may be of interest, the information is repeatedin the main column when the book is collected.


Figure 5.3 Example of Return Book screen.

Figure 5.4 An improved Return Book screen.

❏ Also, the ERD shows a Reservation entity where these details will be held.❏ The user’s normal working practice is to use an abbreviated Book Number

(i.e. no leading zeros).❏ There should be no need to enter today’s date against returned books. This

can be displayed on the screen and overwritten if required.

Figure 5.4 shows an improved Return Book screen.


5.3.2 Grouping itemsGrouping similar items in a display together improves readability and canemphasise relationships between different groups of data. This can be achievedby colour coding, borders or frames around groups of information orhighlighting using reverse video or brightness.

Figure 5.5 shows the Book Reservations screen. Upon entering a BookNumber, the member with the oldest reservation date for that book has theentry displayed in a frame. Colour could also be used to highlight the entry.

Figure 5.5 The Book Reservations screen.

Figure 5.6 An embedded, underlined message, which is separated from the mainbody of information displayed.


5.3.3 Highlighting of informationAt various points within a user’s task, their attention needs to be drawn to aparticular piece of information. This can be achieved by flashing, reverse video,underlining, making the entry bold or using colour.

Figure 5.6 shows an emboldened, underlined message which is separatedfrom the main body of information displayed.

5.3.4 Standardising screen displaysIt will be helpful to the user if all screens are laid out in the same way. AnInstallation Style Guide should be available to all designers from which anApplication Style Guide is produced for a particular project.

The following shows the type of information which could be included in astyle guide.

Installation Style Guide

User interface style MenusFormsGraphical interfaces

User guidance General Issues LayoutColourHelpAccess

ErrorsPrevention of errorsIdentifying errorsMessage control‘UNDO’ option‘RETRIEVE’ option

Prompts

System response time Perception of delayWarning messagesDelay timeRecommendations

Tailoring the user Environmentinterface Adaptability to

individual preference

Using colour displays General guidelinesHow many colours?Which colours?

(Continued overleaf)


Installation Style Guide

The display of time,date and titles

Initial displays Log-on proceduresIdentifying the systemExit from the screen

Keyboard and mouse Key assignmentsUse of mouse Possible actions

Number ofbuttons/keysMajor button functions

Menus When to use menusBasic menurequirementsMenu design Categorising menus

Rules for subdividingmenusMenu titlesNaming menus

Pop-up and pull-downmenus Use of these menus

Accessing the menusChoosing betweenthem

Dialogue boxes Selection of multipleitems within dialogueboxes‘OK’ screen button‘Cancel’ screen button

Forms & Dialogue Scopeboxes Movement within

formsField validationError messages andHelp informationCompleting the form

A standard Microsoft Windows screen has the title and screen name at thetop, a list of available actions underneath followed by the application workarea. The message area is at the bottom of the window. Figure 5.7 shows astandard Windows screen.


Figure 5.7 A standard Windows screen.

Figure 5.8 shows a possible style for the screens in the library system.

Figure 5.8 A possible style for the screens in the library system.


5.3.5 Presentation of textA mixture of upper and lower case text is easier to read than all upper case.Use upper case only to highlight words that need to attract attention.

ENTER BOOK NUMBER AGAINST BOOK RETURNEDENTER Book number against book returned

On a screen right-justified and fully justified text is often more difficult toread than left-justified text with a ragged right margin.

5.3.6 GraphicsGraphics can be used to great effect, particularly when presenting numericdata. Figure 5.9 shows a spreadsheet which holds details of expenses incurredby the library. This information could be shown as a graph, as in Figure 5.10.

Figure 5.10 Graphical representation of expense details.

Figure 5.9 Spreadsheet holding details of expenses.


Figure 5.11 Non-business icons.

Figure 5.12 Icons for business computing.

5.3.7 IconsIcons are small pictures which are commonly used to select an application.The advantage of icons compared with command names is that in many casesthey are easier to learn and remember. However, the icon must be capable ofrepresenting the underlying process. It would be difficult to understand whatthe icons in Figure 5.11 were representing! The icons in Figure 5.12, however,provide considerably more information about the activities they represent.The disk could represent saving to disk, the printer to print and the envelopefor mailing list production.

Figure 5.8 makes use of icons either to return to the main menu, enter moreissue details or bring up the Help facility.

5.4 Communication stylesA dialogue refers to the conversation between the user and the computer. Whenthe computer is first switched on, some form of menu or prompt for input isdisplayed or a graphical user interface is presented. When the user respondsfurther information may be requested or some processing may take place.Communication styles are different ways in which the user interacts with thesystem. Designing a dialogue needs to allow the user to navigate through thesystem without the dialogue getting in the way of the execution of theindividual’s job. For example, a library clerk deals with the followingfunctions:

❏ issue of books;❏ return of books;❏ reservation of books;❏ notification of reserved books available;

Within the computerised library system the clerk could handle all of thosefunctions via a set of dialogues, a possible structure for which is given inFigure 5.13.


Figure 5.13 Structure for a set of dialogues.

Figure 5.14 Dialogues with associated Names.

Figure 5.15 Example for Issue, Dialogue 01.


From the Main Menu the library clerk can choose the Issue dialogue, theReturn Menu or the Reservation dialogue. The Return Menu has a choice ofeither returning the book or processing reserved books available. For eachdialogue the different routes that can be taken need to be documented. Figures5.14 and 5.15 show an example for Issue, Dialogue 01.

5.4.1 Command languagesA command language, such as MS-DOS, requires that the user knows whatthe commands are. Names are limited to eight characters and so cannot bevery descriptive. Error messages are straight to the point!

C:\DOS> is a prompt waiting for a command to be enteredC:\DOS>format enter the ‘format’ commandRequired parameter missing error message, but no help

For the casual or novice user this is unsuitable but for the experienced user itrepresents the quickest form of communication, particularly if function keyscan be used for commands.

5.4.2 MenusA menu is a selection of options from which the user makes a choice. Theoptions can be represented in a number of ways:

❏ Textual – as in Figure 5.16.

Figure 5.16 Example of textual menu.


❏ Pull-down menus – Figure 5.17 is an example of a pull-down menu whichis activated by clicking the mouse on a word in the title bar.

❏ Pop-up menus – an example of a pop-up menu is when the user clicks onan icon or area on the screen and a list of options appears. E.g. withinWindows and whilst using Word, by holding the pointer on a worddocument and clicking the right mouse button a formatting menu pops upallowing fonts to be changed, paragraphs to be re-formatted etc.

5.4.3 Question and answer dialoguesThe user of a question and answer dialogue is guided throughout theirinteraction with the system by prompts on the screen (see Figure 5.18 for an

Figure 5.17 Example of a pull-down menu.

Figure 5.18 Question and answer dialogue.


example). Response to the prompt is by entering data via the keyboard. Thestyle is characterised by the alternation of output messages from the systemand single data item responses by the user. This dialogue style can be wellsuited to novice or casual users of a system since they can be given very fulldetails of what is required at any stage and help and error messages may beclosely tailored to the current state of affairs. More experienced users maybecome frustrated with having to wait for the computer after each entry whenthey already know what they are going to key in next.

Care is needed in designing question and answer dialogue. Careful choiceof the order in which questions are asked may allow static information to beentered first followed by a repeated sequence of questions whose responsesdiffer.

5.4.4 Form fillingWhen the same type of data has to be repeatedly entered into a screen it maybe helpful to design the screen to look like a form, as in Figure 5.19.

5.4.5 Validation rules and error messagesValidation rules must be established for each part of the dialogue that is inputby the user. Two points should be remembered when defining validation rules:

(1) to have an entry continually rejected can become extremely irritating. Ittakes time and can be frustrating, especially if the system gives noindication of how to correct the error;

Figure 5.19 On screen form filling.


(2) a system with many validity checks can give the impression of a rigorouschecking system that cannot accept invalid data.

The effects of errors can be minimised if feedback is provided as early aspossible. The aim of error messages should be to:

❏ indicate that there is an error;❏ locate the error;❏ tell the user what to do next.

Error messages should be as detailed as necessary but no more than that, i.e.they should be explanatory and informative for inexperienced users, and briefand to-the-point for experienced users. There are three main ways of achievingacceptable error messages suitable in systems used by all levels of users:

❏ short, coded error messages which can be expanded by pressing a ‘help’ or‘?’ key or icon;

❏ lengthy, helpful error messages which can be interrupted by the user oncethey have reached the degree of help required;

❏ user performance monitored by the system which then selects the level oferror messages suitable for the user in question.

Under no circumstances must the user be exposed to inexplicable errormessages from the operating system.

Once the user has been notified of an error, they must be provided with themeans of correcting it. Obviously the technique adopted will depend uponthe dialogue style. For instance, with a menu technique the menu can bedisplayed and the request for input can be repeated. With a form-fillingapproach, correction by means of the cursor may be appropriate. Do not makethe user re-input the whole screen as the result of making a single error. Itmay also be helpful in some circumstances if the validation criterion used todetect an error is shown on the same screen as the information that may haveto be changed.

Single transaction checks. Single transaction checks are those which can bemade to each transaction as it is entered. A number of examples of such checksin a stock system are given here.

Self-checking numbers which incorporate a check digit and a descriptiveprint back of the item being ordered are good checks. Range checks can beperformed on parts and customers. Very high value or large items willprobably never be ordered 15,000 at a time and the system can be designed toquestion an entry which seems unlikely; a particular customer can probablybe relied upon never to order above a particular quantity, or a particular value,of any item. Range checks will not trap all quantity keying errors but areusually employed on the basis that they are better than nothing. Logic checks


can link incoming transactions to previous ones and check for invalidsequences of transactions or any other internal contradictions.

Group transaction checks. Some error checks may be applicable to a group oftransactions. For example, in systems which reflect the handling of cash, itmay be useful for the user to be able to request an interim cash balance atintervals, to be checked against cash in the till. Where an operator is involvedin a complex dialogue, for example, the entry of a very long customer order,it may be useful to allow them to see a summary of what been has entered sofar to ensure that no omissions have been made.

File inspection. The checks described should be backed up by regular,probably off-line, checking of files so that any errors which do slip throughthe validation net may be noticed and corrected.

Psychological considerations. Error checks are essential, but it may be possibleto reduce the number of errors by taking elementary precautions in the designof the dialogue. In particular, input sequences which entail awkward use ofthe keyboard should be avoided. For example, consecutive entries involvingthe simultaneous use of a control key and a character (e.g. SHIFT KEY + A,CONTROL KEY + S) can be error prone. Also, it is useful to make certain far-reaching operations like ‘clear screen’ a two-handed, two-key process so thatthey are less likely to be entered by accident.

Error correction. Error messages, like prompt information, may be quite terse.An experienced user will probably be familiar with the errors which oftenoccur and even a mere error code may be sufficient provided that it identifiesthe error exactly. ‘Catch all’ error messages like ‘INVALID DATA’ or ‘SYSTEMERROR’ are not sufficient. If the user does not understand an error messageit is helpful to have an on-line explanation of it available, rather than to haveto resort to a user manual. It is important that the dialogue should allow forimmediate error correction. There is nothing more frustrating than knowingthat an error has been made and not being able to correct it.

To ensure the effectiveness of the dialogue structure in maintaining theaccuracy of on-line systems the following points should be kept in mind:

❏ the psychological considerations in dialogue design should be aimed atminimising the probability of human errors;

❏ the dialogue should be designed to trap as many errors as possibleimmediately;

❏ the dialogue should facilitate the immediate correction of errors;❏ the on-line system should be backed up by subsequent file inspections and

balancing routines if applicable;❏ self checking operations should be built into the dialogue;❏ procedures must be worked out for periods of system failure and recovery.


5.4.6 Failures and recoveryInevitably there will be times when system failure causes terminals to becomeinoperable. Procedures must be designed for such eventualities and forrecovery from these situations, and these procedures must be clearly and fullydocumented for users.

In the event of failure, users must be left in no doubt about:

❏ what action they are expected to take regarding the failure;❏ how long the failure is likely to last;❏ what action they need to take to return to the status quo when the system

becomes available again.

Failures can be a major cause of errors in a system. For example, orders whichwere half entered when the failure occurred may be completed with omissionsafter recovery, if the user is unsure of the point at which the system failed.Procedures must be designed to keep the user fully informed about the failure,and the point up to which work has been accepted.

5.5 SummaryThe important thing to remember when designing dialogues and handlingscreens is that hardware, users and dialogue must all be considered together.The designer may or may not be able to influence the first two. If not, it isimportant to ensure that the dialogue is of a style which suits the hardwareand is sufficiently flexible to accommodate the range of users likely to beencountered. The more the end user can be involved with the developmentand design of dialogues, the better the chance of success.

Exercises5.1 Make brief notes on the impact of each of the following on the design of

the new system:❏ type of user;❏ level of intelligence;❏ level of training desirable or possible;❏ problems related to the user’s working environment;❏ user’s involvement with other systems;❏ response time required.

5.2 Design a screen for the entry of an application to join a Health Club (orsimilar) to be used by members of the public over the Internet. Oncompletion, hand your screen design to a colleague and watch, withoutprompting, their reactions to the design. Make notes of improvementsyou could make.

Forms design 85

6Forms design

IntroductionA form is any surface on which information is to be entered, the nature of theinformation being dependent on what is already on that surface. The surfacecould be paper, a wall board, a piece of plastic, or the front of a cathode raytube.

In some instances the surface may be wiped clean and used again. With acomputer screen, not only the information but also the format can be made todisappear, to be replaced by other formats as required.

Paper is probably the most widely used medium for communicationbetween computer and user because it is versatile, cheap and relativelypermanent. However, for rapid transfer of information which does not needto be on a hard copy, the cathode ray computer screen is most common,together with similar screens such as liquid crystal displays (LCD) and ThinFilm Transistor (TFT). Where large volumes of static information need to bestored, microfilm or microfiche is often used.

Many of the principles which apply to the design of paper documents forthe collection, transmission and storage of information apply equally to thedesign of layouts for screens. The purpose of both is to receive or conveyinformation quickly and completely. If correctly designed, with the type ofuser in mind, the required information can be entered to allow interpretationby the intended recipients with the least time, trouble and possibility ofmisunderstanding or error.

A form must serve the objectives of the organisation which provides it.The specification must therefore include the purpose and the cost. A good

86 Forms design

form is one which allows the required information to be obtained, transmitted,interpreted, filed and retrieved at minimum total cost. Remember that thereal cost of a form is not just its purchase price; it includes all the work that isdone to and from that form during its life. A form that costs a penny initiallymay cost several pounds before its final disposal.

Another factor which must be considered in the design of forms is goodwill.The element of goodwill must be considered whether the form is used entirelywithin the organisation or whether it starts or ends its life outside theorganisation. It is important to make a form as aesthetically pleasing aspossible. If the person completing a form is annoyed by it, then the informationgathered will tend to be incomplete or inaccurate; equally if it is annoying tolater handlers or interpreters, the probability will increase of it being missorted,misfiled, or misinterpreted. This is one good reason for consulting usersfrequently during the design of the form; if users have helped to design aform they are far more likely to accept it.

Forms design is often considered to be a low-level activity to be delegatedto a typist or clerk. The defects in many forms can be attributed to this attitude.In fact, designing forms is a highly demanding activity.

A good form does not occur by chance, it requires complete fact finding,careful design and rigorous testing. The designer of a form is often responsiblefor every aspect of it, from determining the purpose, content and layout tochecking the final version from the printer or on the screen. The forms designershould not pass on untidy drafts to a typist, without very clear instructions.If a draft would not be clear to the printer, then it will not be clear to thetypist. The result may reflect, not the designer ’s intention, but theinterpretation of such by the typist.

Good forms design is not possible without good system design. What ison the form cannot be considered in isolation from the purpose of the formand the contribution it is to make to the objectives of the organisation. Theoccasion for forms design may arise as part of a system study, or a request fora new form may lead to a study of the system.

The stages of form design follow the stages of a project. There must be:

❏ a definition of the objectives;❏ comparison of present results with required objectives;❏ specification of information requirement;❏ design of layout;❏ testing;❏ education and training of user management and staff;❏ implementation.

User involvement is very important at each stage.This chapter is concerned primarily with the detailed design consider-

ations, but the importance of the other stages must be kept in mind.

Forms design 87

Before starting to design a form, the systems analyst should be satisfiedthat the form serves one or several specific purposes which contribute to theobjectives of the organisation. The analyst should ensure that there is no otherform, either existing or proposed, which serves or can be made to serve thesepurposes. Finally, they should check that it cannot be combined with anyother existing or proposed forms to serve the combined purposes with greateraccuracy or at lower cost.

The forms designer has a number of decisions to make for each form. Someof these must be by agreement with the various users; others must be decidedby the designer in consultation with equipment manufacturers or printers.Most of the decisions will be interdependent, calling for the designer’sjudgement.

The main considerations are:

❏ content;❏ layout;❏ make-up;❏ printing;❏ paper.

The first two considerations are common to all formats (on paper or screen),the last three are specific to formats on paper.

6.1 ContentThe content of the form involves all words, spaces, boxes, etc. that are toappear on the blank form. These are the title of the form, detailed entryheadings, instructions for its use and any pre-printed options.

6.1.1 TitleThe title should be brief and meaningful to the users, and normally the lastword should be a noun, but not the word ‘form’. There are several alternativessuch as note, advice, list, report, record, analysis, application, notification,instruction, specification. If a form has a long title such as ‘Advice of Goodsready for Inspection and Despatch’, it is not surprising to find userssubstituting a shorter named. If the particular form is pink in colour, then itmight be called ‘The Pink’, which of course would cause confusion with anyother pink forms used by the organisation. Care should be taken to design ashort meaningful title which does not encourage users to invent their ownlocal term for it. Most paper forms include a stationery reference number tobe used for ordering supplies, but it is better if users recognise the form bysome title rather than just a stationery reference.

88 Forms design

6.1.2 Detailed entry headingsThese are headings to guide the user as to the correct information to enter ineach space. The words used depend on the background of typical users of theform, their level of intelligence and literacy and whether the form is part oftheir normal job.

A literate adult speaker of English, of normal intelligence, when confrontedwith:

Surname

will write his or her surname. A semi-literate or a child might be totallyconfused, or write ‘Yes’.

If phrased as a question:

What is your surname?

there is a good chance that the person’s surname will be entered, but notnecessarily in that space. For such a person:

Write your surname in this space

is likely to produce the required result; but this may still not be good enoughif the form is to be used as a computer-keying document. A possible answerto this could be:

Please write your surname in the space below, starting in the left most square andputting one letter in each square until you have finished.

Where the medium is paper, the same instructions have to be used for eachuser, and brevity is important to save space. Where space can be reused, as ona screen, the words of instruction can be varied to suit the knowledge andexperience of different classes of user.

Headings should always be as brief as possible, but meaning should notbe sacrificed for the sake of brevity. The typical user’s needs should be bornein mind, including both originators and subsequent interpreters of theinformation, and headings should always be tried out with the users beforebeing included in the eventual form. Special care should be taken withheadings on a multi-purpose form.

6.1.3 Instructions for completionIdeally, item headings will be self-explanatory and, if separate instructionsare required, great care should be taken to keep them clear and crisp (e.g.repeated ‘if’ clauses should be avoided). Where possible, instructions shouldbe seen at the same time as the heading or question (i.e. not on the back of aprinted form). It is annoying to have to search for instructions. Figure 6.1shows an example of detailed entry headings.

Forms design 89

Figure 6.1 Example of detailed entry headings.

Where an instruction is critical, such as ‘USE CAPITAL LETTERS’, it shouldbe seen before the person fills in the entry and not following the entry or atthe foot of the page. Where instructions are numerous and detailed, theyshould be numbered in relation to the headings or questions.

The designer should try to avoid using separate instructions. However,where they are necessary, they should be tried out on users in advance.

6.1.4 Pre-printed optionsWhere there is a limited and known set of possible replies, completion andinterpretation can be speeded up and ambiguity avoided by multiple choicequestions asking for marks in one of a number of positions.

As well as check boxes on a screen, this applies to hand-held instruments,such as a pen, pencil or light pen. Where only two replies are possible, onpaper it is best for one to be deleted. Where more than two replies are possible,a positive indication is better, and boxes (up to a maximum of ten) can beoffered for the user to tick. The boxes to be ticked must be placed close to theanswers to which they refer. Figure 6.2 shows the use of such boxes. The lastexample in the figure is a bad one because of the layout; a tick in all but theright-hand box may be misinterpreted.

This method is particularly useful for questionnaires, where a free-formreply would give a problem of interpretation before analysis. This does notdispose of the problem of interpretation, however, it transfers the problem tothe person completing the form. The responsibility of ensuring that the wordsused have the same meaning for all possible originators is imposed on thedesigner and care needs to be taken that:

90 Forms design

Figure 6.2 Use of tick boxes for multiple choice questions.

❏ the options are mutually exclusive;❏ they cover all normal answers.

If there can be other possible answers, a space should be given for a free-formreply. It is important also to ensure that within any form there is a consistentapproach to positive and negative replies.

If printed forms are to be used as input to the computer, each box may needto be marked with a code (for instance, a column number). Any such codeshould be made as unobtrusive as possible to the person completing the form.

6.2 LayoutHaving determined the content of the form, the next stage is to design anappropriate layout.

6.2.1 Direction of printBefore planning any detail of the layout, it is necessary to decide whether tolay out the form vertically or horizontally (portrait or landscape, respectively).

Factors to be considered are:

❏ amount of data;❏ environment of the originator;❏ equipment used;❏ mailing;❏ filing.

It is usually easier to handle and file paper with the long side vertical, and itis probably convenient to regard this as the standard. Exceptions are such

Forms design 91

things as ledger cards, designed to be filed horizontally, and forms whichrequire a number of columns or are particularly wide.

If the form is to be mailed using a window envelope, the size and shape ofenvelope will dictate the position of the address panel and therefore to someextent, the layout of the remainder of the form.

If the form is to be printed by a laser printer, a blank border of 6 mm mustbe included to take account of the area of the paper that is ‘outside the printablearea’.

6.2.2 Title and referenceIf the printed form is to be filed, any filing reference should be in a prominentposition.

Thus, if the filing reference on an invoice is the invoice number, it shouldbe prominent and would normally appear at the top right of the form, unlessthe system in which it was filed required otherwise. Some methods of filingactually require the reference to appear at the bottom of the form, so thedesigner should check how the user intends to file the form.

6.2.3 Entry headingsAs indicated above, it is important that printed words and headings are close toor within the space to which they refer. A common fault is to allow so muchspace for the heading that it is not clear whether the entry is to go in the samespace as the heading or in a space alongside or beneath it. If the heading is withinthe box, it should be placed as far as possible into the top left-hand corner.

Figure 6.3 shows some good and bad layouts. In example (a) it is not clearwhether name should be entered immediately next to the word ‘Name’ or to

Figure 6.3 Examples of good and bad layouts.

92 Forms design

Figure 6.4 Groupings improve readability.

Figure 6.5 Poor example of the use of space and layout.

Forms design 93

Figure 6.6 Use of space in column headings.

the right of the vertical line. Similarly, with example (b) the entry for namecould be made in the same box or the box below. Examples (c) and (d) showbetter ways of designing boxes for these entries.

For ease of understanding, related entries should be placed together andclassified. This can reduce the amount of space taken up as well as improvingunderstanding.

In Figure 6.4, the groupings shown improve readability on the screen. Thetop example in Figure 6.5 is space consuming and the grouping does notmake clear the changeover from details of the gearwheel to those of the chain.The bottom example is confusing and much space is wasted.

The amount of space allowed for the entry should be determined by thenumber of characters in the entry, not by the number of characters in theheading. This applies particularly to column headings (see Figure 6.6). Thesame principle holds good for tabulation produced as computer print out.

6.2.4 Entry sequenceThe usual sequence of entry should follow the usual reading sequence, thatis from left to right and then from top to bottom (unless of course it is inChinese or a language that reads from right to left). The most frequently usedentries within a group should be at the start of the group. This avoids theperson entering the information having to skip over irrelevant boxes.

However, it is not uncommon for the ideal sequence for the originator tobe different from the ideal sequence for an interpreter, or even for differentinterpreters to require different sequences.

Where a compromise is necessary, particularly with a computer inputdocument, account should be taken of the effect of entry sequence on:

94 Forms design

❏ time and accuracy of the originator;❏ time and accuracy of the person inputting the data;❏ computer time.

The originator should not necessarily be expected to arrange data in the orderin which it will be used by the computer; rearranging data is one job thatcomputers do extremely well.

However, if data is to be input via a screen, it is less frustrating for thescreen user if data occurs in the correct order for input, and less transcriptionerrors are likely to occur.

6.2.5 Size and shape of entry spacesA form giving a satisfactory overall appearance is likely to be a series ofcompromises, but an ideal size and shape should be decided on for each entrybefore any compromises begin.

On screens, the size of entry spaces must be the same as the size of the datafield so that the maximum amount of data may be entered. However, thisdoes not mean that the space taken up on the screen must be this size, as inmost modern systems the entry area will scroll across, allowing the maximumnumber of characters to be entered whilst only part of the data is visible.

On printed forms, the space allowed should be more than that required forthe average entry, but for some exceptional entries it may be necessary to usea ‘notes’ space, the reverse of the form or an attached sheet.

The kind of data will determine the shape. If the entry is to be in words thehorizontal dimension must be greater than the vertical dimensions, or if itconsists of several sets of figures, then the vertical dimension should be thegreater.

On a printed form, if writing space is limited, the use of pre-printed optionsmay improve matters.

6.3 Make-upThe term ‘make-up’ is used to denote all the physical features of a printedform apart from the printing and the paper. It includes:

❏ the joining together of forms as sets, in pads or as continuous stationery;❏ the provision by the printer of interleaved carbons or of any chemical

coating for making copies;❏ any punching or perforating required.

When printing forms on a lineprinter, continuous stationery is required,whereas laser printers use sheets of stationery of fixed size. Lineprinters allowthe use of multiple-part carbon paper whereas a laser or ink-jet does not.

Forms design 95

If a form is to be completed by hand, the number of parts in the set shouldnot normally be more than three or four, otherwise the lower copies will beillegible. Some thought also needs to be given to the environment. It is nogood having a flimsy multi-part set if it is to be completed by an outdoorworker. Where any kind of data input is to take place, it should be done fromthe top layer of the set, to minimise the possibility of error.

It may be useful to have printed forms perforated so that, for example, ifdifferent areas are relevant to different departments the form can be easilysplit. It is possible to have the paper heavily or lightly perforated and thechoice will depend on the amount of handling the form will receive before itis split. Heavy perforation will separate if handled too much and may resultin areas of information being lost.

6.4 PrintingExternal printers should not be expected to guess at requirements; preciseinstructions need to be given, especially on critical dimensions, to enable thedesign to be realised. The printer should produce proofs to allow the designerto approve the finished product before a large quantity is run off.

6.4.1 Single- or double-sided printingThe question of whether to print a form on both sides assumes that the amountof information required needs more than one side of the paper; there is nomerit in spreading over two sides if one side is sufficient. Multi-sheet formsshould be avoided if at all possible, since they cause additional problems instoring, requisitioning, feeding into any originating equipment, sorting,mailing, typing and retrieving. However, there are problems caused by double-sided forms, where immediate copies are required.

6.4.2 Serial numberingThe price of printing a form is only marginally increased by serial numbering,however, there is no reason for specifying serial numbering on every form. Itadds to the problem of storing and issuing forms, since, to satisfy the purposeof serial numbering, there is normally a requirement to use the lower serialnumbers first.

The advantage that serial numbering provides is security, particularly withdocuments such as cheques or invoices, which could be used as part of a fraud.

6.4.3 Use of linesThe essential purpose of lines on forms is to separate one area from another.On aesthetic grounds, the use of many different line thicknesses should be

96 Forms design

avoided; two thicknesses are usually adequate. A thick line can be useful toseparate different groups of items, or to make individual items stand out, forinstance, where selected items are to be keyed. Where related entries are to bemade by hand, in a number of columns, faint vertical guidelines are desirable,particularly from the point of view of later interpretation of the entries. Forscreen based forms this is not necessary, vertical lines are a nuisance to thetypist, and there is no problem for the eye of the reader to follow a line of typeacross a screen.

6.4.4 Type facesThe number of different type faces should also be kept to a minimum. Amixture of upper and lower case is preferable to all capitals, being easier toread. It is best to preserve capitals for use as headings for grouped items.

6.4.5 Type sizesSizes of type face are expressed in ‘points’, a point being 1/72 of an inchvertically. This is not the size of the letter itself, but the distance betweenrows. Figure 6.7 shows the point sizes most commonly available. The sizeselected must obviously depend on the space available, but other criteria arethe age of the typical user (since eyesight deteriorates with age) and thelighting conditions in which the form will be used.

6.4.6 ColourOn screens, colour should be used sparingly and selected carefully. It is bestto use two strongly contrasting colours (one for the text, one the background)and possibly shading to separate different areas of the screen. A differentcolour may be used for important messages, to draw the user’s attention.

It may be useful for different copies of a printed form to be either of differentcoloured paper or printed with different coloured inks. If there is no need forcolour to aid recognition, it is probably best to keep to black ink on whitepaper. This avoids problems of matching different paper and ink stocks, andso minimises re-ordering problems, as well as cost.

If a form is to be completed in black ink, the entries will stand out better ifthe pre-printed part is in a different colour, green being the colourrecommended for best legibility. If a colour other than black is used it shouldalways be on white paper to avoid the different types of colour blindness.

Internal or external printing. Most forms may be printed internally on laserprinters. It is usually uneconomic to use internal facilities for printing complexforms, particularly multi-part forms, for which specialist printers are properlyequipped.

Forms design 97

Figure 6.7 Point sizes most commonly available.

6.4.7 Order quantityThe quantity of printed forms to order depends on rate of usage, expectedrate of modification, shelf life and cost of storage.

Buying stationery in small quantities from a commercial printer isexpensive. There is a practical limit to the quantity which should be ordered

98 Forms design

at any one time, since storage space can be a problem. Also, some paper has alimited shelf life. It deteriorates when stored for long periods. For example,paper can ‘warp’ and change shape slightly due to humidity or dryness ofstorage and even a slight alteration can be critical for continuous stationeryfor use in fast computer printers.

6.5 PaperIt is not enough to get the form design right; the right design with the wrongpaper may make the system unworkable. In addition to paper colour,mentioned above, decisions need to be made about size, weight andconstruction.

6.5.1 SizeThe minimum size of a form is determined by the sum of the spaces requiredfor the individual entries, and the specification of the printer used.

The normal sizes are based on the ‘A’ series of the International StandardsOrganisation (ISO). The most common size is A4, which measures 210 × 297mm, A5 is half this size (148 × 210 mm) and so on through A6, A7, etc. A3 istwice A4 (297 × 420 mm).

Unless there is a good reason for doing otherwise, it is best to opt for one ofthe standard sizes. There is unlikely to be any saving in cost from specifyinga size smaller than one of these standards.

Continuous stationery depths are determined by the distance apart of thesprocket holes and occur in multiples of this distance. It is also important tocheck that ancillary equipment used for decollating, bursting or guillotiningcontinuous stationery can cope with the width and length of the proposedform. If the documents are to be folded or inserted into envelopes mechanicallythen the limitations of these machines must also be considered.

6.5.2 WeightPaper is measured in grams per square metre (gsm). The most commonweights are:

❏ 49 gsm – normally used for typing copy paper and suitable for most internalsingle-sided forms;

❏ 61 gsm – used for normal letterheads and suitable for most internal single-sided forms not subject to long-term repeated handling;

❏ 73 gsm – suitable for any double-sided printing and repeated handling;❏ 80 gsm – standard photocopier paper which will take double-sided;❏ 96 gsm – standard for use with high speed optical reading devices;❏ 120 gsm – a heavy paper for letterheads.

Forms design 99

The circumstances in which the form will be used (e.g. outdoors) must beconsidered.

6.6 SummaryThe main guidelines for the designer are to:

❏ try out the form with users, first in draft and then again when a prototypeor proof copy is available;

❏ be certain of the form’s accuracy and practicality before implementing it.

Forms design is a highly demanding activity which is often the province of aspecialist. It is concerned with ensuring that information is collected,transmitted, interpreted, stored and retrieved with accuracy, clarity, ease andspeed. The user’s contact with the computer system is often via forms and itis crucial that the forms do not impede that contact. The design of forms mustbe done in the context of the system as a whole and must take into accountseveral interrelated factors. First of all, the content must be determined in thelight of the system requirements; an appropriate layout for the content mustbe designed mirroring the sequence in which the data is received; the physicalimplementation of the form must be defined; precise instructions for printingmay be required; and finally, decisions have to be made about the size, weightand construction of the paper. The average medium-sized company isreckoned to use about 3000 different forms. Each of these is in itself expensiveto design, produce and store; and yet the cost of using a form has beenestimated at 20 times its cost of production. Clearly, forms design is of crucialimportance to system effectiveness and efficiency.

Exercises6.1 What are the stages of form design?6.2 Name three common media and two very unusual media for a form.6.3 Design a form for use as a turnaround document. A typical example of

this would be a computer produced picking list for use in a warehouse.The warehouse operative uses the form to identify goods to be pickedoff the shelves, and notes on the form the quantity picked. The form isthen used to re-key the quantity supplied for each order. On completion,hand your form design to a colleague and ask them to ‘role-play’ thewarehouse operative’s actions. Watch, without prompting, their reactionsto the design. Make notes of improvements you could make.

6.4 Comment on the appropriate ‘make-up’ of the turn-around documentdesigned in 3. above.

100 Forms design

File design 101

7File design

IntroductionOnce the logical model of the proposed system has been agreed with theuser, detailed physical design of the system can be undertaken. As mentionedin an earlier chapter, there are two aspects to the design process:

❏ process design❏ file design.

Here we will concentrate on file design, leaving the discussion of processdesign to later in the book. However, the two aspects of the design would notnormally be done separately as they are highly inter-dependent. Processdesign incorporates program module design which is influenced by the fileswhich need to be accessed. Process design also encompasses the human/computer interfaces. The speed of access required at these interfaces is a majorinfluence on file design. It is purely for simplicity of explanation that the twoare separated here.

The vast majority of systems have a requirement to store data at variousstages. The way in which this data is stored, and the means provided for itssubsequent retrieval, have a dramatic effect on the speed with which it can beaccessed. If the proposed system is a computer system where very fastresponses are required on-line, data storage methods are especially critical.Input and output operations to and from files are, in computer terms,exceedingly slow operations. To illustrate this, consider the ratio of instructionprocessing speed to file access speed. Since it is comparatively difficult tothink in terms of nanoseconds (10–9) or milliseconds(10–6), the times have beenscaled up to a level which is easier to visualise. If a computer takes one minute

102 File design

to process an instruction, a file access would take about a year. It is thereforenecessary to consider very carefully the file accesses needed within a system.If fast responses are required at the human/computer interface, the numberof file accesses must be kept to a minimum, and data in files must be organisedin a way which allows it to be retrieved quickly.

Some systems may require very few files and those which are needed mayeach be accessed by only one key-field, the primary key by which the file issequenced. The files may be completely independent of each other. In a casesuch as this, the files are simple files because of their independence and singleunique keys. However, it is more often the case that files within a system areinterrelated to avoid duplication of data items, and to form a common poolof data accessible to many users through many keys. This is the databasesituation as the term will be used here. It does not imply a particular structureof files or data items, and need not imply the use of a software package fordata management. The objective here is to set out guidelines to assist in thetransition from a logical description of the files and their data to a physicaldefinition, either in terms of simple files or a database structure, and to give asummary of the factors involved.

The topics covered in this chapter are as follows:

❏ data and logical files;❏ file access requirements;❏ types of file;❏ file design considerations;❏ design evaluation and modification;❏ database design considerations.

7.1 Data and logical filesThe first stage in file design is to determine what data needs to be stored, andwhich data elements belong together, i.e. what logical files are required.

This information is usually be available in the following documents:

❏ Data Flow Diagrams (DFDs), which show all of the places whereinformation flows to and from data stores (files);

❏ the Data Dictionary (DD) and Data Analysis (DA), which fully define thecontent of data flows named on the DFDs, and define data elements andthe data stores to which they logically belong;

❏ Access Path (Access Profile) Diagrams, which define logical groups of data(entities), their keys, and the data-access paths between them.

7.1.1 Data Flow DiagramsThe DFD provides two important pieces of information which the designerneeds:

File design 103

❏ The first is the places (i.e. processes) which access a given set of data;❏ the second the contents of that data set.

Working down from the top level DFD, a data store symbol appears the firsttime a data store is used by more than one process in the diagram. Havingestablished this point, the designer can then decide whether the processesshould be combined into logical program modules or the logical file shouldbe accessed separately by each process. These considerations will be dealtwith more fully in the chapter on procedure and program specification.

The content of the data flow is specified on the DFD and can be comparedto the normalised data structure. In most cases, the normalised structurecontains considerably more data elements than are required for a givenprocess. Consider, for example, a stock issuing system. To allocate stock to anorder, all that is required is stock number and quantity available. However, thefull Third Normal Form (TNF) data structure might be as shown in Figure7.1.

In this instance, the designer has the option of splitting the logical file intoparts, each of which may satisfy a different process. This option is looked atagain under design evaluation.

7.1.2 Data DictionariesThe DD contains the full definitions of all data in the system. From it thedesigner is able to establish the structures present in the data, and also thephysical size of each data element.

This information is required to enable the designer to build up the filestructure and organisation, to determine space requirements and hence theproblems, if any, in achieving the required access speeds.

7.1.3 Access Path (Access Profile) DiagramsThese again are essential in the design of files structures and the determinationof access methods. The method of construction was covered in the book in

Figure 7.1 TNF structure for stock items.

104 File design

the series, Business Systems Analysis, and the implications are discussed in thefollowing section, File access requirements.

When fully developed, an Access Path (Access Profile) contains not onlythe accesses required but also the access key and frequency of each access, allof which help the designer to select the most appropriate access method.

7.2 File access requirementsThe choice of physical file organisation and the physical arrangement of datawithin records, files, etc., is largely determined by the way in which data willsubsequently need to be retrieved for processing or output. If the user requiresfast on-line responses, then the efficiency of data accesses involved in the on-line processes must be the first consideration.

Two types of access requirements can be identified:

❏ operational;❏ informational.

Operational. These are the accesses needed for routine processing. Of these,we need to know the average volume over a particular timescale; any peaksand troughs (when they occur and the degree of fluctuation); and the responsetime required for each process.

Informational. These accesses represent user enquiries on data stores. Forthem, it is necessary not only to know the expected volume and frequency ofeach enquiry type, but also their relative importance to the user, as it may bethat the most frequently used enquiry is not the most valuable to the user’sbusiness.

If the main processing of a system is to be on-line in an environment whereresponses must be rapid, the most cost-effective approach is to concentrateinitially on the operational requirements. These represent the main throughputof the system and require the larger proportion of file accesses. Then, havingprovisionally designed file or database structures to accommodate operationalrequirements, ways of satisfying the informational requirements should beconsidered. It may be that speed of response has to be sacrificed on certainenquiries, or even that some of the enquiries, where immediate access wasnot very important to the user, may have to be answered overnight by batchprocessing. However, this approach enables the designer to make the mostfrequently used accesses run efficiently (see Figure 7.2).

The designer must have answers to the following questions:

❏ by which keys will the files be accessed?❏ what accesses are needed between files?❏ how frequently will these accesses occur?❏ what speed of response does the user require?

File design 105

The first two answers are available directly from the Access Path (AccessProfile)s, and the fourth will probably be part of miniature specificationssupporting the functions shown on DFDs. The third, however, must becalculated by the designer as follows:

(1) look at the logical groups of data (logical files) defined on the accesspaths (Access Profile);

(2) identify from DFDs the functions using these logical data groups;(3) for each logical data group, record the data accesses made by the various

functions;(4) consult the DD for information about volumes, activity, etc.;(5) calculate the number of accesses by each key to each logical data group.

The final point requires knowledge of how the system will perform its variousfunctions. However, the designer should be able to make a reasonable estimate,which is sufficient at this stage.

The use which the designer makes of this information is described in thesection called File design considerations.

7.3 Types of fileThere are five broad categories of data files used in any information system:

❏ master;❏ transaction;❏ work;❏ security;❏ audit.

The designer will certainly have to design the first two types. Depending on

Figure 7.2 Physical data organisation.

106 File design

the system, the software being used, and partially on definitions, they may ormay not have to design the other three types.

7.3.1 Master fileA master file is a file which is permanent in the sense that it is never, apartfrom the time of its creation, empty. The normal means of updating a masterfile is by adding, deleting or amending records. Master files can be furtherdivided into two types of file:

❏ Static master files (or reference files). The business entities held are of apermanent or semi-permanent nature (e.g. products, suppliers, customers,employees, etc.);

❏ Dynamic master files. The business entities held are of transitory importanceto the business (e.g. customer orders, work orders, job tickets, projects,etc.).

7.3.2 Transaction fileTransaction files record data relating to business events prior to a furtherstage of processing, This further processing may be use of the transactiondata to update master files, or the archiving of the transaction for auditpurposes. After the transaction file is processed, it is usually re-initialised,and further transactions are then recorded in it. Examples of transaction filesare:

❏ customer orders for products (to update an order file);❏ details of price changes for products (to update a product file);❏ details of cash postings to customer accounts (to be held for audit purposes).

7.3.3 Work fileA work file is any other file required to enable the processing of business data(excluding files required for security and audit purposes). The designer mayor may not be involved in the design of such files. Examples where the designeris not involved are:

❏ work files used by system software or utilities such as sort/merge processes;❏ work files used as intermediate or inter-process files in computer programs

at a low level. The design of these would be better left to the programmingteam.

If a file is needed to store data created by one business process, before beingused by another business process, then the designer would have to beinvolved. (These files are sometimes referred to as transfer files).

File design 107

Temporary files which hold information for printing also fall into thiscategory. The designer has to specify the record definitions required to producethe correctly formatted output.

7.3.4 Security fileThese files are taken in order to provide backup copies in case of loss or damageto current versions. The techniques of file security are discussed in a laterchapter.

In practice, the designer is unlikely to be involved in the detailed design ofsuch files, as they could rely on system security software (e.g. dump/restoreutilities; transaction logging and recovery routines) or, in batch updatesystems, in holding superceded versions of master files with back copies oftransaction files.

7.3.5 Audit fileAudit files are a particular type of transaction file. They play the same role incomputerised information systems as the postings in a traditional manualledger. They enable the auditor to check the correct functioning of thecomputer procedures by storing copies of all transactions which causepermanent system files to be altered. For example in a sales ledger system,transactions recorded might be:

❏ invoice number, date, cash amount for each invoice raised;❏ date and amount of cash received;❏ credit note number, date, amount of money credited;❏ account adjustment, amount of money, authorisation, adjustment code.

Audit files are usually serial, records being created at the time of the masterfile update, in the sequence of the update.

7.4 File design considerationsThe designer’s aim is to transform the logical model of files and theirrelationships into an efficient and workable physical structure. The physicalstructure arrived at may differ considerably from the logical structure on theAccess Path. The logical model will have emanated from a process such asnormalisation, which will have removed redundancy of data. The physicalinterpretation of this usually reintroduces a certain amount of redundancy,but in a controlled way. This may be limited to pointers between files orbetween the data items themselves; it may take the form of processingredundancy, for example extensive searching. To allow multiple access pathsinto any one file, there must inevitably be redundancy of some sort.

108 File design

7.4.1 Factors to be consideredThe process of file design is complicated and involves juggling with a largenumber of parameters in an attempt to achieve an economic and workablesolution (Figure 7.3).

Some of these parameters are considered in the following paragraphs.

Purpose of the file. What type of application is being considered? Will thefile be used on-line? Will such use be enquiry only or will the file be updatedon-line too?

Availability of hardware. What file organisations are possible on the existinghardware configuration? Is new hardware a possibility either immediatelyor some time in the future?

Method of access. How will the file be accessed? Must it be accessed on-line?Will accesses be purely for enquiry, or will updating need to be done? Whatare the future requirements of the file – is its use, and therefore the type ofaccess needed, likely to change?

File activity. How often is the file likely to be accessed for enquiry or forupdating? When it is accessed, how many records on the file will have to be

Figure 7.3 Factors to be considered in file design.

File design 109

accessed in one process? (This is called the ‘hit-rate’.) If many records fromthe same file need to be accessed by a particular process, it may be an indicationthat the process would be best done as a batch job, or perhaps with on-linedata capture but off-line updating.

File volatility. How often will records be added to or deleted from the file,and is this frequency likely to change over time? If records are frequentlyadded and deleted, the file is said to be ‘volatile’. Certain types of fileorganisations handle volatile files better than others. For example, an indexsequential file which is volatile will need constant reorganisation to bringadded records placed in overflow back in sequence with the file. Index randomfiles handle the situation better since new records are added at the end of thefile, and only the index then has to be updated.

File size. Is the file large or small? The main problems with large files arespeed of access and time required to copy the file for security and recoverypurposes. Both of these are significant if the file is a main file in an on-linesystem. Security and recovery are dealt with later in this book. However, it isworth mentioning here that in some on-line systems there may not be enoughtime, when the system is not required, for off-line copying of a large file.

The control of partial dumping of a file whilst other parts are still beingupdated on-line is quite an exercise for the designer’s skill and ingenuity.Speed of access to a large file depends on the physical data organisation ofthe file. For example, if index sequential was the chosen organisation therewould be several levels of index to be processed, each relatively large, beforethe record required could be addressed. As a general rule, if a file must belarge, it is better to aim for an organisation which does not use an index, forexample algorithmic or direct files.

If a file is large, it is always worth considering whether it could be splitinto smaller, more efficient units.

Output requirements. A file may need to be processed in more than one way.For example, it may be updated on-line during the day and processed inbatch to produce reports overnight or at week or month-end. Whatever thechosen file organisation is, it must allow for different processing and outputrequirements if the need for two or more differently organised versions is tobe avoided.

File requirements. A file may be affected by one transaction at a time, ortransactions may be grouped and applied to the file in a single pass. Althoughthe first method is most commonly associated with on-line systems, the secondcan be applied to great effect in some systems which, although they require a

110 File design

fast on-line response, do not need that response after every transaction. Anexample of this would be where customers’ orders need to be entered intothe computer system. The dialogue between users and computer could bemade to allow a screen full of orders to be entered and the whole screenconfirmed, rather than the slow process of entering one line on a screen andhaving to await confirmation before proceeding. From the file access point ofview, the input lines from the screen could be sorted into the most efficientorder for processing against the order file, making total access time for all theorders quicker than an individual access on, and confirmation of, each order.

Sorting of files. Sorting can be a time-consuming activity if the file to besorted is large. For example, the sorting of a file of, say 20,000 records wouldusually take minutes rather than seconds. Therefore, if this sort were requiredbefore an on-line access could be made, the response time to the user wouldbe frustratingly slow.

It may be beneficial in some cases to split a large logical file into severalsmall physical files, either to remove the need for sorting altogether or tominimise the number of records to be sorted. Another solution is to set up anindex to the file containing only the key of each record and the specific fieldor data item or items required, and sort the index. The index may be quitelarge, but not as large as the original file.

Cost. With certain types of file organisation (e.g. algorithmic), greater speedof access can be obtained by allocating extra storage space to a file andspreading out the records on file, to prevent additional records added to thefile being stored far from their home address. The allocation of extra storageto the file means greater hardware costs, but this may be acceptable to obtainbetter performance from the system.

7.4.2 File handling softwareClearly, the specific physical design must depend on the characteristics of thefile handling software to be used, and these vary greatly. The designer maybe using a traditional file handling system (i.e. sequential, relative, indexedsequential access to conventional stand-alone files), or a database managementsystem. In each of these categories, there are very wide variations in thefacilities and constraints within file handling software provided by differentsoftware suppliers. It is not possible, therefore, to provide a specific logicalfile store to physical file store conversion technique which will work for allsoftware systems.

What is done here is to show how the conversion can be carried out for aconventional file handling system. An analogous approach can be devisedfor any other specific file handler.

File design 111

The following text will assume the use of conventional file handlingsoftware, with the following characteristics:

❏ data organised in records;❏ multiple record types in a file are permitted;❏ sequential file organisation and access, on one primary key;❏ relative record access;❏ indexed sequential organisation (any type of indexed sequential system

may be intended – Virtual Storage Access Method (VSAM) or conventionalIndexed Sequential Access Method (ISAM), for example);

❏ skip sequential access on one primary key.

7.5 The basic approachThe basic approach to the design process is illustrated in the DFD shown inFigure 7.4.

In the first stage, an initial design is created, using the logical file storespecification. This consists of:

❏ DD definitions of the logical stores;❏ entity and Access Path (Access Profile) diagrams;❏ entity/process matrix.

The initial design will meet the logical requirements of the new system, but itmay be inadequate because of the constraints imposed by response time foron-line processes, turnaround times for batch processes, or physical limitationsimposed by the storage devices being used, or other hardware constraints.The second stage, therefore, is to subject the initial design to an evaluation to

Figure 7.4 File design process.

112 File design

see whether or not it meets the specification requirements. If it does, the designis completed. If not, the physical design must be modified to move towardsmeeting the specification requirements.

The second and third stages of this process are repeated until a satisfactorydesign is produced.

7.5.1 Development of initial designThis section of the design process breaks down into two subsections: recorddesign and file design. Each of these sections in turn has two aspects:

❏ logical contents;❏ physical structure.

The design decision can be shown best by means of a grid chart as shown inFigure 7.5. The figure shows nine steps in the process and these are describedbelow.

Record content. Every entity box on the entity diagram (corresponding to anormalised data structure) will become a file record. The key to the recordwill include the key of the normalised structure but, before finalising the designof the record key, the file design must be examined.

Physical representation of data. Since most data will usually be numeric, thedecision on which method to use in storing numeric data in the record is amost important one. The main choices are:

Figure 7.5 Initial design decision.

File design 113

❏ character;❏ binary.

As an initial guideline the designer should choose whatever method iscomputationally most effective, for numeric values on which calculations areto be performed; and whatever method is most efficient in space utilisationfor numeric codes or other data items which are not to be used in calculations.The design of codes is considered in a later chapter.

Record size. The record size is simply the sum of the physical length of thedata items which make up the record. However, when the final physical designis arrived at, the record size may be adjusted to satisfy other criteria, forexample, to make all records fixed length.

Records in a file. The first decision to make is which records are to be held inwhich files. The starting point here is once again the entity diagram. The initialdesign is produced by allocating one file for each record type, with thefollowing exceptions:

❏ transaction records which are processed together go into one file; forexample, additions and deletions to a master file;

❏ records which are derived from a single data structure of the type header +{item} are held in a single file if the item records need to be accessedwhenever the header record is accessed. Suppose, for example, that thesystem data included in job sheet structure is defined as shown in Figure7.6.

Such structures are nearly always required together and access will be moreefficient if the records are stored in one file.

Figure 7.6 Job sheet data structure.

114 File design

File organisation. The basic rules for determining the organisation of thefiles are summarised in the decision tables in Figure 7.7.

File sequence. The physical sequence of the records in the file is primarilydetermined by its organisation. For serial files, it is the sequence in which therecords were written to the file. In the case of algorithmic files, it is determinedby the nature of the algorithm. Where a direct file organisation is used, therecords can be in any order. This gives the possibility of having both a directaccess on one key and a sequential access on a second key simply by physicallyorganising the file, in that sequence. In the case of an indexed sequential file,the data is organised in the sequence of the primary key.

Record keys. The design of the record key can now be completed. There arethree cases to consider:

❏ single record file. In this case, the key of the record is the key of thenormalised data structure;

❏ multiple record file of the header + {item}. In this case, the key is made upof two or more parts based on the key of the repeating group as shown inFigure 7.8. The file will thus be in sequence of header record plus associatedrecords and so on. One purpose of using the record type indicator is thatthere may be more than one type of item record to be held in the file. Figure7.9 shows this as applied to the data structure shown in Figure 7.6;

❏ transaction files containing a number of record types. The keys will be intwo parts, the key of the data structure plus a record type indicator whichwill probably be a simple numeric code, 1, 2, 3, etc.

Figure 7.7 File organisation.

File design 115

Figure 7.8 Multiple record keys.

Figure 7.9 Record keys in job file.

Secondary keys. The specification may call for direct access to master fileson keys other than the main key. Before designing in facilities for direct access,the specification should be carefully studied to ensure that direct (i.e. random)access is really required on secondary keys. If such requirements can be metby a serial scan of the file, this is a far simpler solution than building in specialaccess facilities, which always impose processing overheads. Whichevermethods of implementing such access mechanisms are adopted, secondaryindexes, record chains, etc., some computer time will inevitably be spent inmaintaining these mechanisms. However, assuming that such a direct accessfacility is required, here is a simple method of implementing it. Two casesmust be considered:

❏ the secondary key corresponds to the most significant component of acompound key. To take the example given in Figure 7.6, there may be aneed to access the job detail records using job no. key. This type of access issimple and is within the context of an indexed sequential file handler. Thedesigner does not, therefore, have to design special features into his/herfile to cater for this requirement;

❏ the secondary key corresponds to a data item in the record which is not themost significant component of a compound key (i.e. the complementarycase to the above). In this case, the simplest method of gaining access is toset up a secondary index. This is done by creating, for every record to beaccessed on a secondary key, an index record consisting of:

o the value of the secondary key data element in the record;o the key of the record containing this value.

116 File design

For example, suppose in the example shown in Figure 7.6, it is necessary toaccess the job header records using customer as a secondary key. A new recordwould have to be created for each job header consisting of customer job no.To access a job header record for a specific customer, the index records wouldhave to be accessed, to find out which job no. records contain that customer,and then access those job headers.

Physical file characteristics. The final decisions in file design relate to physicaldesign decisions on the file’s block size, overflow area size, and positioningon a physical device.

Limits to the choice of block size are imposed by the size of the largestrecord on the file (minimum block size) and the physical limit imposed bythe hardware or software (maximum block size). Within those limits thefollowing suggestions may be helpful:

❏ on files which are only sequentially accessed, use maximum block sizes;❏ on files to be accessed randomly, use the smallest block size compatible

with minimising the total number of backing store accesses per recordaccess. For example, in conventional indexed sequential files, if small blocksizes are used, the index blocks will also be small, which may result in twoor more index blocks at each level. So, for example, each cylinder indexcould be two or more physical blocks. Thus when making a file access,there will be multiple accesses simply to read the indexes. By increasingthe block size, the number of index blocks can be reduced to the minimumof one at each level, so reducing the number of comparatively slow accesses.Similar effects may be found in other file handlers.

If the file is directly accessed via a key transformation (algorithm), the designerwill have to consider the algorithm to be used, the overflow area to be allowedin the file, and the methods of handling synonyms. On conventional indexedsequential files, unless the creation of new records and extensions to existingrecords is very evenly distributed across the file, do not use embeddedoverflow areas. The designer should allow sufficient first level overflow tocope with the average file activity on a cylinder between file reorganisation,and sufficient second level overflow to cope with exceptionally high activityon any one section (cylinder) of the file.

7.6 Design evaluation and modificationOnce the designer has been through the initial stage of file design, the filedesign needs to be evaluated against the design objectives and then modifiedwhere necessary. It must also be matched against the hardware and softwareavailable.

File design 117

7.6.1 Evaluate design against system constraintsThe constraints placed upon the designer are as follows:

❏ response time constraints in on-line procedures;❏ turnaround time constraints in batch procedures;❏ hardware and/or software constraints – computer storage limitations, the

number of files which may be open simultaneously, the number of physicalstorage devices, etc.

This evaluation will not be discussed in detail in this section. Timingcalculations are fully discussed in the chapter on system performance.Hardware and software constraints will be specific to the target computerand software system.

The results of the evaluation will either be confirmation that the designdoes meet the design objectives or that it does not. If it does not, the designerwill have clearly identified those points on which the design is unsatisfactory.

7.6.2 Modifying physical designIf the physical design does not meet the requirements of the specification, itmust be amended. There are a number of strategies that can be adopted forimproving the design:

❏ combination of records;❏ splitting the records;❏ amalgamation of files;❏ alterations of processing mode.

Most of these strategies have several effects, some of which may be desirable,others undesirable. The designer must be aware of both main and side effects.After the amendments have been made, the new design is submitted to thesame evaluation as described above, and the cycle repeated until the designobjectives are met or modified.

Combination of records. If the entities to which records correspond have aone-to-one or one-to-many relationship, where the ‘many’ records have astrictly limited number of occurrences, the records may be combined. Forexample, suppose a customer has a discount given on a range of products,which results in two record types:

customer record = customer discount =customer number + customer number +customer address product code +etc. discount %

If the number of discounts is limited to a maximum of five, the two separate

118 File design

record types could be merged into one. This could have the effect of reducingthe number of files, if the records have been placed in separate files. It mightalso reduce access time if the discount data is frequently used at the sametime as the other customer data.

Splitting of records. It may be useful to split a record into two sections, if thedata in parts of the record is required for fast on-line access. The two parts ofthe record could then either be held in the same file, or in different files. Notethat to gain significant advantage in access speed, the physical block sizewould also have to be decreased, and on indexed sequential files, this mayhave the effect of lengthening access times.

Amalgamation of files. Master files may be amalgamated by holding therecords in a single common file. This can be done simply to reduce the numberof files or to reduce the computer memory requirements (by reducing thenumber of file buffers). In sequential or indexed sequential files, differentrecords may be grouped into whatever sequences are required by using ‘recordtype’ fields as part of the record keys.

Care must be taken in amalgamating files. A general rule is that static filesand dynamic files should also be kept separate. That is, two or more staticfiles could be considered for amalgamation, or two or more dynamic files,but they should not be mixed.

A further advantage to the amalgamation of files is that it simplifies backupand recovery procedures. With a smaller number of master files, there is lesschance of inconsistencies arising because one of the files has been restored toan earlier version, while others have not.

Alterations of processing mode. The designer may have to consider changingthe method of processing. If a response time for an on-line process is toolong, for example, it may be possible to split the processing requirementsinto two sections:

❏ those which must be done on-line;❏ those which can be performed in ‘batch mode’ at a subsequent time.

One situation where this strategy can be usefully employed is in the creationof new records, where each new record is added into the same point in thefile. Consider, for example, a system in which new customer orders are enteredon-line, and a new order record is created and added to an indexed sequentialfile, in sequence of order number. In effect, each new order record will beadded to the existing file at the same entry point, and this will inevitablyimply slow processing, since all new records will go into the overflow areas.To avoid this problem, the designer can specify a batch (off-line) process inwhich ‘skeleton’ new order records are created and added to the file. These

File design 119

records will simply contain the order number and a flag indicating that theyare not ‘real’ orders. The on-line order entry process will then amend theseskeleton records by updating their contents. This is a much faster processthan the simpler approach of creating the new records on-line.

7.7 Database design considerationsThe concepts behind a database are those of:

❏ data integration;❏ data integrity;❏ data independence;❏ data retrieval.

7.7.1 Data integrationOne of the concepts of a database is that each data item is stored only onceand is made available only to those applications which need to use it.

For example, details of employees can be kept in several differentdepartments. The Payroll, Pensions and Personnel departments will all needinformation about an employee (see Figure 7.10).

For example:

Payroll Personnel PensionsEmployee No. Employee No. Employee No.Employee name Employee name Employee nameNI No. Home address Home addressSalary Department Pension contributionsDeductions Grade etc. . . .etc. . . . etc. . . .

Figure 7.10 Three views of a database.

120 File design

The employee number, name and home address are repeated. If any changesare made to these fields, more than one file will require updating. Alloccurrences of this information within the company may not be known, whichcould cause it to become out of date.

7.7.2 Data integrityIf several copies of a data item exist and not all are updated at exactly thesame time, there will be inconsistency between those data items. Where thedata is non-volatile this may not cause many problems. In a volatile situation,however, it could cause the business to lose sales.

In the following example, the Sales Order Office keeps a stock balance figurewhich is updated on receipt of orders. The Stock Records department alsokeeps balance and movement figures but these are not updated until receiptof documentation from the Warehouse, some time after the order was received.The Reception/Customer Enquiry desk receives enquiries from customersabout available stock. Company policy states they must contact Stock Recordsfor the information but, as the figures are not up-to-date, incorrect informationis being given out causing considerable problems.

A perpetual stock count is carried out daily, actual stock figures being passedonly to Stock Records (see Figure 7.11).

Figure 7.11 Sales Order Office DFI.

File design 121

Figure 7.12 Sales Order Office database with three discrete ‘views’.

Figure 7.13 Part-ERD showing customer relationship to order.

Figure 7.12 shows how Part details could be organised in a database withthe different departments having their own ‘view’ of the data.

Another aspect of database integrity is to be able to apply referential integrityto data groups. The following part-ERD shows the Customer relationship toOrders. A Customer can exist without an order but an order cannot existwithout a Customer. Referential integrity can be set in the database so that noOrder can be added without the Customer already existing (see Figure 7.13).

7.7.3 Data independenceIn computer programs written in third generation languages, data (file)information was stored together with the program instructions. If the structureof the file changed then all programs using that file had to be amended.

For example, the Customer file details could be written in COBOL asfollows:

FD CUSTOMER-FILELABEL RECORDS STANDARD.

01 CUSTOMER-REC.03 CUST-NO PIC 9(4).

122 File design

03 CUSTOMER-NAME.05 FORENAMES PIC X(21).05 SURNAME PIC X(15).

03 CUSTOMER-ADDRESS.05 ADDRESS-LINE PIC X(25) OCCURS 4.05 POSTCODE PIC X(8).

All programs which need to use the Customer file will require the abovedefinition in the program itself. In the processing part of the program the filewill need to be opened and a record read before any actions can be taken.

PROCEDURE DIVISION.CONTROL SECTION.

OPEN INPUT CUSTOMER-FILE.. . .. . .. . .READ CUSTOMER-FILE.

If the Customer-telephone-number had to be inserted between the customernumber and the customer name, all programs using the customer file wouldhave to be amended.

Within a database the data is stored independently of the program andcan be modified without affecting the programs using it. The programs accessthe information required using names specified in the DD which map ontothe location of that data in the database. The following shows the use ofSoftware Query Language (SQL) in accessing the customer details in thedatabase.

WORKING-STORAGE SECTION.EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 CUST-NO PIC 9(4).01 CUST-TEL-NO PIC X(12).

EXEC SQL END DECLARE SECTION END-EXEC.

Only the data required is specified. There is no need to know where thosedata items are stored within the Customer file details.

When required the data is ‘FETCHed’ into a work area by means ofdeclaring a cursor which will point at each record in turn.

PROCEDURE DIVISION.CONTROL SECTION.

EXEC SQL (declare a cursor to point at each record which, in this case, willconsist only of the customer number and telephone number dataitems)

File design 123

DECLARE A1 CURSOR FORSELECT CUST-NO, CUST-TEL-NO FROM CUSTOMER

END-EXEC.

EXEC SQLOPEN A1 (activate the cursor by ‘opening’ it)END-EXEC.

EXEC SQL (transfer the data items into the fields)FETCH A1 INTO : CUST-NO,

: CUST-TEL-NOEND-EXEC.

7.7.4 Data retrievalAs data is organised independently of the programs which use it, ‘one-off’queries can be simply made and new applications written without concernfor how or where the data is stored. For example:

SELECT CUST-NO, SURNAME, POSTCODE FROM CUSTOMER;

will produce the Cust-No, Surname and Postcode for all records in theCustomer file.

7.7.5 Physical and logical dataThis independence of data from programs or queries which use it suggeststwo forms of database:

❏ logical databases, the user’s ‘view’ of the data;❏ physical databases, which represent attributes, entities and their relation-

ships.

The database concept means that the views which applications have of thedata are not only independent of each other but also they are independent ofthe way in which the data is physically stored (see Figure 7.14).

The Database Management System (DBMS) handles the physical storageof the data and access control to the data. It handles the links between thedata allowing changes to be made without changing the user view of thedata. For example, if Purchasing requested the ‘Delivery period’ (the standarddelivery period of a Part) to be added to the database, this would be availableto the Purchasing Department to use but would not change the ‘views’ ofReception and Stock Records.

124 File design

This suggests there are two distinct ‘views’ of the data:

(1) Different users who need to be able to view the same data in differentways:

❏ the Customer number, name and address (for the Invoice Dept)❏ the Customer name and telephone number (for Customer Enquiries)❏ postcodes (for mail shots by Marketing)❏ etc.

(2) The computer which works with physical representations such as files,records, index structures, access methods and so on:

Customer File – Northern section

0403 Smith 777864 Manchester MM 240405 Jones 633691 Manchester MM 560406 Allen 634925 Leeds LD 920407 Clark 895432 Birmingham BB 73

Customer file – London section

0408 Barber 563778 London LL 920423 Dean 567223 London LL 670424 Armitage 555764 London LL 020426 Davis 592785 London LL 15

The three-schema architecture (illustrated in Figure 7.15) is based on thepremise that:

❏ the same data needs to be viewed by computers and users in differentways;

Figure 7.14 Independent views of data.

File design 125

Figure 7.15 Three-schema architecture.

❏ different users view the same data in different ways;❏ users and computers should be able to change the way in which they view

the data;❏ the computer should not constrain the ways in which users view the data.

In the three-schema architecture, the external schema is the user view, theinternal schema is the physical database and the conceptual schema providesthe mapping between the user requirement and the actual physical locationof the data. An example of a simple data model is given in Figure 7.16.

A customer can have more than one account. The user view or externalschema is of the data they need to use (see Figure 7.17).

There could be a direct mapping between the user view and the underlyingdatabase when no conceptual schema would be required. Figure 7.18 usesrelational tables to illustrate direct mapping.

Figure 7.16 A simple data model.

126 File design

Figure 7.17 The user view.

Figure 7.18 The database.

The Customer table is connected to the Accounts table through theCustomer Number. There is no need for any mapping of requests onto theunderlying database tables as they are directly linked. Any user request forany combination of Cust. No, Name, Address, Tel. No, Account No or Balancecan be extracted directly from the tables, for example Account numbers andbalances for customer 703.

However, if the Accounts database is very large, the database administratormay decide to split the tables according to usage. If, for example, there weremany more accesses to accounts of customers who were in the North, thetables could be split as shown in Figure 7.19 (this would require ‘zoning’ ofthe account by, say, a Region or Area code).

File design 127

The user need not be aware of the ‘zoning’ of accounts, nor of the splittingof the tables. In this case a conceptual model is between the user request andthe tables. It will make use of the ‘Area’ code to extract accounts data fromthe appropriate table.

7.7 SummaryDuring the file design phase of the system, physical considerations, whichwere almost ignored during the analysis of the system, begin to play a largepart. Existing hardware and software for file handling may prove very limiting;there may only be one readily available method of handling direct access offiles.

On the other hand, if the ‘one method’ is a sophisticated DatabaseManagement System (DBMS), life may be made relatively easy for thedesigner. He/she may be able to hand over the design of the database to aspecialist; many of the enquiry features requested by the user may be providedby a separate database query language, of which an increasing number areappearing on the market to accompany established DBMSs.

As is the case with process design, there is not usually one ‘right’ file design,and all others are ‘wrong’, but there are factors which make for good filedesign:

Figure 7.19 Splitting the database.

128 File design

❏ keeping data redundancy to a minimum;❏ keeping access paths short;❏ keeping the number of access paths as low as possible;❏ keeping the number of secondary indexes to a minimum.

In conclusion, the final physical specification of the files may not be identicalto the logical picture, and in fact many do differ considerably.

However, it is important that the logical phase is undertaken, as this helpsto divorce the file structure from the philosophy of the system. The designershould not be influenced by existing actual files, as to copy these may causethe eventual system to be data structure dependent, and create unwelcomemaintenance problems for the future.

Exercises7.1 What are the major logical inputs from analysis, to the task of physical

file design?7.2 What are operational and informational access requirements? What

volumetric information does the designer need to know about these?7.3 What are the different types of file a designer needs to consider? Write

brief notes explaining each of these.7.4 What factors must the designer consider when designing files? Give six

examples.7.5 Explain the meaning of:

❏ data integration;❏ data integrity;❏ data independence;❏ data retrieval.

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Business Systems Design

Documents