Systems Development Life Cycle.

3.1.1 Problem Definition

It is important from the outset to ensure that when a computer system is being designed all
those that are involved are agreed about the aims of the system.

There will normally be a person, or a company or organisation, that decides that a task
would benefit from computerisation. This belief normally arises because there is a problem
which cannot be solved by previously used methods or similar problems seem to have been
solved by computerisation elsewhere. Unfortunately, the owner of the problem probably
understands the problem itself quite well, but does not understand the consequences of
using computers to try to solve the problem, or, indeed, whether such a solution is even
possible. For this reason it is necessary for the organisation to employ a specialist who does
understand computers and computerised solutions to problems. This is the systems analyst.
Unfortunately, it is probable that the systems analyst is not expert in the area of the

The system analyst’s job is to solve the problem by planning and overseeing the
introduction of computer technologies. The owner of the problem will be happy if the analyst
can introduce a computer solution. The problem arises when the analyst, who doesn’t know
very much about the business, solves the problem that they think needs solving, while the
owner of the problem expects a very different problem to be solved.

It seems obvious that if someone is doing something for someone else that they should
make sure that they know what is required. If you are asked to answer questions 1 to 5 and
you do 6 to 10 instead there is an obvious breakdown in communication, but this is what can
happen if you only listen to the instruction, “Do the 5 questions”. The method most often
used to overcome this problem is for there to be discussions between all the interested
parties, and then for a list of objectives to be written up. The solution to the problem is the
successful implementation of all the objectives. The different people involved then agree to
the list of the objectives and the success, or otherwise, of the project depends on the
completion of those objectives.

The definition of the problem is the most important part of the analysis because if it is not
done correctly the wrong problem may be solved. This is quite common and has led to
many failed projects.
3.1.2 A Feasibility Study.

When the organisation and the systems analyst have agreed the definition of the problem, a
decision must be made about the value of continuing with the computerised solution. The
organisation may be convinced that there is a problem to be solved, and that its solution will
be worth the effort and the expense. However, the systems analyst is being paid to look at
the problem, and its solution, from another point of view. The analyst is an expert in
computer systems and what is possible with computer systems. This analyst must consider
the problem from the point of view of the computerised part of the solution and make a
report to the organisation saying whether the solution is possible and sensible. This report is
called the feasibility study because it says whether the solution is feasible.

The feasibility study will consider the problem, and the proposed solution, from a number of
points of view.
Is the solution technically possible? A car firm may decide that if robots are used on the
production line to assemble the different parts of engines then quality of work may improve.
However, if it is not possible to manufacture a robot arm of the correct dimensions to fit into
the small areas under a car bonnet, it doesn’t matter how big an improvement there would
be in the quality of the finished product, it would simply not be feasible.
Is the solution economic to produce? Perhaps the robots exist that can be programmed to
assemble this engine and the benefits will be worthwhile. However, if the cost of the robots
and the program to control them is so great that it puts the car manufacturer out of
business, the introduction of the robots is not feasible.
Is the solution economic to run? It has been decided that there are tremendous benefits in
producing a robot production line and the robots are very cheap to buy, but they have so
many electric motors, and they are so slow at assembling the engines that it is cheaper to
employ people to do the job.
What is the effect on the human beings involved? If the car plant is the only major employer
in the region, and the introduction will put much of the workforce out of work, then the
employer may decide that the human cost is too great, certainly the Government would.
Is the workforce skilled enough? It will be necessary to employ highly skilled technicians to
look after the robots. If there are no workers with the necessary skills, then the
computerisation is not feasible.
What effect will there be on the customer? If the customer is likely to be impressed with the
introduction of the new systems, it may be worth the expense. However, if the customer will
notice no difference, what is the point?
Will the introduction of the new systems be economically beneficial? Put bluntly, will the
introduction of robots increase the profits made by the firm?

If the feasibility study shows a positive result which is accepted by the company, the next
stage will be for the analyst to collect as much information about the process as possible.
3.1.3 Information Requirements of a System and Fact Finding

When a computer system is being designed, it is necessary to ensure that the designer of
the system finds out as much as possible about the requirements of the system. We have
already mentioned the importance of defining the problem but further difficulties can arise.
Imagine an organisation that commissions an analyst to design a new payroll program. The
analyst and the boss of the organisation agree that the software needs to be able to
communicate with the relevant banks, and to deduct tax at source and other important
details. The analyst designs the solution and the software is written. It is the best payroll
program ever produced and is installed into the computer system ready to do the first
monthly payroll. Unfortunately, many of the workforce are employed on a weekly basis. A
simple question to one of those paid in this way would have highlighted this for the analyst
and meant that the costly mistake was avoided. When a system’s requirements are being
studied there is no room for errors caused by lack of information.

The feasibility study has been accepted so the analyst now needs to collect as much
information as possible. Obvious methods of collecting information are to ask different types
of people. It may not be feasible to ask everyone in the organisation for their views, but a
representative sample of workers, management, customers should be given the chance to
supply information. After all, the part time worker on the production line probably knows
more about the business than the analyst. There are three accepted methods of finding out
people’s views:

1. By interview. Interviews are particularly important because they allow the interviewee to
talk at length, and also to leave a prepared script. However, they are very time consuming
and consequently restricting in the number of people whose views can be sought. Also,
questionnaires are very difficult to design. Many people have difficulty completing them,
particularly if the instructions are not very clear.

2. By using questionnaires. Questionnaires make it possible to find out the views of a large
number of people very quickly, but because the questions are pre-determined the person
who is supplying the answers may find difficulty in putting their point of view across.

3. A compromise is to hold a group meeting. This allows a number of people to discuss
points and make their views known and yet cuts down on the amount of time spent in
interviews getting the same answers over and over again. The problem with meetings is
that one or two people tend to dominate, not allowing all the members of the group to give
their opinions.

Often the views of the people connected with the problem are clouded by years of
familiarity, so it is important for the analyst to also gain first hand knowledge of any existing
systems. One way to do this is to observe the current system in action. Care must be taken
to take into account the fact that if the workers know that they are being observed it is
unlikely that they will behave in their normal manner. This is the same effect as a television
camera has on otherwise fairly sensible individuals. The second method is to collect printed
documentation and study it in order to find out what data is required by the system and in
what form information is output.
3.1.4 Requirements Specifications

The planning of any system design must start by deciding what the requirements are of the
system. A system may need to store data for future reference or processing. However,
simply being aware that the system may need to store data is not enough.
Decisions need to be made about the types of data to be held as this will dictate the form
that the data will be stored in and the amount of storage space required for each set of
Calculations as to the number of sets of data that are going to be held have to be made
because the volume of storage will make some storage devices more sensible than others.
Also, the volume of storage can affect the structures that will be used to store the data.
Decisions need to be made about the relative importance of the different ways of accessing
the data. Is it going to be necessary to access individual items of data or will all the data be
accessed at the same time?
Will the data be changed regularly or is it fairly static?

When decisions are made as to the direction that a particular system is going to take, it is
normal to produce a list of tasks that need to be carried out to complete the system. These
tasks should be in a specific order. It would not make sense to consider inputting data into
the system before designing the data structure into which the data is to be put. This list is
called a priority list and it forms the basis of the system design. Each of the tasks that are in
the list should then be considered separately to decide the important points about each one.
An example would be that the file of information on stock being held in a business must
for 1000 items (immediately putting a lower limit on the size of appropriate storage)
for direct searching for information on a single item (means that some storage media are
not suitable, and that some data structures cannot be used)
another file, of manufacturers, to be accessed from each record in the stock file to facilitate
reordering (forces one field to act as a link between the two files).
Plenty of other facts must be considered and decisions made, but a set of constraints has
already been placed on the design. This is known as the design specification and it should
be agreed between the analyst and the organisation before the design is implemented.

Often, the inputs and outputs to a system and the storage and processing that goes on in
the system is such that, in order to understand it, the system needs to be divided up into a
number of interconnected sections, or modules, each one being simple enough to be
handled as an entity. A diagram can be drawn which shows all the sections and how they fit
together. Such a diagram is called a Jackson diagram.

Jackson diagrams:
A Jackson diagram starts with the original problem as the highest level. The next, and
subsequent, levels show how the problems in the previous levels are split up to form
smaller, more manageable, problems. This continues until each of the blocks in the lowest
levels are self contained, easily solvable problems. These individual problems can then be
solved and combined according to the links that have been used. If the links between the
different blocks are then used correctly, the result will be a solution to the original problem.
Imagine a Jackson diagram as a method for showing the individual modules that go to make
up a solution to a problem and the relationships between them.

Original Problem

Individual modules

Final level

The links between the modules can be conditional. For example if the result of a module was
a mark out of 100, then there could be two possible print routines, one for failure if the
mark was below a certain level, and one for pass if it was above the pass mark.

Data flow diagrams:
These are diagrams that are used to describe systems. Boxes are used to stand for input,
processes, storage, and output. Arrows show the direction of communication around the
system, and communications outside the system. As the name implies, these diagrams are
used to show the directions of flow of data from one part of a system to another. Data flow
diagrams can have complex shapes for the boxes that are used, but the important thing is
not the shapes of the boxes, rather the logical train of thought that has been used to
produce the diagram. Rectangular boxes, though not always used, are perfectly acceptable
for all elements in a data flow diagram. Such diagrams are intended to show how the
processes and the data interrelate, not the details of any of the programming logic.
Note: A Systems Flowchart is another name for a data flow diagram.
Students are expected to be able to follow the logic in a data flow diagram and, indeed,
produce their own, but not until the A2 sections of the syllabus, where this topic will be
picked up again.

At this stage the analyst will also identify the hardware that will be necessary for the system
to operate as the user requires, and the software characteristics that will need to be
satisfied for the system to operate.
3.1.5 Design of Input, Output, and Data Structures

Input Design
All systems require input. The way that the data is input to the system depends on a
number of factors.
The data that is required. Is it graphical/textual/physical in nature? Is the data already in
existence or does it need to be collected first?
The hardware that is available. Is the data to be entered via a keyboard by an operator, or
is there an automatic way to enter the data?
The experience of the operator.
The design of the user interface.

This section relates back to section 1.2.3 which covered the different forms of software
interface. The main task in input design is to design the interface with the outside world so
that data can be passed to the system, both software and hardware.

Diagrammatic depiction of the system processing is covered in section 3.1.4, above. It is
not necessary to go into great detail about such diagrams, but students should be aware
that they exist.

Output Design
The results that are produced by the system must be presented in a way that is appropriate
for the application. If the system is designed to produce bank statements for customers,
then it would not be sensible to have an audio output. Similarly, a burglar alarm system
would not serve the purpose for which it had been designed if the output is a message on a
computer screen saying that someone has broken in as there is probably no-one in the
house to read it, which is why the alarm was needed in the first place.

The decision about the type of output will depend greatly upon the same factors as the
input, namely, the hardware available, the form that the output needs to be in, the
experience of the operator, indeed, whether there will be an operator present.
Equally important to giving enough information, is the danger of providing too much. In
order for users to be able to understand the information presented, various tricks can be
Information can be arranged on a monitor screen by always putting the same sort of
information in the same place. The operator will then quickly become accustomed to the
relative importance of different areas of the screen.
Information can be colour coded. Important information may appear in red while that which
is less important is in black. Notice that this implies some form of decision making on the
part of the processor to determine what is important in the first place. It is also necessary to
be very careful about choice of colours. People who are colour blind commonly find difficulty
distinguishing between red and green, so choosing these colours to stand for information
that is dangerously near a limit or at a safe level, could be disastrously wrong. Similarly,
colour combinations have to be chosen carefully. Blue writing on a black background is
almost impossible to see, as is yellow writing in some lighting conditions.
Video reversal can be used to highlight a particular piece of information effectively. This is
when the normal writing on the screen is black on a white background, but the piece that
needs to stand out is shown as white on a black background.
Very important pieces of information may be shown as a dialogue box obscuring the rest of
the screen until it is dealt with.
A printer may be reserved for special messages so that a hard copy of the information is
preserved. Again, the fact that the information appears on that printer means that it has a
particular importance.
Information can be made to flash, or can be printed in a different size, anything that makes
the operator’s eye go to that part of the screen.
It is important not to put too much on a single screen. It is better to use several screens
with the contents clearly shown.
If more than one screen is used, it is important to be able to move both forwards and
backwards through the screens easily.

Data Structure Design
The data used in a computer solution will need to be stored somewhere. The storage is not
that important. What is important is getting it back again when it is needed. In section 1.4,
the data structures array, queue, stack, linked list, tree, were described. When the solution
is designed it is necessary to decide how access to the data will be handled and to choose
an appropriate data structure. Questions on this part of the syllabus will tend to ask for the
sort of choices that need to be made rather than any complex analysis of fitting a data
structure to a given situation, though simple examples like modelling a queue at a check out
till may be asked.
3.1.6 System Evaluation

Any system must match certain criteria if it is to be considered successful. This does not
only apply to a computer system but any system. For example, a car must satisfy various
criteria before being able to be called a car
it must move under its own power
it must be possible to steer it
it must have 3 or 4 wheels
it must have seats.

There would be many other facts which would have to be true before most of us would
recognise that this system is a car. However, some assumptions have been made in just the
four criteria mentioned here. A toy, radio controlled, car fits all these criteria, but it was not
the sort of system that we had in mind when designing the criteria. Perhaps the second
bullet point should have specified that it has to be controlled from within the car itself, or
should there be a new criteria that gives a minimum size for the vehicle? When systems are
being designed, this list of criteria, that the finished system must match, is of paramount
importance. It must also be agreed between the designer of the system and the
commissioner of the design, so that there will be no unfortunate misunderstandings. We can
imagine a situation where the Ford motor company commission a new car design, only to
find that it is 30 cms long when delivered.

Note that these criteria are decided before the system is created. They are used to decide
how well the system works. In other words, does it do what it is meant to? This question can
only be answered if it is known what the system was meant to do in the first place.
3.1.7 Documentation

The documentation of a system consists of all the text and graphics that explain how the
system was produced, how it should be used, and how it can be maintained.
Documentation is created at different stages in the life of a system and for different people
to use. Some of the different types of documentation are met in this section and others will
be encountered later in the course. Indeed, much of the project work that is done in module
5 consists of producing the documentation for a problem solution.

Requirements Specification
This is a list of the requirements of the customer for whom the system is being designed. It
consists, largely, of the criteria that will be used for the evaluation of the finished system
that were discussed in section 3.1.6. It is usual for the system analyst and the customer to
sign the list of requirements so that there is no confusion when the work is finished.

Design Specification
Taking the requirements specification and working out the stages necessary to produce the
required end product is known as the design specification. This will include the different
stages, often shown in diagrammatic form as mentioned earlier in this chapter, and also the
criteria for each stage of the solution. For example, one part of a solution may be the
production of a file of data. The ways that this file of data relates to the other parts of the
system, and the specification of the file (What is the key field? How many records will there
be? What type of medium should it be stored on?) make up the design specification.

Program Specifications
These will include detailed algorithms showing the method of solution for some of the parts
of the problem. These algorithms may well be in the form of flow diagrams or pseudo code.
The language to be used, the data structures necessary, and details of any library routines
to be used will also be in the program specification.

Technical Documentation
The technical documentation will include the program specifications, the coded program
itself, details of hardware configurations. Generally, anything that will aid a technician in
maintaining or updating a system. Indeed, technical documentation is otherwise known as
maintenance documentation. This type of documentation is not intended to be accessible to
the user of the system, who does not need any of these details to be able to use the system

User Documentation
This is the documentation for the person who will actually be using the system. It contains
those details that are needed to make the system operate as it should. Items normally
included in the user documentation will be
how to install the system onto specific hardware
methods of input of data
examples of valid input
examples of output screens
error messages and what to do when they appear

Some user documentation is part of the software and can be called up onto the screen when
it is needed. This type of documentation is called on-screen help.
3.1.8 Testing and Implementation Planning

Any system needs to be tested to ensure that it works. This seems to be a fairly obvious
statement, but in reality such testing is impossible in all but the simplest of systems because
it simply is not possible to test every conceivable input to, or logical construction in, the
system. This difficulty means that testing that is to be done must be carefully planned and
that it should relate directly to the criteria referred to earlier in this chapter. Specific types
of testing have already been covered in 1.3.8.

When the system has been completed it has to be implemented so that it is performing the
tasks for which it was designed. Initially, this involves
ensuring that the correct hardware is available
arranging for staff to be trained in the use of the new system
inputting the data to the data files, either manually or by downloading them from the
original system.

The system handover, itself can be done in a number of ways.
Parallel running. Until the system can be considered fault free, the old and new systems are
run side by side, both doing the same processing. This allows results to be compared to
ensure that there is no problem with the new system. Such a system is ‘safe’ and also
allows staff training to be carried out, but it is obviously very expensive because of the need
to do everything twice. Parallel running is used in situations where the data is so valuable
that there must be no possibility of failure.
Pilot running. Key parts of the new system are run alongside the old system until it is
considered that they have been fully tested. This is a compromise with the idea of parallel
running, but it does not give a clear idea of the effects on the system of the large amounts
of data that are going to be encountered in the full application.
Big bang, or direct change. The old system is removed and the new system replaces it
completely and immediately.
Phasing. Parts of a system are replaced while the remaining parts are covered by the old
system. This allows for some testing of the new system to be done, and for staff training to
take place, but also allows for a back-up position if the new version does not work as

This topic is not fully expounded upon here, the candidate simply needing to understand that
there are different methods of implementation and be able to outline some of the methods
along the lines shown here. This topic will reappear for a fuller treatment in section 6.2.5.
3.1.9 System Maintenance and the Software Life Span

Systems may be designed for a well defined purpose and may realise that purpose, hence
they would be considered successful. However, the original reasons for a particular system
to be created may change, the hardware may alter, the law governing a system may
change. For many reasons the original system may no longer be satisfactory. One solution
would be to produce a totally new system, another would be to adapt the present one so
that it can be used in the new circumstances. This situation is reviewing the system and is
the main reason for technical documentation.

While the system is running it will need attention because of faults being discovered, this
again needs a technician with a set of maintenance documentation.

Computing and computer applications is a subject that changes so regularly through
improvements in technology, new ideas, different legal frameworks trying to keep pace,
that, in reality, a system should never be considered to be finished. Rather than being a
linear process with a beginning, a middle and an end, it should be thought of as a circular
process, continually returning to previous stages to fine tune them and take advantage of
changing circumstances.