There are some good ideas here for completing the analyis part of your dossier.

Evidence that students have carried out any of these methods for their dossier will certainly impress the examiners.

These are excellent tools for the analysis of any problem.

Students who attempt dataflow diagrams often try to do one or two of the whole system and this can lead to confusion. A better approach is to identify all the discrete uses of the system and diagram each one separately.

A context diagram

leads to

A set of use cases

A complete set of use cases describes the operation of a complete system from the users point of view.

From the use cases a prototype solution could be constructed.

On this page:  [ data collection methods | requirements specification ]

              [ feasibility report | dossier issues | data flow diagrams | use cases ]

Analysis is used to get a clear idea of what the existing system does. This is corresponds to dossier criterion A. Many students make the mistake of writing about the solution at this stage of their dossiers.

With projects of any size, the analysis stage of gathering data is essential because you can gain clear insight into data input, processing and output without thinking about the computer system that may eventually be used.

Data collection

This process is sometimes referred to (or sometimes taken to include) fact finding. The classic fact-finding methods are:

• Conduct interviews
• Carry out questionnaires
• Study existing documents
• Search the literature for other solutions to the same problem.
• Observe people working with the existing system

Each of these methods has advantages and disadvantages which can be summarised as follows:

As implied by the above table, a mixture of methods is often a very effective way to research and analyse a problem.

Back to top

Importance of Formulating the Problem Precisely

The project cannot be undertaken successfully if the programmer(s) working on the problem and the end users don't have a clear picture of what is to be done. The end users have to fit the new system smoothly into their organisation. The programmer(s) also have to define the system precisely in order to write an effective testing plan .

For your dossier project your analysis should carefully consider such issues as:

• The data required to be input
• The outputs needed
• The processing to be done
• The outcomes required

Sample data should be collected, presented and analysed within this section. Some formal methods of analysis are presented below .

Remember that not all problems or parts of problems can be solved using computer systems. Computers have been used successfully in supermarkets for some time now but we don't see robotic systems stacking the shelves as goods run out.

Often, good and effective manual systems can be integrated into the overall solution. Below we briefly discuss the example of student registration - some parts of which are manual.

Exercise

Consider the registration process in your school. Some parts could be computerized. What might be the technical problems? What about the costs? What benefits would it bring?

Back to top

Require ments Specification and Feasibility Report

The minimum outcome from the analysis will be a problem statement - a clear and unambiguous statement describing the problem to be solved.

A feasibility report detailing likely costs, possible problems and tentative time-schedules might also be produced at this stage. Not all problems can be solved by computer systems, some solutions might be too costly or take too long - these are "business problems" rather than technical problems.

If there is an initial feasibility report and it is accepted then more detail will be required, this comes in the form of a requirements specification . This may include:

• the data inputs and outputs required for the system to work
• a list of tools that might be used to produce the system
• a list of people needed to build the system
• a schedule for the subsequent stages of the project
• the likely cost of the system
• the likely economic impact (eg staff training, benefits to customers etc)

Back to top

Data flow diagrams

A good analysis starts with a description of the problem to be solved and an analysis of the data requirements. A data flow diagram may usefully be used for this; the following symbols may appear (although there not complete consistency in practice):

Symbol	Description
	The box with rounded corners (maybe square or rectangular) which represents a process.
	The box with an open right-hand side representing a data store.
	The closed rectangle is a source or sink (destination) of data. It shows the limits of our diagram, how the data gets into or out of these boxes is not a concern of this diagram.

These boxes are accompanied by arrows to show the direction of data flow. Often the arrows have other associated information such as the data that is on the move or, in other systems, the person responsible for the process.

In our school, as in many others, a form tutor registers the students each morning and a list of absences is written down and sent to the office so that they can run a check.

No reference is made to hardware used, for example the registration may be fully automated or completed by hand.

Back to top

Use Case diagrams

A common technique is to study the "actors" (people who use the system) to diagram how they use the system:

Registration System

Each separate interaction between person and system can then be described in a use-case scenario. This would consist of a detailed description of the each steps. for example:

Subject Teacher Registers Class

• Opens register
• Calls out each name in turn
• Marks register with tick if pupil present
• Lists missing students
• Sends list to office

Although the use of data flow diagrams and use case scenarios is not a requirement of student dossiers, we find that their use gives students valuable insight into real-world problems and helps in the production of a prototype solution.

Back to top

related: [ systems home | next: design ]

Note: data flow diagrams and use cases are not mentioned in the Subject Guide; this is presented as additional information which may be of use to you.

Questions or problems related to this web site should be addressed to Richard Jones who asserts his right to be identified as the author and owner of these materials - unless otherwise indicated. Please feel free to use the material presented here and to create links to it for non-commercial purposes; an acknowledgement of the source is required by the Creative Commons licence. Use of materials from this site is conditional upon your having read the additional terms of use on the about page and the Creative Commons Licence. View privacy policy.