Analysis Guidelines

The Problem

You need to clearly state the problem you are looking to solve. Defining the problem at the start is key to a good project. If you are not sure what you are trying to solve, then issues will be encountered later. For instance, it will be very difficult to create objectives that are specific and measurable if you are not clear about the problem.

You will need to create a clear statement of the problem, the challenges that may be faced and a broad idea of what the system will do. You will need to think about whether the problem will be too big or too small. Will it offer enough scope to meet the marking criteria for the project? In particular, will the problem allow enough technical skills to be used to be of an A Level standard and access the Group A technical skills?

A smaller well completed project will often score as well as a larger project that may have encountered problems along the way, leaving it not fully functional.

Third Parties

You will need to identify one or more third parties to be involved with the analysis of your problem. It is likely that this will be an end-user of the system.

Some projects may have a named end-user who has been part of the project decision process, but some projects that are created are more general like the creation of a chess game AI which could use friends, family or people that plays chess regularly as the end-users involved in the Analysis section.

If you are carrying out an investigation you would probably use your supervisor as the third party for the Analysis.

Modelling of the Problem

There are times when you may find the creation of models, diagrams or formulae that are key to the problem a good way of conveying your problem and possible solutions in your project. These models are likely to be the same sort of models that you may be creating for the design section, but you might find that if they directly relate to, or help the understanding of the problem, then they should be included at this point.

Project Objectives

The set of objectives you create define the requirements for the rest off the project. Each objective should have some sort of research to support its inclusion in your project. One way to show the research supports inclusion is to make a note as you do the research. For example when you have a meeting with your end-user you should write the key points into your objectives.

You will need to number each of your objectives and this will enable you to reference this later in your project. It is useful if each objective references the research that is related to its inclusion.

The best way to create your objectives is to to start with the most important ones and then break them down into smaller objectives. Eventually each of those objectives should become a small measurable objective, which is some cases will lend itself quite nicely to a subroutine.

The following is an extract from a set of objectives for a website that allows parents to book parents' evening appointments.

Commentary

Your commentary throughout your report should take both your teacher and the moderator through the journey to reach your final solution. It is not a specific section but runs through the whole project. Commentaries are written explanations of what, when and why you are doing something.

Quality is more important than quantity so be concise and don't write more than you need to.

Commentary for the analysis should show how you have gone from your initial idea, researched it, discussed it with your end-user of supervisor, and reached your final decision for the solution.