DO NOT COPY Do Not Plagiarise or Cheat - Tees samples...Marie Barwick – HNC Year 1 – SA&D Page 6...

Marie Barwick – HNC Year 1 – SA&D

DO NOT COPY Do Not Plagiarise or Cheat

Read the Schools Procedures on the Intranet

The plagiarism detection software, Turnitin, is useful for checking whether

plagiarism has occurred in text-based assessments.

The aim of the sample is to provide an overview of typical student work.

Do not copy or follow the style in the samples provided as you will inevitably

take the good and bad styles over to your project.

You must revise content to suite your ica or project.

The samples are protected from both copying and printing.

Use it to help kick start and focus your attention on the need for pro-active work towards your ica or project.

All students are expected to have none or limited experience in developing and

documenting an ICA or Project.

Students need to adopt an appropriate Systems Development Methodology for their proposed system and to utilize that as the basis for their report content.

REPORTS NEED TO CONFORM OR UTILISE THE FOLLOWING GUIDES:

• Writing Formal Reports by Anne Siedles • Advance Word Features by Phil Willers

Do Not Plagiarise or Cheat

https://outranet.scm.tees.ac.uk/staff/school_info/assessment/plagiarism_and_cheating.html


Happy Hour Driving School Computer System.

Systems Analysis & Design Mansha Nawaz.

Marie Barwick - HNC/D Year 1.


Index Page Section Description 1 Introduction 1.0 Terms of Reference

1.1 Statement of Purpose

1.2 Requirements

2 Systems Analysis -Data Flow Diagrams 2.0 Context Diagram

2.1 Events List

2.3 DFD Fragments & Top Level Diagram

2.4 Low Level Diagrams

3 Systems Design - Data Dictionary 3.1 Data Store List

3.2 Data Sample

3.3 Data Store Descriptions

3.4 Data Flow Descriptions

3.5 Data Structures

3.6 Process Descriptors

4 Critical Review

4.1 Critical Review Of Report

4.2 Critical Review Of Analysis

4.3 Critical Review Of Design


1 Introduction

1.0 Terms of Reference

Mr Bilbie and his wife run a small driving school and have done for ten years. They have two

cars and approximately 50 pupils on their books. Just recently Mr Bilbie joined forces with a friend of

his called Mr Chaudry who also runs a driving school. They have also bought between them another

school from an old friend who is retiring. The new business is called Happy Hour Driving School, and

between them they have 12 driving instructors, with 12 cars and currently 250+ pupils registered for

lessons. These numbers are increasing, as the business merge is a success, however the old

paperwork system is now a full time job for Mr Bilble and Mr Chaudry and is overwhelming so there is

a need to simplify the work by having a computer system in place.

1.1 Statement of Purpose The system is designed to register pupils with the driving school and also driving instructors.

When registering a new pupil an instructor will be assigned, on a daily basis the instructor should be

able to print of f his lesson plan for the day so the need for an instructor schedule is vital. The system

must also consist of a booking system for normal lessons and test bookings; the need for recording

test results is also required. Normal lessons are one hour long and test bookings are two hours long,

the need for a car schedule is also vital, as the car will need to be booked out with an instructor for

these. The system will also need to have a car schedule to record car service details, MOT, Insurance

and also DVLA data. One of the most important other aspects of the system is to record payments,

these will be bookings (including the Block Booking with 10% Discount), refunds, invoices, instructor

pay and maybe the occasional fine.

1.2 Requirements • Allow user to register pupils on the system.

• Assign an instructor to each new pupil by checking the instructor’s schedule.

• Allow user to input lessons and test bookings.

• Allow the user to record payments (bookings, invoices, instructor pay, fines, refunds)

• Allow the user to store test results.

• Maintain car service / MOT schedule.

• Register cars on the system.


2 Systems Analysis - Data Flow Diagrams

Dataflow diagrams are commonly known as DFD’s. These are a System Modelling CASE

Tool, which allows the user to show a graphical representation of the system itself. These DFD’s can

be broken down into sub sections to show a more detailed view of the system and its requirements.

2.0 Context Diagram This is a simple diagram representing the proposed system as a whole. The system is shown

as a single process and is represented by a circle. The purpose of this diagram is to show clearly all

the system’s interfaces. Example: Pupil, Instructor etc.

Figure 1: Happy Hour Context Diagram

2.2 Events List • Register Pupil with School

• Maintain Car Service / MOT schedule

• Input Bookings

• Maintain DVLA Data

• Record Payments

• Record Fines

• Register Cars


2.3 Data Flow Diagram Fragments as a Top Level Diagram The Context Diagram can be broken down to sub sections called Event Partitioning or

Fragments, these Fragments are based on the event list above and each have a separate process to

give a more detailed outlook of the system. Fragments introduce data stores, which show the flow of

data. These Fragments are then combined together to create our Top Level Diagram.


Figure 2: Fragments & Top Level Diagram

The above diagram shows all of the events that make up the system as a whole.

1.1 Register Pupil – Registers the pupils into the system and also has block booking information if the

Pupil requires the discount of 10%

1.2 Maintain Car Schedule – This has all the car information in reference to Service, MOT &

Insurance. This must be kept up to date as the car needs to be road legal.


1.3 Input Bookings – The Instructor is responsible for inputting the bookings at the end of each day,

This also imports data into their schedule and then enables them to print of a daily schedule.

1.4 Maintain DVLA Data – This maintains the car registration information when a new car is

purchased.

1.5 Record Payments – All Payments come through this part of the system. These include bookings,

invoices, instructor pay etc.

1.6 Record Fines – All fines on each car and against each instructor are updated here as we do not

want to employ constant offending instructors.

1.7 Log Tests – All test results are logged here by the instructor, this will enable us in the future to

show statistics on how the school as a whole is performing.

2.4 Low Level Diagram The Fragments & the Top Level Diagram can be broken down into even sub sections called Low Level

Diagram these diagrams are still based on the Fragments & the E vent List however are in even more

detail than the Fragments themselves. Once again these have a separate process to give a more

detailed outlook of the system. Once again the flows of data and the data stores can be viewed here.

Figure 3.0 Low Level DFD – Register Pupil


Figure 3.1 Low Level DFD – Maintain Car Schedule

Figure 3.2 Low Level DFD - Input Bookings


Figure 3.3 Low Level DFD – Maintain DVLA Data

Figure 3.4 Low Level DEF – Record Payments


Figure 3.5 Low Level DFD – Record Fines Figure 3.6 Low Level DFD – Log Tests The above Low level diagrams show the following…


Figure 3.0

1.1.1 Register Pupil – Pupils register with the system and enquire about block booking, pupil details

are stored in the Pupils data store.

1.1.2 Assign Instructor – Pupils book lesson are assigned an instructor, the pupil can also change

instructor is they require, data is transferred into the Instructors and the Bookings data stores

Figure 3.1

1.2.1 Maintain Service Schedule – Car service details are complete and are input into the car

Schedule Payments data store along with payments, which are logged into the Payments data

store.

1.2.2 Maintain MOT Schedule – Car MOT complete and details are input into the Car schedule data

store, payments are also logged into the Payments data store.

1.2.3 Maintain Insurance – Insurance for all cars are complete and up to date, these are logged in

the Car schedule database and payments are logged in the Payments data store.

Figure 3.2

1.3.1 Log Bookings – Instructor logs payments and bookings into the system. Bookings are updated

in the data store, as are the payments. The car is also booked out via the Car Schedule, and

the instructor schedule is updated. The instructor can then print his schedule.

1.3.2 Log Test – Instructor can book tests and log payments, the relevant data stores are updated

and once again he can print off his schedule.

Figure 3.3

1.4.1 Maintain DVLA Tax Data – Tax reminder from the DVLA is due, the documents are stored in

the DVLA data store, the instructors schedule is updated as well as the Car Schedule.

1.4.2 Maintain Car Registration Data – car registration is sent to the business and these are

updated as above and stored in the relevant place.

Figure 3.4

1.5.1 Record Car Invoices – Invoices and Tax are updated in the system and all payments are

logged in the Payments data store

1.5.2 Record Instructor Pay – Instructors schedule is checked and the instructors pay is worked out,

payments are logged in the Payments data store

1.5.3 Record Booking Payments – Bookings are added to the system and payments are updated

and logged in the payments data store.

1.5.4 Record Refunds – Refunds are checked in the system and for those pupils who have passed

in with the 20 lessons are due a refund. Payments are updated in the payments data store.

Figure 3.5


1.6.1 Record Speeding Tickets – Local authorities send documentation to the business in reference

to speeding. The instructor’s data store is updated with the ticket and so is the Payments data

store. The fine is also sent to the instructor.

1.6.2 Record Parking Fines – Local authorities send documentation to the business in reference to

parking fines. The instructor’s data store is updated with the ticket and so is the Payments

data store. The fine is also sent to the instructor.

Figure 3.6

1.7.1 Request Test – Pupil Requests to book a test, the instructors schedule is then checked and

the Car schedule is checked to book the car out for a two hour lesson.

1.7.2 Book Test – The test is then booked and payment is taken and updated in the Payment data

store

1.7.3 Test Result – The instructor inputs the test result into the system, this is added to the test

results data store and the pupils database for future reference.


3 Systems Design – Data Dictionary 3.0 Data Dictionary

The data dictionary is a collection of further details about everything that is set within the data

store and the processes. Each data store and data flow requires a description of comprising its own

Data Structures & Elements; these are made up by numbers and characters.

3.1 Data Store List

3.1.1

3.1.2

3.1.3

3.1.4

3.1.5

3.1.6

3.1.7


3.2 Data Sample

3.2.1 Pupils Surname Firstname Address Pupil No Tel No Driving

Licence Barwick Marie 2, Park

Lane, Redcar, Cleveland,TS10 1RA

HHDS 001 01345 765345

BARW 123

3.2.2 Instructors

Surname Firstname Address Tel No Speed Ticket

Parking Fine

Licence Car No

Rule Matthew 72, Fernie Road, Guisborough, Cleveland, TS14 7LY

01287 898956

1 1 Rule 239 10

3.2.3 Bookings Surname Firstname Next Lesson Instructor Car No Barwick Marie 20/05/2005 Rule 10 3.2.4 Car Schedule

Car No

Instructor Next Booking

Lesson / Test

Pupil No Insurance Due

MOT Due Service Due

10 Rule 20/05/2005 Lesson HHDS 001 30/08/2005 29/12/2005 05/01/2006

3.2.5 Test Results Test Date Result Surname Firstname Pupil

No Instructor Car No

27/07/2005 Pass Barwick Marie HHDS 001

Rule 10

3.2.6 Payments

Instructor Lesson Surname Firstname Pupil No

Pay Method

Rule 20/05/2005 Barwick Marie HHDS 001

£15.00 Cash

3.2.7 DVLA Store

Car Make

Model Colour Registration Speed Tickets

Park Fines Tax Due

BMW Mini One

Blue 51YR 856 3 1 29/12/2005


3.3 Data Store Descriptions

3.3.1 Pupils

Name:

Content: Pupils = {Pupil}

Description: **This stores and registers the pupil details Inputs: 1.1 Pupil Details Outputs: 1.2 Pupil Details Read: Live / daily / weekly / monthly

Write: Live / daily / weekly / monthly

Status: Disk / Paper ledger / Written Report

3.3.2 Instructors

Name:

Content: Instructors = {Instructor}

Description: **This stores all the instructor details Inputs: 1.1 Bookings Outputs: 1.2 Instructor Schedule Read: Live / daily / weekly / monthly



3.3.3 Bookings

Name:

Content: Bookings = {Booking}

Description: **This stores all the bookings on the system Inputs: 1.1 Booking Outputs: 1.2 Instructor Schedule Read: Live / daily / weekly / monthly




3.3.4 Cars Schedule

Name:

Content: Cars Schedule = {Car Schedule}

Description: **This stores all the Car details in the system Inputs: 1.1 Bookings Outputs: 1.2 Schedule Read: Live / daily / weekly / monthly



3.3.5 Test results

Name:

Content: Test results = {Test Results}

Description: **This stores all test results in the system Inputs: 1.1 Results Read: Live / daily / weekly / monthly



3.3.6 Payments

Name:

Content: Payment = {Payments}

Description: **This stores all the payments within the system Inputs: 1.1 Payments Outputs: 1.2 Refunds Read: Live / daily / weekly / monthly




3.3.7 DVLA Store

Name:

Content: DVLA Store = {DVLA Store}

Description: **This stores all the DVLA data within the system Inputs: 1.1 Documents Outputs: 1.2 Reminders Read: Live / daily / weekly / monthly




3.1 Data Flow Descriptions **(Due to the number of these a select few have only been noted)

3.4.1 Register Pupil

Name:

Content: Sname+Fname+Address+PupilNo+TelNo+Licience

Description: **Pupil details being input into the system Source: Process Data Store 1.1 Register Pupil 1 Pupils Destination: Process Data Store 1.2 Input Details 1 Pupils Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.2 Change Instructor

Name:

Content: Sname+Fname+Address+TelNo+Licience+CarNo

Description: **Pupil requesting to change instructor Source: Process Data Store 1.1 Change Instructor 1 Pupils Destination: Process Data Store 1.2 Assign Instructor 1 Instructors Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.3 Book Lesson

Name:

Content: Sname+Fname+Lesson+Instructor+CarNo

Description: **Instructors input bookings Source: Process Data Store 1.1 Book Lesson 1 Bookings Destination: Process Data Store 1.2 Schedule 1 Instructors Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report


3.4.4 Test Request

Name:


Description: **Pupils requesting a test booking Source: Process Data Store 1.1 Book Test 1 Bookings Destination: Process Data Store 1.2 Schedule 1 Instructors Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.5 Book Test

Name:


Description: Instructor booking test Source: Process Data Store 1.1 Book Test 1 Bookings Destination: Process Data Store 1.2 Schedule 1 Instructors Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.6 Test Results

Name:

Content: Tdate+Result+Sname+Fname+PupilNo+Instructor+CarNo

Description: Instructor booking test Source: Process Data Store 1.1 Test Results 1 Test Results Destination: Process Data Store 1.2 Test details 1 Test Results Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report


3.4.7 Payments

Name:

Content: **Instructor+Lesson+Sname+Fname+PupilNo+Pay+Method

Description: Instructor Inputting Payments Source: Process Data Store 1.1 Payments 1 Payments Destination: Process Data Store 1.2 Payments 1 Payments Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.8 Registration

Name:

Content: CarMake+Model+Colour+Reg+Tax

Description: **Register car into system Source: Process Data Store 1.1 Registration 1 DVLA Data Destination: Process Data Store 1.2 Registration 1 DVLA Data Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report

3.4.8 Parking Fines

Name:


Description: **Count No Of Parking Fines by Instructor Source: Process Data Store 1.1 Fines 1 DVLA Data Destination: Process Data Store 1.2 Fines 1 Instructor Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report


3.4.9 Speeding Tickets

Name:


Description: **Count No Of Parking Fines by Instructor Source: Process Data Store 1.1 Fines 1 DVLA Data Destination: Process Data Store 1.2 Fines 1 Instructor Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly Status: Disk / Paper ledger / Written Report


3.5 Data Structures 3.5.1 Pupils

Data Structures: PUPILS Description

NAME nametitle+fname+sname ADDRESS house#+street+town+county+postcode PUPILNO pupilNumber TEL telephone LICENCE licence

3.5.2 Instructors Data Structures: INSTRUCTORS Description

NAME nametitle+fname+sname ADDRESS house#+street+town+county+postcode TEL telephone SPEED TICKETS count FINE count LICENCE licence CAR NO carno

3.5.3 Bookings

Data Structures: BOOKINGS Description

NAME nametitle+fname+sname NEXT LESSON date INSTRUCTOR sname CAR NO carno

3.5.4 Car Schedule Data Structures: CAR SCHEDULE Description

CAR NO carno INSTRUCTOR sname NEXT BOOKING date LESSON/TEST lesson/test PUPILNO pupilnumber INSURACE DUE date MOT DUE date SERVICE DUE date


3.5.5 Test Results Data Structures: TEST RESULTS Description

TEST DATE date RESULT number NAME nametitle+fname+sname PUPILNO pupilnumber INSTRUCTOR sname CAR NO carno

3.5.6 Payment Data Structures: PAYMENTS Description

INSTRUCTOR sname LESSON date NAME nametitle+fname+sname PUPILNO pupilnumber PAY number METHOD cash/check

3.5.7 DVLA Store Data Structures: DATA STORES Description

CAR MAKE make MODEL model COLOUR colour REGISTRATION registration TAX DUE date


3.6 Data Elements 3.5.1 Pupils

Data Elements: Pupils Type Description Nametitle 2{char}4 [Mr|Mrs|Ms|Miss|Dr|Prof] Fname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Sname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] House# 1{char}3 Usually numeric but can be subset [0..9|A..Z|a..z] Street 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Town 1{char}20 Usually from [A..Z|a..z|0..9| ,-] County 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Postcode 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] PupilNo 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Telephone 11{char}11 **Numeric characters each [0..9] Licence 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9]

3.5.2 Instructors Data Elements: Instructors Type Description Nametitle 2{char}4 [Mr|Mrs|Ms|Miss|Dr|Prof] Fname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Sname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] House# 1{char}3 Usually numeric but can be subset [0..9|A..Z|a..z] Street 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Town 1{char}20 Usually from [A..Z|a..z|0..9| ,-] County 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Postcode 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Telephone 11{char}11 **Numeric characters each [0..9] Speedtickets 1{char}2 **Numeric characters each [0..9] Parkingfines 1{char}2 **Numeric characters each [0..9] Licence 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] CarNo 1{char}2 **Numeric characters each [0..9]

3.5.3 Bookings Data Elements: Bookings Type Description Nametitle 2{char}4 [Mr|Mrs|Ms|Miss|Dr|Prof] Fname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Sname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Nextlesson 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Instructor 1{char}20 Usually from [A..Z|a..z|0..9| ,-] CarNo 1{char}2 **Numeric characters each [0..9]


3.5.4 Car Schedule Data Elements: Car Schedule Type Description CarNo 1{char}2 **Numeric characters each [0..9] Instructor 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Nextlesson 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Lesson/Test 1{char}6 Usually from [A..Z|a..z|0..9| ,-] PupilNo 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] InsuranceDue 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Motdue 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9]

3.5.5 Test Results Data Elements: Test Results Type Description Testdate 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Result 1 {char}2 **Numeric characters each [0..9] Nametitle 2{char}4 [Mr|Mrs|Ms|Miss|Dr|Prof] Fname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Sname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] PupilNo 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Instructor 1{char}20 Usually from [A..Z|a..z|0..9| ,-] CarNo 1{char}2 **Numeric characters each [0..9]

3.5.6 Payments Data Elements: Payments Type Description Instructor 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Nextlesson 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Fname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Sname 1{char}20 Usually from [A..Z|a..z|0..9| ,-] PupilNo 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Pay 1 {char}6 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Method 1 {char}6 Usually from [A..Z|a..z|0..9| ,-]

3.5.7 DVLA Store Data Elements: DVLA Store Type Description CarMake 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Model 1{char}20 Usually from [A..Z|a..z|0..9| ,-] Colour 1{char}10 Usually from [A..Z|a..z|0..9| ,-] Registration 7{char}7 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Speedtickets 1{char}2 **Numeric characters each [0..9] Parkingfines 1{char}2 **Numeric characters each [0..9] Taxdue 10{char}10 Format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9]


3.7 Process Descriptors 3.6.1 Register Pupil

DATA DICTIONARY: PROCESS DESCRIPTORS

Name:

Description: Registers pupils to the system

Data Inputs: Dataflow register pupil details into system. 1 Pupils

Data Outputs: Dataflow complete pupil then assigned instructor . 2 Instructors

Mini-Spec: REPEAT INPUT next Register Pupil IF Pupil Details = 0 THEN Register Pupils AND Assign Instructor ELSE IF Pupil Details = 1 THEN Change Instructor END IF UNTIL no more Register Pupil


4 Critical Review

4.1 Critical Review of Report

The report fully utilises the requirements and features of the SCM Report Guidelines. There is

always room for improvement. The overall layout of the report has been set out well and reference

via the index is clearly labelled. The report demonstrates the Context Diagram, Fragments to make up

the Top Level Diagram and a detailed overview of the Low Level Diagram. The report includes a brief

overview of the Pupil’s Data Dictionary to include elements and Structures and also a detailed

overview of the Register Pupil process structure. The report has tried to obtain every thing that was

required in reference to the case study.

4.2 Critical Review of Analysis

The DFD model has been composed to show either one or the other in reference to the Top

Level and Low Level Diagrams as inputting both would have been too much information. In order to

reduce this, the Top Level Diagram has been incorporated into the Fragments section. This took

much time to decide on and the model had been amended on a number of occasions in order to

complete.

4.3 Critical Review of Design

The overall design of the model would work but given more time could have been extend to

complete fully the requirements in the case study. Use of Yourdons notation has been used to

completed the DFD’s in Ascent, however the System’s Analysis & Design Module was only thirteen

weeks long, in order for better knowledge and understanding continuous learning of the subject may

help.

DO NOT COPY Do Not Plagiarise or Cheat - Tees samples...Marie Barwick – HNC Year 1 – SA&D Page 6...

Documents

Transcript of DO NOT COPY Do Not Plagiarise or Cheat - Tees samples...Marie Barwick – HNC Year 1 – SA&D Page 6...