Upload
phungduong
View
216
Download
0
Embed Size (px)
Citation preview
Marie Barwick – HNC Year 1 – SA&D Page 1
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
Marie Barwick – HNC Year 1 – SA&D Page 2
Happy Hour Driving School Computer System.
Systems Analysis & Design Mansha Nawaz.
Marie Barwick - HNC/D Year 1.
Marie Barwick – HNC Year 1 – SA&D Page 3
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
Marie Barwick – HNC Year 1 – SA&D Page 4
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.
Marie Barwick – HNC Year 1 – SA&D Page 5
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
Marie Barwick – HNC Year 1 – SA&D Page 6
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.
Marie Barwick – HNC Year 1 – SA&D Page 7
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.
Marie Barwick – HNC Year 1 – SA&D Page 8
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
Marie Barwick – HNC Year 1 – SA&D Page 9
Figure 3.1 Low Level DFD – Maintain Car Schedule
Figure 3.2 Low Level DFD - Input Bookings
Marie Barwick – HNC Year 1 – SA&D Page 10
Figure 3.3 Low Level DFD – Maintain DVLA Data
Figure 3.4 Low Level DEF – Record Payments
Marie Barwick – HNC Year 1 – SA&D Page 11
Figure 3.5 Low Level DFD – Record Fines Figure 3.6 Low Level DFD – Log Tests The above Low level diagrams show the following…
Marie Barwick – HNC Year 1 – SA&D Page 12
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
Marie Barwick – HNC Year 1 – SA&D Page 13
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.
Marie Barwick – HNC Year 1 – SA&D Page 14
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
Marie Barwick – HNC Year 1 – SA&D Page 15
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
Marie Barwick – HNC Year 1 – SA&D Page 16
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
Marie Barwick – HNC Year 1 – SA&D Page 17
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
Marie Barwick – HNC Year 1 – SA&D Page 18
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
Write: Live / daily / weekly / monthly
Status: Disk / Paper ledger / Written Report
Marie Barwick – HNC Year 1 – SA&D Page 19
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
Marie Barwick – HNC Year 1 – SA&D Page 20
3.4.4 Test Request
Name:
Content: Sname+Fname+Lesson+Instructor+CarNo
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:
Content: Sname+Fname+Lesson+Instructor+CarNo
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
Marie Barwick – HNC Year 1 – SA&D Page 21
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:
Content: CarMake+Model+Colour+Reg+Tax
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
Marie Barwick – HNC Year 1 – SA&D Page 22
3.4.9 Speeding Tickets
Name:
Content: CarMake+Model+Colour+Reg+Tax
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
Marie Barwick – HNC Year 1 – SA&D Page 23
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
Marie Barwick – HNC Year 1 – SA&D Page 24
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
Marie Barwick – HNC Year 1 – SA&D Page 25
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]
Marie Barwick – HNC Year 1 – SA&D Page 26
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]
Marie Barwick – HNC Year 1 – SA&D Page 27
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
Marie Barwick – HNC Year 1 – SA&D Page 28
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.