SECTION B – DESIGN

Section B – Design

Really this section should be entitled analysis and design. In an AQA minor project there is no specific mark section allocated for design. However both Specification (13 marks) and Implementation (20 marks) require you to show evidence that you have carefully considered the end-user’s requirements and ways of tackling the problem before embarking on implementation. According to AQA “The ultimate goal of these sections is for the candidate to produce an effective solution to the problem stated”. You can’t do this without considering alternatives and planning thoroughly.

Good design work shows that you have analysed the problem in detail (gaining good marks on the Analysis section) and makes you consider the “advanced” Access features you could use to implement a solution (gaining good marks on the Implementation section). Effectively, your design contributes towards over a third of the marks available.

In this section of your project you are trying to take the end-user’s specification and produce a workable database solution on PAPER. A relatively competent 3rd party should be able to implement your ideas from the paperwork alone. This part of your project will involve you:

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 strategy and plan
Planning a schedule of activities to ensure that the project is finished by the deadline

Preparation

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

While you’re working through the preparation section of this document complete Appendix B. When your preparation is complete see your teacher to arrange an interview to discuss your initial design ideas. THIS IS VERY IMPORTANT! Good ideas can fail because of poor design!

Make sure that your teacher agrees that your design is workable and that it contains sufficient depth to gain you a good mark before tackling the paperwork.

Identifying Outputs

Look back at your specification and research 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 your are going to need and what processing will have to be carried out on the data to achieve the desired results.

In Appendix B Section 2 list the reports or other outputs (mailing labels, form letters etc.) that you intend your system to produce.

Identifying Inputs and Data Stores

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-RD and proposed outputs. What data are you going to need to accomplish your objectives? At some stage in the future you, or the end-user is going to have to input this data.

In Appendix B Sections 3 and 4 list the input/stored data required for each output you have identified. As an example:
Output = Menu
Input data = Meal details (Name, description, price etc.)
Method of input = Menu form

Processing

As this is your first Access project this will probably prove to be your most difficult task - how to get from A (input) to B (output). Look at the user-requirements/objectives and your output ideas and try to identify any outputs and requirements that cannot come from stored data alone. Examples: archiving data; calculations, records that meet a specific criteria etc.

As part of your preparation you only need to identify processing in plain English e.g. archive last weeks orders, multiply price by quantity on an order, calculate VAT on an invoice, identify overdue subscriptions etc.

Complete Appendix B Section 5 with as many processing requirements as you can identify. Where might you need an action query or macro? Don’t bother including routine processes such as add/amend/delete records for every table/form.

Menus and Navigation

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 end-user will access the forms/reports/features that you have created and try to design a “navigation” system for your application. Look at the example on page 186 of Heathcote (2nd Edition) for some ideas and then complete Appendix B section 6.

Test Plan

Testing accounts for a significant proportion of the marks in the Implementation and Testing section of your report

It’s important at the design stage of a project to think about how you are going to test your prototype. For your testing you’ll need to draw up a test plan that shows that you have carefully chosen your test data and tested each module thoroughly. In order to do this you’ll need to make sure you understand:

            a)         What the objectives of testing are
            b)         Types of testing
            c)         What normal, extreme and erroneous test data are

Read Heathcote pages 188-190 and make sure you understand these concepts. Start thinking about which elements of your solution need to be tested, why and how?

Paperwork

You could use the following outline plan to write up your design. This is not prescriptive and you may choose to include more headings:

1. Consideration of a possible solution

Comparison of alternative solutions

Your project could probably be implemented using software applications other than Access (for example a spreadsheet package). One solution might even be to streamline/improve a paper-based system. You need to justify the use of a RDBMS by comparing Access with at least one other package.

Compare two or three packages using the example format provided in Appendix C.

Note: You don’t have to list the user requirements/objectives as they have already been stated in your specification. They are shown here to illustrate how your comparison of packages should relate to your objectives. Each row in the table should be numbered to relate back to one or more of your original numbered objectives.

1.2 Justification for Chosen Solution
Write a short paragraph to explain why you have chosen Access. In addition to your reference to 1.1 try to relate your explanation to the key advantages of a RDBMS: the reduction of redundancy, inconsistency, program/data dependency.

Database Design

2.1 Entity-Relationship Diagram
Explain briefly what an E-RD is and draw a diagram to provide evidence that you have normalised the data in your system (in a minor project you do not have to formally document the process of normalisation). The diagram should be annotated if necessary to explain the exact nature of the relationships (e.g. one salesperson is allocated one company car – one-to-one relationship). Write a brief sentence to explain the purpose of each table in your design e.g. Customers – this will hold details such as the name and address of existing customers. In the case of “link” tables such as Orders explain why the link is necessary.

2.2 Data Descriptions
You will need to describe in detail the attributes of every piece of stored data in your system. For each table described in 2.1 above complete a table design sheet – Appendix D.

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 courtesy title?

Input

3.1 Forms - Background
Explain why the use of forms is important in a database application. Remember that you are designing a system for another user and not yourself. Your end-user may be a database novice and could easily get into trouble trying to enter, amend or delete data at table and query level. Using input forms protects her or 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 a complex system e.g. one important use of forms is the implementation of “form level validation” – the use of tools such as check boxes, radio buttons and combo/list boxes to limit data entry.

Re-read your tutorial notes and the Access help files (about forms) for helpful information about what you could include in this section.

3.2 Input Forms

Input forms need to be designed/sketched by hand (or using a DTP package). Your form designs should be annotated to describe each form element used. The designs do not need to be works of art but should contain enough detail and information to allow a 3rd party to implement the design as you intended.

Try and maintain a consistent look and style for each form.

Your input forms may develop as your project progresses – you may find that an idea doesn’t work or that there is a better solution to the one you originally designed. This is unimportant! You can show, by including the original designs, how your project has progressed.

Output

4.1 Reports/Other Output - Background

Explain why the use of reports is important in a database application.
Re-read your tutorial notes and the Access help files (about reports) for helpful information about what you could include in this section.

Reports/Other Output

Reports and other output (form letters, mailing labels etc.) need to be designed/sketched by hand (or using a DTP package). Your designs should be annotated to describe each element used. The designs do not need to be works of art but should contain enough detail and information to allow a 3rd party to implement the design as you intended.

Try and maintain a consistent look and style for each report/output.

Your reports/output may develop as your project progresses – you may find that an idea doesn’t work or that there is a better solution to the one you originally designed. This is unimportant! You can show, by including the original designs, how your project has progressed.

Menu Design

Menu Design

Draw an organisation chart style diagram to show how the end-user will “navigate” your application. See Heathcote page 186 (2nd edition) for an example.

Security

Some, if not all, of the data in your application is going to be commercially sensitive. Assigning passwords and/or security levels allows you to control who sees what in your application. Explain why security is necessary (refer to the DPA) and explain how you will protect the data in the application.

Test Plan

Testing

Write a few short paragraphs about the nature and purpose of testing to show that you recognise why testing is so important.

Test Plan

Your test plan is very important! A good design will take into account any and all possibilities of why the system might fail. Using the example format below draw up a reasonably exhaustive test plan for your project – this will probably run to 3 or 4 pages!

It cannot be emphasised enough how important this element of your design is. Make sure that every field and control in your application is tested. Look back at your input/output/table designs and identify what you need to test. Make sure that you test relationships, calculations, expressions, macros, data types, field lengths, validation rules and input masks.

Use realistic data! A customer name is “Mrs. Everard” and NOT “xuudruhf”. Make sure you include extreme and erroneous data in your test plan

Test No.	Test Data	Purpose	Expected Result	Comment/ Verified
1	Incorrect password “ABC”	Test password	Password rejected
2	Enter CustomerID “25” on order form	Test referential integrity	Error message
3	Enter new menu item with ID 123, Chicken Jalfrezi	Test “Add menu item” function/ command button	Chicken Jalfrezi added to database

Note that the last column is empty. You’ll only fill this in after actually implementing your solution. Before completing the table re-read Heathcote pages 188-190 to recall the purpose of testing and what constitutes good test data.

Try to be systematic in drawing up your plan. Take one module (function) at a time and think about how you can test each element. Read section D and appendix F for some guidance about producing the test plan.