8 Procedure specificationshafraznazim.weebly.com/uploads/2/8/5/2/2852303/iad_bsa...Procedure...

Procedure specification 171

8Procedure specification

IntroductionThe high-level recording of the elements of a system, using Data FlowDiagrams (DFDs), needs to be supported at the lowest level by individualspecifications of the actual procedures carried out.

For each lowest level process on a set of levelled DFDs, there must be anassociated mini-spec (also referred to as an elementary process description orelementary function description). This can take several forms:

❏ flowcharts;❏ structured English;❏ pseudocode;❏ decision tables.

In this chapter the above are described with indications of where each maybe particularly appropriate, and what standards should be followed.

8.1 Low-level procedure specificationSince DFDs contain no decision symbols and since most business activitiesinvolve decisions of one kind or another, it is obvious that the DFD alonecannot be a complete specification.

The DFDs show how data passes from one process to another, but theyprovide no detailed information on what is actually done to the data insideeach process. This is the purpose of the mini-spec. When supporting a logicalDFD, it is a statement of policy only, stating what is done to the data, not themethod by which this policy is carried out. When it accompanies a physical

172 Procedure specification

DFD, it describes a job that is done, or to be done, either clerically or bycomputer.

The mini-spec, as it is called when using DFD techniques, equates fairlyprecisely with module specifications or components specifications, asunderstood by exponents of structured design and development methods.However, it is important to differentiate between a module specification anda mini-spec, since they occur at totally different stages of the system life cycle.

A mini-spec is an analyst’s document. It is produced to support the set ofDFDs developed by the analyst. It covers precisely the area of processing thatis shown by one symbol on the DFD. This may be quite different from aprogram module. Indeed, the work may still be carried out manually. Thepurpose of the mini-spec is to define what is done, or to be done, within oneprocess on a DFD.

8.1.1 FlowchartsOne of the most popular early pictorial methods of logic description was(and in some cases still is) the flowchart. Most procedural flowcharts can beconstructed using a very small set of standard symbols (Figure 8.1). The sizeof the symbols is never significant and they are drawn as small as possible,consistent with clarity of annotation.

Each of the three fundamental logic elements (sequence, selection anditeration) has a completely self-contained flowchart representation, which maybe easily incorporated into an overall description of a process.

A sequence of two or more processes is drawn as shown in Figure 8.2. Thelogic flow is from top to bottom or from left to right. The decision symbol isused to indicate a selection element, as shown in Figure 8.3. The iteration, orloop, is represented as in Figure 8.4 and a complete flowchart is shown in

Figure 8.1 Symbols used in flowcharts.


Figure 8.2 Sequence.

Figure 8.3 Selection.

Figure 8.5. Connectors are used to indicate continuation on another page, thepage number being placed in the circle.

Small or part flowcharts can be used in mini-specs to represent pictoriallydecisions and flow. To produce a full mini-spec using a flowchart could resultin a substantial document. Each action or condition needs to be defined withina symbol and this could make it difficult to read. A flowchart is a map, a two-dimensional representation, whereas a mini-spec is essentially a list of whatneeds doing, which is one-dimensional. Therefore, some substantialmodification is needed to do the conversion. What is efficient and easy toproduce as a map is often inconvenient as a list. Therefore, changes are madeto the actual logic as the program code is produced, and all too often theflowchart is not amended to match, because a flowchart is not easy to modify.


Figure 8.4 Iteration.

Figure 8.5 A complete flowchart.


8.1.2 Structured EnglishStructured English is a subset of the English language, consisting of a limitedset of verbs and nouns, organised to represent a reasonable compromisebetween readability and rigour. The purpose of structured English is to allowthe analyst to describe, rigorously and precisely, each of the componentprocesses of the system. At the same time the description is intended to becomprehensible to the average user. In its most extreme form, structuredEnglish consists of the following elements only:

❏ a limited set of action-oriented verbs, such as ‘find’ or ‘print’;❏ control constructs borrowed from structured programming, e.g. if ... then

... else ..., while ... do ..., like the ones in our free-format language;❏ objects defined in a data dictionary.

The following is an example of structured English showing a manual processapplied to overdue invoices.

1 If the amount of the invoice times the number of weeks overdueis greater than $5,000thena give a photocopy of the invoice to the salesperson who is

to telephone the customerb record on the back of the invoice that a copy has been

given to the salesperson, with the date on which it wasdone

c refile the invoice in a file for examining two weeks fromtoday

2 else if more than four overdue notices have been sentthena give a photocopy of the invoice to the appropriate

salesperson who is to telephone the customerb record on the back of the invoice that a copy has been

given to the salesperson, with the date on which it wasdone

c refile the invoice in the file to be examined one weekfrom today

else -the situation has not yet reached serious proportions,but a reminder is to be sent.

The structure is simply expressed by indentation. The convention is that a listof sentences or phrases altogether, and all with the same indentation fromthe left margin, forms a group. The numbers and letters are optional, but canaid clarity. The structure is used to express the three standard constructs ofany procedure. These are sequence, selection and iteration.

SequenceSequence is a list of actions to be performed, in the order in which they are


listed. In the above example those statements labelled a, b and c are to becarried out in sequence.

SelectionSelection can take one of two forms. The simplest form is the IF ... ELSEconstruct. This implies that there are two possibilities being examined.Occasionally, there may be more possibilities to take into account, and in thissituation the SELECT CASE construct is best used. For example:

Terms of paymentFor each order

Examine credit limitCase 1 Credit limit $1000Case 2 Credit limit $5000Case 3 Credit limit unlimited

Endcase

IterationIteration is the repetition of a sequence of actions according to a rule. The ruletells the reader when to stop the iteration. There could be a fixed number ofiterations (‘for each calendar month’) or a number determined by theinformation (‘for each invoice line’), or the rule could state some externalinterrupt (‘until coffee time’).

Example using paragraph numbers:

1. For each book returned1.1. Calculate number of days book borrowed

– If number of days book borrowed > 21– calculate fine– add fine to fine field in member details– request payment– If payment made

– reduce fine field in member details– record fine paid– issue receipt

1.2. Record book returned on book details1.3. Record book returned on member issue details1.4. Check book reservation list2. For each reservation2.1. Compare book number with book numbers on reservation list

– if book reserved– extract member details with oldest reservation date– record on reservation list against member details ‘member notified’ and today’s date– extract reservation card and place in book– place book in reserved books shelf

2.3. Place book on ‘return to shelves’ trolley


Figure 8.6 Psuedocode.

Structured English uses relatively clear statements. Each activity to beperformed is written in a short sentence or phrase, starting at the left-handmargin. When there is a rule (the condition in an ‘IF ...’ or ‘FOR ...’ statementor the iteration control statement) it is written starting at the left, with the listof activities indented about half an inch from the margin. At the end of thelist of things contained in the ‘IF ...’ or ‘FOR ...’ the next statement starts at theleft margin. There can be ‘nested’ structures. An ‘IF ...’ may occur within anexisting indented list, so a second deeper indentation is used.

Writing like this is very good practice because it makes the analyst thinklogically and clearly about what he or she is writing.

8.1.3 PseudocodePseudocode is a reasonably well-organised and precise way of producing amini-spec. The point of pseudocode is that a set of logic is presented as a list,ready for actual coding. Like structured English it uses indentations. It alsouses closure statements to terminate iterations and selections. Unlike structuredEnglish, paragraph numbers and letters are not used. There are severalcommonly used constructions and there is a general principle that allconstructions shall have a defined beginning and end (Figure 8.6).

The following pseudocode counts the number of times words occur in afile of text where each record contains a sentence. A table is produced at theend showing how many times each word occurred, e.g. ‘The word ‘the’ occurs200 times’; ‘the word ‘at’ occurs 52 times’:

DO WHILE there are more text recordsDO WHILE there are more words in the text record

extract the next text wordsearch the word table for the extracted wordIF the extracted word is found

increment the word’s occurrence countELSE

insert the extracted word into the table


ENDIFincrement the words-processed count

ENDDO at the end of the next recordread the next text record

ENDDO when all text records have been readdisplay the table

The example shown in the Structured English section could be written inpseudocode as:

WHILE book returnedcalc-fine = (date returned – date issued) – 21IF calc-fine > 0

fine = calc-fine * 0.50IF fine not paid

member-fine = member-fine + fineELSE issue receiptENDIF

ENDIFIF book-reserved ...

...ELSE place book on ‘return to shelves’ trolleyENDIF

WEND

Standards on writing pseudocode (or structured English) can be established,such as using WHILE ... WEND or DO WHILE ... ENDDO, to enable analyststo produce mini-specs using the same constructs. The analyst should keep inmind the person for whom the mini-spec is being written. Clarity is the aim,so that the user can actually understand, check and agree or disagree with it.

Structured English or pseudocode are ways of expressing logic by using aform of rudimentary language. Either method is suitable for producing mini-specs and which one is chosen can depend on existing standards or theanalyst’s preference.

8.1.4 Decision tablesA decision table takes the basic constructs of sequence, selection and iterationand presents them as questions (conditions) and/or things to do (actions) inthe form of a table or several tables. Since it specifies only the logic rulesinvolved and contains no implications about the procedure to be executed, adecision table is more problem orientated than a flowchart, which is solutionorientated.

A decision is represented in a flowchart by the diamond symbol, and instructured English or pseudocode by the ‘IF ... ELSE’ statement. In a decisiontable the question is asked first, followed by the answer which is either Yes orNo.


Figure 8.7 Example of actions.

Sequence is represented in a flowchart by rectangles connected together,and in structured English or pseudocode by a list of statements. Similarly, ina decision table, sequence is a list of statements which are called actions. Forexample:

Get out of bedGet washedClean teethGet dressedMake a cup of teaGo to work

Sometimes these actions depend on the result of an earlier question, as inFigure 8.7.

Iteration is represented in a flowchart by lines and arrows, and in structuredEnglish or pseudocode by the ‘DO ... ENDDO’ or similar statements. Iterationin a decision table is achieved by naming the table so that the name can bebranched to. It is not usual practice to place a name within a decision table sothat the logic may be repeated. This can mean that statements may have to bebroken down into several decision tables in order to achieve iteration. Forexample:

Table OnequestionsactionsGO TO Table TwoGO TO Table One (loop round again)

Table Twoactions (doesn’t need to have questions)GO TO Table Three

Table Threequestionsactions (doesn’t go anywhere so must be at the end)


The four basic elements of a decision table are known as:

❏ the condition stub;❏ the condition entry;❏ the action stub;❏ the action entry.

The condition stub and condition entries describe the conditions to be tested,while the action stub and action entries describe the actions to be taken (Figure8.8). In a decision table these four elements form quadrants.

The condition entries and action entries together constitute one or morerules, which run vertically through the two right-hand quadrants. Each ruleindicates the actions to be taken when a particular combination of conditionsapplies. In a limited-entry decision table the conditions are expressed as simpleYES/NO questions, and the actions are restricted to either ‘execute’ (indicatedby the ‘X’) or ‘do not execute’ (indicated by the ‘–’).

In Figure 8.9, if the conditions under Rule 1 are satisfied, it is cold and it isnot wet, then the action ‘Take Coat’ will be carried out. The action ‘TakeUmbrella’ will not be carried out as the ‘–’ says ‘do not carry out this action’whereas the ‘X’ says ‘do this’.

The decision table is by no means complete. What if it is both wet andcold? To ensure that all combinations have been covered, the formula:

Number of rules = 2c

where c is the number of conditions, is applied.In the above example there are two conditions, ‘Is it cold?’ and ‘Is it wet?’,

therefore 22 = 4, so there should be four rules in the decision table (Figure8.10).

Consider the following example:

A department store is offering interest-free credit on selected items of

Figure 8.8 Basic elements of a decision table.


Figure 8.9 Example decision table.

Figure 8.10 Decision table.

furniture. If a customer wishes to take up this offer one of the following criteriamust be satisfied:

1. the customer is creditworthy. If not,2. the customer is a salaried employee. If not,3. the customer is classified by the store as a ‘special person’, owing to a long

association with the store.

If none of the criteria is satisfied then interest-free credit is not allowed. If anyone is, then the customer is given the interest-free credit.

This could be shown in flowchart form (Figure 8.11). As a limited-entrydecision table, the conditions and actions could look as in Figure 8.12. This isa ‘full’ decision table and there are three conditions, so using the formula 23 (2× 2 × 2) there should be eight rules in the decision table. Figure 8.12 shows areasonably sized table for three conditions resulting in eight rules. However,eight conditions will result in 256 rules!


Figure 8.11 Flowchart solution.

When the full decision table has been laid out, it should be inspected to seewhether there are any rules which have identical action entries. If suchinstances are found, it may be possible to combine these. Also, in Figure 8.12,if the answer to condition 1 is ‘Y’ then no further conditions need to be tested.The decision table entries could be reduced to the one in Figure 8.13.

A further way to simplify a decision table is by use of the ELSE rule,corresponding to ‘if no other rules apply then use this one’. The conditionentries for the ELSE rule are left blank. If used it is always the last rule on thefirst condition line, as shown in Figure 8.14.

The above decision tables are known as limited-entry decision tables. Inanother type of table, known as extended entry, the conditions and/or actionsare extended into the condition stub and entry stub.

If, for example, different percentage increases were to be added to some ofthe types of postal service available, a limited-entry decision table could looklike Figure 8.15. There is no need to put in ‘N’ as, in this case, it is only ofinterest if the answer to the question if ‘Y’. The ELSE rule is there to coverother types of postal service available. The table could be simplified by usingextended entry as in Figure 8.16.


Figure 8.12 Decision table solution.

Figure 8.13 Reduced table solution.

Figure 8.14 Simplified decision table.

The decision table in Figure 8.16 equates to the one in Figure 8.15; it is justless to produce and looks clearer. The ELSE rule still applies to cover for othertypes of postal service. Note that the last line is limited entry: it is allowableto mix limited-entry and extended-entry lines (rows) only.

If there is a large number of logically independent conditions to beconsidered, say nine or more, consideration should be given to defining therules by using several tables rather than only one. This will make it clearerfor both the analyst and the user to understand. Tables with a large numberof rules can be difficult to follow as they look confusing. In effect, there willbe a high-level decision table, the actions of which direct the user to severalsubordinate tables, as shown in Figure 8.17.


Figure 8.15 Limited-entry decision table.

Figure 8.16 Extended entry decision table.

8.1.5 The decision table as a specification toolDecision tables have many useful features for the analyst. They are:

❏ simple, easy for the user to understand;❏ complete and unambiguous: the analyst can calculate the exact theoretical

number of rules to be specified. Methods exist for laying out these rulessystematically so that none is missed or specified twice;

❏ statements of policy: they say nothing about how the policy is carried out;❏ working documents: like all good analysis tools, the decision table is a

useful working document. Used as part of the dialogue between analystand user, it leads to clear communications and identification of areas ofuncertainty or error in the analyst’s understanding.

8.2 SummaryThe ‘mini-spec’ is the expansion of a lower level process within a set of levelledDFDs. Every lowest level process (known as an ‘elementary process’) requiresa supporting mini-spec. If the set of levelled DFDs is envisaged as a branchingstructure, the tip of every branch, however long or short, is a mini-spec.


Figure 8.17 Multiple decision tables.

The mini-spec is a procedure document. It states what procedure is followedto convert incoming data flows into outgoing ones. All decisions within asystem are contained within mini-specs, and therefore the mini-spec is‘decision orientated’. If narrative is used, and this is highly recommended, itmust have visible structure through the use of indentation, and of shortsentences or phrases. Common English words are frequently employed toaid user understanding, but computer jargon may be included (e.g. ‘IF ...THEN ... ELSE’) provided this does not obscure the meaning. The analystshould consider the needs of the readers of the mini-spec.

If a set of interrelated, rather than simply dependent, conditions has to betested for the decisions to be made, then decision tables are also recommended.

Flowcharts may be used to structure the logic, but are not recommendedfor documentation within a mini-spec as described previously.

ExercisesThe questions below relate to the following scenario:

‘If you want to use the combined photocopier and fax machine to send afax, you must place the document to be faxed in the document holder ontop of the machine (face up) and press the ‘FAX’ button. Make sure firstof all that the machine is plugged in and switched on, and that the displayon top says ‘FAX’. If it does not, pressing the ‘FAX’ button should correct


this. After typing the telephone number you wish to fax to into the numberpad on the top of the machine, pressing the green ‘GO’ button next to thekey pad will send your fax. If this does not work, it is better to checkcarefully that you did the whole thing properly and try to again. Onlycall the engineer if you are certain that there is a fault in the machine,since this can be a very expensive option.’

8.1 Draw a decision table to represent the procedure above.8.2 Draw a flow chart to represent the procedure above.8.3 Rewrite the above procedure in Structured English.8.4 In the above exercises, identify where there are gaps in the logic. Which

method of structuring the procedure did you find most useful and why?Is there benefit to be gained from using more than one approach?

Entity analysis 187

9Entity analysis

IntroductionAn entity is a ‘thing’ about which an organisation holds information. Entitymodelling is a technique for showing relationships between entities. Entityanalysis is the process by which the model is developed, and identifies theunderlying structure of the data and relationships of those data. The diagramproduced from entity modelling is called the Entity Relationship Diagram(ERD). Computer systems which store large quantities of data need to retrievethe data rapidly, in a variety of sequences and combinations. Problems canoften result, whether the system uses a database or individual files, becauseof the way in which individual data items are stored within the computersystem; This may not reflect the underlying structure of the data that exists inthe business world outside the computer system.

9.1 When is entity analysis performed?Entity analysis is performed at two stages during the analysis phase of a system:

❏ during analysis of the existing system, to aid the analyst’s understandingof it;

❏ in conjunction with relational data analysis (see Chapter 10) to produce amodel of the required data structure for the new system.

Ideally, analysts beginning work on a new project do not have to start theERD from a blank sheet of paper. Many organisations have recognised theimportance of their data sufficiently to have developed a corporate data model,which is just a company-wide ERD. Such a model ensures that the underlying

188 Entity analysis

Figure 9.1 Insurance company.

structure of data from the point of view of the organisation as a whole isappreciated. If a corporate ERD is available, the individual project’s ERD willjust be a subset of this, and the analysts, whilst developing more detail inrelation to the entities within their particular project area, will have aframework to guide them. However even if such a corporate data model doesexist, entity analysis is still essential to the individual project.

For example, an insurance company’s corporate view of the data may be(Figure 9.1):

Agents who sell their productsProducts the different types of policy soldClients who buy the policiesBeneficiaries named in the policies

If the requirement was to implement a sales and administration computersystem to service customer enquiries, ‘products’ would not be detailed enough.A product (Figure 9.2) could be life insurance, home insurance, car insurance,

Figure 9.2 Expansion of ‘product’.

Entity analysis 189

etc., each with a number of different types of policy, therefore a product wouldconsist of several policies. A policy generates many premiums, details of whichmust also be available to the user.

9.2 EntitiesAs defined above, an entity is a thing about which the organisation wants tohold information. Entities may be physical things, such as:

❏ customer;❏ invoice;❏ product;❏ supplier;❏ employee;❏ training course;

or conceptual things related to the business area, such as:

❏ salary grade;❏ sickness history;❏ project.

9.2.1 Entity occurrenceAn entity has a number of occurrences. If there are 200 employees in anorganisation there will be 200 occurrences of the entity ‘employee’. Eachindividual occurrence must have a unique identifier (a key).

For example,

Employee no: Name: Address: Dept: Salary: ... etc.A624 Brown, B.J. Nottingham Accounts £25,000

is one occurrence of the entity employee with a unique key of employeenumber.

9.2.2 AttributesAll entities have attributes; they are the data which describes or qualifies theentity. In the entity employee the attributes could be:

❏ employee number;❏ employee name;❏ employee address;❏ employee department;❏ employee salary, etc.

In the previous example, ‘A646’ is the specific value of the attribute employeenumber for one occurrence of the entity employee.

190 Entity analysis

9.2.3 RelationshipsThe relationship between two entities describes the way in which anoccurrence of one entity is linked to, or influenced by, occurrences of another.For example, a department may have zero, one or many employees, but eachemployee will relate to only one department (in this example, where thebusiness rule is that an employee only ever works in one department).

9.2.4 NotationEntity description. The entity name is always in the singular within a

rectangle, which can be ‘hard’ (as in Figure 9.3) or ‘soft’ (with rounded corners)depending on which structured development method is followed.

Relationships. A relationship between two entities is shown as a line (Figure9.4).

9.3 Producing an entity relationship diagramThere are a number of steps to producing an ERD.

9.3.1 Selecting initial entitiesThese can be identified by looking at existing files and documents. Wherethere is a unique key (identifier) this will be a candidate for an entity, anemployee has a unique employee number, an invoice a unique invoice number,etc. In the library example a member (borrower) has a unique membershipnumber (Figure 9.5) and a book has a unique book number (Figure 9.6).

Figure 9.4 Relationship.

Figure 9.3 Entity.

Entity analysis 191

Figure 9.5 Membership number key.

There will also be a topic catalogue where each topic name is unique, anauthor catalogue where each author has a code, and a reservation facilitywhere the borrower number and the book number are recorded. Thus thefirst set of entities identified for the library is:

BORROWERBOOKTOPICAUTHORRESERVATION

As with Data Flow Diagrams (DFDs), entity modelling is an iterative process.Not all entities may be located at the first attempt. If there is any doubt aboutwhether something is an entity or not, it should be included. The model willgo through many stages of checking, where redundant entities can be removed.

Figure 9.6 Book number key.

192 Entity analysis

Figure 9.7 Entity grid.

A further method of identifying entities is to look at a description of thearea of interest and list all nouns which relate to something about which datawill be kept.

9.3.2 Placing the entities in a gridAn entity grid is shown in Figure 9.7. The analyst must establish where directrelationships exist, that is, no other entity comes between. For example, in acustomer, order, product scenario the customer receives the product, whichmight indicate a relationship; however, the customer cannot receive theproduct without an order, therefore there is no direct relationship betweenthe two (Figure 9.8).

Asking the question of the library example, does the book have a directrelationship with reserve (short for reservation)? If so, place an ‘X’ in the box(Figure 9.9).

Figure 9.8 Customer, order and product.

Entity analysis 193

Figure 9.9 Completed entity grid.

Figure 9.10 Initial entity relationship diagram.

9.3.3 Converting the grid into an initial entity relationship diagramEach entity in the grid is represented by a box on the diagram. A line is drawnbetween boxes where there is an ‘X’ in the grid (Figure 9.10).

9.3.4 Determining the degrees of the relationshipRelationships can be of three types:

❏ one to one;❏ one to many;❏ many to many.

For every pair of entities connected on the diagram, two questions are asked.For example,

❏ Can one occurrence of author be associated with more than one occurrenceof book ?

194 Entity analysis

Figure 9.11 One-to-many relationship.

Figure 9.12 One-to-one relationship.

Figure 9.13 Many to many relationship.

❏ Can one occurrence of book be associated with more than one occurrenceof author ?

If an author writes several books the answer to the first question is ‘YES’. If abook is only ever written by one author the answer to the second question is‘NO’ (to keep it simple assume that a book is written by only one author).The relationship is one to many between author and book.

The ‘many’ end is represented by a ‘crow’s foot’, as shown in Figure 9.11.There is no one-to-one relationship in the library example: Figure 9.12 would

mean that all authors only ever wrote one book!In Figure 9.12 one customer only ever has one order. This would not

normally be the case, but if the customer was an electricity company and theorder was for a nuclear power station, this could be true!

The relationship between book and borrower is many to many. A book canhave many borrowers and a borrower can borrow many books, as shown inFigure 9.13.

This implies that there is a missing entity. The borrower details can be noteddown on the book record, and the books borrowed can be recorded with theborrower details. It may be a business requirement that this information iskept, possibly as historical information. However, for dealing with theborrowing and return of books the system needs to be able to identify whichbook belongs to which borrower. This is done by creating a link entity, i.e.something that identifies the specific link for each occurrence of therelationship. To do this it helps to look at the attributes for each entity. Thebook will have many issue and return dates together with the borrower

Entity analysis 195

Figure 9.14 List entity.

Figure 9.15 Employee/project example (many-to-many).

number, while the borrower will have many book numbers. Whereinformation occurs on both entities, the repeated attributes will probably formthe link entity, e.g. the issue date, the return date and a fines field (Figure9.14). The key of a link entity is the two keys of the master entities concatenated.

An example. An employee can work on several projects and a project mayhave several employees assigned to it (Figure 9.15).Requirements from this information are:

(1) Management requires reports showing how each project is progressing,how much time has been spent on it and how much effort in person-daysis required to complete it. This will require details of the total effort spentand the total effort required to complete the project. A part project planshowing how much of the project has been achieved (the black line in themiddle of the light rectangle) is shown in Figure 9.16. This informationcan be obtained from the project entity (Figure 9.17).

(2) Each project manager requires details of the employees’ work on theirproject, such as time spent and time outstanding. This information couldbe obtained from the project to employee relationship by the projectmanager using the project key (e.g. project number) to extract the detailsof employees working on that project (Figure 9.18).

196 Entity analysis

Figure 9.16 Project plan.

(3) Each employee fills in a weekly timesheet showing time spent on eachproject. This information could be obtained from the employee to projectrelationship (Figure 9.19). It will show all projects on which the employeeis working.

(4) Whilst working on a project each employee needs to update the time spent,time outstanding, tasks completed, percentage of current task completed,etc. There is no relationship for an individual employee to one project. Thisrequires a link entity connecting the employee to one project, as shown inFigure 9.20. An employee is assigned to a project.

Figure 9.18 Employee/project example (many-to-many).

Figure 9.17 Project entity.

Entity analysis 197

Figure 9.19 Employee/project example (one-to-many).

Figure 9.20 Link entity.

Figure 9.21 Author/book relationship.

9.3.5 Identifying additional characteristicsName relationships. The relationships between two entities should be named

in both directions. In Figure 9.21, an author is the writer of a book, and thebook is written by an author.

Optional relationships. A book can exist without being issued; the relationshipwith issue is zero, one or more; however, an issue cannot exist without abook. Some disciplines use a dotted line to show optional relationships and asolid line to show a permanent relationship, as in Figure 9.22. In the figure,there is no optionality between author and book: if details of an author arekept it is because there are books in the library written by that author. A bookis always written by an author. Borrower details can be kept without thatborrower taking out any books (the optionality is shown by the dotted line);however, issue details must be associated with a borrower (shown by the solidpart of the line between issue and borrower).

A relationship defines the association between a master entity and a detailentity. For each master occurrence it should be possible to access all details

198 Entity analysis

for that master. The customer is the master and order the detail. Given acustomer number, all orders for that customer can be accessed. In order/product the order is the master and product the detail. Given an order numberall products on that order can be accessed. An entity can therefore be a masterin one relationship and a detail in another (Figure 9.23).

The dotted line can indicate optional masters, e.g. an Invoice has a one-to-many relationship with a training course, but training course details can existwithout an invoice. An alternative approach, where the dotted line approachis not used, is to place an ‘O’ on the relationship line indicating optionalmasters (Figure 9.24).

Figure 9.22 Permanent and optional relationships.

Figure 9.24 Optional relationships.

Figure 9.23 Master: detail.

Entity analysis 199

Figure 9.25 Exclusive details.

Exclusive relationships. Exclusive relationships describe either/or situations.This is indicated by an arc which shows exclusive masters or exclusive details(see Figures 9.25 and 9.26). In Figure 9.25, an employee has either weekly paydetails or monthly pay details. In Figure 9.26, an invoice is sent to either asupplier or a customer.

Recursive relationships. There are times when entities have relationships withthemselves. In Figure 9.27, for example, each employee reports to a supervisorwho is also an employee. Each employee who is a supervisor may supervisemany other employees. An optional recursive relationship is shown in Figure9.28.

Figure 9.27 Recursive relationship.

Figure 9.26 Exclusive masters.

200 Entity analysis

Figure 9.28 Optional recursive relationship.

9.3.6 Validating the ERDThe ERD should be checked against the lowest level DFDs to ensure that thedata is available for the process to be performed. A check should also be madethat each entity is being used in a process.

If any new entities are added as a result of checking against the DFDs, thesteps taken to produce the initial ERD should be retraced to check therelationships of the new entity with the existing entities.

9.4 Documenting the entitiesSupporting documentation for the ERD should contain:

❏ the entity name;❏ the entity description;❏ key(s);❏ attributes, including size and type;❏ volumetrics, i.e. number of entity occurrences, number of details per master.

9.5 A scenarioThe Victoria Hotel is one of six hotels forming the Crown Hotels group, whichoperates in the North West. The hotel has 180 rooms with the capacity tosleep 240 people. The hotel guests fall into two categories. The first categoryincludes tourists and business people. The other category covers conferencingand banqueting; it includes meetings, seminars, courses, weddings and otherfunctions. The Victoria Hotel has six function rooms of various sizes and aconferencing and banqueting department.

Currently the hotel has very little in the way of computer systems and islooking to improve this situation.

Initial investigations produced the following potential entities.

❏ customer;❏ room;❏ invoice;

Entity analysis 201

❏ guest;❏ room type;❏ room usage.

‘Customer’ and ‘guest’ are usually the same person, but there are occasionswhen they are different. For example, a company (customer) may bookattendees (guests) into the hotel for a course or seminar.

‘Room type’ is a code identifying a room as single, double, family,conference, etc.

‘Room usage’ contains information on how many rooms of each type areavailable and how many are reserved. Attributes are room type, date, roomrate, rooms available and rooms reserved. These details are sent weekly tothe general manager of the group.

Placing the entities in a matrix results in Figure 9.29. Connecting the entitiesbased on this matrix results in Figure 9.30.

The relationships are shown in Figure 9.31. Resolving the many-to-manyrelationship between guest and room produced the link entity reservation:guests book rooms by making a reservation and invoices are produced against

Figure 9.29 Hotel entity matrix.

Figure 9.30 Hotel entities.

202 Entity analysis

Figure 9.31 Hotel relationships.

Figure 9.32 Hotel entity relationship diagram.

a reservation. A guest may have more than one reservation and would beinvoiced for each reservation (Figure 9.32).

9.5 SummaryEntity analysis is a rather intuitive technique, and the identification of aninitial set of entities may seem daunting. However, the steps presented in thischapter are designed to check and recheck each other, and by iteration willresult in a reliable logical model of the data and the relationships used by thebusiness.

Entity analysis 203

Exercises9.1 In the following scenario, what are the initial entities, given that you are

looking to improve the ordering of goods from external suppliers?

‘A company places purchase orders with suppliers for items it cannotmake in its own factory. A purchase order will be sent to one of theapproved suppliers, showing the item code and quantity. Each purchaseorder will only be for a quantity of one item. The supplier will deliverthe items to the company, after which the company will pay the supplier,in monthly amounts, once a supplier invoice has been received.’

9.2 Draw the entity model for the above scenario.9.3 In the following scenario, what are the initial entities, given that you are

looking to administer an examination system, controlling records ofexaminations, candidates and examiners?

‘Examination days are organised to test candidates in the various modulesof study. Each module may have several examination papers. A candidatewill make a booking for possibly more than one examination day. Thecandidate will receive an examination result after attending anexamination day. Each examination day will have one invigilator allocatedto it. Invigilators are not examiners, and examiners never invigilateexaminations. Each examiner has the skill to mark particular modules.Each module would have more than one examiner skilled to mark it.One examiner would be allocated to each examination event’

9.4 Draw the entity model for the above scenario.9.5 What does the recursive relationship shown here tell you about the entity

‘PERSON’?

204 Entity analysis

Relational data analysis 205

10Relational data analysis

IntroductionIn Chapter 9, entity analysis was used to determine and describe logicalgroupings of data and the relationships between them. The topic of thischapter, Relational Data Analysis (RDA), addresses the same ideas from adifferent viewpoint. Whereas entity analysis takes a top–down view of thedata, RDA is a much more rigorously rule-based technique following a bottom-up approach. The products of RDA are a set of normalised relations (i.e.entities) and ultimately an Entity Relationship Diagram (ERD).

In this chapter the benefits of RDA are discussed and a set of rules is givenfor determining the correct logical groupings of attributes. Finally, rules arepresented for drawing an ERD from the normalised relations. The ERDs fromthe two data analysis techniques, entity analysis and RDA, are then comparedand brought together to produce a single refined data model.

In Chapter 11 this refined ERD is considered further in relation to theprocessing requirements of the system.

10.1 Benefits of relational data analysisRDA, often referred to as normalisation or Third Normal Form analysis (TNF or3NF), originated in work based on mathematical set theory which was firstpresented in the early 1960s by Dr Edgar Codd. The rules for normalisationof data which resulted from this are intended for practical application. Datanormalised by following these rules will provide a sound foundation forphysical design.

206 Relational data analysis

Figure 10.1 The customer entity.

To understand the need for RDA, consider the example in Figure 10.1. Itwas assumed previously that certain attributes belonged to certain entities.For example, customer address was assigned to the customer entity. Intuitively,putting customer address with the customer entity seems right, but whatwould be the implications if it were to be put in the wrong place, for examplewith the job entity, as in Figure 10.2?

Figure 10.2 Customer and job entities.


First of all, it is clear that the job entity now includes a lot of redundancy,which would be removed by putting addresses back into customer. Thearrangement shown in Figure 10.2 would also cause processing problems ifused as a basis for physical file design. These problems are the anomaliesdescribed below.

10.1.1 Insertion anomalyThe customer’s address cannot be recorded until a job is accepted by thesystem.

10.1.2 Deletion anomalyIf all jobs for a particular customer are deleted from the system, for examplebecause they have been completed, all trace of the customer’s address is lost.

10.1.3 Amendment anomalyIf the customer decides to move to new premises, all jobs in the system haveto be accessed and the address changed on each and every one of them!

RDA is aimed at preventing the kind of redundancy illustrated above andavoiding the splitting, between different entities, of attributes that areinterdependent, whilst ensuring the separation of attributes that areindependent.

10.2 When is relational data analysis performed?Looking back to Figure 1.14 in the introduction, it can be seen that a logicaldescription of the system is produced in box 2 (logical existing system) andbox 3 (logical new system). These logical descriptions each consist of DataFlow Diagrams (DFDs, and their supporting documentation) and an ERD,which could be produced by entity analysis, RDA or a combination of both.The ideal situation would be to use both techniques for both the existingsystem ERD and the new system ERD. However, time will rarely allow forthis, and it is doubtful whether it is worth spending the time on the existingsystem, which will be subject to change. The compromise usually taken is touse entity analysis for the existing system ERD, with perhaps a small amountof RDA in areas where the analyst is having difficulty identifying entitiesintuitively, and then to perform the more thorough RDA in relation to thenew system ERD. This can then be compared with the entity analysis ERD,bearing in mind changes made to accommodate new system requirements.


10.3 Relational data analysis and its terminologyRDA results in a set of normalised relations, i.e. a set of tables of attributes,each with a unique key, defined such that no attribute is unnecessarily repeatedand each attribute is logically grouped with others, based on the way in whichthe business uses its data.

10.3.1 RelationA relation is simply a table of data (see Figure 10.3). A relation has the followingfeatures:

❏ no two rows are identical;❏ the ordering of rows must not be significant (if it is, some data is being

implied which is not expressly stated – such data must be made explicit);❏ every column must have a unique name (i.e. each column represents a

different attribute);❏ the ordering of columns must not be significant (again if it is, some data

are implicit).

A row of the relation is called a tuple and a column of the relation (or, morestrictly, the set of allowable values for any one column of the relation) is calleda domain. The terms row and column will be used in this chapter in preferenceto tuple and domain.

With entity analysis, the physical equivalent of the logical entity wasconsidered to be the file (eg the Customer File). Similarly, a relation can bethought of as a kind of logical file, a row as a record and a column as anattribute. A normalised relation (i.e. after the normalisation rules below havebeen applied) is the equivalent of an entity.

Figure 10.3 Relation.


10.3.2 Key or identifierThe definition given in Chapter 9 is still valid, but is modified here to applymore specifically to relations. A key or identifier is an attribute (or attributes)which uniquely identifies a single row within the relation. This key is oftencalled the prime key or primary key to distinguish it from a foreign key (definedbelow). The chosen key should always be the minimum set of attributesrequired to identify uniquely a row of the relation.

In this chapter the convention for distinguishing primary key attributeswill be to underline them.

10.3.3 Foreign keyAn attribute which is the primary key of one relation but appears as anattribute in another relation is called a foreign key.

Foreign keys are distinguished in this chapter with an asterisk (*).

10.4 Normalisation and normal formsAny collection of attributes can be said to be either unnormalised or in aparticular ‘normal form’ depending on its compliance with the rules givenbelow. Many normal forms have been defined. Codd originally defined first,second and third normal forms. There are some cases, particularly where keysare complex and contain many attributes, where further normalisation maybe required. For such cases, Boyce–Codd normal form, fourth normal formand fifth normal form also exist. In this book, normalisation will only becovered up to the third normal form, since this is sufficient for most practicalpurposes. For further information about the other normal forms the reader isreferred to Date (2000).

10.5 The steps to third normal formIn order to obtain a set of normalised relations, the following steps should beapplied in sequence:

(1) gathering data;(2) choosing a key;(3) converting to first normal form;(4) converting to second normal form;(5) converting to third normal form;(6) optimisation.

These steps will be followed through using a simplified example relating to aprinting company. A brief description is given below.

Roundel Print is a small printing company. Customer enquiries are receivedto which estimates are given. These usually result in an order being placed.


The order, on receipt, is given an internal job number and the work to becarried out by various departments documented on an internal job sheet.The cost of work done is calculated by each department involved with thejob and then totalled for the job. This total is then used to calculate the priceto be charged to the customer. Customers are sent a weekly invoice whichcovers jobs completed in the previous week.

The document in Figure 10.4 is used as a source of data.

10.5.1 Gathering dataIn the real world, the most readily available source of attributes for inclusionin the proposed system is documents from the existing system, files, screens,printed reports, etc. Inputs, outputs and data structures designed for the newsystem should also be normalised to ensure the correct representation ofrelationships between the data. Care must be taken when normalising existingsystem data to recognise any relationships between the data which may nolonger be required in the new system and to modify the logical structure torepresent the new system requirements.

The analyst must also look out for implied data. There are many possibilitiesof this, but one example is that of a particular meaning or status being attachedto the colour of the document. A customer order to be given priority overother orders may be recorded on to a pink sheet of paper, to contrast with thewhite of a normal order. This priority status may need to be recorded within

Figure 10.4 Roundel internal job sheet.


the new system and an attribute to hold such information must be present. Afurther warning to the analyst is to check for areas of documents which arebeing used for a purpose not originally intended. Normalisation should bebased on data drawn from as many sources as time will allow, in order thatall data and relationships are identified.

The attributes extracted from the document in Figure 10.4 are listed in Figure10.5. This list is called the unnormalised data.

10.5.2 Choosing a keyA key which uniquely identifies this particular grouping of data is job number.Sometimes one attribute alone is not sufficient to accomplish this and two ormore may need to be concatenated together. Sometimes, there are severalattributes which would serve equally well as keys. In such cases the analystmust ascertain from the user which attribute is most relevant to the businessand which is least likely to be changed. If the relation shown in Figure 10.3 isexamined, it appears that either product number or bin number might serveas the key (assuming that each is unique and there is one product per bin,and one bin per product). However, the attribute of most relevance to thebusiness is the product number; this is therefore the better choice of key.

10.5.3 Converting to first normal formFirst and second normal forms are not significant in themselves, except asstepping stones to third normal form. Conversion to first normal form involvesthe removal of repeating groups of data. The presence of repeating data in afile has many disadvantages, as described earlier, so such data is removed to

Figure 10.5 Unnormalised data.


a separate relation. Since the link between the departmental costs and theoriginal job must not be lost, job number (the key of the original relation)must be added to the new relation, which has been called job cost. A keymust then be selected to identify uniquely any occurrences within this newrelation. Job number and department code together will do this. This type ofkey is called a compound key.

This gives the two relations shown in Figure 10.6.

10.5.4 Second normal formThis step is concerned with relations already in first normal form. It affectsonly relations with more than one attribute in the key. (Relations with single-attribute key are, by definition, already in second normal form.) The questionmust be asked for each non-key attribute, ‘Is it dependent on the whole keyor only a part of the key?’ The meaning of dependency is explained below inrelation to the Roundel example.

Department name can be determined uniquely from department code, andwill remain the same regardless of the job number associated with it. Thedepartment name is dependent on department code but not on job number.As such it is removed from the original relation and a new relation created asshown in Figure 10.7, with just department code as its key.

Department cost per hour is a more difficult choice. If this remains thesame regardless of job number, it is only dependent on department code, andit too must be removed to the new relation with department number as itskey. However, if it varies depending on both the job and the department code,

Figure 10.6 First normal form.


Figure 10.7 Second normal form.

it will remain in the original relation. Such questions need to be discussedwith the users of the data to ensure that the business view is taken. In thiscase department cost per hour is found to be dependent on department codeonly.

Time for this job will depend on both the department involved and theparticular job, and so remains in the relation with both job number anddepartment code as the key.

Department total cost is calculated by multiplying department cost perhour by time for this job. More consideration is given to derivable attributessuch as this at a later step. For the moment they receive the same treatment asother attributes. Department total cost is dependent on both job number anddepartment code.

The resulting relations in second normal form can be seen in Figure 10.7.

10.5.5 Converting to third normal formThis step is performed for relations already in second normal form andconsiders the dependencies between non-key items. For each non-keyattribute, the question needs to be asked, ‘For any one value of this attributeis there always just one value of another attribute, without reference to thekey?’ If the answer is yes, the attributes involved are taken out to form aseparate relation, with the determining attribute as the key. The determiningattribute also remains in the original relation to maintain the link with theoriginal key, but is marked as a foreign key.

This is illustrated by the Roundel example. For any one customer ordernumber, it is ascertained from the user that there is just one customer number,


Figure 10.8 Third normal form applied.

customer name, customer address, customer order date and order requiredby date. These are taken out as a separate relation, which will be called order,with customer order number as its key (see Figure 10.8). The other Roundelrelations show no dependency between their attributes.

When normalisation has reached this point, the analyst should alwaysrecheck all relations to ensure that nothing has been missed, and that therelations really are in third normal form. On rechecking, it can be seen thatthe order relation is not yet in third normal form as customer number uniquelyidentifies customer name and customer address without reference to customerorder number. Therefore these are removed to a separate relation as shown inFigure 10.9.

10.5.6 OptimisationThis step is concerned with the consolidation of data from many sources,compiling a full set of attributes for each normalised relation. The analystshould normalise as many documents and other sources of data as time allowsto ensure that no attributes have been missed. Data from each source shouldfirst be normalised separately, and once in third normal form the resultingrelations brought together. Any relations with identical keys should becombined, their attributes being pooled, but with no duplication. The onlyattributes that may legally be duplicated after normalisation are keys, part-keys or foreign keys.

The rule for third normal form should always be reapplied afteroptimisation to ensure that no data dependencies have been reintroduced.

Care should be taken throughout the normalisation process never toeliminate attributes, unless it is certain they are derivable. Derivable attributes,i.e. those which can be calculated from others, are not required in a logicalmodel of the data as they represent a form of redundancy. In the example, the


Figure 10.9 Third normal form after checking.

Figure 10.10 Order form.


attributes total job cost and department total cost can be calculated from otherattributes and so are not required. It may be argued that these could havebeen removed at the outset (i.e. not included at all in the normalisationprocess). Whilst this approach is often taken, if derivables are included untiloptimisation, a relation may emerge which has only derivable attributesinitially, and its very presence in third normal form may prompt the discoveryof other attributes applicable to it. If derivables are omitted at the start, thereis a danger that such information may be missed.

An example. The following example shows third normal form of the data asa result of carrying out RDA on three documents, an order (Figure 10.10), adespatch note (Figure 10.11) and a picking list (Figure 10.12).

Dealer code and branch code is a composite key. A dealer can have severalbranches, therefore a dealer with a code of 016 could have four branches, 01,02, 03 and 04. Another dealer, 019, could have three branches also numbered01, 02 and 03. Therefore the branch code is not unique and must always beassociated with the dealer code.

Figure 10.11 Despatch note.


Figure 10.12 Picking list.

Notes to Figures 10.13–10.15.(1) The order number is Spare Parts Sales Ltd, sales order number.(2) Dealer code is a key in its own right, as the number is unique for each

dealer.(3) As the branch code is not unique, it cannot exist as a key by itself, it is

always associated with its dealer code.(4) Invoices are always sent to dealers. Orders come from branches and goods

are delivered to branches.(5) The despatch number is not part of this composite key as the quantity

outstanding is identified at the time of the order and will be identified bythe order number and the part number. Information on how much isoutstanding is kept with the order details not despatch details.

(6) ‘Total picked’ will have a value if the warehouse staff were not able topick the quantity requested. Breakages or damage to parts can occur, e.g.50 of part A05567 may be to be picked but there are only 48 in the bin.

(7) The field ‘description’ is not kept with this data. It is held with the partrelation and will be extracted from the document which contains detailsof new parts when they are added. Spare Parts Sales Ltd only makes useof the part number in their order processing system.

Only three documents have been put through RDA, there will be many moreused in the company which, when analysed, will produce the final third normal


Figure 10.13 Order third normal form.

Figure 10.14 Despatch third normal form.


Figure 10.15 Picking list third normal form.

form data model. Part, for example, will have attributes of description, costprice, selling price, quantity in stock, etc., these attributes being extracted fromdocuments or files other than the order form, despatch note and picking list.

After optimisation, the remaining relations are as shown in Figure 10.16.

Figure 10.16 Optimised relations.


The despatch note data group,

Despatch numberPart number

Total despatched have disappeared, as the ‘total despatched’ of any one partnumber can be calculated. It is possible for one despatch note to detail thesame part more than once if they came from different orders.

The picking list data group,

Despatch numberPart numberTotal to despatch

Total despatched has disappeared, as the ‘total to despatch’ is an accumulationof the current quantity ordered for a part plus any outstanding orders forthat part, details of which are held in the order items relation. The ‘totaldespatched’ is the number of the part actually picked, if different from thequantity to pick. This figure is not stored but used to amend ‘quantitydespatched’ and ‘quantity outstanding’.

In the Roundel Print example the final relations are as shown in Figure10.17.

10.6 Building an entity relationship diagram from thirdnormal form relations

In order to compare the results of RDA with those obtained from entityanalysis, an ERD must be produced from the normalised relations. This is astraightforward matter of applying the following rules to optimised relations.

(1) Produce a TNF data group by drawing a rectangle. Name the relationand place the key fields, including foreign keys, in the box. This is knownas a TNF data group.

(2) Composite keys contain foreign keys.(3) All masters of compound keys must be present.(4) Compound key relations become details.(5) Foreign keys indicate masters.

Continuing with the Roundel Print example (see Figure 10.17), these ruleswill now be considered.

10.6.1 Rule 1Produce a TNF data group by drawing a rectangle. Name the relation andplace the key fields, including foreign keys, in the box. This is known as aTNF data group. Figure 10.18 shows data groups derived from the TNFrelations in Figure 10.17.


10.6.2 Rule 2Composite keys contain foreign keys.

There are no composite keys in the Roundel Print example. Consider Figure10.19 from the order processing example, where dealer code and branch codeis a composite key. Mark the top element of the composite key with an asterisk,indicating a foreign key only where the composite key is the only key (see theconsultancy example in Figure 10.20).

10.6.3 Rule 3All masters of compound keys must be present.

Where a key is a compound key (i.e. part of the key refers to a relation),make sure that there is a box for each part of the key. For example, the job cost

Figure 10.18 Third normal form data groups.

Figure 10.17 Roundel Print relations.


Figure 10.19 Composite key.

Figure 10.20 Consultancy example.

relation has a compound key of job number and department code. There mustbe a relation (box) for each of those keys. The relation job has the key of jobnumber and the relation department has the key of department code.

This is not the case where the key is a composite key. In the example inFigure 10.19, branch code is just a qualifying element indicating which branchof which dealer has made the order. The branch code is not unique andtherefore cannot stand alone, so no relation (box) is created for it.

Another example of Rule 3. This example is taken from a consultancy situationwhere consultants carry out projects, each project being broken down into anumber of activities. In order to monitor work done, time and expense sheetsare completed by consultants each week showing work and costs associatedwith each activity in which they are involved. Project number plus activitynumber make up a composite key.


Figure 10.21 Add third normal form data.

From Figure 10.20 it can be seen that part of the compound key in allocation,the composite key project number plus activity number, occurs in its ownright, in activity. Consultant number is the primary (only) key in consultant.In the compound key in time & expenses, the composite key project numberplus activity number occurs in activity, consultant number in consultant, butthere is no master for week number. A TNF data group must be created forweek number to satisfy rule 3, as in Figure 10.21. At a later stage, this datagroup may be removed if no other data items are found to be associated withit or the analyst decides that it will not be efficient to keep it as a separate datagroup.

Note that in Figure 10.20 the composite key in activity is marked with anasterisk according to rule 2. Each occurrence of the composite key is not markedas a foreign key; it is only necessary where the composite key occurs as theprimary (only) key.

10.6.4 Rule 4Compound key relations become details.

Here the data groups are connected together on a one-to-many basis.Starting with the largest compound key (the ‘many’ end), connect it to thedata group where the majority of that key exists. Continue connecting allcompound keys to their masters.

The Roundel Print example is shown in Figure 10.22.

Figure 10.22 Compound key relations for Roundel Print.


Figure 10.23 Compound key relations for consultancy example.

Figure 10.23 shows the consultancy example from Figure 10.20 with datagroups connected according to this rule.

In this example, time & expenses has the largest number of keys. It isconnected to allocation, which has the keys project number plus activitynumber and consultant number. This leaves the week number key in time &expenses: time & expenses is therefore connected to week.

Allocation is the next compound key. This is connected to activity (projectnumber plus activity number) and consultant (consultant number). Allcompound keys have now been dealt with.

Project is connected under the following rule.

10.6.5 Rule 5Foreign keys indicate masters.

Connect relations which have foreign keys (as the ‘many’ end of one-to-many) to the relation where the foreign key is the primary key.

In Figure 10.24, the relation order is connected to customer by the foreignkey customer number. The relation job is connected to order by the foreignkey customer’s order number.

Referring back to the consultancy example, in Figure 10.25, the relationproject has been connected to the relation activity through the top-level keyin activity (project number) being marked as a foreign key under rule 5.


Figure 10.24 Roundel Print rule 5.

Figure 10.25 Consultancy example rule 5.


Figure 10.26 Roundel Print entity relationship diagram.

10.7 Comparison of entity relationship diagrams from entityanalysis and relational data analysis

The TNF data structure is compared with the ERD by drawing a skeletonstructure of entities where the two match, together with their relationships.Any remaining entities on either diagram should be examined to see wherethey came from and whether they should be included on the final picture.

The ERD for Roundel Print is shown in Figure 10.26.It can be seen by comparing the two diagrams that there are two differences.

(1) The invoice was not discovered during normalisation. This illustrates inthis case that not enough sources of data were used, since the invoice wasnot represented in the documents normalised.

(2) The relationship between job and order was resolved as 1:1 during entityanalysis. Normalisation has recognised the possibility that a job and anorder may not be the same entity and that an order may be split intomany jobs. This point should be discussed with the user and, if it is certainthat the order will always represent one job and the job one order, the 1:1relationship should be chosen.

The final diagram for Roundel Print will include the invoice and, afterdiscussion with the user, leave order to job as a one-to-many relationship(Figure 10.27).

The approaches of entity analysis and RDA are very different. Entityanalysis concentrates on the business view. It is likely to get the businessview right for what it discovers, but is quite likely to miss some entitiescompletely and does not detail all attributes. RDA concentrates on the detail


Figure 10.27 Roundel Print final entity relationship diagram.

of the attributes and as such is likely to pick up more information and is lesslikely to miss entities. However, it may identify some entities that are notrelevant as separate entities to the business and it may identify relationshipsas one-to-many when they are in fact only used as one-to-one. It may alsogenerate redundant relationships that are not actually used by the system’sprocesses. Both approaches have their strengths and weaknesses, but acombination of the two ERDs should combine the strengths and cover theweaknesses of each technique.

Further refinement of the ERD will result from checking access requirementsto ensure that data are available to support the required processes and thatthere are processes to use and maintain the data.

10.8 SummaryThe aim of RDA is to produce a set of normalised relations which can be builtinto an ERD. The entities and their relationships are defined in a way thatremoves redundancy, separates independent attributes and groups mutuallydependent ones. The ERD produced by RDA is a logical model of the datawhich can then be compared and combined with the results of Entity Analysisto provide a reliable model of the true data structure from a business point ofview. This refined ERD can subsequently be used as a sound basis for physicaldesign.


Receipt Number 11223

WELCOME TO KEAI FURNISHINGS STOREStore 1122 Warrington – VAT Number 9933775566Telephone: +44 20 111 3323 5566Open 9.00 – 17.00 Monday to Friday and 9.00 – 1800 Saturday

‘Look out for half-price items in store this week’

Receipt in £ sterling

Item No Item Price StorageDescription location

36680540 Desk Organiser 7.00 A33003875 Roller Blind 29.99 C56578485 Dining Table 233.00 A

subtotal 269.99

TOTAL 269.99

Exercises10.1 What are the benefits of Relational Data Analysis?10.2 What is a relation?10.3 Using the till-receipt below perform the process of Normalisation to

Third Normal Form.You should show all stages from the un-normalised data, 1st NormalForm, 2nd Normal Form through to 3rd Normal Form.If you make any assumptions about the data, state what those assump-tions are.

Analysing access requirements 229

11Analysing accessrequirements

IntroductionIn Chapters 9 and 10, techniques were introduced for building an EntityRelationship Diagram (ERD) to show the logical structure of data which thebusiness wants to use. The ERD is initially based on data held in the existingsystem, as it is usually safe to assume that the data used and processed by thenew system will be largely the same in content. The existing system ERDmust then be modified in the light of new processing and informationrequirements to produce an ERD for the new system. This new system ERDforms the basis for physical database or file design. Whilst the logical structuremay not represent exactly the final physical structure of the data, it doesrepresent the most flexible structure from the point of view of data access. Atthe physical design stage changes may have to be made which compromisethat flexibility in order to obtain the necessary performance.

To ensure that the logical model contains the data and relationships tosupport the processing requirements of the new system, all data accessesrequired by the new system processes must be checked against the ERD. Thiswill determine two things:

❏ whether the data held within the ERD are sufficient to satisfy the system’sprocessing and information requirements;

❏ how many logical accesses are necessary to obtain the required data, andthus whether the accesses are feasible. The need for a large number ofaccesses for a time-critical process at the logical stage indicates a problemwhich must be addressed at the physical design stage.

230 Analysing access requirements

Figure 11.1 Entity/process matrix for Roundel Print.

In this chapter, access requirements will be analysed by drawing an entity/processing matrix and by examining the number of logical accesses required inrelation to the ERD.

11.1 Entity/process matrixThis matrix is a way of checking that the logical data structure described bythe ERD represents all data needed to support the system’s processes, andalso that the necessary processes exist to support and maintain the data.

The matrix is a grid, as in Figure 11.1, in which all lowest level processesfrom the new system Data Flow Diagrams (DFDs) (those for which mini-specs should be written) are listed down the side and all entities from thenew system ERD (after refinement by comparison with the results from entityanalysis) across the top.

The matrix in Figure 11.1 applies to the Roundel Print example encounteredin earlier chapters. For the purpose of the following observations, we mustassume that it contains all lowest level processes for the new system, and allentities within the boundary of the new system.

The matrix should be checked to ensure that processes exist at least to createand read occurrences of each entity, and usually to delete them too. If this isnot the case, it implies that some processing has been overlooked. Furtheranalysis must be done and the DFDs updated when the missing processesare identified. In Figure 11.1 the Customer and Department entities areexamples of this, as they are apparently only ever read. Processes to create,update and delete these must be defined. If an entity is created, read anddeleted but never updated, again the completeness of the processing must be


questioned. How will the information within the entity be kept up to date?Occasionally, it is permissible that entity occurrences are not updated, if thedata is for reference only.

Full analysis of the matrix can go much further than this, to record theusage of each attribute within each entity. Checking should also ensure thatevery attribute of every entity is used and that sufficient data are present toallow each process to be performed. Processes which update and create butdo not read anything, for example, require further investigation to establishon what basis they are making their update decisions. An input data flowshown on the DFD may be sufficient, but this should be checked.

The entity/process matrix is a very powerful tool for checking thecompleteness of the new system definition. It can, unfortunately, become verylarge for a sizeable system, but automated tools are available which willproduce the matrix and help to analyse it.

11.2 Access paths through the entity relationship diagramThe new system ERD, supported by the documentation of attributes resultingfrom normalisation, embodies all data to be stored in the new system and therelationships between them. This can be seen as the logical database. A usefulinput to the physical design of the database or files is an analysis of how thelowest level processes from the DFDs will need to navigate around the ERDto obtain the required data. This technique goes under the various names ofaccess path analysis, transaction analysis, access profile analysis and logicalenquiry/update process outlines.

The implication of the ERD model is that data can be obtained by travellingaround it, via the relationships that link the entities. In particular, the followingtwo assumptions can be made:

❏ any entity can be accessed directly if its key is known;❏ it is possible to travel along the relationship line that links any two entities

in either direction.

The validation of the ERD by checking access paths is concerned with findingwhether there is a path through the ERD to the data required. It may frequentlybe found that there are several paths. In this case, the physical designer willchoose the optimum path. On occasions there may be no path to the datarequired. In this case, further work is necessary to check that the accessrequirement has been interpreted correctly and, if it is found to be correct, tomodify the ERD.

Figures 11.2 and 11.3 show, respectively, the refined ERD and attribute listresulting from relational data analysis and entity analysis, described in Chapters9 and 10. These will be used to illustrate how access paths are followed anddocumented, and how the number of accesses required is calculated.


Figure 11.2 Refined entity relationship diagram.

Figure 11.3 Refined attribute list.


Figure 11.4 Access path.

As an example, the access path for one new system requirement will befollowed. The lowest level process concerned is required to:

❏ list by name and department code all departments currently doing workfor a particular customer.

The access would start with the entity for which we have a specific key, i.e.the key of customer: customer number. From there it would proceed to job,then to job cost and finally to department. In passing through each entity, theprocess can be assumed to pick up (and retain for future use) all attributesassociated with the entity.

There are many ways of documenting an access path. One way is a dataaccess diagram (see Figure 11.4) with the access path being read from top tobottom. The reader should notice that the crow’s feet are still shown in thesame orientation to the entities as they appeared on the ERD, and that accessis allowed towards and away from the crow’s foot.

To calculate the number of accesses required, it is useful to annotate thediagram with some volumetric information. In Figure 11.4, the numbers refer


Figure 11.5 Number of accesses for an access path.

to accesses required. Initially, it is usually sufficient to work with averagefigures, unless maximums are known to be considerably higher and likely tobe frequent enough to cause problems.

The number of occurrences of each entity likely to be on file at any onetime must be estimated. For the example, the following figures will be used:

Customer 200 occurrences;Job 800 occurrences;Job cost 8000 occurrences;Department 10 occurrences.

The number of accesses required for this particular access path can now becalculated. In Figure 11.5 the number of accesses of each entity for eachoccurrence of the entity above has been written against the relationship lines.

Thus, since there are 200 customers and 800 jobs on file, for each access tocustomer, four accesses to job (on average) will be made. The actual numberof accesses for this requirement is written against the entities themselves. For


Figure 11.6 Access paths to update job cost.

each access to job there will be ten to job cost, but since there are four accessesto job there are 40 to job cost. For each access to job cost there is one access todepartment (the relationship is only 1:1 in this direction). Since there are 40accesses to job cost, there are 40 to department. The total of these accessesthen represents the logical number of accesses for this access path.The number of accesses can be used by the system designer to assess thefeasibility of the accesses and adapt the physical implementation of the datamodel according to usage and timing considerations. Ideally, access pathswould be worked out by the analyst for all access requirements in all lowestlevel processes. This is rarely practical, however, unless the system is verysmall.

The analyst should therefore concentrate on the most time-critical on-lineaccess, where this technique will yield maximum benefit.

The data access diagram can be further annotated to show where accessesare not just reads but updates, creations or deletions of entity occurrences.This is usually done by entering the appropriate operation within the entitybox. Figure 11.6 shows the data access diagram for an update to the job costentity occurrences following a change of rate for one department.

11.3 SummaryThe ERD represents data, and the relationships between data, required bythe business to support the new system. It represents the most flexible structurefor the data but is not usually the most efficient from a performance point ofview. By creating an entity/process matrix, the completeness of the ERD andDFDs can be checked. By looking at access paths required to obtain data for


at least the most time-critical accesses, the practicality of those accesses canbe assessed, communicated to the designer and discussed with the user.Physical design for the data can then be made in awareness of where theproblem areas are likely to be, and optimised to ensure the necessaryperformance in areas most critical to the business.

Exercise11.1 Consider the Entity Relationship Diagram below for a Computer

Wholesale Company which receives orders from customers bytelephone, email and post.

CUSTOMER

ORDER

ORDERITEM

PRODUCT

DEPOT DEPOTSTOCK

The sales manager wishes to know which customers have ordered aparticular product in order to offer them an enhancement upgrade tothat product. Consider the question ‘Name all customers who haveordered Product 1234’.

Is it possible to get that information via the ERD and how manyaccesses are necessary to find out that information?

During Analysis it was found that the Company had 50 Customers,500 orders totalling 2,500 order items from 1,250 products which thecompany sells. The company has 5 depots and holds stock of 12,500items.

11.2 Describe an Entity Process Matrix and explain what it shows?

Entity life histories 237

12Entity life histories

IntroductionFor an analyst to understand a system thoroughly, it is necessary to examineit from a number of different viewpoints. Two such viewpoints are representedby Data Flow Diagrams (DFDs) and entity analysis.

DFDs look at the system from the standpoint of its processes, indicatingthe relationship between processes in terms of the data passing between themand to and from data stores and external entities.

Entity analysis looks at a system from the point of view of its data, indicatingthe way in which data items are grouped together into entities and specifyingthe relationships between entities.

These two views of a system are essentially static. DFDs do not necessarilyshow the sequence in which processes are performed, and an entity modeldoes not indicate how the model changes with the passing of time. Forexample, the content of entities changes as entity occurrences are added tothem or deleted from them, the values of attributes within entity occurrenceschange and the relationships between entities are created or deleted. DFDsand entity analysis, even taken together, provide only a partial representationof a system. Entity Life Histories (ELHs) look at a system from a thirdviewpoint, providing a means of representing how entities change within asystem with the passage of time. ELHs start with the creation of an entityoccurrence, record the sequence of changes that take place during its life withinthe system and end with its removal from the system.

238 Entity life histories

12.1 When are entity life histories produced?The ELH is both an analysis and design tool. It should be used during logicalsystem design to validate the completeness and correctness of DFDs and dataanalysis, and again alongside analysis of access requirements (see Chapter11), to ensure that all events which cause changes to entities are considered.

Looking back to Figure 1.2 in the Introduction of this book, ELHs wouldbe produced initially in box 3, used in box 4 and modified in box 6.

12.2 Concepts and terminologyBefore describing ELHs, a number of concepts needs to be understood. ELHsare used to help to define the logic associated with update processes, so anexamination of processes provides a starting point.

12.2.1 Update processesProcesses can be divided into two types: those which change the system’sdata, and those which simply reference it. They are called update and enquiry/retrieval processes, respectively. ELHs are concerned with update processesonly.

Figure 12.1 represents an update process on the DFD. Update processingwithin the process ‘create new customer’ may include:

❏ a validity test of the format of the input data flow;❏ a check that the customer is not already on file;❏ creation of a new occurrence of the customer entity.

Update processes may also include other processing to produce output dataflows and to deal with error conditions.

12.2.2 EventsAn event is anything that activates (triggers) an update process. It may be thereceipt by the process of a particular data flow, or it may be the arrival of aparticular point in time, e.g. ‘end-of-day’, ‘month-end’, ‘year-end’, which isrecognised by the system.

Figure 12.1 Update process.


12.2.3 Input data flowThe receipt in Figure 12.1 of the input data flow ‘new customer details’ is theevent that triggers the process ‘create new customer’.

12.2.4 Time-based eventsTime-based events are not normally shown on a DFD, except by default, i.e.the absence of a data flow from an external entity to an update process mayindicate that the event is time based (see Figure 12.2).

12.2.5 EffectsA single event may cause more than one entity to change, i.e. it may havemore than one effect.

An effect can be:

❏ the creation or deletion of entity occurrences;❏ changes to the attributes of entity occurrences;❏ the creation or deletion of relationships;❏ a combination of the above.

Frequently a data flow that appears on a high-level DFD will have an effect onmore than one entity. The example in Figure 12.3 shows how the receipt of acustomer order triggers the creation of an internal job and the updating of twoentities. The example is related to Roundel Print, encountered in Chapter 9.

This may be broken down in a lower level DFD as shown in Figure 12.4. Inconstructing ELHs, events are defined as they are represented on the lowestlevel DFDs.

Figure 12.2 Time-based event.


Figure 12.3 High-level data flow diagram input data flows.

Figure 12.4 Lower level data flow diagram.

12.2.6 Sub-eventsA single event may result in different effects depending on the condition ofthe data when the event occurs. In such cases, the different effects are said tobe caused by sub-events, which are the combination of an event and thecondition of the data within the system at the time that the event takes place(Figure 12.5).

It is essential that conditions which cause different effects (given the sameevent) can be recognised by the system. Recognition of differing conditions


Figure 12.5 Sub-events.

may entail the addition of new attributes to entity descriptions. Note that theeffects could be on different entities.

Identified sub-events are treated as ordinary events, but the event nameshould be qualified by the condition, as in Figure 12.6.

12.3 Entity life history notation12.3.1 General structureAn ELH is a pictorial means of representing events that can affect the life ofan occurrence of an entity, from its creation within the system to its deletionfrom the system. The general structure of an ELH is indicated in Figure 12.7.The events follow the sequence create, amend, delete, from left to right in thediagram.

The diagramming technique used here is based on Jackson StructureDiagrams. The conventions used are the same, but the reader who knows thetechnique from programming should beware. The concepts of the diagramare different, with boxes representing events in the life of an entity rather thanprogram sections or modules.

Figure 12.6 Qualified sub-events.


Figure 12.7 General structure of an entity life history.

The top box always contains the name of the entity. Lower level boxesrepresent events that can happen during its life within the system.

The diagram is a hierarchy. Each lower level box will only be related(connected) to one higher level box. The higher level box represents a sequencemade up of the lower level boxes connected to it.

It is usual to consider the most common sequence of events first, adding inabnormal events once an initial diagram has been drawn.

The structure diagram is based on three constructs:

❏ sequence;❏ selection;❏ iteration.

These will be explained in relation to Figure 12.8, which illustrates a simplifiedELH for the entity Customer for Roundel Print.

Sequence. The ELH in Figure 12.9 states that new customer authorisation isthe first event to have an effect on customer, followed by customer amendment,followed by customer deletion, followed by monthly archive. These eventsalways happen and always in that sequence. This is rather restrictive butthere are ways around the strict sequence by using the other constructs.

Selection. The symbol ‘o’ in the top right-hand corner of a box denotesselection.

In Figure 12.10 the diagram states that a detail change event is either acredit limit change or an address change. It is never both, but it is always oneof these. A choice of more than two events is allowed.

Iteration. The ‘*’ in the top right-hand corner of a box denotes iteration.Figure 12.11 states that the event customer amendment consists of zero, oneor many detail changes. Looking back to Figure 12.8, the sequence of events


Figure 12.8 Customer entity life history.

Figure 12.9 Sequence.

Figure 12.10 Selection.

Figure 12.11 Iteration.


Figure 12.12 Option.

at the first level can now be read as ‘the entity customer will be affected(updated) in its life by a new customer authorisation, followed by zero, oneor many detail changes (in the customer amendment event) followed bycustomer deletion followed by monthly archive’. Thus the strict sequence ofeach event being compelled to happen has been circumvented by the zeroaspect of the iteration. Customer amendment may happen zero times.

It should be noted that the ‘*’ and the ‘o’, which denote iteration andselection, respectively, must not appear at the same level as sequence boxes(unmarked) since confusion could arise.

12.3.2 Optional eventsAn optional event is one which may or may not occur.

The situation represented in Figure 12.12 is that customer reinstatementmay or may not occur. It is represented by a selection box containing theword ‘possible’ with two boxes underneath representing, respectively, theevent (or group of events) that may occur, and a null box to represent theevent (or group of events) not occurring.

12.3.3 Parallel structuresNot all events occur in strict sequence.

Figure 12.13 illustrates the fact that the job amendment event may occurindependently of the job progress event. Job progress is an event whichcontains regular updating of how far work on a job has progressed (thenecessary lower levels of the ELH are not shown here). At any time, thecustomer may require the job to be modified. The parallel lines indicate thatthe two groups of events are not sequential, but can occur in parallel withone another.


Figure 12.13 Parallel structure.

Figure 12.14 Quit and resume.

12.3.4 Quit and resume sequence changeIn Figure 12.14, if customer reinstatement happens, the sequence should notgo to monthly archive, but should restart at customer amendment. This canbe achieved by using Q1 against customer reinstatement to indicate that thesequence quits here and resumes at R1. If other events similarly change thesequence matching pairs of Q2–R2, etc., should be used.

12.3.5 State indicatorsState indicators can be added to the ELH diagram to clarify the allowedsequence of events. In the physical system they can be represented as an extraattribute against the entity and used to control the sequence of processingassociated with the events in the ELH. Thus they are a valuable aid tomaintaining system integrity by detecting events arriving in the wrongsequence.


Figure 12.15 State indicators: sequence.

State indicators are assigned to the lowest level boxes of the ELH structureonly.

The state indicator has two values:

❏ a before value of the entity, valid before the event takes place;❏ an after value, set by the processing associated with the event, once it has

been completed.

The state before the first allowed event and after the last is null, indicated by‘–’. In Figure 12.15, after the first allowed event, ‘confirmation of attendance’,the state indicator is set to 1. On arrival at the second event ‘examinationresult’, the state indicator is set at 1; after the event has taken place it is set to2. On arrival at the event ‘notification of pass’ the state indicator must be 2;after the event has taken place it is set to null. Figure 12.16 expands thesequence, including a selection of events for examination result.

Figure 12.16 State indicators: selection.


Figure 12.17 State indicators: iteration.

In Figure 12.16, after ‘confirmation of attendance’, where the state indicatoris set to 1, there is a selection of either a written examination result, an oralexamination result or a null result. The state indicator comes in at 1 and is setto 2 or 3, depending on which option is chosen. A null event does not needstate indicators as it does not have an effect. The final event ‘notification ofpass’ comes from either ‘confirmation of attendance’ (having passed throughthe null event), written exam result or oral exam result, hence the 1,2 or 3 inthe before value.

In the example in Figure 12.17, written and oral examination results areiterated, therefore on the first occurrence of ‘written exam result’ the beforeindicator will be set at 1 and after the event will be set to 2. This followed bythe ‘oral exam result’ event, which sets the state indicator to 3. On the secondand subsequent iterations the before state indicator for ‘written exam result’ isset at 3, having come from ‘oral exam result’ in the previous iteration.

The final event ‘notification of pass’ can come from ‘confirmation ofattendance’ (iteration can be zero) or from the last iteration of ‘oral examresult’.

An example. The following example outlines the events which affect theentity casualty at a major hospital.

A casualty entity is created whenever someone enters the hospital throughthe accident and emergency department and is deleted three years after the


patient has been discharged. All events described below cause modificationto the entity.

A preliminary examination is carried out, the outcome of which will be to:

❏ admit to a ward;❏ administer first aid, then admit to a ward;❏ administer first aid, then discharge;❏ discharge.

Following admission to a ward a full examination is carried out by a doctor,who will prescribe a course of treatment. The course of treatment is carriedout and may consist of:

❏ administration of drugs❏ operation❏ physiotherapy

A course of treatment may use one of these exclusively or any combination ofthem (e.g. administration of drugs on many occasions, or an operationfollowing by physiotherapy more than once).

On completion of a course of treatment a progress examination is carriedout by a doctor, who may then discharge the patient or prescribe a furthercourse of treatment.

The ELH for this is shown in Figure 12.18.Note how state indicators can be written as 5, 6, 7, 8, 9/6 or 5–9/6; both

have the same meaning.

12.4 Constructing entity life historiesIn order to construct ELHs the following steps should be taken:

❏ identifying events;❏ producing ELH matrix;❏ drawing initial ELHs;❏ reviewing ELHs;❏ adding state indicators

12.4.1 Identifying eventsIn order to identify the events associated with an entity, it is helpful to askthese questions:

❏ What causes entity occurrences to be created and deleted?❏ What causes changes to attributes?❏ What causes relationships to be established and to change?

Information will be available from the analysis done so far, particularly in the


Figure 12.18 Casualty entity life history.

DFDs and ERD. Further questions which arise from using the techniques willneed to be directed to the user.

In the library system example the entities identified were book, borrower(member), issue, topic, author and reservation

Examining the lowest level DFDs provides most of the events that have aneffect on those entities (see Figure 12.19).

On receipt of notification from a member that they have resigned, theborrower entity will be affected. However, on examination of the ERD in Figure12.20, borrower is related to issue and reservation, so cannot be deleted untilany outstanding books or reservations have been dealt with.

12.4.2 Producing an entity life history matrixThe ELH matrix is a grid that identifies the entities affected by a particularevent. Events are written along the top of the grid and entities down the side.


Figure 12.19 Library low-level data flow diagram.

Figure 12.20 Borrower entity relationship diagram.

Entries are made in the grid as shown in Figure 12.21, which is a part matrixshowing some of the events. Where they affect an entity this is marked as Cfor Create (or I for Insert), M for modify or D for delete.

Having completed the grid, checks should be made to ensure that:

❏ every event affects one or more entities;❏ every entity has an event which created it;❏ every entity has an event which deleted it.

Omissions discovered during checking will show where events or effects havebeen missed and further investigation is required.

12.4.3 Drawing initial entity life historiesIdeally, an ELH should be developed for every entity on the ERD. If this isnot possible because time is short, the greatest benefit will be derived fromconcentrating on the entities with most complex lives. These are usually theentities on the ERD which appear more often at the ‘crow’s foot’ end of one-


Figure 12.21 Entity life history matrix.

to-many links and less often at the ‘one’ end. Another way of looking at thisis that these entities are more often a detail and less often a master. It is best towork in sequence from events which create the entity, through the life, untilfinally the events which delete the entity from the system are reached. Thequestions below will help:

❏ Are the attributes all created when the entity is created? If not, how dothey get there?

❏ How is each attribute amended/deleted?❏ What will cause the entity to change its relationship with its master(s) or

detail(s)?❏ What will cause optional relationships to be created/deleted?❏ What are the obviously important milestone events in the life of the entity?

Even though they have no direct effect on the entity, they may point toother events that do.

12.4.4 Reviewing entity life historiesThe following aspects of ELHs should be reviewed:

❏ the ELH matrix should be checked again with respect to additional eventsidentified during the development of the ELHs;

❏ events must be checked to ensure that they can be recognised by the system,e.g. for the event delete member to be recognised, the trigger return ofbooks must contain some indication that all books borrowed have beenreturned;

❏ the same qualified event should not appear more than once in an ELH. Thesame event may well do so but the occurrences must be qualified byappropriate conditions to make them unique.


12.4.5 Adding state indicatorsWhen ELHs are first constructed, their main purpose is to provide a thirdview of the system based on the changes to each entity caused by the passageof time. As a result, modifications may be made to DFDs, providing a morecomplete specification of system requirements.

ELHs may have to be revised as the result of normalisation and thedevelopment of an ELH for one entity may uncover new information relatedto another. When such changes have been made and the analyst is confidentthat the final, complete ELHs have been developed, state indicators shouldbe added.

12.5 SummaryThe ELH is both an analysis and a design tool.

During the specification of the required system, ELHs are used to validatethe completeness and correctness of DFDs and the ERD. This is done byexamining what causes each entity in the ERD to be created, amended anddeleted within the system.

In physical design, the priority and sequence of the processing logic whichforms the basis of program specifications can be derived from ELHs.

Exercises7.1 What kinds of processes are ELHs drawn for?7.2 What is an event?7.3 What is an effect?7.4 What are the three logical constructs shown by ELH structure diagrams?7.5 The following example outlines the events that affect the entity GUEST

at a hotel:A GUEST entity is created whenever someone makes a booking with thehotel and is deleted three years after the guest’s last booking with thehotel.All events described below may cause modification to the entity GUEST.❏ Guest books for the first time, and reserves a room.❏ Guest arrives to stay in the room, and the date of their intended leaving

is recorded on GUEST (this will be used, long after RESERVATIONentity occurrences have been archived, to determine an ‘Active Guest’,and is not to be deleted).

❏ Guest notifies a change of their details at any other time.❏ Guest pays the bill and leaves (date of end of stay is recorded on GUEST

entity).❏ Guest is sent a mailshot when special offers are available (date of

mailshot recorded on GUEST entity).Create an entity life history for the entity GUEST.

Logical systems modelling 253

13Logical systems modelling

IntroductionEarlier sessions in this book gave an overview of the structured analysismethodology and showed where the various tools of structured analysis areused, namely:

❏ Data Flow Diagrams (DFDs);❏ Data Dictionary (DD);❏ miniature specifications (mini-specs);❏ Data Analysis [Entity Analysis and Relational Data Analysis (RDA)];❏ Entity Life Histories (ELHs).

Logical Systems Modelling is the transition from the analysis of the currentsystem to the specification of the new system.

This involves two transformations which correspond to boxes 2 and 3 inFigure 1.2. Together, these two stages may be described as logical systemsmodelling. The two stages are logical in that they describe what the informationsystem is to do rather than how to do it.

Many of the problems associated with systems are caused by the way inwhich things are done, i.e. the how, when, where and who aspects. If the existingsystem could be described only in terms of what processing is done usingwhat data, then the problems associated with the way things are done areremoved from the picture of the existing system. This process is calledlogicalisation and the resultant modified view is known as the current logicalDFD.

Each physical implementation of a system will have its own problems.Often the task being attempted by a given process or series of processes is

254 Logical systems modelling

obscured by the way in which it is physically performed, e.g. reports beingsent to departments that no longer make use of them.

It is unrealistic to provide definitive rules for the derivation of a currentlogical DFD. It is, however, possible to provide some guidelines to assist thesystems analyst in this step.

13.1 Guidelines for the production of logical data flowdiagrams

(1) Replace physical data stores with main logical data stores.(2) Remove transient data stores.(3) Remove processing that cannot be automated.(4) Remove processes that only re-organise data.(5) Combine processes joined by data flows.(6) Combine processes performing the same function.(7) Minimise data flow content.(8) Obtain data only when needed.(9) Use meaningful names.

(10) Remove all references to physical location.(11) Remove processes that do not alter data.

The following scenario describes a consultancy company and is used toillustrate the guidelines.

13.1.1 An exampleEnquiries from existing or potential clients are received in the advisory servicesdepartment office from the company’s regional offices. A quotation isproduced in the advisory services department using information about similarprevious projects undertaken and current costs. The quotation is sent to theregional office, which forwards it to the client and awaits acceptance orrejection. A copy of the quotation is retained in a file of possible projects inthe advisory services department office.

If the quotation is accepted, the acceptance is forwarded to the advisoryservices department from the regional office and a project plan is produced.

Development of a project plan involves examining similar previous projectsin the light of the quotation and determining the skills and availability ofconsultants capable of undertaking the project. Consultants are allocated tothe project and one is designated project leader. The project plan consists of aset of activities to be undertaken, each activity being allocated to a specificconsultant. This is held in the current project file. The project plan containingthe activities is sent to the computer department, where it is recorded in acomputer file (the current project activities file) and a list of the activitiesallocated to each consultant is sent to them. The project then commences.


Weekly timesheets are produced by the consultants working on the project,together with expense sheets, detailing travel and accommodation costs. Theseare authorised by the advisory services department and then sent to thecomputer department for recording on the current project activities file. Thisis a two-part process. The data is entered on-line and stored in a temporaryfile as they are received, but the current project activities file is only updatedonce a week. The authorised expenses are also sent to the accounts departmentfor payment.

Activity reports are produced from the computer system at monthlyintervals. From these, the advisory services department produces a monthlyreport which is sent to the client and also filed in the current project file. Thedepartment raises proforma invoices, based on the activity reports, whichare sent to the accounts department (which is outside the area of study). Severalproforma invoices may be produced for one project, depending on theagreement reached with the client.

Figure 13.1 shows the current physical DFD for the above scenario.

1 Replace physical data stores with main logical data stores.The current physical DFDs will almost certainly contain references topermanent stores of data, e.g. filing cabinets, card indexes, manuals,catalogues, wall charts and main computer files.

Permanent stores are those files that are always present, although theirspecific contents may vary as information is added, changed or removed.Stores that only exist for the time it takes to process one or a group of processesare not normally defined as main data stores.

The current physical main data stores are unlikely to be direct equivalentsof Entity Relationship Diagram (ERD) entities; indeed, it is probable that eachwill contain data related to more than one entity. The contents of physicaldata stores also tend to be duplicated throughout the system, for such reasonsas:

❏ geographical location;❏ access requirements;❏ security;❏ history;❏ politics.

One of the objectives of logicalisation is to rationalise these references topermanent data stores. In constructing the current logical DFD, such referencesshould be replaced by the equivalent entity or entities. To do this may requireexamination of the data items associated with the physical data stores, inorder to establish which entities contain the attributes involved.

The ERD for the consultancy company is shown in Figure 13.2.


Figure 13.1 Level 1 current physical data flow diagram.

From Figure 13.1, it can be seen that the main physical data stores andtheir equivalent entities are:

Physical data stores EntitiesM1: Current costs GradeM3: Possible projects ProjectM4: Current projects ProjectD1: Activities Project + activityM5: Consultant data Consultant


Figure 13.2 Consultancy entity relationship diagram.

Figure 13.3 Physical process 1.

The current physical DFD for process 1, prepare quotation, is shown in Figure13.3.

By replacing the physical data stores in Figure 13.3 with main logical datastores, we obtain Figure 13.4.

2 Remove transient data stores.Transient (temporary) data stores that represent delays within the currentsystem should be removed. It is likely that they only exist because ofconstraints within the existing physical environment, i.e. processes that canonly be performed at certain times of the day or week owing to staffingproblems, or documents which are collected together awaiting an internalmail system.


Figure 13.4 Replace data stores with entities.

Figure 13.5 Physical processes 5 and 6.

In Figure 13.1, process 5 puts timesheets and expenses onto a temporaryfile (T6) which is used to update the project activities file weekly (process 6),as shown in Figure 13.5.

By removing transient data stores (i.e. T6) from Figure 13.5, we obtain Figure13.6.

3 Remove processing that cannot (or should not) be automated.Current physical DFD processes may include operations that cannot or shouldnot, within the terms of reference, be automated, i.e. ultimately turned into acomputer program. Examples of these are physical activities such as pickinggoods in a warehouse or replacing books on shelves in a library. These shouldbe removed from the processing and made into sources or sinks for data flows.

In the consultancy example, the actual project plan is created outside thesystem, leaving only the retrieval of required data inside (see Figure 13.7).


Figure 13.6 Remove transient data stores.

Figure 13.7 Physical process 2.

By removing manual processing from Figure 13.7 we obtain Figure 13.8.The dotted line between Regional Office and Advisory Services in Figure 13.8shows communication between external entities.

4 Remove processes that only reorganise data.Processes that only re-organise data in a data store should be removed. Inlogical terms, the physical sequencing of data is immaterial, since all requiredaccess paths are shown on the ERD. A sort process, as shown in Figure 13.9,would therefore be removed and not appear on the logical DFD.

5 Combine processes joined by data flows.On a physical DFD, it is possible to find processes which are joined by a dataflow. An example of this is where physically one process is clerical and theother computerised. Logically this distinction does not exist. Thus processes


Figure 13.8 Remove processing that cannot be automated.

Figure 13.9 Sort process.

should be connected only via entities and if there is no such link via an entity(i.e. they always occur together and are triggered by the same event) the twoprocesses should be merged. The only possible exception to this is when theprocesses joined must occur in different geographical areas and as such mustbe shown as separate processes.

However, at logical level, since reference to where processes take place isremoved, this separation usually becomes unnecessary. Therefore, Figure 13.6can be simplified to give Figure 13.10.

6 Combine processes performing the same function.Processes that are logically performing the same functions, although perhapsin physically different ways or locations (e.g. monitoring two physical filesthat are in fact representations of the same entity) should be combined intoone logical process.

Figure 13.11 shows a possible depiction of part of the administration systemfor the consultancy firm. This can be simplified by combining both processes,to give Figure 13.12.


7 Minimise data flow content.The content of data flows should be minimised to include only those dataitems required by the recipient process, entity or external entity.

The contents of each data flow shown on the logical DFD should be bothnecessary and sufficient. That is to say, every data element required by theprocess should be present in the data flow; no data element that is not requiredshould be contained in the data flow.

The necessity for and sufficiency of each data flow are examined byquestioning the purpose and method of the process that uses the data flow.In making data flows more logical it may be necessary to make new entries inthe data dictionaries to define the new logical data flows.

Figure 13.10 Combine processes joined by data flows.

Figure 13.11 Client administration.

Figure 13.12 Combine processes performing the same function.


Figure 13.13 Price invoice.

Figure 13.14 Minimise data flow content.

For example, Figure 13.13 shows that a product catalogue is referencedbefore invoicing goods used on a project. Not all of the product categoryentry is required to produce an invoice, so the data flow content is minimised,as shown in Figure 13.14.

8 Obtain data only when needed.Data items should only flow from a data store to a process when required bythat process, i.e. not retrieved by one process solely in order to be passed onto another.

9 Use meaningful names.All remaining references to the physical environment such as departmentnames should be removed. Data flows and processes should be given namesthat reflect their logical content or function as accurately as possible.


Figure 13.15 Add new consultant.

Figure 13.16 Use meaningful names.

For example, a physical document name should be replaced by a descriptionof the data flow it represents as required by the receiving process. Thus formCP6 in Figure 13.15 would be replaced by new consultant details, as in Figure13.16.

10 Remove all references to physical location.Logical processes show what is being done, not where or by whom. This isreflected by the removal of all references to location.

11 Remove processes that do not alter data.If data is not altered by a process, then that process should be replaced by adata flow. This will apply to processes that only retrieve data in order to printor display it.

13.1.2 Reconstructing the logical data flow model hierarchyThe removal of physical references and the rationalisation procedure describedabove take place on the lowest level processes, i.e. the lowest level DFDs. Thechanges introduced make it necessary to regroup the processes into higherlevel ones. In effect, this regrouping introduces new DFDs up to level 1.

When regrouping, there are three objectives to keep in mind:

❏ functions should not span more than one top-level process;❏ functions should be easy to identify;❏ an attempt should be made to group processes that update the same data.

The grouping of processes into higher levels should be based on a combinationof the following:


Figure 13.17 Process/entity matrix.

❏ the users’ perception of functional areas;❏ similarity of type between low-level processes;❏ group processes that access the same data.

Functional areas. If functional areas are based on the users’ perceptions, theresult could be a copy of the existing physical DFD grouping, or based on theorganisational structure.

Group processes that access the same data. It is very useful to group togetherprocesses that update the same data. This task can be made easier by creatinga process/entity matrix, which helps to identify which process affects whichentities.

A process/entity matrix for the consultancy example is shown in Figure13.17.

Consistency and completeness checks. One final activity is necessary beforethe process is complete, that is to carry out consistency and completenesschecks. It is important to ensure that no information or process has beenoverlooked, i.e. the new DFDs are complete and that the resultant structure isconsistent.

Check that all the following have been accounted for:❏ data flows;❏ processes;❏ data stores.Where components have been removed, the reason for their deletion shouldbe checked and documented. In addition, bottom-level processes on the logicalDFDs must be readily identifiable as a component of a function.

User involvement. The users must be heavily involved in the criticalexamination process, as they are the only people who might know why the


system is as it is. They should also be walked through the logical DFDs as afinal check on their validity.

It should be noted that the physical to logical conversion can rarely beachieved completely in practice. Some systems are so illogical in their currentform that they will defy the process described here. Nor must it be forgottenthat, in the real world, the analyst is subjected to pressures from both dataprocessing and user management to do something useful. It is an unfortunatefact of life that while the presence of bugs in computer systems is painfullyapparent, their absence is more likely to be taken for granted. A complete andthorough understanding of the logical requirements of the current system isan absolute prerequisite to the design of the new system.

13.2 Logical design of the new systemDuring basic fact-finding, analysis and critical examination of the currentsystem the analyst will have discovered many deficiencies in that system. Heor she will have confirmed with the users that some or all of the deficienciesshould be corrected and removed from the new system. In addition, in theirterms of reference the analyst may have some mention of features to bedesigned into the new system. All these are put together and called the userrequirements. This information, together with the current logical systemdescription, form the starting point for the logical design of the new system.This stage in systems analysis is shown as box 3 in Figure 13.15. There arefive broad activities in this transformation, and their relationship to oneanother is shown in the expanded DFD in Figure 13.18.

13.2.1 Identify boundaries of new systemThe first step in the design of a new system is to define precisely what thenew system is. This is done by examining the current logical system DFDsand mini-specs in the light of user requirements for the new system. Eachand every lowest level process on the current logical DFD and itsaccompanying mini-spec must be examined and the question asked, ‘Is thisprocedure affected in any way by the changes being proposed?’

If the answer is ‘Yes’, then the process is added to the list of processes thatlie inside the domain of change. At the end of this exercise all logical processeshave been divided into two lists, those affected by the changes and thoseunaffected. These can be marked on the DFDs as shown in Figure 13.19.

By definition, all those processes inside the change boundaries areunaffected by the change. It should be apparent, however, that this providesother information as well. The data flow lines crossing the change boundaryare defined in the Data Dictionary and they specify, precisely, the new systemin terms of its inputs and outputs. The diagram, when simplified, providesthe context diagram for the new system, as shown in Figure 13.20.


Figure 13.18 Prepare logical description.

13.2.2 Analyse new data structures and combine requirementsThe user requirements may include changes to the system inputs and outputs.If so, these must be incorporated into the existing system structures to producethe logical data flows and file store structures for the new system. Two casescan be identified:

(1) modifications are made to existing input or output data flows. This maymean adding new data elements or deleting existing data elements;

(2) entirely new input and/or output data flows are required.

In the first case, the analyst retraces the normalisation process on the originaldata structures, with the new data elements added in. This shows where thenew data elements belong in the normalised structures. Deleted data elements


Figure 13.19 Domain of change.

Figure 13.20 Context diagram.


are simply deleted from the relevant normalised structure. In the second case,new data flows are normalised and the results combined with the existingnormalised structures (see Chapter 10 for a description of this process).

The result of this process is to define Third Normal Form (TNF) datastructures for the data stores of the new system.

The process of normalisation means that a fairly large number of distinctstructures is produced. So many, in fact, that when the new high-level DFDsare drawn up, a bewildering number of data stores and flows is shown. It isconvenient, therefore, to package the separate TNF entities into a small numberof logical files, each with some meaningful name. This does not, in any way,pre-empt any physical design decisions of the system designer. It merelysimplifies the description of the new system. The correct data flows must beidentified in the lower level DFDs and in the mini-specs.

13.2.3 Design new logical systemFigure 13.18 shows five processes. Processes 1, 2, 3 and 5 are all, to a largeextent, mechanical processes, where simple rules can be provided for eachone. The analyst must exercise care and use a great deal of common sense,but there is almost no creative skill involved. Process 4, however, does requirecreative skills. It is therefore impossible to provide rules; the best that can bedone is to propose a few general guidelines. They do not actually contributeanything towards the creative process, but they help to ensure that theresulting initial design contains the features required in an effectiveinformation system. The guidelines are as follows.

(1) Work top–down. The context diagram for the new system has already beendefined. It provides the starting point for the DFDs in the new system.The analyst should not be tempted to start the design process at too lowa level of detail. The initial design drawing should occupy one sheet ofpaper. It can then be expanded into detail.

(2) Think logically, not physically. The analyst is designing the new system atthe logical level. Computer processes and human processes have no placeat this stage of the design. The analyst should just be guided by the systemrequirements.

(3) Document as the work progresses. DFDs must be used at all stages duringthe design process. When satisfied with the design, the analyst shoulddefine the data flows and add the definitions to the DD. Attention shouldbe paid to detail in the documentation, using the guidelines given inChapters 6 and 7.

(4) Minimise information flows. Each and every data flow between processesmay ultimately have to be implemented by a physical movement of


information from one place to another, so the number of interprocessdata flows should be minimised, in two ways: (i) by using transfers viathe entities whenever this is sensible and possible; and (ii) by the choiceof partitioning used (i.e. the way low-level processes are grouped intohigh-level processes).

(5) Do not expect to get it right first time. Many creative processes, and systemsdesign is one of them, are iterative. An initial design is proposed and isfound to lead to problems, so the designer backtracks and takes a differentroute. A whole design is produced and is seen to contain a flaw, so again,the designer backtracks and amends the design.

(6) Consult the user. The analyst will find that the freedom given by designingsolely at the logical level towards global system goals raises manyquestions of policy that have not been considered before. These questionsshould be taken to the user to be resolved. By this stage the analyst shouldbe thoroughly familiar with the techniques being used. The analyst isshowing the user a model of the new system. Every opportunity must betaken to ensure that it is correct and acceptable.

13.2.4 Analyse data access requirementsThe output from process 4 (see Figure 13.18) of the design stage is:

❏ a set of DFDs for the new system;❏ supporting mini-specs for low-level processes;❏ updated DD containing definitions of new data flows required in the new

system.

The final stage in the preparation of the logical description of the new systemis to carry out data access requirements analysis as described in Chapter 11.The physical file design is a critically important aspect of physical systemdesign. The analyst will have defined the file structures at the logical level,and these definitions form the starting point of the physical design. However,the designer will be particularly concerned with relationships between thelogical structures and the requirements for access to them.

13.3 SummaryThe designers of artefacts, such as buildings, ships and aircraft, are all familiarwith the use of models in their work. The design engineer or architect, as partof their work, will produce a scale model of the design. The advantages ofdoing this, for the designer and the client, are obvious. The designer hassomething that he or she can experiment on, show the client for commentand use in developing their ideas. The client has something that they can see,take apart, imagine using and comment on. This chapter has presented a


means of achieving a similar end in information systems design work. A logicalsystems model should be, as its name implies, a model of the informationsystem, which can act as a development aid for the analyst and a means ofshowing the user what is being proposed.

Exercises13.1 What is the difference between a physical and logical DFD13.2 Why do a logical dfd? What are the advantages? Are there any dis-

advantages?13.3 What are the steps in the production of logical data flow diagrams?13.4 What documents/diagrams would you need as input to the production

of logical DFDs13.5 The following diagram shows a DFD which a colleague has ‘logicalised’.

What additional points would you recommend that they consider tocomplete the process?

Preparing the structured specification 271

14Preparing the structuredspecification

IntroductionThe objective of the analysis phase of a project is to prepare a logicalspecification of the required system. The new system requirements should bedefined in terms of the data to be processed and the functions/processes tobe performed. Consideration of the hardware or software technology used toimplement the system should really only be fully considered when analysisis complete and the design phase is about to be entered (although in practicalterms there may be certain constraints imposed by the existing hardware andsoftware in place in the organisation.). However, unless a clear distinction ismade between analysis (logical) and design (physical), physical considerationsmay be built into the philosophy of the system. This may lead to problems.For example, it may be impossible to make later changes to the technologysupporting the system without fundamentally affecting the system as the usersees it. Similarly, an analyst, with the capabilities and limitations of a particularcomputer configuration in mind, may influence the user towards a systemthat will be technically easy to produce, but the result may be a system thatdoes not support the business need and satisfy the user’s requirements.

Although there is a need for a clear distinction between the analysis anddesign phases of a project, this does not imply that the analyst’s involvementwith the project ends when design begins. Design may lead to further analysisas more specific details, or clarification of certain points within theimplementation, are needed. It is an iterative process of analysis, then design,then a little more analysis, and so on. The only restriction is that the initialanalysis phase must be carried out to cover the breadth of scope of the systembefore design begins. This will then provide a framework within which to

272 Preparing the structured specification

design, and will highlight dependencies between processes and their data.The trick is to analyse deeply enough to uncover these dependencies andreduce the risk of designing the wrong system, but not to spend so muchtime on analysis that the business need cannot be met within a commercially-acceptable timeframe.

An organisation may assign the same person to do the analysis and thephysical design (and possibly the coding and testing too). Alternatively, theanalyst may produce a logical specification of the requirements and then handover, with appropriate walkthroughs and documentation, to another personwho will be responsible for the physical design. Both approaches are common,but the greatest danger of confusing analysis with design occurs when thefirst approach is used. It is essential for the person to wear an ‘analyst’s hat’for the first part of the project and allow him or herself the freedom to considerwhat is required, before having to focus on the technical aspects of how therequirements will be achieved.

This chapter examines the final two stages in analysis, which begin to bridgethe gap between logical design and physical design:

❏ defining and presenting alternative physical implementations to the user;❏ preparing the system specification.

These are the two stages shown in boxes 4 and 6 on the analysis phase diagram(Figure 14.1).

Figure 14.1 Stages in analysis.


14.1 Presenting the user with alternativesIn the past, it has frequently happened that the current system would bestudied and one system would be proposed to solve the more obviousproblems. This was mainly because the techniques in use for analysis anddesign did not make the visualisation of alternative solutions easy. However,with structured and object-oriented techniques, which provide diagrams fordescribing the logical requirements, it is easier to see several physical solutionsto the user’s problems.

Alternatives options would be considered at Feasibility Study, but the detailof these would be clarified during analysis, and further physical detail addedduring design. SSADM suggests the use of two types of option: BusinessSystems Options and Technical Systems Options. These were described inmore detail in Chapter 4. The chosen Business System provides the analystwith a starting point for the specification of the required system. The chosenTechnical System addresses specification of the technical environment, howfunctions will be carried out and the organisational impact of changes, inaddition to cost and benefit implications.

In discussing requirements with the user, the analyst will have identifiedareas that are likely to be computerised. The terms of reference may also haveidentified such areas, and may even have specified a particular type ofautomation. However, it is not until the analyst has thought through the entiresystem and documented the specification in a variety of diagrammatic models,that he or she can start to take a sensible view of what alternative physicalimplementations are possible. Since the identification of alternatives inphysical design must involve design skills, the need to complete the logicalspecification before considering design alternatives is emphasised.

14.2 Alternatives in designTo determine what alternative designs may be possible, the analyst mustconsider the following:

❏ the domain of change, which can be drawn larger or smaller within thedomain of study to include or exclude certain functions from the change;

❏ the domain of computerisation, which can also be drawn differently toinclude or exclude processes;

❏ that within the domain of computerisation.

The analyst must also always consider the option of purchasing a softwarepackage as an alternative to in-house development of the applicationssoftware. Many excellent software packages are available for all of the mostcommon commercial requirements and these have the benefit of being tried-and-tested and available to be seen before selection.


Figure 14.2 Domain definitions.

14.2.1 Amending the domain of changeIn the terms of reference given to the analyst at the start of the analysis phase,the area of study and domain of change may well have been indicated.However, as a result of analysis it may become apparent that there are goodgrounds for amending the domain of change. If, as a result of analysis, it isfound that a function previously outside the domain of change has a significantinterface with functions within the domain, then the analyst may suggestthat is should be included, thus widening the domain of change. The analysisphase may have covered a large number of functions within the organisation,giving a potentially large domain of change. It may be decided to implementa new system in parts, giving each part time to settle in before implementingthe next part. In this case, the specific area of change is reduced. The analystshould study the interfaces between any existing systems and any proposednew system. Ideally, the number of such interfaces should be reduced to aminimum.


14.2.2 Processes to be computerisedThe analyst may already be committed by the terms of reference for the systemto computerise certain processes. Having noted these, the analyst should thenapply the following guidelines:

❏ minimise the number of human/computer interfaces;❏ ensure consistency of computerisation.

Human/computer interfacesConsider first of all the DFDs represented by Figure 14.3.

If the analyst were to propose computerising processes A to D, two inputflows (marked C/I) and four output data flows (marked C/O) would needcomputerising. Since every human/computer interface point is a potentialsource of error, any alternative with a large number of these should be avoided,if possible.

Consider now the second set of DFDs shown in Figure 14.4. Process 5 onthe Level 1 DFD has been identified as a potential candidate for computer-isation. However, if on inspecting the lower level expansions of the process it

Figure 14.3 Initial area for computerisation.


Figure 14.4 Levels of data flow diagrams.

can be seen that one of its constituent processes must be manual, it thenbecomes doubtful whether high-level process 5 should be computerised.

Consideration of this guideline implies two points:

(1) Work from the lowest level DFDs.(2) Consider related groups of processes.

Consistency of computerisationIn the case in Figure 14.3 the data stores marked D1, D2 and D3 need to beconsidered for automation. D2 would certainly be automated, being sharedby only automated processes, but what about D1? It is shared by process A,to be computerised, and process E, which is to remain manual. Since it is notusually possible for a computerised data store to be read clerically, or vice


versa, a decision is needed. Either process E (or part of it at least) must beautomated to read the computerised D1 or part of process A must remainmanual. Only reference to the nature of the specific processes and data willallow this decision to be made. Data store D3, which has been left outside ofthe boundary of computerisation, raises the same problems as D1. The entity/process matrix described in Chapter 8 can be used to highlight processes whichaccess the same entity.

Regarding the processes that produce and receive the data flows at theboundary of computerisation, these too will have a clerical aspect and anautomated aspect unless the externals are totally computerised (i.e. it is acomputer/computer interface).

14.2.3 Method of automationAs well as thinking about the alternatives in which processes are computerised,the alternatives of how they are computerised must be considered. Broadlyspeaking, there are three options for each computerised process:

❏ on-line;❏ on-line entry with batch update;❏ batch mode

On-line. The use of an on-line system for processes with input data flowsimplies the use of one or other of the interactive data entry methods, such as:

❏ screens and keyboards;❏ badge readers;❏ barcode readers.

It also implies real-time file updating. There are great benefits from thebusiness point of view in this approach and in many circumstances it offersthe only feasible way of meeting user requirements.

In addition to these options in the type of processing used, a very widerange of hardware options may be open to the designer, including:

❏ a centralised system based on a mainframe or powerful minicomputersystem, with ‘dumb terminals’ (i.e. no localized processing capability);

❏ a distributed system based on some combination of mainframe,minicomputer, intelligent terminal/personal computer (PC) or centralised/decentralised file store;

❏ a system based on PCs, with parts of the system software held at PC level.This may be linked by a local area network (LAN), providing sharedsoftware and data. This LAN may have a gateway to a wide area network(WAN) exclusive to the organisation, and/or to partner organisations, and/or to the Internet.


On-line entry with batch update. In some applications, it may be found thatthere is a requirement for on-line data entry, but the associated file processingis so complex or time-consuming that to do it all in real time would giveunacceptably long response times. In other cases an immediate response isunnecessary or undesirable. In those circumstances, a possible approach is tocarry out the basic input, validation and partial file updating in an on-linemode. The main file updating would then be done either later in the day as abatch process, or as a background job to the on-line system (i.e. the computergives first priority to the on-line data entry, performing the file updating tasksas a low-priority background task).

Batch mode. Where batch mode is used, data capture is often based on high-speed, mass-keyed data entry, or the use of optical mark reading, optical ormagnetic character recognition, or their derivatives.

In any situation where the volume of data to be processed is large and afast response is not required, batch processing is by far the more efficientmethod, in terms of both computer run times and program development time.However, user expectation of immediacy of computer response reduces thesituations in which batch mode is an acceptable option.

14.3 Preparation of the alternativesFigure 14.5 shows an expanded view of ‘Examine options in physicalimplementation’, which is box 4 on the ‘stages in analysis’ chart (Figure 14.1).Each of the processes will now be examined.

14.3.1 Identify optionsThis actively involves the analyst, the designer and the user. The work to bedone investigating the alternatives and studying their implications is timeconsuming. It is therefore necessary to ensure that, broadly speaking, theoptions to be studied are all viable from the user’s point of view. This step isequivalent to producing Technical Systems Options (TSOs) described earlierin this chapter.

14.3.2 Analyst examines business implicationsOutline technical options would have been presented as part of the feasibilitystudy. The analyst must take each option in turn and examine the implicationsfor the business, considering such factors as:

❏ effect on staff;❏ effect on management control information;❏ effect on external organisations (customers, suppliers, auditors);❏ staff involvement in implementation.


Figure 14.5 Examine options.

14.3.3 Designer examines hardware and software implicationsThe designer must study the options selected, to determine the computerimplications. In effect, the designer must carry out a mini-design for eachalternative in order to estimate such factors as:

❏ additional hardware requirements;❏ additional systems or applications software requirements;❏ design effort;❏ programming and testing effort;❏ the costs of these factors.

14.3.4 Consolidate cost–benefit analysisIn the final step, the results of the analyst’s consideration of the businessimplications and the designer’s consideration of the computer implicationsare consolidated into a single statement. This summarises, for each option,the implications for the business, and the costs and benefits to be expectedfor each option.


14.4 Preparing the system specificationThe analyst is now in a position to present the user with a set of optionscontaining their costs and benefits specified in general terms.

The user can now identify one or other of the alternatives presented asbeing closest to requirement at an affordable price. The user may not chooseone of the exact alternatives offered, but possibly a modified version. Thefinal task in the analysis phase (though not, of course, the analyst’s final task)is to finish the specification in relation to the option chosen. This is already acomplete specification of what the new system is to do, but some physicaldetails now have to be added. It may contain, for example:

❏ data flow diagrams;❏ mini-specifications;❏ data dictionary;❏ entity relationship diagram;❏ entity/process matrix;❏ entity life histories.

The designer will need, in addition, the details discussed below:

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

14.4.1 Specification commentaryThe purpose of the commentary is to act as a guided tour of the structuredspecification. It is to be expected that many people will work on theimplementation. More than one designer may be involved; in addition therewill be programmers, operations staff, even users who have not seen the entiredesign. All of these individuals will benefit from an understanding of thewhole system. While this can be gained alone from studying the diagrams ofdata, processes and system behaviour, it is useful to give a brief narrative tohelp to interpret the detailed specifications.

14.4.2 Physical constraintsThe option selected by the users will include some physical limitations to thesystem, e.g. type of hardware to be used. This information must bedocumented for the design team.


14.4.3 Timing constraints and prioritiesTiming constraints can apply to all processes and, in effect, they specify thetime dependencies between processes. The following types of constraint canappear:

❏ on-line response times required to be within certain limits (e.g. in thecustomer account management system, the response time from keying theaccount number to the point where customer name and address appearson screen should be within two seconds for 90% of the time).

❏ batch computer runs that must be completed by a certain date or time withina schedule (e.g. invoice run to be completed in time to mail invoices by8.00 a.m. on the following morning);

❏ clerical procedures that prepare data for computer input to be completedby a given date or time;

Priorities are mainly concerned with the on-line processes and provide thedesigner with guidelines on which processes are to be given priority by thecomputer, at times of heavy machine usage.

14.4.4 Fall-back and recovery procedure requirementsRecovery procedure design is a design responsibility and need not be speltout by the analyst. However, in on-line applications, the analyst needs tospecify any user fall-back requirements. In such applications, the user’sbusiness operations will depend very much on the availability of the computer.

If the computer is not available, these business operations may be severelydisrupted. The analyst has to discuss this problem with the user and determinewhat is to be done in case of computer breakdown.

14.4.5 Audit requirementsThe standard computer system controls will be built into the system by thedesigner. However, the auditor may specify additional controls, in order tobe satisfied as to the accuracy and security of the new system. These mayrefer to specific audit trail requirements, test procedures, source documentrecording and so on.

14.4.6 Access and security requirementsIn on-line systems, one of the main sources of access to the computer systemand to the data contained therein will be via on-line computer terminals. Theanalyst must define the access and security requirements for the designer.Questions such as the following must be answered:

❏ Who is allowed to carry out this computer process?


❏ Who is allowed access to the data?❏ Who is allowed access to this terminal?

It is then the designer’s job to ensure that adequate measures are taken tomeet the requirements.

14.5 The completed system specificationThe specification of a new system, to hand over to the designer, should be:

❏ graphic: the main components of the specification are diagrams which aresupported by precise definitions of symbols and names used;

❏ partitioned and top–down: these features enable the reader of the specificationto move easily from a high-level broad view of the system to a low-leveldetailed view;

❏ iterative: small sections can be passed back and forth between user andanalyst for modification;

❏ easily maintained: the partitioning of the specification, and the controlledredundancy within it, make it easier to incorporate changes that may beneeded during implementation;

❏ easily understandable: concentrating on the logical aspects of the system. Itmay be used as part of the dialogue between analyst and user;

❏ primarily a logical level view of the system with no unnecessary reference tophysical implementation details. The designer is thereby given maximumfreedom to design an effective system to meet the logical requirements;

❏ precise and concise and therefore easy to read.

The system specification must provide the starting point for systems design.It must contain sufficient information about requirements and constraints todirect the designer to the right system to be built, whilst allowing appropriatefreedom to the designer to use the best design and physical components tomeet the requirement within time and cost constraints..

The next chapter gives more detail about documentation standards ingeneral. These should be followed for the structured specification, but withoutcompromising its graphic, readable nature.

Exercises14.1 Define:

❏ the domain of study;❏ the domain of change;❏ the domain of computerisation.


14.2 On the DFD shown, identify the inconsistencies of computerisation14.3 What staffing and other implications must the analyst consider when

defining physical options for the new system?14.4 What are the advantages of a structured specification?

E1E1

E2E2

E5E5

E4E4

E3E3

E2E2

11

77

6655

44

33

22

D1D1 D4D4

M3M3

D2D2

Domain of computerisation

M = Manual processA = Automated process

M

M

A

A

M

A

D3

M

Example: Physical DFD with inconsistencies


Documentation standards 285

15Documentation standards

IntroductionThere are two reasons for recording or documenting facts. The first is so thatthey can be referred to at some future time, when the memory of the detailhas faded. The second is to communicate with other people at the presenttime.

Documentation is a communication between the present and the future.

Any type of communication requires standards if it is to have maximum effect.A standard format makes it easier for people to understand. Non-standardcommunications may be difficult to understand, or at worst completelyincomprehensible.

Documents must be kept in a way which allows access to the facts theyinclude, when they are needed. This implies a referencing and filing systembased on the information on a document.

This chapter explains and develops these themes.

15.1 JustificationWhile an analyst is working on one aspect of a system, they remember thedetails and requirements of that area. As time passes, the continual acquisitionof new information and details tends to make it more and more difficult forthe analyst to recall earlier fine detail accurately.

Furthermore, as an analyst completes one project, they will move on to thenext, and other people will need access to the information. In fact, whetherthe original analyst or someone else seeks the information, it still needs to beaccessible.

286 Documentation standards

Documentation, is a mechanism for recording relevant known facts, so thatthe facts will be available in the future, when they are needed.

Documentation is a communication between the present, when all necessaryinformation is readily available, and the future, when it will probably not beavailable from memory.

However, communication may also be needed over a much shortertimescale than has been implied so far.

Normally an analyst is a member of a team, all the members working onthe same project. Each member needs to have ready access to decisions madeby the others. The essence of effective team work is that duplication of effortand conflicting decisions are avoided. Documentation is the way this can beachieved. There must be a pool of information from which each member canextract what they need, and to which each member is able to add their owncontribution.

Users of any system also provide information and need to ensure that it isproperly understood. So the communication aspect of documentation can beseen in two ways:

❏ first, there is the communication between present and future;❏ second there is the communication between team members and between

the team and the users.

There is a golden rule of communication:

If there is a standard, use it.

Any communication, formal or informal, whether spoken, written or passedby some other means, must be as clear as possible. If anything is allowed todistort it, or to reduce the recipient’s understanding of it, the communicationwill be incomplete, and this could be inconvenient or disastrous. Non-standardcommunications are inherently worse than standard ones. If the sender andreceiver both use the same standard for the communication, this must bebetter than if they use different standards.

To make a communication as effective as possible, the sender must use thestandard which the receiver expects.

Standard forms with pre-printed boxes and accepted conventions forcompleting them offer two advantages over blank paper:

❏ they act as checklists;❏ they speed up and facilitate retrieval of information.

A checklist reminds the analyst of the facts to be recorded. It also suggestsfacts which the analyst may not have even considered recording. Omittingan entry on a standard form, and putting a dash through the appropriatespace is deliberate. Forgetting, or not even considering a fact is accidental.Deliberate omission is common and perfectly valid. Accidental omission isunprofessional and distorts the communication.


If a certain fact is always recorded in the same place on a particulardocument, then someone looking for that fact will find it quickly and easily.The same fact, buried amongst many others, in the sequence in which theanalyst happened to think of it, may be missed or overlooked.

The essence of any documentation system is retrieval. A fact which isrecorded must be filed where it can be found when needed. If it cannot befound, or it cannot be found quickly enough for the purpose of the personsearching for it, it might just as well have been omitted.

Documentation standards, therefore, must have a simple, comprehensive,unambiguous way of generating a filing reference for any piece of paper,dependent solely on the information contained. That filing reference is writtenon the piece of paper, and the paper is filed, with all other documents generatedfor the system being developed, in the sequence of that filing reference.

When the information is needed, the person seeking it can generate thefiling reference and look in the designated place for it. For example, a systemof generating filing references could create a four part reference, each partbeing a breakdown within the previous part.

This would allow segmentation and convenient storage of documentswithout the need for extensive (linear) searching.

15.2 The scope of documentation standardsThe documentation of any system must include the following:

❏ details of the way the system functions;❏ what data sets are accessed and maintained;❏ how the system interfaces with others.

It is also valuable to be able to look up how the system has altered, and throughwhat stages it has passed to arrive at this present stage. This will often giveguidance as to what changes may be needed in the future.

All the above is fact, related directly to the system. If a system is installedand working, some opinion can be added to these facts, as part of the systemaudit. This also should be part of the documentation of the system.

These aspects of the documentation are the results of what analysts,designers and developers do, and are not the result of how they are managed,or what systems of project control, budgeting or salary review are in operation.They are all management functions, not directly related to the work of systemsand programming staff.

The documentation standards discussed here should apply to all work ofthe staff, but should not apply to the management of the staff.

The best way to envisage a set of documentation standards is to considerthe set as a tool-kit. Each of the standards has a purpose, and is designed tocarry out one or more specific tasks. There should be a tool in the kit for everyjob which the analyst (and others) has to do.


There need not be any suggestion that the documentation of a system mustcontain certain documents. The purpose of documentation standards is toenable the analyst to record what is relevant to the project, and relevant to thestage in that project which they have reached, in a standard way. That is all.

Management, project control and documentation between the various jobsto be performed will vary from installation to installation, and from projectto project. They are not the concern of the system documentation standards.

15.3 Keeping documentation up to dateDocumentation which is misleading is unhelpful to the people who use it. Ifdocumentation is produced during the system life cycle, up to the point ofinstallation of the system, and that documentation is good, readable, accessibleand reliable, then people who need information about the system will rely onit. If changes are made to the system, but are not reflected in thedocumentation, problems are likely to arise.

Any set of standards for documentation must therefore contain provisionfor keeping the documentation up to date and in step with the actual systemitself.

This requires two things:

❏ there must be a change control procedure;❏ the documentation itself must be as easy as possible to modify.

15.3.1 Change controlChange control procedures normally follow a standard pattern (see Figure15.1). When anyone wants an alteration to the system, either an enhancementor a correction, there must be a way for that person to communicate the needfor change to the development group. Often a form is provided, on which therequest can be made. What is put onto that form is a clear description of whatis needed. This need not contain any idea of how the change could be made,or what effects it may have on timescales, personnel deployment or othersystem functions. The request is simply for what is required.

Figure 15.1 Elements of change control.


When the development group receives this request, a specification of thechange is created. In the specification, as well as the technical description ofchanges needed, there should be an estimate of how much effort this willabsorb – usually expressed as man-days, and also as an elapsed time. Detailssuch as earliest start date and earliest finish date should be included (asestimates) in the specification of the change.

From the specification, the users can make a decision on whether or not toproceed immediately, later, or not at all. Sometimes dates will have beenplanned for major revisions to take place, and a change may (with theagreement of the user) be accepted for incorporation into the revision. Theremay be delays as a result of the change; either delays in the (not yet arrived)installation date of the system to be changed, or delays in other systems causedby the withdrawal of manpower from these systems to effect the requestedchange.

Finally, there must be a log of changes, so that each element of the requiredalteration can be specified and ‘signed off’ as it is completed. The changes areto the system and to the documentation, and both must be completed.

15.3.2 Attributes of good documentationThere are numerous attributes of good documentation.

Programmers will already be familiar with the idea that an easy to modifyprogram is modular, with each module fitting into a clear structure. Moduleindependence, with minimal interaction between modules, is a necessaryfeature. The same idea applies to documentation.

Each aspect of the documentation of a system should be developed in a‘top-down’ way, so that high levels show structure and low levels show detail.This means that a change to the detail can be made by altering the minimumnumber of documents at the detail levels, and making no changes at all to thehigher levels.

A change in the structure will mean a change of high level, and perhapsadditional low level material – but again, this type of change is easy to makewith minimal effect upon other parts.

The individual documents can also be designed for easy updating. A sheetof paper covered with manuscript is very difficult to alter, as is a large, complexflowchart with dozens of symbols. Pre-printed forms, with boxes ofinformation, make it easy to identify what has to be altered, and change itwithout any effect on the rest of the detail.

Charts with no more than half a dozen symbols on them, in a level-by-level structure, are obviously much easier to alter than massive interconnectedcharts all at one level.

Documentation which has a recognised and logical filing system, withsimilar documents held together, separate from dissimilar or unrelated ones,also makes the task of updating documentation easier.


As soon as any system of documentation is implemented, an updatingmethod must be available, and must be used.

Out-of-date (and therefore wrong) documentation can be very misleadingand can cause much frustration to both users and development staff.

There is a good case for making a distinction and separation between thedocumentation of a ‘live’ system, and the documentation actually held by,and used in, the development group. Some installations, accepting that newversions of a system may be under development while a live system is beingsupported, make a rule that a live system must be handed over to theoperations or ‘live systems support’ people, together with a complete copy ofall systems documentation and program documentation which applies to thatsystem at the moment of hand-over. This then becomes the masterdocumentation of the live system, and can only be altered through the changecontrol system. Another copy of the documentation stays in the developmentgroup, and may be the basis of modification to produce the later version ofthe system, if one is required.

15.4 The limitation of documentation standardsReturning to the concept expressed earlier that a system of documentationstandards should be a tool-kit, it is important that certain limitations arerecognised.

Because the standards are just ‘tools’, they do not affect the professionalskills of analysts, designers or programmers. Good documentation standardswill not necessarily lead to good systems, nor will bad standards necessarilylead to bad systems. However, if a system is viewed as a whole, then absentor poor quality documentation could be seen as bad features of an otherwisegood system, and so the whole system is not as good as it could or should be.

Documentation standards do not normally affect the management, controlor training of the development staff, and therefore do not influence aspects ofa system which are dependent on these features. For example, gooddocumentation cannot ensure that the system is delivered according to a plan.

Since the main purpose of documentation is communication, either betweenusers and the team or people in the same team, or between the present andthe future, it cannot have any effect until the communication takes place.

A perfect system, requiring neither corrections nor enhancements, producedby one individual in a short time, is unlikely to put too many demands ondocumentation. The communication is hardly used. Such systems are veryrare. More commonly, at least two people are involved, and corrections willbe needed. Also, with use a system is usually subject to enhancement, as userenvironments (and requirements) change. Therefore a static system is indeedrare.

There is also the problem of emergency maintenance. When a system on


which the user depends goes wrong, there is obviously time pressure to get itworking again, and change control procedures must allow for this and by-pass certain steps. This is normal and acceptable, provided that the full controlprocedures are followed up after the emergency is over, to bring anydocumentation up-to-date by incorporating any changes which were made.

15.5 Methods of documentationNarrative, alone or with standard pre-printed forms, is used in one way oranother in all types of documentation. Usually it is restricted to a couple ofexplanatory sentences on a particular topic. Any more extensive use ofnarrative is best if some structure is applied to it.

15.5.1 Structured EnglishStructured English is just such a narrative form where the structure of thetext is indicated by the layout so that it is easy to understand or modify. Ituses the same principles that are used to structure program code withindentation to indicate grouped sections of the code.

15.5.2 Pre-printed formsPre-printed forms have the checklist and easy reference advantages mentionedearlier. A balance must be found between forms which are so general purposeas to be useless for either checklists or reference, and forms which are sospecific that dozens of different ones are needed.

Some forms will be needed which are effectively blank except that theyinclude the pre-printing which is needed for the referencing and filing system.

Grids pre-printed onto forms are more or less essential for such uses asprintout specification and screen layout. They are also helpful for laying outtables, charts and other diagrammatic representations, and may be desirablefor narrative.

15.5.3 Charts and diagramsCharts or diagrams are very useful indeed. Into this category come flow chartsfor the conventional logic path programming charts, and also such charts asrun-charts to show the sequence of computer operations, and Data FlowDiagrams (DFDs), to show the movement of data in any type of system.

Various block diagrams, such as Entity Relationship Diagrams (part ofEntity Modelling) and Entity Life Histories (ELHs) are also used effectivelyin system specification and design. Note that levelled charts are always easierto assimilate and modify than large single level ones, and are thereforepreferred. Organisation charts also come into the category of charts.


15.5.4 Tabular representationsTabular representations can also form part of the documentation of a system.This includes Decision Tables to show logic flow when many decisions arerequired, Third Normal Form Analysis (TNA also called normalisation) andmany types of cross-referenced lists. These lists may be used to show, forinstance, relationships and interactions between procedures and data, betweeninputs and outputs, between files and records contained, and many more.

15.5.5 ReferenceAll these types of information recording are relevant, each at an appropriatepoint, though some are more favourably received than others. Clear structuredEnglish will always be more effective communication for systemdocumentation than blocks of narrative without structure or logical sequence.DFDs, supported at the lowest level by mini-specifications, overcome manyof the disadvantages of flowcharts used as the only procedure descriptions.

The diagrammatic forms, either charts, tables or just visually structuredtext, are better than words alone when retrieving information from a largequantity.

15.6 A typical standards manualWe will now consider a typical standards manual.

In our example the manual is divided into six main sections, each withappendices. Each standard in the manual has a number (in decimal format,e.g. 4.2.1) and a name. The sections cover the following:

1) Document Control This shows how to generate a filing reference and howto file documents. It also gives standards covering change control.

2) Communication Here, the various groups of documents which are createdby IT for internal and external circulation are defined, with checklists ofsuggested contents. User manuals, operations changeover procedures andsystem audit reports are examples. A standard is also given to cover therecording of facts obtained or decisions made during discussions, whetherformal or informal.

3) Procedures All standards which relate solely to procedures are includedhere. There is an assumption that any system will be developed in a top-down, structured way, so the documentation follows the levelleddescriptions which match the development. Both clerical and computerprocedure descriptions are included.

4) Data The standards for the specification of files, records and data itemsare given here, together with standards covering, for example, TNF analysis,entity modelling and DFDs.


5) Relationships and Interactions This describes how to record relationships,for example between data items and procedures, events and entities andbetween records and files. Other types of relationship, such as organisationcharts, are also found here.

6) Test Documentation Certain standards apply to all testing of computersystems, and this suggests an appropriate approach.

Appendices should include:

❏ a list, and then an example, of all different standard forms as blanks;❏ an appendix relating standards to the phases of a project, in general terms;❏ a cross-reference index to enable anyone wishing to alter or remove a

standard to see what other documents relate to it;❏ an index and glossary. The glossary provides an explanation of, or a

reference to, the specialist IT terms in the standards manual with whichthe trainee analyst may be unfamiliar. Also, references to relevant standardsare provided.

15.7 A standardEach standard follows a convention used throughout the manual. Figures15.2 and 15.3 are sample pages from a manual which illustrate theseconventions.

There are three elements present in every standard:

❏ the number and name of the standard (in the example 3.1.1 System Outline).Note that the manual is not numbered in sequential pages, but in standardnumbers, with a page number within each standard;

❏ if one or more standard forms is relevant, the names and references of suchforms are listed;

❏ every standard begins with a statement headed ‘1 – Purpose’. In this section,the purpose of the standard is explained. If the analyst looks up a standard,they will check the purpose to ensure that the standard applies to the taskin hand.

After ‘1 – Purpose’ comes a series of sections and sub-sections describing thestandard, what the conventions and applications are, and how the standardis put to use.

Each standard is a free-standing module within the manual. Where onestandard refers to another, this is done by putting the standard number referredto in brackets, with a paragraph or sub-paragraph number if needed, e.g.(3.2.2) as in paragraph 3.2 of the example above.

15.8 Filing of documentsGenerally, system documents are filed in a binder (usually a ring binder) with


one binder per system. There will probably be a number of program binders,one for each program within the system, but that is not the current concern ofthe analyst.

There is normally up to three (in some cases, more) versions of thedocumentation (Figure 15.4).

❏ New system file During development work, the documents are workingpapers, and are totally under the control of the analyst.

❏ History file The time will come when it is necessary to implement someform of change control. Any superseded document contains informationwhich was a good idea at the time, even though it may now be out-of-dateor inappropriate. Rather than throw away superseded papers, they shouldbe filed in a history file, together with the paperwork of the amendment.

Figure 15.2 Sample page (1).


Figure 15.3 Sample page (2).

Figure 15.4 System file.


Keeping a history file for a system has many advantages, not least thatwhat is inappropriate now may well turn out to be just what is needed inthe future. It is therefore preferable to keep original details, rather thanthrow them away.

❏ Old system file It is quite likely that the analyst will be working initiallyon an existing system, and the designer will be creating a new, replacementsystem. These, obviously, cannot be documented together, since they containcontradictory or conflicting specifications of processes, data sets andmethods of working.

In some circumstances, to illustrate the kind of tailoring which may benecessary, organisations choose to refer to the ‘Level Number’ of a system,rather than simply old and new. The level number could be similar to thatcommonly used for software packages, with the ‘version’ and ‘release’.

Any system binder will carry, on the spine, the system identity (see nextsection) and new, old, history or whatever. Program binders will, similarly,carry the program identity on the spine.

If a system has a name or mnemonic by which it is commonly known, thismay also be included in the title on the spine.

15.9 The filing referenceThe filing reference consists of four elements as follows:

❏ system;❏ document;❏ name;❏ sheet.

15.9.1 SystemAll systems are allocated a code usually two or three letters, sometimes amnemonic, or a code which is simply issued in sequence. This code is writtenon the spine of the system file(s) as noted above, and will also be written atthe head of each document filed, as the first element of the filing reference(SOP in Figure 15.5).

15.9.2 DocumentWithin a system, there must be a way of dividing the documents up intoreasonably balanced groups, to minimise the time it takes to find a particulardocument. The grouping chosen could be based on a set of numeric codes,each defining a particular type of detail. The filing system in our example isbased on the information contained, not on the type of document or formused, or the stage of the project at which the document is generated.


Figure 15.5 Filing reference.

Figure 15.6 Example of document referencing system.

The numeric codes themselves are shown in Figure 15.6. The left-handcolumn contains the document reference number, the two right-hand columnsgive examples of the type of document or information which may be foundin a system file (old, new, etc) and a program file, and the central columncontains a description of the document reference.


What this document referencing system offers is a way of giving anydocument (whether on a standard form or just a plain piece of white paper,even an internal memorandum) one, and only one, quite unambiguous,document reference number from the list. That is the second of the fourelements of the filing reference.

To locate a document, the analyst can identify the document reference underwhich they would file it, and look in the group of papers in that system file,under that reference.

Some document references will become very familiar – others, used lessoften perhaps, can be looked up when needed.

15.9.3 NameThe third element is name (SOPSYS in Figure 15.5). This is a freeform name,chosen by the analyst to differentiate between this document and any otherdocuments within the same document reference number.

15.9.4 SheetDocuments may be a single sheet – but commonly run to more than one. Thesheet number, just a simple serial number, is the last element of the filingreference.

15.10 Numeric codingIt is appropriate to summarise the numbering systems which have beenreferred to in this chapter so far to clarify and reinforce the points made.

First, each standard has a number in the manual. The analyst will only usethis as the access mechanism to find the required standard. This number willnever appear in the actual system documentation.

Next, each standard form has a number. This is purely a shorthand namefor the form, and a stationery reference. It is quicker and easier to refer to an‘S44’ than to a Record Specification.

Finally, and most importantly, there is the numeric code which is adocument reference, often abbreviated to ‘document’. This code is found onevery working paper used and filed by the analyst. No other codes are usedfor this purpose.

15.11 Summary of document referencingAny standard form should have four boxes pre-printed at the top right-handcorner, containing:

❏ the system code;❏ one of the document references from the list;


❏ a name;❏ the sheet number. If there is only one sheet, then the sheet number is usually

left blank.

The name is usually the name of the object specified. For a record specification,the name is the record name as used in the program or other processdescription. It is not appropriate to generate a different name for the document.

Any document which is not a standard form should have the referencewritten in the top right-hand corner, with oblique strokes between elements(e.g. SOP/4.1/OLED/2).

When referring on one document to another, the same method of writingthe filing reference is used. For example, on a printer layout chart, recordscould be referred to as SOP/4.5/REC1 or more likely 4.5/REC1. The omittedsystem code is implied to be the same as the one at the head of the sheet,unless otherwise specified.

When a document contains information about more than one topic,therefore needing to be filed under more than one document reference, it isnormal practice to file it under the most significant document reference (orthe first if none is significant) and to put sheets under each of the others, withthe comment ‘see ref 2.1/USER3 for details’. The sheet has its own uniquereference, of course.

15.12 Copying a sheetOccasionally, before any formal control procedure is applied, there is a needto give someone a photocopy of a sheet, and to record the fact that the copyexists, and needs to be updated. If it does not need to be updated, no recordneed be kept.

It is suggested that a coloured pen be used to put an asterisk immediatelybefore the filing reference, on the original, before copying it.

Then the photocopy will have an asterisk in the same colour as the rest ofthe page, which shows that it is a copy. The original, with a coloured asterisk,will be referred to under copy control.

This is preferable to recording where the copy went to on the documentitself, because the copy control section acts as a positive reference to anydocuments needing update. Marking the sheet itself is not detectable withoutgoing through all the file.

15.13 Documentation of testingTesting is the process of :

❏ deciding what is being tested for;❏ choosing test data to perform that test;


❏ defining the results which will be achieved if processing is correct;❏ performing the test and comparing the actual results with those expected.

Any other method, such as the provision of more or less random data andcasual checking, could more accurately be described as experimenting, whichmay be suitable for research, but is not suitable for production work.

The last item in the list may need to be performed several times, with systemmodifications each time. Each such attempt is referred to as a ‘test shot’. Onlywhen ‘actual equals expected’ can that particular test be said to be complete.

The standards should offer ways of generating and filing test data andresults, and two standard forms, one for planning the tests (the first threeitems in the list), and the other for recording the test shots (the fourth item).

Note that planned and actual shots and dates form part of the planningand logging of testing.

15.14 SummaryIn this chapter, a typical set of documentation standards has been explained.

The standards should be easily accessible and modular, minimising bothsearch time and study time. The minimum of cross-referencing is used, sothat the analyst does not waste time looking backwards and forwards in themanual when they are actually trying to establish how to use one particularstandard.

There is no implication, or actual statement, in a manual which says thatthe analyst or designer or any member of the IT staff should be doing onething or another; nor is there any management and control information. Theseare external to the standards, which are basically a kit of tools. When theanalyst is doing a particular task, that task should be documented.

The appropriate ‘tool’ for the documentation is found in the manual. Thereare many different ways of recording, for example, procedure information.The analyst should select the one (or those) appropriate to the task.

15.15 Summary of the book and the continuing role of theanalyst

This book has presented a series of techniques for analysis, which may beused within the overall framework of a structured or object-oriented approachto analysis. In one sense, there is nothing new in the ideas presented. Analystand designers have always gone through the same stages in developing anew system:

❏ fact-finding and specification of requirements;❏ design;❏ implementation.


What is new is the relationship between analysis and design, and the graphic,diagrammatic approach to analysis.

Whilst the analyst will progress through the six main steps shown in Figure14.1, it is unlikely to be a simple progression from one to the other. There willusually be a continuing need to backtrack through earlier stages, asinconsistencies or gaps in the analyst’s knowledge of the system beinginvestigated or defined are found. This backtracking is likely to continuethrough to the early parts of the design phase. Detailed physical design willalmost always raise questions of policy or detail that were not raised inanalysis.

Different people will also view a problem in slightly different ways, and ifthe analyst and designer are not the same person, this is likely to cause newquestions to be asked of the user. Therefore one aspect of the analyst’scontinuing role is to continue the investigation and analysis work throughthe early stages of the design phase.

The analysts role continues through into implementation. In this capacity,the analyst will be actively involved in the following aspects of the project,after the initial analysis phase:

❏ planning for implementation, file creation, system changeover procedures;❏ design of clerical procedures, preparation of job specifications, training

documents and training procedures;❏ preparation of user documentation manuals;❏ system test planning and system testing.

The analyst is the main communication channel between the user and theinformation technologists, throughout the project.

Exercises15.1 What is the purpose of documentation? Why do we need standards?15.2 What is the benefit of standard forms for documentation?15.3 What is change control and what are the steps in its operation?15.4 What format should documentation be in?


Appendix A 303

Appendix AData Protection Principles

‘I have travelled the length and breadth of this country and talked with thebest people, and I can assure you that data processing is a fad that won’tlast out the year.’

The editor in charge of business books for Prentice Hall, 1957

It is always risky to try to predict the future!! The exponential rise in theamount of information that is manipulated every day has understandablygiven rise to real concerns for the rights of individuals to privacy of informationabout them. The UK Data Protection Act forms the basis of the discussionhere but similar pieces of legislation exist in many countries of the world.

As technology advances, computerised records are becoming common-place. With the increase in personal data being held by companies andindividuals, there are a great many dangers arising for the preservation ofprivacy. Concurrently, the increase in computerised records also promisesmany benefits for both companies and individuals. Our discussion here willfocus on the UK Data Protection Act, and the safeguards that it offers for theprotection of the individual.

The original UK Data Protection Act was implemented in 1984, under theauspices of Eric Howe, formerly of the National Computing Centre. It outlinesthe principles for the processing of electronic data, with the purpose ofpreserving the individual’s human right to privacy. In the 1998 addendum,the act was extended to include paper records. This brings the Act in linewith European Human Rights legislation.

304 Appendix A

The eight guiding principles of the UK Data Protection Act 1998

These state that data must be:

1. Fairly and lawfully processed;2. Processed for limited purposes;3. Adequate, relevant and not excessive;4. Accurate;5. Not kept longer than necessary;6. Processed in accordance with the data subjects rights;7. Secure;8. Not transferred to countries without adequate protection.

The Act requires organisations that hold data about individuals (the datasubjects) to control that data in such a way that they will not infringe theindividual’s right to privacy. Any data that can be uniquely identified to anindividual must be properly stored, maintained, used and disposed of. Anyorganisation which holds such data must, in Law, make a notification to theInformation Commissioner (where not exempt), and appoint a data controllerwho is formally responsible for protection of the data.

Elizabeth France, the current (2001) Information Commissioner (The titlehas changed from ‘Data Commissioner’), has stated that ‘the act has beenengineered in a way that leaves it open to interpretation’. By leaving the actsomewhat ambiguous, a broader area can be enforced using the eightprinciples, giving greater protection to the data subject. Elizabeth France alsodirects attention to the non-technologically-specific nature of the Act,explaining that, with the pace of change of technology still accelerating, anAct that referred to specific types of technology would quickly becomeirrelevant. ‘It is unreasonable to think that we can keep up with technology.By constructing the act in this way, we can at least ensure that the Actremains applicable to all technology.’

The most significant change in the Data Protection terms since 1984 is theaddition of an export guideline (principle 8), which protects the data subject’srights from dissolution through the transportation of data into a country withinadequate Data Protection legislation. In general, this term prohibits thetransfer of data outside of the European Union without proper security havingbeen implemented by the data controller (the person responsible under theAct for the data).

The Individual’s Data Protection Rights

The Data Protection Act gives the following seven Data Protection Rights toindividuals in respect of personal data held about them by others:

1. Right of subject access (the data subject can demand to see what data isheld about them).

Appendix A 305

2. Right to prevent processing likely to cause damage or distress (the datasubject may appeal to have data processing involving themselves ceasedor prevented).

3. Right to prevent processing for the purposes of direct marketing.4. Rights in relation to automated decision taking.5. Right to take action for compensation if the individual suffers damage by

any contravention of the Act by the Data Controller.6. Right to take action to rectify, block, erase or destroy inaccurate data.7. Right to make a request to the Commissioner for an assessment to be made

as to whether any provision of the Act has been contravened.

Is the Data Protection Act an adequate safeguard for individual privacy?One of the most basic of these rights is the right to exclude oneself from directmarketing. Legally, if a data subject makes a request to a data controller forthe ceasing of all data processing related to that subject concerning directmarketing, then the controller must comply. The data controller must stillhold enough information to identify the data subject to avoid direct mailingin the future. The data subject may insist that he or she is removed completelyfrom the company’s database, but with this comes the acceptance that thedata subject may inadvertently be mailed in the future.

The seven individual data protection rights are paramount in the protectionof the individual, each providing security against specific areas related topersonal data. The right of subject access is, arguably, the most powerful ofthe seven, as it allows the individual to examine the personal data held onhim or her by a data controller. A time limit of 40 days is placed upon datacontrollers to complete a subject access request, ensuring that individuals arenot kept waiting for an unrealistic length of time. Once a data subject hasviewed his or her records, they may find it necessary to invoke one or moreof the other rights. The most common breach of the Data Protection Act is thestorage of inaccurate data. The data subject may appeal to have this datachanged by the data controller. This protection ensures that an individual isnot adversely affected by data which is inaccurate or out of date, such as aninaccurate credit rating that would prevent the individual from securing aloan.

Is the Data Protection Act an adequate safeguard against the disclosure ofpersonal information to others?

The spirit of the Data Protection Act is that the individual should have accessto, and control over their personal data, wherever held. Forced subject access,where a data subject is required to obtain their data from a data holder and todisclose that data to a third party is a highly controversial issue. Some largecompanies have been reported to the Data Protection Commissioner forinsisting that job applicants obtain copies of their personal data from a

306 Appendix A

government department, such as the Department of Social Security (DSS) orthe police, and hand it over to the potential employer, in order to secure a job.Despite the immediate privacy issues, this practice is still commonplace inbusiness today. In the UK, there are plans to outlaw forced subject access andto introduce a ‘legitimacy certificate’ which could be requested in its place.This certificate would be a minimal summary of only certain government-held information. For example, it would show a person’s criminal record(particularly necessary for persons seeking employment where they will bein contact with children) but would only show outstanding criminalconvictions and sentences served or completed within the previous six years,thus ensuring that when a sentence had been served, or a conviction dismissed,the subject would not be penalised further when being considered for a jobposition.

Is the Data Protection Act an adequate safeguard for the individual fromtheir data being used in ways which could cause them damage?

An individual’s right to prevent the processing of data which is likely to causethem damage or distress, where they are the data subject, allows the individualto stop the processing of personal data relating to themselves, within reason.If, for instance, the data concerned was highly sensitive and processing itwould expose the information to many people who could then use it againstthe data subject, then he or she would be entitled to prevent this. A danger ofthis right is the caveat which states that the individual may lose the right toprevent data processing if the data controller has complied with one of thefirst four data protection principles. Returning to the previous example, thedata subject mentioned would have no recourse against the processing of hisdata under this right, as while it may be sensitive data, it is accurate and is assuch exempt from this right.

Sensitive data is data related to, for example: race; political opinions;medical records; religious or other beliefs. Stricter conditions are applied tothe processing of such sensitive data. In the case where sensitive data is to beprocessed, the data controller will usually have to obtain the explicitpermission of the data subject. This is the case even if the data controller hascomplied with all eight principles of the Act. The only way around this rule isby proving that the processing is required for specific legal reasons. Datasubjects can be reassured by the presence of this rule that direct guidance isoutlined concerning data such as this which is likely to be heavily damagingif used in an inappropriate manner.

The Data Protection Commission in the UK operates a reactive, rather thanproactive, enforcement policy. In some cases this can work against theindividual, particularly when compensation is sought. If a data controller,for instance, has failed to deliver information requested under subject access

Appendix A 307

within the required time-period, the Information Commissioner can only forcethe controller to deliver this data. Once the data has been delivered, nothingmore can be done for the data subject. In terms of penalty, the data subjectmay choose to request that the data controller is assessed to determine whetherthe Data Protection Act is being adhered to, and in the case that it is not, thedata controller may be prosecuted, but the data subject will see no direct benefitfrom this. Compensation can usually only be obtained when damage has beeninflicted upon a data subject and the data controller cannot prove that he orshe took appropriate care to comply with the relevant requirement. Whilecompensation is a right, it is unlikely that the data subject would be able toclaim for distress, except where the data is used for special cases coveringjournalism, art and literature. This lack of coverage for emotional and mentaldamage is a dangerous omission as it precludes the possibility of compensationfor an infraction, which while not being overtly damaging may havesignificantly altered the life of an individual.

With the introduction of the 1998 Act, fewer data controllers are requiredto register, or ‘notify’ (as it has now been renamed) than would previouslyhave been the case. As an additional safeguard to the data subject, all datacontrollers are expected to comply with the principles of the Act, whetherthey have notified or not. This implicit acceptance provides a much widerjurisdiction area for the Information Commissioner, but removes some of theprotections that registration on a larger scale provides. Those data controllerswho do not notify will not be required to disclose the nature or use of thedata collected and as such, could be breaching the Act unnoticed.

Despite the reduction in the number of data controllers required to notify,the 1998 Act maintains the need to notify unless exempt. The classes ofexemption have been expanded to include:

❏ Non-profit making organisations;❏ Recreational data processing (family, household etc.);❏ Processing of personal data for the maintenance of a public register;❏ Staff administration data;❏ Advertising, marketing and public relations;❏ Accounts and records.

A controversial issue, relating to individual protection, is the exemption ofpersonal data processed for journalistic, artistic or literary purposes, wherethe publication is in the public interest. Effectively, the provision entitles themedia to disclose personal data about a data subject without fear of retort.After many media incidents demonstrating the tendency of the media to gotoo far, this issue is under heavy scrutiny. If the disclosure of personalinformation were likely to severely affect an individual’s life, it would appearthat such an individual has little recourse for preventing the information beingdisclosed. Some support is provided for the individual in claiming

308 Appendix A

compensation as the right to compensation is extended such that a data subjectcould claim compensation for distress, even when no damage has been caused.

The final right, the right for assessment (as mentioned earlier) is concernedmainly with the enforcement of data protection legislation upon a datacontroller. Any person may request that an assessment is performed todetermine whether a data controller is complying with the terms of the Act.The Data Protection Commission has the right to enter an organisation, withthe correct court order, and examine the data protection practices withoutprior notification to the organisation. If the data controller is found to be inbreach of the Data Protection Act, the Data Protection Commissioner maychoose to prosecute. This right does not have any direct benefit to theindividual apart from the prevention of similar occurrences in the future.

The Data Protection Act offers many safeguards against the misuse ofpersonal data, but there are still some circumstances where personal datacould be misused. As the amount of personal data stored on both electronicand manual systems increases, so the safeguards must evolve to accommodatenew developments. It is unlikely that there will ever be a completely water-tight Data Protection Act, but by adopting change and continually examiningthe situation, it will be possible to maintain a protective and relevant Act.

Bibliography 309

Bibliography

Ashworth C & Goodland M; SSADM A Practical Approach; McGraw-Hill, London;1990.

Avison DE & Wood Harper AT; Information Systems Development Research: An Explorationof Ideas in Practice; The Computer Journal Vol 34, No 2; 1991

Bennett, McRobb and Farmer; Object-Oriented Systems Analysis and Design using UML;McGraw Hill; 1999

Benyon D & Skidmore S; Towards a Tool Kit for the Systems Analyst; The ComputerJournal Vol 30, No 1; 1987

Boehm BW; Software Engineering Economics; Prentice-Hall Inc. New Jersey 07632; 1981Burrell G & Morgan G; Sociological Paradigms and Organisational Analysis; Heinemann,

London; 1979CCTA, The Stationery Office; SSADM Foundation: Business Systems Development with

SSADMCCTA, The Stationery Office; Data Modelling: Business Systems Development with SSADMCCTA, The Stationery Office; Database and Physical Process Design: Business Systems

Development with SSADMCCTA, The Stationery Office; Function Modelling: Business Systems Development with

SSADMCCTA, The Stationery Office; User Centred Design: Business Systems Development with

SSADMCCTA, The Stationery Office; The SSADM4+ Reference ManualCoad P & Yourdon E; Object Oriented Analysis; Yourdon Press/Prentice-Hall, New

Jersey; 1990Connor D; Information System Specification & Design Road Map; Prentice Hall, New

Jersey; 1985Cutts G; Structured Systems Analysis and Design Methodology; Paradigm Publishing,

London; 1988

310 Bibliography

Date CJ; An Introduction to Database Systems, 7th Edn; Addison Wesley, Wokingham;2000

Davids A; Practical Information Engineering – the management challenge; PitmanPublishing, London; 1992

De Marco T; Structured Analysis and System Specification; Prentice Hall, New Jersey;1979

Downs E, Clare P & Coe I; Structured Systems Analysis and Design Method Applicationand Context; Prentice Hall, London; 1998

DSDM Consortium; DSDM V3 ManualEva Malcolm; McGraw-Hill; SSADM Version 4: A User’s GuideFinkelstein C; An Introduction to Information Engineering; Addison Wesley, Wokingham;

1990Fitzgerald G, Stokes N & Wood JRG; Feature Analysis of Contemporary Information Systems

Methodologies; The Computer Journal Vol 28, No 3; 1985Flavin M; Fundamental Concepts of Information Modeling; Yourdon Press; 1981Flynn DJ; Information System Requirements: Determination and Analysis; McGraw-Hill;

1992Gane C & Sarson T; Structured Systems Analysis: Tools and Techniques; Prentice Hall,

New Jersey; 1979Gane C; Computer-Aided Software Engineering; Prentice-Hall; 1990Gilb T; Principles of Software Engineering Management; Addison-Wesley, Wokingham;

1988Graham DR; Incremental Development: review of nonmonolithic life-cycle development models;

Information and Software Technology 31, 7–20; 1989Graham DR; Incremental Development and Delivery for Large Software Systems, in CSR:

Sixth Annual Conference on Large Software Systems; Elsevier; 1990Graham I; Requirements Engineering and Rapid Development; Addison-Wesley; 1998Harrington J; Organisational Structure and Information Technology; Prentice Hall; 1991Henderson-Sellers B; A book of Object-Oriented Knowledge; Prentice-Hall; 1991Hoffer Jeffrey A, George Joey F, Valacich Joseph S; Modern Systems Analysis and Design;

Addison, Wesley and LongmanHolloway S; Methodology Handbook for Information Managers; Gower Technical,

Aldershot; 1989Kerr J & Hunter R; Inside RAD: How to build fully functional computer systems in 90 days

or less; McGraw-Hill, 1994Kim W & Lochovsky FH (Eds); Object-Oriented Concepts, Databases and Applications;

ACM Press, New York; 1989Kotonya Gerald & Sommerville Ian; Requirements Engineering: Processes and Techniques;

Wiley; 1998Jackson MA; Principles of Program Design; Academic Press Inc., London; 1975Land F. & Hirschheim R. Participative Systems Design: Rationale, Tools and Techniques;

Journal of Applied Systems Analysis, Vol 10; 1983Leffingwell & Widrig; Managing Software Requirements: A Unified Approach; Addison-

WesleyMartin J; Computer Database Organisation; Prentice Hall; 1982Martin J; Information Strategy Planning; James Martin Associates, Dublin; 1988

Bibliography 311

Martin J; Business Systems Design; James Martin Associates, Dublin; 1988Martin J; Information Engineering (Volumes 1–4); Savant, Carnforth; 1989Martin J; Rapid Application Development; Macmillan Publishing New York; 1991Martin J & McClure C; Structured Techniques For Computing; Prentice Hall, New Jersey;

1985McConnell Steve; Rapid Development, Taming Wild Software Schedules; Microsoft PressOlle TW et al. Information Systems Methodologies: A Framework for Understanding; Addison

Wesley, Wokingham; 1989Rock-Evans R; Data Analysis; IPC Business Press, Surrey; 1981Rumbaugh J, Blaha M, Premerlani W, Eddy F & Lorenses W; Object-Oriented Modelling

and Design; Prentice-Hall; 1991Skidmore S; Introducing Systems Design; Macmillan Press; 1996Sommerville I; Software Engineering; Addison Wesley, Wokingham; 1992Tudor DJ & Tudor DJ; Systems Analysis and Design – A Comparison of Structured Methods;

Macmillan Press; 1997Tudor DJ & Tudor DJ; Business Systems; NCC Education Services Ltd; 1997Ward P & Mellor S; Structured Development for Real Time Systems; Yourdon Press; 1986Weaver, Lambrou and Walkley; Practical SSADM Version 4+ Second Edition; Pitman

Publishing; 1998Yeates, Shields and Helmy; Systems Analysis and Design; PitmanYourdon E (Ed); Writings of the Revolution – Selected Readings on Software Engineering;

Yourdon Press, New York; 1982Yourdon E & Constantine L. Structured Design: Fundamentals of a Discipline of Computer

Program and Systems Design; Englewood Cliffs, N J Prentice Hall; 1989Yourdon E; Modern Structured Analysis; Prentice-Hall International; 1989Yourdon E; The Decline and Fall of the American Programmer; Yourdon Press, Englewood

Cliffs, New Jersey; 1992

312 Bibliography

Index 313

Index

access paths (through ERD) 231–235access requirements 281–282after value 246–247anomalies 207attributes 189audit requirements 281

BAM 107–113before value 246–247Booch 96, 98boundary 52, 118–119, 265Burns, T 30Business Activity Modelling (see BAM)business

activities 109, 110events 109–110objectives 22–23organisation 23–24perspectives 108projects 85rules 110system 59system options 75

CASE 168–169change 115change control 288–289

charitable institutions 15charts 291compound key 212Computer Aided Software Engineering

(see CASE)configuration manager 82constraints 280–281content 44–46context diagrams 151contingency theorists 30control procedures 128co-operatives 14–15corporate management 21cost justification 73–75costs 119

data 38, 94, 129–130element 156element entries 159–161flow entries 162gathering 210–211pipeline 138–139store entries 163store symbol 137structure 156structure entries 161

database principle 64–65

314 Index

decision making 37decision tables 178–184departmentalisation 25–26dependency 212discussion record 130documentation 47–48, 130, 299–300document filing 293–296documenting entities 200document flow diagrams 151domain 208domain of change 273, 274domain of computerisation 273domain of study 118DSDM 100–102Dupont 100dynamic model 97–98Dynamic Systems Development

Method (see DSDM)

effects 239e-mail 48elementary function description 151elementary process description 151ELSE rule 182–183entities 189–190entity process matrix 230–231Entity Relationship Diagram (see ERD)ERD 187events 93, 98, 238exclusive relationship 199external entity symbol 134

fall-back requirements 281feasibility study 73Fiedler, F 29filing (of documents) 293–296filing reference 296–298financial accounting 17–19first normal form 211–212flat organisational structures 29flow (of information) 47flowcharts 172–174foreign key 209formal information 32functional model 98functional relationship 25functions 93

Gannt chart 131grid chart 131

Hertzberg, Frederick 28hierarchical structures 31–32high level test plan 5history file 294–296human/computer interfaces 275–276Human Relations School 26–30human resources 19–20

identifier 189, 209implementation 78information

flow 47informal 32level 42–44purpose 42validity 46within business 37–38

inputs 54input data flow 239interviewing 124–125investigation 105–106investigation boundaries 118–119investigation objectives 118iteration 242–244

Jackson Structure Diagram 241Jacobsen 96, 98joint stock companies 14

key 189, 209, 211key data flows 142

level 1 DFD 149level number 296levels 140–142Likert, R 29local government 15logicalisation 253lower level DFD 149–151

maintenance 79management accounting 17–19

levels 34process 33–34

Index 315

services 21managers 81–83marketing 20Martin, James 100Maslow, Abraham 27–28Mc Gregor, Douglas 28mini-spec 141, 151, 171–172modules (in SSADM) 96municipal enterprise 15

name relationship 197nationalised industries 15new system file 294normalisation 205, 209normal procedures 128numeric coding 298

objectives (of investigation) 118Object Modelling Technique (see OMT)object model 97object-oriented modelling 96–98observation 122old system file 296O&M 130OMT 97–98optimisation 214optional event 244optional relationship 197–198Organisation and Methods (see O&M)organisation structure 24–33outputs 54

parallel running 78parallel structures 244partnerships 13–14physical constraints 280pilot project 88planning and control 34–36pre-printed forms 291presentation of results 120–121primary key 209procedures 128–129process 39–42process definitions 164processing 54process symbol 135–137production 16–17

project manager 81–82prototyping 100–101pseudocode 141, 177–178purchase and supply 17

quality management system 83quality manager 83questionnaires 124quit and resume 245

RAD 6, 79–80, 100–102Rapid Application Development (see

RAD)record searching 122–123recovery procedure requirements 281recursive relationship 199reduced redundancy 164relation 208relationships 190requirements analysis 76requirements catalogue 119–120requirements definition 112research and development 20–21resource flow 144–146resource flow diagram 151results presentation 120–121Revans, RW 40role (of systems analyst) 91–92Rumbaugh 97, 98

sales 17sampling 123–124second normal form 212–213selection 242sequence 242sinks 118–119, 142sole trader 13–14sort process 259sources 118–119, 142special purpose records 123specification 115–116specification commentary 280SSADM 93–96, 273stages (of system life cycle) 70–79Stalker, GM 30standard 293standard forms 286

316 Index

standards manual 292–293state indicators 245–248, 252steering committee 3–4strategy 72–73Structured English 175–177, 291sub-events 240–241sub-systems 60–64system

boundary 143categories 56–57concepts 52–55control 57–58file 296life cycle 65–70, 116–117model 58–64projects 85review 79

specification 2, 280–282systems analyst

characteristics 92role 91–92

systems development method 88

tabular representations 292tall organisational structures 29technical system options 75–76terms of reference 72–73, 117–121,testing

acceptance 6–7component 6integration 6system 6, 78

Theory X and Y 28Third Normal Form analysis (see TNF)time based events 239timescales 119TNF 205, 209–220TNF data group 220–221training (of staff) 88–89transient data stores 257–258trigger 144Trist & Woodward 30tuple 208

UML 98–99Unified Modelling Language (see UML)update processes 238Urwick, Lyndall 24, 25user catalogue 126user, dealing with 113–115user investigation 126–128user manager 83

validation 5verification 5V-model 2, 69–70

Waterfall model 67–69work practice modelling 126, 128workshops 125–126

Yourdon 96

www.nccedu.com

Feedback Form

Please give us any comments you have about this workbook.

Page numbers

Description(Please use BLOCK capitals)

Contact details(Please use BLOCK capitals)

Name:

Address:

Email:

Telephone no: Fax:

Please send photocopied forms to:

Product Development, NCC Education Ltd, The Towers, TowersBusiness Park, Wilmslow Road, Didsbury, Manchester, M20 2EZ.Fax Number: +44 0161 438 6240.

Business Systems Analysis

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

www.nccedu.com

Enquiry FormI would like to know more about NCC Education Limited and your products.

Please send information to:(Please use BLOCK capitals)

Name:

Address:

Email:

Telephone no: Fax:

I am interested in:(Please tick)

Academic Awards: English Language Framework International Foundation Year Computer Pioneers International Certificate in Computer Studies International Diploma in Computer Studies International Advanced Diploma in Computer Studies International Diploma in eCommerce BSc (Hons) in Computing and Information Systems International Diploma in Business International Advanced Diploma in Business Postgraduate Diploma in Strategic Business Information Technology MSc in Strategic Business IT with the University of Portsmouth 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 ICTfor Teachers

TechMaster Courses Systems Analysis Certification Systems Design Certification Database Design and Development Project Management Business Management

Automated Testing Software: Automated Test Software NCC Education PC Competency

Test

NCC Education Skills Profile Test NCC Education Recruitment Test

Please send photocopied forms to:Product Development, NCC Education Ltd, The Towers, TowersBusiness Park, Wilmslow Road, Didsbury, Manchester, M20 2EZ.Fax Number: +44 0161 438 6240.

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

Business Systems Analysis

The systems analyst is responsible for the investigation, analysis and outline design stages of the system

development life cycle. These phases of work are critical to the final design and successful implementation of the

resultant system, so it is essential that they are undertaken in a professional manner.

This book gives an overview of the more common analysis techniques and discusses how to use them most

effectively. It also reviews the mix of business, technical and inter-personal skills required by the successful systems

analyst.

In particular it covers:

> A review of defined methods and techniques for systems development

> The scope and nature of investigation, including the use of Business Activity Modelling

> The production of Data Flow Diagrams and the Data Dictionary

> How to use flowcharts, structured English and decision tables to produce the 'mini-spec'

> The roles of entity analysis, data analysis and entity life histories in structured systems analysis

> Construction of the logical systems model

> The preparation of the structured specification

The text takes the student through the stages of systems analysis in a clear and concise manner, with practical

examples provided for the tools and techniques discussed. Extensive exercises are included at the end of each

chapter.

ISBN: 1-90234-348-4

www.nccedu.com

Date post:	04-May-2018
Category:	Documents
Upload:	hoangnhi
View:	218 times
Download:	3 times