7.1: Analysis guidelines

The problem: identification and background

This should include a description of the organisation, how many people work there, what sort of work they do, and who is your main contact. This section describes the actual problem itself. For example, if you are writing a school library database, then you need to describe the school, the library and possibly explain who uses the library.

Description of the current system

Describe the current system and the environment in which it is used. Describe the ways that computers are being used, if there are any computers. If the current system works well then there is unlikely to be a real need for a computerised system – so indicate the problems with the current system.

Identify the aspects of the problem that you will tackle.

Identification of the prospective user(s)

You may have more than one type of user who will be using your system. For example, if you are writing a library database for your school, you may have two sets of users, the librarian and the pupils who are looking up books on the system. You should make it clear what different roles they have and give some indication of how many people are involved.

Identification of user needs and acceptable limitations

You have already identified your users. Now you need to find out more about what each different user needs the system to do. Based on the results of your interview and research so far, describe what the system must actually do. Explain how you found out about the current system and what the user wants for the new system.

There are likely to be areas that you may not cover within the scope of your project. Although it is important that your system will meet the needs of your user, you should list any anticipated limitations of your system. These are likely to cover the amount of data that your system can cope with and extra features that may be added later.

Indicate any constraints that the user has, such as software, hardware, time, user knowledge, and so on.

Data source(s) and destination(s)

All the data that goes into the system must come from somewhere, whether it is customer orders, invoices or scores from a sporting event or books in the library. List the different sources, their format and where they will come from. Explain how the data will be entered into the system.

List the outputs from the system and indicate their quantity and regularity (e.g. 20 per month).

Specify the medium of each output (e.g. printout in a letter, report printout, picture, screen).

Data volumes

For each data input and output indicate their quantity and regularity (e.g. 20 letters to customers per month). You also need to indicate the volume of data being processed. For example, if you were creating a piece of maths software for teachers to use to simulate a countdown game, you would need to say how many times a day the software will perform its calculations.

Make an estimate of the file sizes required and the number of records so that you will know how much data storage space the system requires.

Analysis data dictionary (from perspective of end user)

A data dictionary contains information about a database. The analysis data dictionary is also the place to keep any descriptions/definitions of terms that the customer has specified. A dictionary should be created that contains an entry for every item of data that is to feature in the proposed system. Data dictionaries do not contain any actual data from the database, only the information about how it will be stored. Therefore you should outline:

n  the entities in the proposed system

n  the fields that will be stored in each entity and what form the information takes, including data types and maximum and minimum values

n  a description added to each entry that makes clear the purpose of the data item, its type and range of permitted values

n  the related fields between the entities (primary and foreign keys).

If your project is not going to have data contained in a database, you still need to define the fields of data you are going to use on input and output. The data dictionary should contain enough information for a user interface designer to work with this information to produce a user interface that could be shown to the end user. You should also include error messages and other display items.

Data flow diagrams (DFDs) (existing and proposed system) to level 1

Your diagram needs to show where data comes into the system, how it is processed, where it is output from the system, and where data is stored in the system. Remember to use the correct DFD symbols. You need to provide a DFD for both the current system and the proposed system. The current system may be a manual system and this still applies. The DFD for the proposed system is likely to differ from the DFD for the current system, and if so should also be drawn up.

Objectives for the proposed system

You will use your objectives in two ways. One way is to check that you are meeting the objectives when you are designing the project. The other is at the end of the project when you carry out your evaluation. You will use these objectives to help you to evaluate the final program. For these reasons, you must both quantify and qualify your objectives.

To quantify means talking about actual numbers, for example: ‘the database must be able to hold 10,000 records’, or ‘the system must be able to convert a graphic in under a minute’. To qualify means describing something by listing its characteristics or qualities. A qualifying statement can usually be checked in some way, for example ‘the user must find it easy to work through the process in three steps’, or ‘the system must be robust and not crash frequently’.

It is usually easiest to write down the list of objectives in bullet point form.

Remember, objectives should be:

n  Specific: objectives should specify exactly what they want to achieve.

n  Measurable: it should be possible to measure whether the objectives are met or not.

n  Achievable: the objectives should be achievable.

n  Realistic: the objectives should be realistically achieved with the resources available.

n  Timed: there should be a set time given to achieve the objectives.

Realistic appraisal of the feasibility of potential solutions

Start this section by listing potential solutions to the problem. This should include:

n  non-computerised (manual) solutions

n  generic software package solutions

n  off-the-shelf software solutions

n  bespoke software solutions.

For each potential solution, you must give an example of the software that could be used and describe why it would be better than the existing system. You will need to do some research into off-the-shelf software solutions to establish whether there are any products currently for sale that could be chosen as a solution. You need to identify the advantages and disadvantages of each potential solution.

Justification of chosen solution (use of formal methods, e.g. observation, analysis of existing paperwork, interviews, surveys)

You should have a lengthy interview with your end user. This is the main source of information on which your whole project will be based. This interview should be structured, questions outlined before the meeting and notes taken. You could also spend time in the working environment and talk to everyone who will be affected by your system. It is a good idea to gather sample documents and include them in your project. Make a full record of any visits/meetings. Before you interview the user, prepare a list of questions to ask. The interview transcript must be included in your report.

If you wish to include a survey by questionnaire, you should send out a number of questionnaires and perform some analysis of the results.

When you have completed your interview, you need to describe the solution you have chosen and indicate why you have rejected the other possible solutions to the problem. Would this really be the best solution to the problem? And if so, why? Your justification should include the software you will be using to implement the solution. Explain why you have chosen your programming language/package.

Entity relationship (E-R) model and diagrams

If your project is going to store data in a database you will need to provide an entity relationship model.

Term / Explanation
Entity / An entity is an object, person, event or thing of interest to an organisation and about which data are recorded.
Relationship / A relationship is an association or link between two entities.
Degree of relationship / The degree of relationship between two entities refers to the number of entity occurrences of one entity that are associated with just one entity occurrence of the other, and vice versa.

You need to draw a diagram of the entities in your system. Next, you need to identify the relationships between the entities – one-to-one, one-to-many, many-to-many.

Identification of objects and object analysis diagrams for object-oriented programmed solutions

If your project is using an object-oriented language, you will need to provide an object analysis diagram.

Object analysis consists of:

n  determining the objects in the problem domain – the nouns

n  determining the relationships between the objects – association, aggregation and inheritance diagrams, and

n  determining the attributes and the behaviours of each object.

You will need to provide a diagram that shows the objects, their associations, aggregations and inheritance.

AQA Computing A2 © Nelson Thornes Ltd 2009 4