Wikibooks Comp4 Analysis Essay

This section should be where you are going to plan out your entire system before you build it. It doesn't always work out this way and you might find yourself coming back and changing things as you actually code your project. It is not recommended to write the design before you have done some coding. From your Analysis you should have an idea of what you are going to produce and have sourced some text books to get you started. Complete a couple of simple example programs before writing your Design, this way you'll have a better idea of the capabilities of the language you are using. And remember, don't be afraid to come back and change things!

Sections to Include[edit]

To get full marks you should aim to write something about all of the following. Some projects won't require all sections, for example you might not have a database and therefore have no need to include SQL. It's always best to check with your teacher about what you need to include.

Overall System Design[edit]

To give a clear idea of how we are going to complete our project it's a good idea to use an IPSO chart. IPSO stands for Input, Process, Storage, Output. Every project should have information under these headings. An example is below:

  • Input - these might include various types of human interaction and loading data from external sources such as databases, web feeds, scientific instruments etc.
  • Process - this is the important bit. What are you going to process, what is it going to calculate?
  • Storage - this will record all the ways that you are going to store data, it might include database table names, structure names and external files such as xml and csv.
  • Output - What will the end user be given, what will be output to the screen?

Let's take a look at an example:

User Details
New purchase
Monthly sales
Highest performing Salesperson
Highest paying customer
Database tables:
Stock Item
Monthly sales chart

Modular Design[edit]

When you design your system you need to split it into smaller components. Like this book having different chapters about different things, your project should have different parts (modules) that do different things, but when they are combined they make up a complete whole.

There are two ways to split your project into modules, one is code based and the other is form based. Ideally, your project should be using both methods.

Form/Navigation Based[edit]

If your program has lots of different functions and uses a website or an application you probably have different pages to perform different tasks. You are also able to navigate from one page to another starting at your main menu. You need to show the different forms/pages that you use and how you would get from one to another:

  • Main Menu
    • Adjust Products
      • Add Products
      • Remove Products
      • Update Products
    • Sell Item
    • Adjust Staff
      • Add Staff
      • Remove Staff
      • Update Staff
    • Reports

Even better than this you could draw a nice diagram on how everything links together.

Code Based[edit]

If you are writing a very complicated coding project then you might be using modules of code, some modules that build off other modules. You might also be using Classes and you need to show the class inheritance diagrams

Definition of data requirements (Design Data Dictionary)[edit]

Incredibly similar to your Analysis. If you haven't made any changes since then and it is normalised, just copy the data into here. You'll have to do a little more work in a second on the validation areas. Write down how the values are to be stored while the program is running and what data needs to be stored long-term, is the data to be stored in database tables or files?

Definition of record structure[edit]

If you are saving anything to text files or XML files mention here how those files are organised.

If you are using records or structures in your code mention them here and how they work.

Validation required[edit]

If you are getting the user to input data you will definitely need to validate the data that they insert. For example if you are getting them to fill in a new customer record you will have fields such as Title, First Name, Date of Birth, Number of toes. You want them to input data such as:

Mr. Peter 16/07/93 9

And what will happen if they type in the following:

Mrr. PeanutButter jellytime -8

Well it'll probably break your system, we need to prevent them from entering garbage into our system. If we allow rubbish data our calculations won't work, our reports will be wrong and the data will be useless. Remember this rule:

Garbage In, Garbage Out

To prevent garbage being input we are going to validate, that means check, each item of data that a person inputs into the system. We can do this in many ways

Validation CheckDescriptionSuitable Applicable FieldValid dataErroneous Data
DatatypeChecks that only a certain data type is inserted into a field. Such as a date or an integerdate of birth18/02/9713/13/13 or "clot"
LengthChecks that the data entered has the correct number of characters. For example a British phone number is always 11 characters, or the ID of a shopping item might always be 5 charactersPostcodeE4 7HJEEE668 JUY
RangeChecks that the data is within a set range, being greater than, less than, between, etc. For example the age of someone will be greater than 0, the number of days in a month would be greater or equal to 28 and less than 31.Number of kidneys245
PresenceThis is when you need to make inputting data compulsory, the user isn't allowed to miss a field out. For example, they must state whether they agree or disagree with a legal statement, they must enter a postcodePhone number07070707070(blank)
Lookup/ListThis is when you only allow set values into a field. For example a Title would only allow for "Mr.", "Ms.", "Miss.", "Mrs.", "Dr.". Anything else would be erroneous. You can implement this normally by using a drop down listGenderFemaleTeaPot

Most of these validation checks are built into database packages, so if you create a database and then use a development suite to create the forms, the validation will be built into the forms automatically. If you don't have this privilege, you'll have to hard code it. That of course will come in the Technical Solution stage. Let's take a look at our original garbage data, did we manage to use validation to stop all the nonsense getting into our database?

Field NameValidation ChecksDescriptionError messageDataCaught
TitleLookup ("Mr.", "Ms.", "Miss.", "Mrs.", "Dr.")only allow correct formatted titlesPlease insert a valid TitleMrr.Yes
First NamePresencemake sure name is a sensible length and presentPlease insert a namePeter8No, we can't catch people being purposely malicious, you could try and code some checks but beware of the 'Scunthorpe problem'!
Date of BirthDatatype(Date)Make sure they have input a correct DoBPlease insert a valid datejellyYes
Number of toes14 > Length >= 0Make sure they have a sensible number of toesPlease insert a number between 0 and 13-8Yes

For your report you need to write a table like the one above, though you can omit the last two columns.

Validation notation: Regex

When you are trying to enforce a format to data being input, you might want to use validation notation. For example if you want to specify that a class name must be a two digit number followed by three letters, for example 12PKP, You could write:


Or even more simply:


The regex expression equivalent could be:




File organisation and processing (if appropriate)[edit]

Database design including normalised relations (if appropriate)[edit]

If you are making a database then you need to include an E-R Diagram. You should show the diagram and explain what each of the relationships mean. For example:

  • A student can have many bookings
  • Each booking only has one student
  • Each booking only has one book
  • A book can be involved in many bookings

Sample of planned SQL queries (if appropriate)[edit]

If you are making a database you need to write about the SQL that you use to SELECT, INSERT, UPDATE and DELETE things from your tables. In some cases you might also be writing the code behind making the individual tables, the data definition language. In fact those headings are exactly what you need to use.

Reserved words

When you are querying your database you might get some unexpected errors, where a query fails to run when it doesn't appear to have any problem with it. This may be due to using a resevered word in your query. SQL has a lot of reserved words, words that have special meanings, and if you use one of these in a query it won't treat it as a field name. For example:


This might bring up an error as is a reserved word in SQL. To get by this problem you might want to change your fieldnames to something a little more sensible or put the fieldname in square brackets:


There are many other reserved words out there, so be careful:


Different databases have different sets of reserved words, you can find a good list here

Note: If you are not using a SQL server (for example, using MySQL with PHP) you may need to use `backticks` instead of square bracket notation.


This section should list all the SQL you have written that returns selections of records. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement selects the details (ID, Name, Price, Description) of a product which has been selected by the user. So that the user can view the product detail on the preview screen before buying the product




This section should list all the SQL you have written that inserts new records into your database. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement adds a new high score along with the date the score was achieved for a users account.




This section should list all the SQL you have written that updates an old record with new details. You should describe in plain English where the SQL is used and what it does and then include the SQL with any annotations that you need. For example:

English Description:
This SQL statement updates the date of birth of a user, after they have updated the form that launches when they first log into the program.



Data Definition Language[edit]

If you have designed your database tables using a program such as Open ModelSphere you can then define the code behind making your tables which you can then feed into MySQL or MSSQL to create your database. Get some credit for this and list your DDL. For example, the command to create a table named employees with a few sample columns would be:


Identification of storage media[edit]

This is quite easy if you remember the hardware section of Unit 2. You must recommend how your system will be distributed to and then run by the user.

You need to start off by calculating how much space the program will take up to distribute and how much space it will take up when it is running.

Distributing your software will require that you transmit the data to the user somehow. This could be through a CD-ROM, USB drive, DVD-ROM or internet connection. Why would you pick each? Which would be most suitable? Think about security, speed, having a backup, size of files to transmit.

Running the system will in most cases require the user to be able to write new files to your system, saving high scores, new purchases etc. How big will the system feasibly get? You need to recommend something that will allow the user to read and write to, something that is secure and reliable, and something that will be big enough and fast enough to handle everything. A CD-ROM would not be suitable here, why? Hard Disks could be suitable, why?

Identification of suitable algorithms for data transformation, pseudocode of these algorithms[edit]

You will be asked to provide examples of designing your code. If you have lots of code then pick the 6-8 most interesting examples. For each bit of code try to include the following:

  • Title
  • Plain English explanation
  • Pseudo code

For example with a log in screen you could write the following:

Plain English[edit]

This code takes the username and password input by the user and then checks them against the login details stored in the login file.

Pseudo Code[edit]

var userName = Textbox.username var password = Textbox.password

load the acceptable login names and passwords from the text file and store it into var acceptableLogins

If userName and password are in acceptableLogins Then

Login Allowed
Show Menu screen


Show error message

End If

Class definitions(diagrams) and detail of object behaviours and methods (if appropriate)[edit]

If you have used Object Orientation in writing your program (highly recommended to get in the top mark band) you need to describe it here. You must mention the following:

  • Class names
  • Any inheritance
  • Attributes (variables) and whether they are public or private, explaining what they are for
  • Function names with return values and description
  • Procedures names with return values and description
  • Any overriding performed

User interface design (HCI) rationale[edit]

In all projects you will have some form of user interface, in nearly all cases this will be a GUI. This section actions you to show and explain the methods that you are going to capture data (inputs), and the ways you are going to display/print out data(outputs). Notice in each case it says sample, so you don't have to show how every form/printout will look, 4 examples of each should suffice. You could hand draw each, or draw them using an arts package like inkscape, alternatively you could design them in a package like Visual Studio and use the design views of the form. DO NOT use screen shots of the final code running, we need to see your designs.

UI sample of planned data capture and entry designs[edit]

This section needs to show the designs of your forms / interfaces. Don't be afraid to include early screen shots of forms in design view. Remember we are not marking this section on working code, but on the design ideas behind each form / interface. You must mention your reasoning:

  • Tick Boxes / radio buttons
  • Drop down lists
  • positioning of elements
  • colour schemes
  • ease of navigation

You can do this by annotating each screen shot.

UI sample of planned valid output designs[edit]

This might be one or more of several things:

  • the designs of reports that your system is planned to produce
  • the high score board of a game or quiz
  • the game screen showing points health etc.
  • a graph showing data
  • anything that is calculated and shown to the user

Using the same rationale as the previous section you must complete annotated versions of these.

Description of measures planned for security and integrity of data[edit]

Security and integrity are slightly different things.

Security means preventing unauthorised people accessing areas of your work. This might include students accessing each others marks for a test, customers accessing other customers' details, students accessing the marks to a test or anything that conflicts with the data protection act. To do this you need to implement security systems such as usernames and passwords, access rights and restricted areas. You might have certain buttons and areas that only appear for certain users. If they are restricted users there will be parts of your system that they won't see, and for the admin user, they should be able to see everything.

Integrity is making sure that your data doesn't 'corrupt'. This means making sure that certain bits of data always take on the correct format or don't violate certain rules. For example, if you had a date of birth, you wouldn't want people to be inserting their name in that field. How do you do this? With validation rules. Write about them here. You might also want to make sure that your database maintains its referential integrity. This will prevent people linking to records in other tables that don't exist. Talk about how you would do this.

Description of measures planned for system security[edit]

You don't want unauthorised people gaining access to your data. This might include stalkers trying to find out personal details stored on your system, students trying to cheat etc. You might recommend that the end user keeps data in secure locations or behind operating system passwords. Or that there is a main password to get into your system.

You should also mention how the system will be recovered in the circumstance that it becomes corrupted or lost. Mention the method by which you will recover the system/reinstall etc.

Overall test strategy[edit]

There are several different ways that you could test your system. This section asks you to consider each and mention how you are going to test your system with regard to each. Don't just describe each, you must talk about how you will use them to test your system.

Black-box testing[edit]

In this mode you don't care about the code behind what you are testing, you just know what results should come about from particular data inputs. This is useful for complex sub routines that have multiple possible inputs. For example testing a search algorithm. If you do come across any problems then you will have to find and fix them. For that we use...

White-box testing[edit]

In this you are going to test as many routes 'through' your code as you can. This means looking at your code and trying to come up with tests that will test every logical statement that you have written. For example if you have an if statement that checks if a password is correct or not, put a test in place to see if it works when the correct password is inserted AND when an incorrect password is inserted. Things you should include:

  • If statements
  • While loops

Trace tables[edit]

This is a great way to find and fix problems. You should try to pick two or three of your most complex pieces of code to perform a trace table upon. By using this you prove that the code works.

this is a simple diagram, you would have to explain each of the attributes and subroutines
Black box testing diagram
White box testing diagram, where each coloured line is a route through the code

A-level Computing is an A-level course run for students in the UK

Note: current version of this book can be found at


  • (AQA) Peter EJ Kemp (editor) - London
  • (CIE) Peter Astbury - Alexandria, Egypt

Contributors and proof readers

  • Students from Christ the King Sixth Form College
  • Students from Loxford School
  • Students from Wreake Valley Academy
  • Peter L Higginson - Reading

Thanks for helping out!

Book Overview

This is a book about A-Level Computer Science. It aims to fit with the AQA GCE A-Level Computer Science 2015 syllabus but is not endorsed by AQA. It should be useful as a revision guide or to find alternative explanations to the ones in your textbook. If you haven't heard of an A-Level then this book probably won't be of much interest to you but you can find out about them at Wikipedia.

If any part of this book is unclear or even wrong then please post a comment on the discussion page or simply fix it yourself! In particular, please say if the book assumes any knowledge or skills which not all A-Level Computer Science students have.


Paper 1

Paper 2

Non-exam assessment


Accepted languages

A-Level Projects can be written in any language.

Old Specification (up to 2017)

AS modules

A2 modules

How to read the book

You will meet several coloured boxes, here are their meanings:

Specification link

What the specification says you must learn for each chapter


Example questions and how to solve them


Questions to test yourself, click below


to check if you were right


Topics that aren't examined but you might be interested in

There will be a lot of concepts that you need to be familiar with, definitions are highlighted like so:

Unit 1 - Summary

This exam is worth 60% of your AS grade (30% of the full A-Level). It is examined in June only.


Unit 1 definition list

The examination

Problem solving

A-level Computing/AQA/Problem Solving, Programming, Data Representation and Practical Exercise/Problem/Solving

Introduction to principles of computation

Computing is a very different course from ICT and if you have studied ICT at secondary school you should see a big difference between the two. This course will introduce you to the theory, mathematics and logic that sit behind the computing revolution. Over the course of this book I also hope to take you through the steps needed to practice computational thinking, the art of using computers to solve problems. This doesn't mean getting you to think like a computer, but it does mean getting you to think in ways that you can use computers to solve problems. Computational thinking is made up of four parts:[1]

  • Decomposition
  • Pattern recognition
  • Pattern generalisation and abstraction
  • Algorithm design

Let's take a look at what each of these mean:


Part of being a computer scientist is breaking down a big problem into the smaller problems that make it up. If you can break down a big problem into smaller problems then you can give them to a computer to solve. For example if I gave you a cake and asked you to bake me another one you might struggle, but if you watched me making the cake and worked out the ingredients then you'd stand a much better chance of replicating it. If you can look at a problem and work out the main steps of that problem then you'll stand a much better chance of solving it.

Let's look at an example, the equation to work out the roots of a quadratic equation.

On first look it might appear a little scary, but if we decompose it we should stand a better chance of solving it:

One thought on “Wikibooks Comp4 Analysis Essay

Leave a Reply

Your email address will not be published. Required fields are marked *