How to write your AQA A Level Computer Science Project Part 3 – What needs to go in your write-up!
Welcome to part 3 in a series about your AQA Computer Science A Level project. In the first two parts of this article, we’ve looked at how to get started, how to pick a project and how to go about scoring decent marks.
In this final part of the series we look at all the things that you will need to put into your write-up to help you get a good mark.
You will not be handing in your working program, simply because too many people will be doing too many different things. The only thing you have to prove your program works is your write up, so getting this right is really important.
Fortunately, AQA have a good, clear requirement specification, and they want to see your write up broken down into several sections.
Section 1 - Analysis
Official AQA guidance states that the Analysis should:
•• produce a clear statement that describes the problem area and specific problem that is being solved/investigated
•• outline how they researched the problem
•• state for whom the problem is being solved/investigated
•• provide background in sufficient detail for a third party to understand the problem being solved/ investigated
•• produce a numbered list of measurable, "appropriate" specific objectives, covering all required functionality of the solution or areas of investigation (Appropriate means that the specific objectives are single purpose and at a level of detail that is without ambiguity)
•• report any modelling of the problem that will inform the Design stage, for example a graph/network model of Facebook connections or an E-R model.
In order to achieve this your analysis should contain the following sections:
Part 1 Introduction – Problem Statement
1.1 Description of the Problem area
This means what is the field where your program is eventually going to be working? Is it in maths, geography, hotel booking, lesson scheduling, networking? What is the subject area where you program is going to be used.
1.2 Problem Definition
This means what is your program trying to do? What problem exists that needs your program to solve it.
Part 2 Research into the Problem
2.2 Description of Existing Systems
Here I would fully document two existing systems that do roughly what your program does. Document them from a computing point of view, get as may screenshots as you can and try and determine any inputs, outputs, variables, any processing that can be done from a good, educated guess at the screenshot.
For example, if a screenshot is drawing a graph, this is the output, but what was the input? Can you identify the datatypes of the input
Don’t forget to include the name of the program as well as the URL of the program, so your examiner knows it’s real.
2.3 Identification of Prospective users
Who is going to end up using the program? Are they old, young, computer literate or not? This will determine how your user interface is going to look – if you have someone who has never used a computer, your interface will need to guide them through your program step by step.
3. Client interviews.
The important bit, here is where you record all of your interviews, either as emails or as a transcript.
Part 4 Objectives of the new System
4.1 Specific Objectives
Here is where you put your numbered, specific objectives of your system. I would use some form of grid like this:
Where you give each objective an ID, and make sure they are specific (i.e. one thing only) and you have assessed whether you can measure success (does it work or not), is it achievable (can you do it) and is it relevant (is it what the user has actually asked for)
These objectives, as we have seen, are critical for completeness and for scoring high marks, so consult with your teacher when you get a list of objectives as soon as possible. If it looks like you can’t achieve some, then delete them from this list as your examiner will use this to determine your testing, your evaluation and how complete your project is.
4.2 Identification of Key Requirements
In other words, what does your program absolutely need to do, which will form the basis of your objectives
.
4.2 Identification of User Limitations
What can the user do without, in the time available? Users will want lots of things, which you will simply not have time to do, so here is where you list the ‘nice to have’s’ and this will come out in your interviews.
Part 5 - Data Models
These are where you need to model what your system is going to look like. AQA recommends you include enough models to describe the system fully, and include OOAD models, ERD models, and Data Flow Diagram models (DFD) to Level 1. I can show you how to draw these and put them into your analysis so you can score high marks on your analysis document, so why not get in touch and see how I can help you.
