GCSE Project Guide

Database projects in MS Access

Introduction.....................................................................................................................................2
Project mark structure.................................................................................................................2
Section A – Analysis (15 Marks)....................................................................................................3
Aim..............................................................................................................................................3
Background.................................................................................................................................6
Investigation................................................................................................................................6
New System Objectives (Performance Criteria).........................................................................7
Problems, sub-problems and links between them......................................................................7
Section B – Design (20 Marks).......................................................................................................8
Aim..............................................................................................................................................8
Choice of Possible Software.......................................................................................................8
Database Design........................................................................................................................9
Figure B – Table Design.............................................................................................................9
Input Designs..............................................................................................................................9
Figure C – Query Design..........................................................................................................11
Output Design...........................................................................................................................13
Figure D – Test Plan.................................................................................................................14
Section C – Implementation (35 marks).......................................................................................16
Aim............................................................................................................................................16
Implementation documentation.................................................................................................17
Section D – Testing (15 Marks)....................................................................................................19
Testing......................................................................................................................................19
Section E – The User Guide (10 Marks)......................................................................................20
Aim............................................................................................................................................20
Section F – Evaluation (5 Marks).................................................................................................21
Aim............................................................................................................................................21
Evaluation.................................................................................................................................22
Final Presentation.........................................................................................................................22

1
Introduction
You need to produce a report on a problem that you have designed and developed a solution
for. To get the best possible marks for your project you need to:

 Identify and research a realistic problem for which there must be a real end-user – don’t
just make something up!

 Identify a situation where a small number of different problems need solving – don’t just
concentrate on producing a solution to a single problem

 Try and produce solutions to problems that can be used by real people after you have
finished them

 Involve the appropriate use of a range of features and functions of MS Access

(database)

In the project you take on the role of systems analyst – this is someone who looks at existing
systems, investigates and identifies problem areas and suggests solutions.

Project mark structure

The project is worth 30% of your final GCSE marks and is broken down as follows:
Section

Section Marks
Analysis 15
Design 20
Implementation 35
Testing 15
Evaluation 5
User Guide 10
Total Marks 100

2
Section A – Analysis (15 Marks)
Aim
The aim of this section of your project is to investigate the user’s requirements and draw up a
set of objectives. You will investigate an existing system (preferably paper-based) within an
organisation and determine how it could be improved by the introduction of a database system.
This involves some fact finding and analysis of existing systems to determine what user
requirements (objectives) could be addressed by the introduction of a new system.

Preparation

You need to find a real client (end-user) for your project as soon as possible. After finding an
organisation on which to base your coursework you need to get in touch with them to discuss
possible projects in more detail. The following approach is recommended:

1. An informal discussion/fact finding to establish the problem to be solved. You should

then complete the questions below and discuss it with your teacher before agreeing to
tackle the problem.

 Remember that the project has to have enough scope to gain you good marks and that you
have a limited amount of time in which to complete it. Under no circumstances take on a
project that is too big or too small without consulting your teacher.

2. A formal investigation. This should take the form of an interview and/or questionnaire.
Try to get hold of any original documents (order forms, invoices, receipts etc.) used in the
current system for inclusion in your appendices.

 If a partially computer based system is already in place try to get screen dumps (or
photographs if this isn’t possible) of the current system. These will help you to identify
necessary inputs, stored data, processing and outputs.

You must complete the following questions:

1. What is the name of the end user?
________________________________________________________________________

2. Describe what type of business/organisation they work for:

____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

3
3. What data does the business/organisation collect and record (e.g. customer’s names,
addresses, product details, quantities of products sold etc)?
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

4. Describe how some of the data is collected (e.g. manually – written by hand or automatically
by an input device such as a scanner or OMR)
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

5. How do they record and store the data? (e.g. in account/log books; on paper/card; in filing
cabinets; on computerised database files etc) Get a copy of any data stores.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

6. What information does the business/organisation produce from this data (e.g. lists of
customer orders, invoices, receipts, membership cards, reports)
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

7. Find some of the documents/reports that you have stated above. Name and describe them below.
Photocopy these if you are allowed to.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

4
8. Find out if there are any problems with how things are done currently (e.g. do records get lost, is it
hard to search for information or is it sometimes hard to read hand written documents). Briefly
explain these problems below.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

Comment:

Teacher’s signature _____________

Possible Objectives

1 Database

2 Input

3 Output

4 Output

5
Background
Describe the organisation in very general terms and give some brief background information
about it i.e. nature of its business; is it a large/small organisation; number of transactions per
day etc.

Investigation
The current system

This should be a very detailed description of the main points of your investigation/research
regarding the current system. Describe how the existing/current system works. Refer to the
questionnaire/interview transcript or summary and any original annotated documents.

Your detailed analysis must explicitly identify inputs, outputs and processing for the current
system:

 List all the data input (and data capture methods)

 Describe the information output (including format and content)
 Describe what data processing is carried out

Problems with the current system

What problems exist with the current system? You need to try and be specific here. E.g.
Orders take too long to process leading to customer dissatisfaction, It is difficult to find out if an
item is in stock, Invoices have to be calculated manually leading to the possibility of mistakes
being made. List and describe the problem and sub-problems identified in detail.

Possible Solutions

List the problems that you plan to try and solve. For each of these problems you should:

 Manual - Describe a way of solving each problem without using a computer.

Describe some advantages and disadvantages of this type of solution
 Computerised - Describe some different ways that a computer could be used to
solve each problem. Describe some advantages and disadvantages of using a computer
for this problem.

Chosen Solution

Explain why you will be using a computer to set up a new system for the user. It should include
your reasons for:

 Using a computer to solve the problems

 Explain how a computerised system will enable your system to be reusable

6
New System Objectives (Performance Criteria)
Objectives/User requirements

List the objectives/user requirements of the new system. This might include, for example,
storing details about customers, products and orders or calculating the value of invoices.

Performance Criteria

For each objective you have stated, prepare a numbered list of performance criteria. You
should have at least four performance criteria per objective against which the system can be
judged. These criteria should focus on the user requirements in more specific detail.
Remember, these are your instructions from the user to ensure you develop a solution that
successfully meets all the needs of the user.

This part of your paperwork is VERY important, as you will need to refer back to it in your
design, testing and evaluation. Performance criteria should be numbered so that you can refer
back to them e.g. “Performance Criteria 3 was met by…” Unless you can link these sections of
your coursework to specific objectives you may score badly.

NB you can always go back and add more to your list of performance criteria whilst creating the
new system.

Reusability of the new system

State at least three ways in which the information will change over time.

Problems, sub-problems and links between them

You will need to draw a diagram to identify how your objectives link together.
For example, if you were to create a system for ordering takeaway food then the diagram may
look something like this:

Input Input

A system to store data

about….. Process
Process

Output Output
7
Section B – Design (20 Marks)
Aim
In this section of your project you are trying to take the user’s requirements and produce
solutions on paper. You need to produce a detailed design for each problem/objective.

A relatively competent 3rd person should be able to implement your ideas from your designs
alone. This part of your project will involve you:

 Comparing alternative software choices

 Identifying the hardware requirements
 Relational database design
 Identifying the required outputs
 Identifying input data
 Specifying the processing that needs to be carried out (i.e. how to get the outputs you
want)
 Devising a test plan

Preparation

Obviously, before documenting this section of your report you’ll need to do a lot of thinking,
planning and drafting.

While you’re working through the tasks in the design section of this document discuss your
ideas/designs with your teacher – he/she has probably seen similar projects in the past and will
be able to advise you about how you can improve your designs. THIS IS VERY IMPORTANT!
Good ideas can fail because of poor design!

Choice of Possible Software

Comparison of alternative software

Your project could probably be implemented using software applications other than a database
application. You need to justify the use of a Relational database by comparing a database
application with a spreadsheet application.

You should discuss the features that these packages offer, which could be used to solve the
problem. Compare and contrast them with reference to the user requirements/performance
criteria in your analysis

Justification for Chosen Software

Based on the above explain why you have chosen a database application (Access). In addition
try to relate your explanation to the key advantages of a relational database: the reduction of
redundancy, inconsistency and repeating data. You must justify the chosen package with
reference to the performance criteria and in terms of its usability and functionality. Describe six
features of the chosen software that make it suitable to meet the requirements of the end user.
8
Database Design
Entity-Relationship Diagram

Try to identify the objects/people/things involved in the system you are proposing and the
relationship between them.

Draw an E-RD diagram to provide evidence that you have produced the best design for you
database. The diagram should be fully annotated to explain the exact nature of the
relationships, e.g. one customer can make many orders (one-to-many relationship).

Write a brief sentence to explain the purpose of each table in your design e.g. Customers_tbl –
this will hold details such as the name and address of existing customers, the user will also be
able to add new customers into this table.

Table Structure

For each table described above complete a table design sheet – Figure B.

Attention to detail here is particularly important. You receive better marks for showing an
appreciation of the importance of data type, field length, format, default values, validation rules
and input masks.

Annotate your design sheets to explain why you have made decisions e.g. why is the product
description field data type memo? Why did you use a lookup field on the customer’s title?

Figure B – Table Design

Use these headings to design your tables:

Table Name Primary Key

Field Name Data Type Length  Validation Description Typical Data

 Input Mask
 Default Value

You must have at least two different data entry restrictions

Input Designs
You should now have some kind of idea about what data you’ll need to input and/or have
stored in order to produce your output. Look at your E-R diagram and suggested outputs.
What data are you going to need to meet your objectives?

In a two-column table list the necessary inputs and stored data.

What data will need to be input for each problem, where will it come from and how will it be
input?

9
Remember that you are designing a system for another user and not yourself. Your user may
be a database novice and could easily get into trouble trying to enter, data into the system or
query data.

Using input forms protects her/him from the reality of the database – they don’t need to know
how that data is stored in different tables or how to perform operations such as searching the
database. The forms you create will act as a “bridge” between a novice user and your system.

Forms need to be sketched by hand. Your form designs should be annotated. The designs do
not need to be works of art but should contain enough detail and information to allow a 3 rd
person to implement the design as you intended. Explain how the form(s) can be reused.

Form design checklist

For each form you must include √

A description of the form’s purpose
Sketches of designs in development
Fully annotated sketches – background or text colours and styles, additional
formatting
Reference to where data comes from of goes to (tables/queries/fields)
Reference to buttons/controls that run macros
A consistent look and style for each form
Discussed reusability

Query Design

Look at the user-requirements/objectives and your output ideas and try to identify any output
requirements that cannot come from stored data alone. Examples: calculations, records that
meet a specific criteria (i.e. queries).

As part of your preparation you should try to identify and draft a list of processing needs e.g.
multiply price by quantity on an order, calculate VAT on an invoice, identify overdue
subscriptions etc.

Try and identify the Access tools (macros, queries) that will be used to address each of the
identified processing requirements. For each query complete a query design sheet – Figure C.

The design sheet should be fully annotated to describe the purpose of the query, criteria used
and fields to be output. Try to explain how the end user can reuse the query. Figure C – Query
Design

Explain how the queries can be used more than once and how they can be used to find
different results. Give examples that refer to the end user’s needs.

You will need to design the two queries that will help you create objectives 3 and 4. If you want
an A grade you will need to design a third query.

10
 Figure C – Query Design
Hand Drawn Query for _______________________________________________

Field

Table

Sort

Show

Criteria

Or

11
Output Design
Look back at your Analysis to help identify what outputs you’ll have to produce. This
part of the design process is particularly important as it will determine exactly what
input data you’re going to need and what processing will have to be carried out on
the data to achieve the desired results.

Draft a numbered list of the reports or other outputs (mailing label, letters etc.) that
you intend your system to produce.

Reports/Other Output

Reports and other outputs need to be sketched by hand for each problem. Your
designs should be annotated. The designs do not need to be works of art but should
contain enough detail and information to allow a 3 rd party to implement the design as
you intended.

Explain how often the reports/other outputs will need to be produced and what
information on the report will change over time.

Output design checklist:

For each output you must include √

A description of the outputs purpose
Sketches of designs in development
Fully annotated sketches – background or text colours and styles,
calculations, additional formatting
Reference to source, where did the information come from?
tables/queries/fields
A consistent look and style for each output
Discussed reusability

Switchboard (optional)

Your system has to be user friendly. How are you going to achieve this? The user
interface should be structured logically so that a novice has no problems “navigating”
it e.g. (s)he should be presented with a main menu from which (s)he can make a
simple choice. Start thinking about how the user will access the
forms/reports/features that you are going to create and try to design a menu system
for them.

Draw a detailed menu of the system from the user’s viewpoint. You must show the
links between menus.

Test Plan

For your testing you’ll need to draw up a testing plan for each problem that show
that you have carefully chosen your test data and tested thoroughly. In order to do
this you’ll need to make sure you understand:

13
 a) What the purpose of the testing is for
b) The difference between normal, extreme and erroneous data:

Normal - data you would normally expect to be input

Extreme- data that could be entered by error, such as values that are too large
Erroneous- data that is ridiculous and should not be entered, such as letters
instead of numbers, negatives and special characters

Your testing plan is very important! A good design will take into account any
possibilities of why the system might fail (the aim of testing is to provoke failure!)
Using the example format in Figure D, draw up a test plan for each problem in your
project.

Look back at your Performance Criteria and input/output/table designs, identifying

what you need to test. Make sure that you test relationships, queries,
calculations, macros, data types, field lengths, validation rules and input
masks.
You will need to have at least 12 tests of these 6 are for validation tests for 3
different fields and 6 tests of the queries.

Checklist for testing plan

For the testing section you must: √

Have a numbered list of what you are going to test
State a reason why you are doing the test
If validation is applied to fields then each field will need to be tested
State what data you are going to use to test your system - including normal,
extreme and erroneous data
List the expected results for each test?
Have an extra column for any comments (needed for testing)
State in your test plan whether your test data used is normal, extreme or
erroneous

Figure D – Test Plan

This is a sample layout for your test plan. You will need to create your own table in
MS Word

This shows the three tests for a validation rule that a price must be between 0 and
100

Test No Test Purpose Test data & Expected Comments

Type Results
To test the validation Enter 50 (normal
1 50 is accepted
rule for Price data)
To test the validation Enter 101 101 is not
2 rule for Price (extreme data) accepted

14
 To test the validation Enter Fifty Fifty is not
3 rule for Price (Erroneous data) accepted

15
Section C – Implementation (35 marks)
Aim
Now you have designed your system you need to implement it to make sure it
actually works! Remember, you can only get marks for implementation based on
the written evidence you supply.

The implementation section of your documentation should be an evidence of how

you built the system using detailed screenshots and annotations.

As you are working with a short deadline you’ll need to be organised to ensure that
you can implement your solution and document it in the time available.

Time Management

 Read software skills books and/or tutorials to help you overcome any problems
you encounter
 Refine your hand drawn designs or annotate printouts
 Draw up test plans
 Plan/draft your documentation
 Plan how you are going to make the best use of your next lesson!!

Preparation

The only evidence you can submit to the Examiner is paper-based and without this
paperwork you cannot be credited for what you have achieved.

1 Buy a binder or folder and keep everything related to your project carefully
stored in it. This should be divided into sections so that you can quickly find what
you are looking for. At this stage you may choose to keep your notes in plastic
wallets, for organisational purposes, but your finished report must not be handed in
inside either a ring binder or wallets.

2 Make sure you have your design documentation in front of you and use it.
You need to ensure that you don’t forget to implement all elements of your design. If
your design needs to be altered for any reason do so, and make a note of why. You
will be credited rather than penalised for showing how your designs have developed.

3 Make sure that you take backup copies of your work after every revision.
Blaming Microsoft, the school network and the family dog won’t bring back your
project if you lose it! It’s a good idea to send a copy of your work to your e-mail
address so you can retrieve it from school or elsewhere.

4 Take screenshots as you implement the solution to show how the design
work develops into the finished product. It’s far easier to document the
implementation as you go along rather than finish the practical work and then have
to reproduce what you did just to get a screen dump. Documenting your project in
this way allows you to show how your design has progressed.

16
Implementation documentation
You must provide printed evidence of the work that you have done to solve each
problem. This should include printouts of the stages you have worked through in
developing the solution to the problem. Printouts and screenshots should be
annotated.

1 Commentary
Should describe how you approached each problem, in what order, what was done,
what decisions were made and why, any problems encountered and how they were
dealt with. You must document any deviations from the design and explain why.

For database solutions, the following should be included:

2 Tables
Having created the database you should show each table in Design View and
Datasheet view. Provide evidence of your work by taking screenshots of the
completed tables. Show development of validation rules and add cropped shots of
that part of the screen. Annotate all of your work explaining what you are doing and
why.
You will need a printout of each one of your completed tables

3 Relationships
Include a screenshot of the established relationships between tables annotated to
explain what it shows.

4 Forms
Show the development of forms in Design View* with annotations describing links
made to fields/tables/queries. Also describe any additional and/or conditional
formatting that has been carried out or properties that have been changed. Where
macros or sub forms have been used you will need to add cropped shots of that part
of the design. Don’t forget to include the menu form designs.

*Include copies of the forms in Form View to show the effect of changed property
settings e.g. maximise, resize, borders, scrolling etc.

5 Queries
Show each query in Design View, annotated to explain the expected result of any
criteria or sorting including copies of results. Where criteria are entered directly by
the user (e.g. parameter query) you will need to add cropped shots of that part of the
screen. Annotate all of your work.

6 Reports
Show the development of reports in Design View with annotations describing links
made to fields/tables/queries. Also describe any formatting carried out.

Do the same for any other non-Access output (mailing labels, form letters etc.) you
have used in your system. Print a fieldname view of the mail merge document e.g.
Word, Publisher, and annotate it.

17
Include copies of the printed reports to show that formatting is correct.( 1 st draft
and final copies)

18
Section D – Testing (15 Marks)
Testing should be an on-going process throughout the implementation of your
project.

Many students fail to fully understand its importance and as a consequence fail to
provide sufficient evidence that they have produced a workable solution to each
problem.

Preparation

Before embarking on your testing of each problem:

1. Make sure that you understand the distinction between normal, extreme and
erroneous test data.

2. Try and identify the operations your database solution is expected to perform–
calculations, opening a form or report with data already in it. How are you going
to test these operations?

3. Does your project include any validation rules/input masks? If so these need to
be tested. Identify wherever validation and/or input masks have been used and
consider what type of data you could use to test the validation.

4. Consider your performance criteria. These should be included in testing, as they

are used to prove whether you have been successful in meeting the user
requirements.

Testing
 Follow the test plan for each problem, which is in the design section, and
make a record of the results obtained.

 Produce printed evidence of test results and make sure any printouts and
screenshots have the test number written on them, along with a comment
explaining what was being tested, whether the test was successful and any
further action that is necessary.

 Compare what actually happened in the test with what was expected to
happen. You will need to show evidence.

 Highlight printouts or print screens to show that the tests have worked.

 Evidence of test results should be clearly annotated to show evidence of

errors, changes made as a result of errors, and successful re-testing.

19
Section E – The User Guide (10 Marks)
Aim
You must produce a user guide that describes how to use the solution to a problem.
You need to provide clear documentation that users of your system can refer to
during their training on the system and use as a reference if they experience
difficulties later (troubleshooting). A good user guide should not just describe how
to use a particular software application.

The User Guide needs to be a self contained part of the project

You can use the following checklist to document your user guide:

In your User Guide you could include: √

A table of contents
Numbered pages
A consistent style
Introduction – what the system is about and who it is for
How to open/shut down the system
Show two different ways of inputting data into two different tables
Show how to do a search
Show how to produce two outputs
Show at least one example of data being changed
Show at least one example of data being deleted
Explain what error messages might occur.
Give one example of help/advice

20
Section F – Evaluation (5 Marks)
Aim
You must evaluate how successful your solution to each problem was by comparing
what you actually produced with the Performance Criteria you identified back in the
Analysis section of your project. Identify limitations to the solution and potential
improvements that could be made.

It’s tempting to sit back, think “I’ve finished!” and produce a three line evaluation
patting yourself on the back for a job well done. Don’t!

No design is perfect.

 You may have had ideas about a feature you would like to have used but at
this stage, didn’t know how to do it.

 Your testing will have identified some limitations and/or other errors – how
many calculated fields did you leave named as “expr1” or formatted as
number when they should have been currency?

Preparation

Evaluation is all about assessing what was successful and how your solution could
be improved:

1. Look at your original user requirements/performance criteria. Make a note of

those you achieved and those that weren’t achieved. You’ll need to look at
your testing to find evidence that you actually fulfilled these criteria. Make
a note of the pages that show the evidence.

2. Try and evaluate why some performance criteria weren’t achieved and make
notes on why not.

Your evaluation must prove two things:

1. You have, as far as possible, satisfied the user requirements and performance
criteria

2. You have taken account of the limitations of your solution

You could use the following outline plan to write up your evaluation:

21
Evaluation
Performance Criteria

Restate your original Performance Criteria as a numbered list. This will provide a
checklist for you to evaluate your project against.

Evaluation

Work through the numbered list systematically and evaluate how well you have met
each criteria – some will have been completely met, others partially met and others
not met at all.

Each of the comments in your evaluation must be supported by evidence – either

the results of your testing or implementation printouts or screenshots.

Improvements

Even if your solution met all the user requirements it is likely that it could still be
improved. Write a few paragraphs outlining how your solution could be improved.
This may include minor enhancements (such as adding or removing controls from a
form) or major upgrades (adding completely new forms/reports).

Final Presentation
Your project report must be presented in a cardboard folder and securely fixed using
treasury tags.

Projects will not be accepted if work is presented in plastic pockets or if work is not
securely attached.

22