Systems Analysis

These and other applications within a business are interconnected by the information, which flows between them. Such connections can be illustrated with the use of data flow diagrams (DFD), which are described in Chapter 25.

Establishing priorities for computerisation

The applications which are going to bring greatest benefit to the business should be computerised first.

Establishing individual system objectives

The objectives of the relevant application must first be clearly understood.

The following is a typical list for stock control serves to illustrate the definition of such objectives.

• To maintain levels of stock which will be sufficient to meet customer orders promptly.
• To provide a mechanism which removes the need for excessive safety margins of stock to cover customer orders. This is usually effected by setting minimum stock levels, which the computer can use to report variations below these levels.
• To provide automatic re-ordering of stock items which fall below minimum levels.
• To provide management with up-to-date information on stock levels and values of stocks held.

---

Contents of the Feasibility Report

The Feasibility Report should contain the following sections:

Terms of reference

These should set out the original purpose of the study, as agreed by management and detail the business objectives to be achieved, for example:

1. the improvement of customer service, such that orders are delivered within 24 hours of order receipt;
2. the provision of more up-to-date management information on current stock levels and projected customer demand;
3. a tighter control of the business's cash resources, primarily through better stock management.

Applications considered for computerisation

The applications which may assist the achievement of the business objectives set out in the Terms of Reference are listed, for example: stock control; purchasing; sales order processing; invoicing; accounts.

System investigations

For each application under consideration there should be:

• a description of the existing system;
• an assessment of its good and bad points. For example, the sales order processing system may be slow to process customer orders and this results in poor delivery times, which in turn causes customers to take away their business;
• an estimate of the costs of the existing system. For example, apart from the cost of staffing, an estimate has to be made of the cost of lost business, which could be avoided with an improved system.

Envisaged system requirements

This section should detail, in general terms, those aspects of each application which need to be improved and a broad outline of how each system may operate following computerisation.

Costs of development and implementation

These will include both capital costs and revenue or running costs. Capital costs are likely to be incurred for the following:

1. computer hardware;
2. systems software and software packages (either 'off-the-shelf' or 'tailor-made');
3. installation charges for hardware and software;
4. staff training.

Revenue costs include those for the maintenance and insurance of the system. In addition, unless there are existing computer specialists in the organisation, additional suitable staff may need to be recruited

Timescale for implementation

This will depend on the scale of the operation, the type of application and whether or not packaged software is to be used.

Expected benefits

These are more difficult to quantify than the costs but may include, for example:

• estimated savings in capital expenditure on typewriters and photocopiers;
• more efficient stock management allows customer service to be maintained whilst keeping stock levels lower. This releases valuable cash resources and reduces possible interest charges on borrowed capital;
• expansion in business turnover, without the need for extra staff and reduced overtime requirements.

Other considerations

The staff have to support any development for it to be properly successful and this usually means consultation at an early stage in the feasibility study and the provision of a proper staff-training programme. Customers must also be considered. For example, when a customer receives a computer produced invoice it should be at least as easy to understand as the type it replaced. Assuming that the feasibility study concludes that the proposed computerisation is worthwhile, according to the criteria set out in the report, then more detailed investigation and design can follow.

---

System Investigation and Design

Introduction

If the feasibility report gives the go-ahead to the computerisation project, then a more detailed investigation of each candidate system begins. The facts gathered about each system will be analysed in terms of their bearing on the design and implementation of a computerised version. The objectives of the analysis are to gain a thorough knowledge of the operational characteristics of the current system and to settle, in a fair amount of detail, the way in which a computerised system will operate. It is extremely important that the new system does not simply computerise existing procedures. The design should, as far as possible, ignore existing departmental structures, which may inhibit the introduction of different and improved procedures. The aim of the investigation and design process is to produce a specification of users' requirements in documented form. This is referred to as the Statement of User Requirements and will be used to tender for supply of hardware and software.

Fact-finding methods

There are several methods, which can be used to gather facts about a system:

1. interviewing;
2. questionnaires;
3. examination of records and procedure manuals;
4. examination of documents;

8. observation.

Each method has advantages and disadvantages and the method or methods chosen will depend on the specific circumstances surrounding the investigation, for example, the size of the business, the number of staff employed and their location and distribution.

Interviewing

This method has much to recommend it, in that the facts can be gathered directly from the person or persons who have experience of the system under investigation. On the other hand, a business with a number of geographically distributed branches makes the process of extensive interviewing expensive and time-consuming. Further, interviewing skills need to be acquired if the process is to be effective. The interviewer needs to know how to gain the confidence of the interviewee and ensure that the information, which is given, will be of value in the design of the new system. Questions need to be phrased unambiguously in order that the interviewee supplies the information actually required and a checklist of points will help to ensure that all relevant questions are asked. Of course, the interview may need to stray from the points in the checklist, if it becomes apparent that the interviewee is able to provide relevant information not previously considered. For example, clerical procedures may be designed quite satisfactorily but may be made less effective because of personality conflicts between staff. Such tensions may only be revealed through personal interview.

The interviewer also needs to detect any unsatisfactory responses to questions and possibly use alternative methods to glean the required information. Unsatisfactory responses include:

• Refusal to answer. Such refusal may indicate, for example, that set procedures are not being followed and that the member of staff does not wish to be 'incriminated'.
• Answer with irrelevant information. It may be that the question is ambiguous and has to be re-phrased in order to elicit the required information.
• Answer with insufficient information. If a system is to be designed which covers all foreseeable user requirements and operational circumstances, it is important that the analyst has all relevant information.
• Inaccurate answer. The interviewer may or may not be aware that an inaccurate answer has been given but it is important that other sources of information are used to cross-check answers

---

Questionnaires

Questionnaires are useful when only a small amount of information is required from a large number of people, but to provide accurate responses, questions need to be unambiguous and precise.

The questionnaire has a number of advantages over the interview:

• each respondent is asked exactly the same questions, so responses can be analysed according to the pre-defined categories of information;
• the lack of personal contact allows the respondent to feel completely at ease when providing information, particularly if responses are to be anonymous;
• questionnaires are particularly suited to the gathering of factual information, for example, the number of customer orders received in one week;
• it is cheap, particularly if users are scattered over a wide geographical area.

A number of disadvantages attach to the use of questionnaires:

• questions have to be simple and their meaning completely unambiguous to the respondents;
• if the responses indicate that the wrong questions were asked, or that they were phrased badly, it may be difficult to clarify the information, particularly if the respondents were anonymous;
• without direct observation it is difficult to obtain a realistic view of a system's operation.

The questionnaire often provides only statistical information on, for example, volumes of sales transactions or customer enquiries.

Examination of records and procedure manuals

If existing procedures are already well documented, then the procedure manuals can provide a ready-made source of information on the way procedures should be carried out. it is important to realise that procedures detailed in manuals may not accord entirely with what actually happens. The examination of current records and the tracing of particular transactions can be a useful method of discovering what procedures are carried out.

Special purpose records, which may involve the ticking of a box when an activity has been completed, can be used to analyse procedures, which are causing delays or are not functioning efficiently. The use of special purpose records imposes extra burdens on staff who have to record procedures as they happen and the technique should only be used when strictly necessary.

Examination of documents

It is important that the analyst examines all documents used in a system, to ensure that each:

• fulfils some purpose, that is, it records or transmits information which is actually used at some stage. Systems are subject to some inertia, for example, there may have been a 'one-off' requirement to record and analyse the geographical distribution of customers over a single month and yet the summary document is still completed because no-one told the staff it was no longer necessary;
• is clear and satisfies its purpose, for example, a form may not indicate clearly the type of data to be entered under each heading. In any case, it may well require re-designing for any new system which is introduced.

The documents, which should include, for example, source documents, report summaries, customer invoices and delivery notes, help to build a picture of the information flows which take place from input to output.

Observation

It is most important to observe a procedure in action, so that irregularities and exceptional procedures are noticed. Observation should always be carried out with tact and staff under observation should be made fully aware of its purpose, to avoid suspicions of 'snooping'.

The following list details some of the features of office procedures and conditions, which may usefully be observed during the investigation:

• office layout - this may determine whether the positioning of desks, filing cabinets and other office equipment is convenient for staff and conducive to efficient working;
• work load - this should indicate whether the volume of documents awaiting processing is fairly constant or if there are peak periods of activity;
• delays - these could show that there are some procedures which are constantly behind schedule;
• methods of working - a trained observer can, through experience, recognise a slow, reasonable or quick pace of working and decide whether or not the method of
• working is efficient. It is important that such observations should be followed up by an interview to obtain the co-operation of the person under observation;
• office conditions - these should be examined, as poor ventilation, inadequate or excessive temperatures, or poor lighting can adversely affect staff efficiency.

Often the observation will be carried out in an informal way but it may be useful on occasion to, for example, work at a user's desk, so as to observe directly the way that customer orders are dealt with. It is important to realise that a user may 'put on a performance' whilst under observation and that this reduces the value of the information gathered.

Documenting the results of analysis

A number of standard approaches, apart from narrative description, can be used to document the result of the system analysis, including: data flow diagrams (DFDs); organisation charts system flowcharts. Their applications are illustrated in the following section, which examines the categories of information, which need to be gathered and recorded during a system investigation.

Categories of system information

The major categories of information which need to be gathered involve:

• functional relationships and data flows;
• personnel and jobs;
• inputs;
• processes;
• outputs;
• storage.

Functional relationships and data flows

A business has a number of functional areas, such as Sales, Accounts, Stock Control and Purchasing, each having its own information system. However, the computerisation of a system in one functional area cannot be carried out without considering its effects on the rest of the business. Information systems within a business interact with and affect one another. The business, as an entity, also interacts with and is influenced by individuals and organisations in the surrounding environment and the business's individual information systems should be co-ordinated to allow the achievement of overall business objectives. The data flows between individual functional areas can be illustrated with the use of a data flow diagram.

Personnel and jobs

It is possible to design a computerised system without involving staff, but it is likely to be less successful, partly because users can provide valuable insights into the practical aspects of system operation and partly because they will feel less motivated if they have had little or no influence on the final design.

A formal organisation chart can be used to gain an overall picture of staff relationships and responsibilities but it should be borne in mind that designated and actual job responsibilities can differ radically. For example, it may turn out that a junior sales clerk is carrying out the checking of orders, which should be the responsibility of the sales supervisor.

For example, a job description for a sales clerk may include the following activities:

completion of standard order forms; checking stock availability; notification of orders to accounts.

Therefore, although the sales departmental manager may have knowledge of such procedures, the sales clerk will have practical experience of their operation and should be consulted.

---

System inputs

A number of details concerning the data inputs to a system need to be established:

• source. It may, for example, originate from a customer, a supplier, or another department in the business;
• form. The data may arrive, for example, by telephone, letter, or a standard form such as an order form or supplier's invoice;
• volume and frequency. For example, the number of orders received daily or weekly;
• contents. For example. the individual items of data which appear on a supplier's invoice.

Such information will allow the analyst to make recommendations on the most appropriate methods of computer input. The design of appropriate input methods also has to take account of several tasks involved with the collection and entry of data to a system:

• recording. For example, the completion of a customer order form following receipt of a customer order by telephone;
• transmission. For example, the order details may need to be transferred to another department or branch of the business for encoding and computer processing or they may be keyed in directly at the point of collection;
• visual checking. It may be, for example, that a customer order has no quantities entered;
• encoding. Verification procedures need to be designed to prevent transcription errors when data is encoded onto a computer storage medium for processing;
• validation. Data is checked by a data vet program against set limits of validity, for example, account numbers may have to fall between a particular range of values.

Thus, decisions need to be made concerning:

1. data collection procedures;
2. methods for the transmission of data to the place of processing;
3. data entry, data verification and data validation procedures.

Data collection

The designer needs to be aware of the available input technologies. These can be divided into two categories, keyboard entry and data capture technologies such as bar code reading, optical character reading (OCR) and optical mark reading (OMR), which allow direct input to the computer from specially designed input forms.

Keyboard entry

This is the most common method of input and requires the transcription of data from source documents. These can be designed to minimise the possibility of transcription errors at the data collection stage.

Direct input

Bar codes are pre-encoded and are thus immune from errors of transcription (assuming that the' bar code is correct in the first place). Optical mark reading requires that pencil marks be used to indicate particular values from a limited set on a pre-designed form. Although no keyboard entry is required, mistakes may be made by the originator of the document and good design is therefore important.

Data transmission

It may be that no data transmission is necessary because the data is processed at the point of collection. For example, customer orders may be recorded on order forms at the sales desk and then taken into the next room for keying into the computer. Alternatively, the data may have to be transmitted some distance, perhaps to another floor of the building or to another building some miles away. A fundamental decision has to be made, whether to localise processing at the points of collection, or to use a central facility with data communications links from each location.

Data entry

The data entry method chosen will depend on the data collection methods used and may involve keyboard transcription from source documents or data may be captured directly from bar codes, OCR or OMR type documents. Where keyboard transcription is used, verification and validation procedures are likely to be interactive, in that the data entry operator has to respond to prompts on screen and make corrections as and when the system indicates

Most small business computer systems will be used for on-line processing, where transactions are processed immediately with master files at the data entry stage. Consequently, validation and verification have to be carried out immediately prior to the processing of each transaction.

On-screen verification

At the end of each transaction entry, the operator is given the opportunity to scan the data on the screen and to re-enter any incorrect entries detected. This usually takes the form of a message at the bottom of the screen, which is phrased in a way such as Verify (yes or no).

---

On-screen validation

Character, data item and record checks, such as range and mode checks, can be made each time the RETURN key is pressed during data entry. For example, the screen may prompt for the en-try of an account number, which must be 6 digits long and be within the range 000001 to 500000. Any entry which does not conform with these parameters is erased and the prompt re-displayed for another attempt.

Appropriate screen dialogue to allow the data entry operator to enter into a 'conversation' with the computer is a crucial part of the input design process and is dealt with as a separate topic in Chapter 21.

Batch data entry

The type of keyboard transcription used will be affected by the type of input data. Where, for example, files only need to be updated weekly, transaction data may be batched and entered onto magnetic disk for processing at a later stage in one update program run.

---

System processes

All the clerical and machine-assisted processes, which are necessary to achieve the desired output from the given inputs, need to be identified. This will allow the systems analyst to determine the role of the computer in the new system, the programs necessary to take over the processing stages and the changes needed to clerical procedures, before and after computer processing.

There are many instances when the processing requires not only the input data but also data retrieved from files. For example, to generate a customer invoice requires:

1. input data concerning commodity codes and quantities ordered;
2. data from the stock master file concerning prices of items ordered by reference to the input commodity codes;
3. customer details from the customer master file.

The above processes can be completely computerised but other processes may require human intervention. For example, before a customer order is processed, the customer's credit status may need to be checked and referred to a supervisor before authorisation.

Non-standard procedures

Most processes will follow standards suitable for their particular circumstancesIt is important, however, that the investigation identifies and notes any non-standard procedures. For example, what procedure is followed when there is an insufficient quantity of an ordered item to completely fulfil a customer order? It may be that some customers will take part-orders, whilst others require the full quantity of an item or none at all. If non-standard procedures are needed, it is important to know their complexity, how often they are used and what extra information is required. Ideally, a system should be designed to cope with all possible circumstances, but cost sometimes forces a compromise.

Document flow

System flowcharts can be used to model the movement and interaction of documents and the data they record, as well as the processes involved. In order that the involvement of each section, department or personnel grouping in the processes can be identified, the system flowchart is divided into columns representing these divisions of responsibility.

---

Based on the above information, the following tasks can be carried out:

1. selection of an appropriate output device to display or communicate the outputs.
2. designing output screen and document layouts.

---

System storage (files)

The storage of historic and current information is a vital part of any business system. For example, to produce a payslip not only requires transient input data concerning hours worked and sickness days but also data on rate of pay, tax code, deductions of tax and superannuating to date etc., which are held in the payroll master file stored on magnetic disk. Information on the contents of files will be gathered from existing manual files, together with responses from users regarding the output requirements of any new system. If packaged software is to be used then the contents of files will be dictated by the package, in which case some data item types may be surplus to requirements, whilst others which are required may not be available.

File contents

Each file consists of a number of logical records, each of which has a number of associated data items. For example, each stock record in a stock master file may include:

Stock Code;

Description;

Unit Price;

Minimum Stock Level;

Re-order Quantity;

Quantity in Stock.

File organisation and access

This concerns the logical ordering of records within a file.

Database management systems (DBMS)

An increasingly popular alternative to traditional file processing systems is to construct databases controlled by a DBMS. The design process requires that data is analysed according to subject area, for example, raw materials or staffing, rather than by department or functional area.

Choice of storage device

Choice is concerned with storage capacity, mode and speed of access.

Data Flow Diagrams

Data Flow Diagrams are a widely used technique for representing the information flows of a system.  They are a particular feature of SSADM methodology (Structured Systems Analysis and Design Method).

They arc used in the early stages of a systems analysis to provide an understanding of the present system. As the project proceeds they are used to represent the required and also as a basis for program specification.

DFDs can be drawn at various levels of detail. At the high Level the DFD is known as a Context Diagram which shows the system as one box with flows going to and coming from external entities. This can then be decomposed into more detailed DFD’s.  A DFD can show the physical processing of the present system detailing the departments and individuals concerned in the work, or it can be a logical DFD which shows what happens to the data rather than how the processing is carried out.  A logical DFD is useful as it frees the analyst from being over influenced by the present system.

Purpose of A Data flow diagram

It is a diagrammatic representation of information flows within a system showing:

• how information enters and leaves the system.
• what changes the information.
• where information is stored.

A DFD is also useful to:

• show the boundaries and scope of the system.
• check the completeness of the analyses
• ensure that all information flows and activities have been considered.
• show the major functional areas of the system and therefore identify particular program requirements.

DFDs can he used by both technical and non-technical staff and is used in discussions between the analyst and the user.

One of the greatest strengths of DFDs is that they can be used to describe a system at several levels.

Components of DFD’s

External Entity

The source of information provided to the system. Or the recipient of information provided by the system. An oval shape represents it.  If understanding of the DFD can be enhanced then an external entity may be drawn more than once.

Process

A process transforms or manipulates data within the system. It is represented by a box and will include a numeric identifier, the location of the process, and the process identifier. When naming processes begin with a verb and follow it by an object. e.g. Make Delivery, Receive payment. The object should always be singular.

Data Store

Data stores may be manual or computer files, and represent the place where a process places data so that it can be retrieved later. Each data store is labelled with the letter M for manual or D for computer and is given a number.

Data Flow

Represented by an arrow which should be labelled with the data that is being carried (never use a verb on a data flow).

Boundary

A boundary is sometimes drawn around a DFD to show the limits of what is being investigated.

Levels of DFD

Level 0 DFD (Context Diagram)

Shows the entire system a single black box communicating with the external entities.

Level 1 DFD

An outline DFD using typically up to 12 process boxes. It shows:

• system boundaries,
• external entities
• main system flows,
• main system functions.

• data stores.

Level 2 and 3 DFD

Successively more detailed DFDs showing up to 8 process boxes per DFD.

---

Data Flow Diagrams - How do you start?

Case study - Example

Draw a Data flow diagram of the following scenario

Data flow diagrams

A manufacturing company has a strict health and safety policy. They have a small health and safety department, which maintains safety levels in the organisation. They require that employees report any problems to them if they discover faults within the organisation of a hazardous or potentially hazardous nature.

Reports from employees are received in the Health and Safety department either by telephone, e-rnail or internal memo. This information is received by the health and safety administrator who logs the calls on his fault logging computer database. The computer database issues a unique problem number, which is given to the head of department of the employee highlighting the fault. The head of department is also provided with details of the nature of the problem.

There are two health and safety inspectors employed by the organisation who investigate the problems when they occur. They are based in the health and safety department and are given the details of the problem and the fault number from the computer database by the administrator who logs the assignment of the task on the fault logging database.

When the problem is investigated and therefore the task is completed the inspectors contact the administrator to advise them of the situation. The administrator advises the particular head of department that the necessary work has been carded out and the task is closed in the fault logging database.

---

Example 1

A purchasing department receives a purchase requisition from the stores. The requisition is checked, and an invalid requisition is returned to the stores for correction. An order is made out using a file of approved suppliers, and sent to the appropriate supplier. A copy order is filed. The requisition is filed.

When the goods arc received the invoice is compared with the filed copy order and an invalid invoice is returned to the supplier. Valid invoices are passed to the accounts department for payment, and fulfilled orders are filed.

Draw a Level 0 and level 1 DFD for the purchase requisition system.

Example 2

When an invoice is received from a supplier, it is checked against a file of authorised purchases. If the invoice does not much an authorised purchase it is returned to the supplier with, a querying letter. If the invoice matches an authorised purchase, but is for an incorrect amount then it is returned to the supplier with a standard form. If the invoice reconciles, a payment authorisation is made out. A cheque is then sent to the supplier, and the invoice and the authorisation are filed. Draw a level 0 and Level 1 DFD for the system.

Example 3

This case study is based on the video issue recording system of the Gentlepeople's Video Library Club (GVLC). GVLC specialises in obscure videos that are not readily available from other sources. GVLC lends only to members of the Video Society part of the exclusive and very desirable Gentlepeople's Club. Details of finance are outside the scope of the investigation. Any member of the club is automatically a member of the library. Club membership is for one year; a few new members are admitted on 1 January each year; new members are not admitted during the year.

The library is set up along conventional lines, though members are not restricted as to the number of videos they may borrow at any one time. Videos are requested for return only if required by another member. Most active users of the library regularly change their videos.  Two or three copies of popular titles are available.

In order to borrow a video a member selects it takes it to the issue desk and gives the video and his club membership card to the librarian. The librarian takes the video ID card from the video sleeve and adds the membership number to the card. The librarian places the card in the loans file and the member leaves with the video.

When a member returns a video. He or she presents the video to the librarian. The librarian finds the video card in the loans file and places the card in the video sleeve before returning the video to the library shelves.

To reserve a video, which is on, can. A member asks the librarian and leaves their membership number. The Librarian finds a relevant video in the loans file and adds the members number on the reservation column on the video card. The librarian also makes a note of the member who has the video on loan and completes a return request card addressed to that member. The address is taken from the library copy of the club membership book. When the reserved video is returned the librarian puts the video under the counter and completes a Reservation Ready card addressed to the member who requested the reservation again taking the address from the membership book. Tine member requiring 'he video 'can then pick the video up from the librarian and have it issued in the usual manner.

Members make many enquiries of the librarians: typical questions include

• is the video entitled ‘Dziadek’ on loan?
• Which video did actress Anna Kucharski appear in?
• have we a video entitled 'Son of Arturo'?
• Have we any videos on the subject 'Right Action'?

The librarians are able to answer these queries by inspecting the loans file the actor index the subject index and the title index.

In addition to the above duties the librarians receive new videos from the social committee of the club. The selection ordering and payment for the videos is outside the scope of this investigation. On receipt of the new video the librarian has to make out a video card for insertion in the video sleeve and the relevant entries for the indexes.

The librarians are also responsible for amending the library copy of the membership book with changes of address and at the end of the year far collecting the new membership bock from the Club Secretary.

---

Answers

Activity 1 – College Library

1. Zero Normal Form - 0NF
   List Attributes
   
   Stud#
   Name
   Address
   TG
   Tutor
   Book#
   Title
   ISBN
   ReturnDate
   
   Identify Primary key and repeating attributes. Write out in 0NF using standard notation:-

STUDENT(Stud#, Name, Address, TG, Tutor, Book#, Title, ISBN, ReturnDate)

2. First Normal Form -1NF
   Rule- An entity in First Normal Form must not contain any repeating attributes.
   
   Remove repeated attributes to form a new entity LOAN_BOOK. There are now 2 entities in 1NF:-
   
   STUDENT(Stud#, Name, Address, TG, Tutor,)
   
   LOAN_BOOK(Book#,Stud#, Title, ISBN, ReturnDate)
   (A composite key is required to uniquely identify each loan of a particular book)
   
3. Second Normal Form – 2NF
   Rule – An entity is in 2NF if it is 1NF and all non key attributes are fully functionally dependent on the whole of the primary key.
   ( 2NF applies to entities with composite keys, that is a primary key composed of two or more attibutes. An entity which is already in 1NF, with a single attribute primary key is automatically in at least 2NF)
   
   The STUDENT entity has a single attribute primary key and is therefore already in 2NF. The LOAN_BOOK entity has a composite primary key so we need to examine all the non-key attributes to ensure they are fully functionally dependent on the whole of the primary key.
   
   

Therefore Title and ISBN need to be removed to form a new entity BOOK. Book# is included to provide a link.

The tables in 2NF are now:-

STUDENT(Stud#, Name, Address, TG, Tutor,)

LOAN_BOOK(Book#,Stud#, ReturnDate)

BOOK(Book#, Title, ISBN)

4. Third Normal Form – 3NF
   
   Rule – To be in 3NF an entity must be in 2 NF (and therefore in 1NF) and contain no non-key dependencies. Fields which are not part of the primary key must always depend on the primary key and not on anything else, such as another non key field.
   
   Consider the entity STUDENT, Name & Address depend on the primary key but Tutor depends on the Tutor Group code TG and not on Stud#. They should therefore be removed to form a new entity, TUTOR. A copy of the code TG is left in the student table to form a link.
   
   STUDENT(Stud#, Name, Address, TG)
   TUTOR(TG, Tutor)
   
   Consider the entity LOAN_BOOK, return date is dependent on the primary key and therefore already in 3NF.
   
   Consider the entity BOOK, title is dependent on the ISBN and not on the Book#, this should be removed to create a new entity ISBN. A copy of ISBN is left in the BOOK entity to provide a link.
   
   BOOK(Book#, ISBN)
   ISBN(ISBN, Title)
   
   
   The final tables are:-
   STUDENT(Stud#, Name, Address, TG)
   TUTOR(TG, Tutor)
   LOAN_BOOK(Book#,Stud#, ReturnDate)
   BOOK(Book#, ISBN)
   ISBN(ISBN, Title)