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
- A set of questions covering the details of how the current system works and what improvements are required.
- A transcription of the interview. We cannot accept a recording!
- The interview signed by the user
- One other form of fact finding (document collection is normally the best)
- Hardware and software requirements of the proposed solution
- A requirements specification
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 –
- What input will be required and how does the user want the data entered?
- What output the user wants to see? This includes reports, printouts and onscreen information.
- What searches need to be done or what analysis is required?
- What is the workflow? How does data progress from input to output?
- Details on each problem specified in the problem definition.
- Does the system require any security arrangements?
- Is backup needed?
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.
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
- Will need to be able to add new information
- Will need to delete information
- Will need to edit
- ... and so on!
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 –
- Register new customer
- Validate their email address with a confirmation email
- Ensure that this customer has not already signed up with the same email address
- Take a new order and set the correct status depending on current stock levels
- Set to be “new order” if stock exists
- Set to be “waiting stock” if it is waiting stock
- Set to be “order new stock” if stock does not exist and has not been ordered.
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.
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.
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.
Some elements have been discussed but with little or no user involvement.
High mark boundary
- Clear user involvement and detailed fact finding.
- Detailed requirement specification with no omissions
- All requirements are linked back to the fact finding and are fully justified.
- Clear hardware and software requirements.
- The chosen hardware / software method has been compared with another potential solution and justified.
Middle mark boundary
- User has been involved but fact finding may have omissions.
- Requirements specification has been produced but will have omissions and lack detail.
- Some justification has been made on why requirements have been chosen.
- Hardware / software requirements may be missing or lack detail.
Low mark boundary
- An interview has been made and transcribed but lacks detail and only gathers superficial information.
- Little or no attempt to justify requirements.
- No hardware / software requirements
- A basic / minimal requirements specification has been produced.
- It does not hurt to have two interviews!!
- If you do not understand something the user has said... FIND OUT!!!
- Get used to matching your requirements back to your interview. If you have a requirement which cannot be matched back then simply have another interview!
- Use state and Use Case UML diagrams where possible. It cuts down the amount of words you need to write and will help you understand the system.
- Mistakes made in this phase will cause major problems later. Do not move onto design till you and your teacher are 100% happy.