what do you require in the Analysis

In this section we look at problem identification; producing a list of client requirements and interpreting this list in terms
of input, processing and output. This section is important as you will need to take work into the examination from the analyses that you complete.
What do I need to include in the analysis of a problem?
Statement of problem and background information
This is where you set the scene and give some background information for the reader. This
will include information about the client as well as what you are trying to solve.
As you do not have to create a formal project for the new specification this reduces the
amount of work that you will need to do; however you do need to produce an analysis of a
real system. This work is then taken into the examination where you will use it to answer
questions from the paper.
Analysis is often thought of as being difficult and as a result students do badly on this section. Think of it as a scene
setter, finding out exactly what the client wants from the system. A good place to start is to explain what you are
planning to do – this is the statement of problem – and then produce a background to both the problem and the
organisation. The background explains what you are going to do, giving information about both the client and problems
he is facing with the current system.
You then need to find out as much information about the problem from the client as possible. This could include:
• An interview with the client
This gives you a one-to-one situation with the client and allows you to ask questions about the problem and what the
client wants from the solution. It has to be planned to work effectively but if questions come up in the course of the
interview then they can be quickly dealt with. Recording the interview with a Dictaphone and then analysing it
afterwards is a good way of keeping a record of it.
• Viewing the current system in operation and looking for problems
Looking at people working in an organisation helps to see where the problems occur.
• Viewing documentation from the current system
Looking at the current documentation is a good way of finding out what is going on in the current system. It is also
useful for locating the inputs, processing and outputs that we will need later in the analysis.
• Producing a questionnaire from the client and / or the users
Questionnaires tend to be used when you and the client cannot get together for a formal interview. They are filled in
when the client has time to fill them in. The questions have to be mostly closed questions so they are easy to analyse.
Questionnaires tend to be of use when information is needed from the users of the system.
Having gathered the information which you will need to complete the client’s requirements
you now need to analyse what you have found. The client’s requirements are simply what the
client wants from the solution to the problem. It may be that they want a great deal from the
solution, far more than you can produce; do not be put off by this but simply break the
problems down and choose the bits you can do. If they do not want a lot from the solution then
this would have been a problem in the past, as any program would have been small, but now
you are only using the analysis to help in the examination, so as long as there is sufficient
scope the solution need not be limited.
Breaking the problem down
A large problem should be broken down into smaller ones and then each of these analysed to help with the design section.
Produce requirements specification for the identified problem to match the client’s needs
The requirement specification should be clear and concise as this lays out the plan of what the client wants from the new
system. A description of the client’s requirements will give a clear picture of what you are aiming to solve. Having
produced the requirements you need to go back to the client to see if what you produced is what they wanted; if it is then
they can sign it; if not then changes can be made and then signed.
Describe the input, processing & output needs to match the requirements specification
Having described what the client wants from any new system you now need to describe the inputs that are needed to
achieve this, followed by a description of any processing that needs to be carried out and finally a description of the
information that is produced following this processing. These inputs, processing and output must match what the client
wants not what you think the client wants.
Having a clear idea at the end of the analysis leads onto a good starting point for the designs.