system analysis

when the analyst writes out how a system operates in detail

the analyst:

• writes in past tense
• listen to someone who operates the current system e.g. a librarian
• breaks the system into sub systems
• describes the system as an observer
• feed back to "the librarian" to see if they have missed anything
• this takes time and may include diagrams to combine ideas

this is usedf to summerize the flow of data, it makes the informaion easier to understand as people can visualize it. the sub systems are described and drawn on the diagram

there are four basic symbols:

• An oval, representing an entity. This is someone or something that puts information into the system or receives information from it.
• An arrow, representing a flow of data from one place to another.
• A box, which represents an action or processing on some data.
• A long box, which represents a store of data.

A different type of Dataflow Diagram is known as a 'system flowchart'. This type of diagram also gives an overall picture of a system. A systems flowchart shows similar information to DFDs in that it shows the processes that happen on data along with the data flows. In addition, however, these diagrams also show what hardware is used for input, what hardware is used for output and also the data storage devices. They also show what type of file is being used, for example, whether it is a master file or a transaction file. Both system flowcharts and DFDs are used by analysts to show whole systems.

A number of symbols are used in systems flowcharts. These include:

• manual input 
• process
• magnetic tape
• magnetic disc
• ddocument

Structure diagrams can also be used to represent systems and also program designs. They show a different type of information to DFDs. One type of structure diagram uses symbols from the JSD, or Jackson Structured Development way of showing systems. This breaks down a problem into ever-increasing levels of complexity. It is read from top to bottom (using a different number for each level) and from left to right (using a different number for each process in one level).

Breaking a problem down - the start of JSD.

This type of diagram can be used to break down complex problems into easier-to-understand blocks. If you were programming, each block could then represent a module or function. We have come across this type of diagram before when we discussed top-down design. Even if you are not programming a system but just want to understand the processes involved, this kind of diagram can pull together a lot of complex descriptions into a form that can be understood at a glance. 

The data dictionary holds information about data! Any system needs data to make the system work. The Systems Analyst must construct a dictionary of all the data items used in the system because this information will be needed by the people who actually build the new system, who write the software. This point of reference for information about data items is known as the 'data dictionary'. They tell somebody the form of the data, how each data item is actually made up. Data dictionaries are often best done as a table, using the following headings:

• The name of the data item.
• What synonyms there are for the data item.
• Data type. (Whether it is a real number, an integer, a text, a character, a Boolean, a date).
• Validation rules that apply. (For example, the range of allowable values for integers, the number of allowable characters for text, the allowable characters for a character, the way that the date has to be entered, the number of decimal points allowed, for example).
• Examples of typical data entries.
• The origin of the data, where it comes from, how it is generated in the first place, where it is stored.
• What exactly the data item is used for, what happens to it, why it is part of the system at all.

The Systems Analyst will start the data dictionary at the beginning of the project and, like the list of problems, will add to it as new information becomes available. Some of this information may come from interviews, but much may come from existing documentation. One reason why collecting documents from an existing system is important is that it shows the Systems Analyst what data is needed in the current system, with examples of the data, where data comes from, how it is used and so on. This information can be summarised using a data dictionary and then used as a definitive reference.

As interviews progress and the Analyst becomes more familiar with the existing system, problems with it will emerge. People using the current system and methods will highlight problems and the Analyst will notice others. For example,

• System users might complain about things not working as it should.
• Users might complain about some tasks being time-consuming or requiring a lot of paperwork.
• Customers might complain that they never get the right information at the right time.
• It might become obvious to the Analyst that some tasks are labour-intensive and could be easily automated.
• It might become obvious to the Analyst that some tasks which should be possible and which an organisation has never thought about doing are simply not possible with the current set-up.

For example, in the paper-based library example, the librarian might during interviews bemoan the fact that she has to use two different card index systems, one so she can search for members and the books they have out and one so she can search for books to see which member has it out! The Systems Analyst might do a questionnaire to pupils to find out what they think of the library service and many might comment on how slow the system is or what features they actually like about the current set-up. The Systems Analyst should write a list of all the problems as they come across them! They should also write a brief description explaining why each problem happens. This is often best done as a table.

When the Analyst has fully investigated the problem area of a business, they should have produced the following deliverables for the Systems Analysis stage of the systems life cycle:

• Written descriptions of current methods.
• DFDs of current methods.
• System flowcharts.
• Structure diagrams of current methods.
• A data dictionary of the current system.
• A table of problems and why they exist.

In summary, the Analyst now understands the business, the problems in detail and the methods used at the moment. Note that they have as yet not started work on designing the detail of a new computerised system. Having said that, the Analyst will have been considering how the problem can be solved. They will have been investigating alternative solutions and weighing them up against each other. They will have a good idea where the solution will come from, but they haven't got down to the detail of designing the new system yet. This is because they have not actually agreed with the customer what the final system will be able to do! This is the next job in this stage. The Analyst should work on producing one of the most important deliverables in the project, the Requirements Specification. This document will form the contract between the company needing a new computerised system and the company who will make the new system. It lists:

What the customer expects the system to be able to do. How, when the project is complete, the final product will be judged. Each item in the Requirements Specification should state a way that the success or failure or degree of success of that item can be measured. When the project is finally finished, it is the Requirements Specification that is used by the customer to check that they have got what they agreed to buy and it is used by the Systems Analyst to check that they have made what they said they would make, to the standard they said they would make it to.

Once the Requirements Specification has been completed, the Analyst can start outlining solutions. They need to think about what software will be used and how the features of the software will be employed to meet the requirements laid down in the Requirements Specification. It is always possible in a piece of software to approach a problem in different ways. The Analyst should document some of these possible approaches. They could also look at different applications to solve the problem and compare and contrast the ability of each application to meet the needs of the Requirements Specification. They may also look at designing a completely new application from scratch.

Whichever of the solutions is preferred, it should be justified. There should be a clear statement which identifies the features of the software that will solve the problem as laid out in the Specification.

The Analyst needs to produce a list of the hardware and software that is being used in the current system (if applicable). When a list has been drawn up of what exists currently, they should then comment on how this may or may not impact on any future solution. They might be able at this stage to identify that certain software is being considered for a solution, but the software cannot be run on the existing machines because they are not of the right specification, for example. It may be that there are only standalone computers at a business but the analyst is thinking of using email and shared resources that require a network. It may be that an operating system needs to be updated or printing facilities need to be reviewed.

The Analyst should then draw up a list of any new software and hardware that will be needed. They should also justify these proposed purchases to the company so that they are clear about the reasons for spending their money on this equipment.

Once the Requirements Specification is completed and agreed to, the real work can begin! The Systems Analyst can start designing the detail of the new computerised system in the next stage of the systems life cycle - the Design stage.