What is it?

Analysis is the fact finding part of the system. You will already have had an informal meeting with the user in order to write the problem definition. Future meetings will be more formal and much more detailed. You will be expected to do at least 2 different fact finding methods in order to get a good understanding of the system.

What you need to include


Interview questions

Your questions must get the required detail. That means questions such as “what do you want in your new system?” or “what are your current problems?” will not suffice. In fact you already know most of this from the problem definition! What you need to find out is the detail required in order to fully implement the system.
You need to find out the following –


A work flow / use case specifies how data will move through a system. Consider a mail order company. When an order arrives a number of things can happen. It could be that the item is out of stock and stock needs to be ordered. It could be that stock has already been ordered but has not yet arrived. The status of a order will change as it moves through the system from allocated to packing and finally dispatched. At different stages different things must happen.
As you can see this information is critical in order to make a working system! A question such as “What problem do you have with ordering?” would not get this detail! The current business processes MUST be found out and documented. In order to find this out a question such as “How does an xxxx progress through the current system? What states can it be in?” would start to pick up this detail.
It is important to remember that a user will not venture this information unless asked!! This will not be out of malice but because they will not realise you need that information.

Hardware and software requirements

You need to specify exactly what software and hardware the user is going to need in order to implement your system. This includes the minimum PC requirements (CPU speed, memory size and HDD space needed). You should also include any software you use to develop the program in. That will give the moderator an idea of how you went about making the system.
You need to research this section carefully. You must also decide on the programming language you are going to use and what API’s you will need to make the system. Your teacher will be able to point you in the right direction. You ARE NOT allowed office based applications.

Requirement specification

The requirement specification is little more than a big list of what your new system will do. This list MUST be detailed. A lot of students will write requirements such as

This is not detailed and could describe any system! You need to split down these types of requirements. For example we could split the “add new information” requirement into –

You should also refer each requirement back to your fact finding so we can see why each requirement is needed. If you have added a requirement which cannot be found in your fact finding then you will lose marks. It makes it easier for both you and the moderator to be specific about why each requirement has been included.
You can use diagrams to aid your explanations. Describing workflow, for example, is much easier as a state diagram. Although they are not essential they are very helpful.


Mark descriptions

9–11 marks

Excellent user involvement with detailed recording of the user’s requirements. All other items must be present, showing a thorough analysis of the system to be computerised. A detailed requirements specification, including full justification for the approach and hardware and software requirements, has been produced.

6–8 marks

Good user involvement and recording of the data collection methods. Most of the necessary items have been covered. However, one or two items have been omitted. A requirements specification is present with some attempt to justify the approach based on the results of the investigations but with some omissions, eg hardware and software requirements.


Some evidence that an attempt has been made to identify the end-user requirements and some recording of it has been made. Attempts at some of the other items have been made. An attempt has been made to develop a requirement specification but with little attempt to justify this based on the results of the investigation.

1–2 marks

Some elements have been discussed but with little or no user involvement.













High mark boundary

Middle mark boundary

Low mark boundary

Top tips