Chapter 3

Systems development life cycle

32.1 Some words of advice....

The systems life cycle can be very confusing! This is because every author has his or her own
idea of exactly what it means, what jobs should be done in each stage and what documents
should be produced. On top of that, people will combine or split certain stages in the life cycle
and then use different words to describe the same thing, or the same words to describe different
things!! There is no getting away from the problem but you do need to tackle it head on. You
must read around the subject. Read four or five different descriptions of the systems life cycle
and then make your own mind up.

32.2 Introduction
What is a 'systems life cycle'?
The phrase 'systems life cycle' simply describes the steps that are taken in a project, from the
time that the project is started to when it is finished. When any computer-related project is
initiated, a number of distinct steps, or stages, can be identified in the life of the project. Each of
these stages will involve people doing jobs and producing 'things', for example, a design
document, a test plan or a piece of program code. Each of these things takes the project a little
further towards completion. Things that have to be produced at the end of each stage are known
as 'deliverables'.
The idea behind the project life cycle is that the deliverables associated with each stage in the
project must be produced and checked off by the Project Manager before the next stage can
begin. A stage cannot be started until the previous stage is finished. This stops a project getting
ahead of itself. For example, it will stop someone trying to start the stage called 'implementation'
(the stage where you actually make the project using a database application or code) before all of
the design documentation has been completed. You may have had some experience of this
scenario yourselves with coursework - you don't want to do the paperwork or a detailed design,
you just want to get on and do the project! This, however, is the road to potential disaster! For
example:

 How can a project be designed if it is not clear what the problem is?
 How can a project be built if it is not designed?
 How can it be installed if it is not properly tested?
 What happens if a key project member leaves - how can someone new pick up where
they left off if half of the paperwork is missing or incomplete?
 How can a Project Manager accurately manage a project if they can't clearly see that
deliverables are being completed on time and within the budget?
  How can someone make changes to the product in the future if the documentation is
incomplete?

The list of potential problems goes on and on. A project life cycle gives a project a structure and
therefore allows a Project Manager to manage the project rather than reacting to things when
they go wrong! We can summarize the project life cycle (sometimes called the 'waterfall
model') with the following diagram:

Notice with this model that there is nothing stopping a stage feeding back into an earlier stage, so
that the project can constantly loop around until it is perfect!

32.3 An alternative approach - Rapid Application Development (RAD)

We will briefly mention here the RAD approach to project development as an alternative to the
traditional systems life cycle approach because it has become very important recently with the
rise of something called 'Object Oriented Programming'. The traditional waterfall approach has
some drawbacks. For example, it can take a while for customers to actually see the final product.
Another concern is that software produced using this approach in theory is easy to change but in
practice is difficult. The problems caused by the need to change software because of the
Millennium Bug are witness to this. The RAD approach is different to the classic systems life
cycle. It involves building a series of prototypes. After each one is built, the user is involved.
They are asked to try out and comment on features and test some of the functions. Their
comments are then fed back into the next prototype and a better one is produced. This process is
repeated until the product is finished. The product is in effect developed a little bit at a time but
constantly involves the customer throughout the development process.
It is also possible and common to combine the classic systems life cycle with a prototyping
approach, so that the waterfall model is followed, but the 'implementation stage' involves the
user commenting on a series of prototypes.
32.4 How are projects initiated?

Projects are initiated in a number of ways.

 A system that is currently in place in an organisation is not doing its job efficiently.
Perhaps the business has grown and the system can't cope anymore. Perhaps too many
problems keep arising.
 Perhaps it is a new business that needs a way of solving a problem, for example, a new
company needs to take on-line payments.
 Perhaps an old system isn't flexible enough, or costs too much to run.
 Perhaps there is a change in legislation that requires an existing computer system to be
modified in some way.
 Perhaps the company has heard of some new technology that they think may help them
make their business more efficient and give them an advantage over their competitors.

Whatever the reason, a manager will notice that a system needs to be looked at. In the first
instance, they will arrange a meeting with a Systems Analyst.

32.5 The first meeting

A Systems Analyst's job is to take charge of assessing a problem and to see whether or not it is
suitable for computerization, or whether an existing computer system can be upgraded. They will
be expert in assessing situations. They will have a wide knowledge of existing computer
technology and will be able to visualize what can be achieved with this technology.
Before a Systems Analyst solves a problem, however, they need to be clear what the problem is!
This might sound like common sense but can take a lot of time to get clear and it must be clear
before any real work begins.
When company X has a problem, they will call in a Systems Analyst to look into it. We can
assume that the company will be expert in whatever area of business they are in. They will not be
expert in computer systems. They will not know about the latest technology. They will not
necessarily know all that can be achieved using computers in their business area.
This is where the potential problem lies. The Systems Analyst is an expert in computer systems,
but not company X's business. Company X is an expert in their business but may, at best, have
only a vague idea about computer technology and what it can do for the business. Yet they have
to talk together at the beginning of a project to decide what the project aims are. It is a little like
two people who speak two different languages meeting together. They have to find a common
way to communicate.

When company X calls in the Systems Analyst for the first time, they will sit down together and
company X will explain why they have contacted the Systems Analyst. The Systems Analyst
will listen carefully and will also use this opportunity to ask any questions, perhaps clarifying
some of the jargon that company X has used during the discussion or double-checking that they
have understood what they have been told by the company. Together, they will try to define the
'scope' of the problem. They will try to flesh out what the problem is in language that both
company X and the Systems Analyst understand.

TASK 1 - Explain what is meant by the 'systems life cycle'.

TASK 2 - Summarize 2 advantages and two disadvantages of this approach.
TASK 3 - Name a project methodology suited to Object Oriented Programming, saying why it is
suited to OOP.
TASK 4 - Suggest two situations that would initiate a new project.
TASK 5 - What does a Systems Analyst do?
TASK 6 - Suggest why it can be difficult to define a problem that needs a solution.

32.6 The feasibility study

After a company has made contact with a Systems Analyst, the Systems Analyst will go into the
company and make a provisional study of the problem. They will do this to decide if a solution
is possible, how it can be done and whether it is a good idea to implement. This study is known
as a 'feasibility study'. The deliverable for this stage in the systems life cycle is the Feasibility
Study Report.

The Systems Analyst will carry out a number of tasks.

 They need to find out about the company and how it functions so that they can better
understand and define both the problem and the context of the problem. Remember, the
Systems Analyst doesn't know anything about the company yet, other than what they
learnt in the first meeting. They need quickly to understand the business and its
operations so that they can fully understand the nature of the problem.
 They need to investigate and then document the nature of the problem in some detail.
This means that the Systems Analyst will do a scaled down 'systems analysis'. They
might do some of the systems analysis tasks in 'outline detail'. You can read more about
these actual tasks later.
 They need to identify, suggest and justify possible solutions. Often, a number of possible
solutions are put forward to allow a choice to be made. The Systems Analyst will need to
identify the benefits to the company of each possible solution put forward and how much
each solution will cost the company. This is sometimes known as a 'cost-benefit analysis'.
 In addition to a cost-benefit analysis, the Systems Analyst will also identify a time scale
for each proposed solution - how long each one would take to implement.
 They need to identify any legal or moral considerations in the possible solutions.
  They need to identify any implications for the company. This could include identifying
any new skills that the workforce will need, identifying any changes in the way the
company will do business, identifying any changes in the way customers will interact
with the business and Health and Safety issues, for example.

The Systems Analyst will carry out the above tasks and produce a report called the Feasibility
Study. They will then present this written report to the company and may also do a presentation
of their findings. This report will be the document that the company uses to decide whether or
not to proceed with the project.

Two outcomes are possible. They can decide not to go ahead with the project, perhaps because a
solution is more expensive or more disruptive than they thought. Or they can decide to go ahead
with a solution. If they decide to go ahead, they need first to select the solution that they want to
go with from the range of possible solutions put forward in the Feasibility Study. They then need
to agree other details such as the budget for the project and a start date for the next stage in the
project. If you refer back to the systems life cycle diagram, you will see that the next stage is
known as the Systems Analysis stage.

TASK 7 - What is the purpose of a Feasibility Study?

TASK 8 - What is the deliverable for this stage?
TASK 9 - Summarize in a diagram what tasks the Systems Analyst will do in the Feasibility
Study.
TASK 10 - Explain in your own words what a 'cost-benefit analysis' is.
TASK 11 - Describe what happens to the Feasibility Study when it is completed.
TASK 12 - What stage follows the Feasibility Study?

32.7 Systems analysis - information requirements and fact-finding

A company may decide to go ahead with a project after considering the Feasibility Study. They
will agree a date for the next stage in the project life cycle to begin. This is known as the
'Systems Analysis' stage. During this stage, the Systems Analyst will investigate the problem in
much more detail than was done for the Feasibility Study.
A Systems Analyst must find out exactly what information the company needs to use in any
proposed solution. They must also clearly identify why a company needs to keep each piece of
data. Data stored but not used is a waste of resources!

 Unused data has to be stored somewhere, taking up valuable storage space.

 Unused data has to be entered into the system, which is a waste of input resources if it is
never used.
 Unused data can slow down data operations such as file retrieval.
Not only is it important to identify what data is not needed, it is important to identify what is
needed and in what form the data is needed. For example, if a Systems Analyst is designing a
mail order system and they don't identify that the company also sends out emails, they will not
design email use into any new system. The company will not be happy when they realise that
they cannot email customers anymore! If the company likes to also keep a record of how many
times a customer buys a product, they will not be happy if they cannot do this anymore with the
new system. The Systems Analyst could have identified both of these scenarios by simple fact-
finding methods during the systems analysis stage. There are six fact-finding methods that could
be used. These are:

1. One-to-one interviews.
2. Group interviews.
3. Collecting documents.
4. Observations.
5. Questionnaires.
6. Letters, emails and phone.

32.7.1 One-to-one interviews

a well-planned interview will involve:

 Preparing questions.
 Making an appointment.
 Giving the person you are interviewing the questions in advance.
 Carrying out the interview, ideally recording it if possible.
 Writing up the interview for the appendix of the Systems Analyst's report.
 Clarifying with the interviewee any points that the interviewer is not sure about, then
updating the write-up.
 Summarizing the interview's findings for the body of the Systems Analyst's report.
 Thanking the interviewee.

Interviews should ideally be held with the managers first, to get an overview of a system,
followed by interviews with the users of a system, to find out the day-to-day operational
problems. During interviews, the Systems Analyst can start getting a feel for what people want
from any new system, what problems they want solving, what reports they want generating and
so on. Interviews can be quite time-consuming to organize, especially if you need to do more
than a few. They are very important to do, however, because details of the way things are
currently done and the way people would like to do things can quickly be ascertained.
32.7.2 Group interviews

We have already said that doing lots of one-to-one interviews can be time-consuming. A
compromise would be to hold a group interview. This could be done with the employees from a
department, for example. They could all be called together and operations, problems and
methods could be discussed. The Systems Analyst needs to understand that for many workers,
introducing a new computerized system equates to redundancies and they will need to show skill
in finding out what they need to know without upsetting anyone! While group interviews can
save time, there is a danger that one or two people will dominate these events and that some
people's views will be drowned out.

32.7.3 Collecting documents

An excellent way of finding out about the data used in any existing system and the way a
company currently does things is to collect examples of documents that are used. These will
show the names of data items give examples of the items themselves and will prompt the
Systems Analyst to ask employees questions about the data. For example:

 Where did the data originate?

 How is the data constructed?
 Are there any synonyms used for any data items - different names for the same piece of
data? For example, most people would call a car a 'car' but some might use the words
'auto or 'automobile'. You would, however, only want to set up one field for car, not
three! Are there any instances where different names are used to describe the same piece
of data in the system being investigated?
 What is the range of allowable values?
 What actually happens to the data on a document?
 Who uses the data?
 When is the data removed from a system and who does it?

Collecting documents also helps the Systems Analyst to start the data dictionary, discussed later.
32.7.4 Observations

Sometimes, what people say they do is different to what actually happens in practice.
Sometimes, people simply don't mention things in an interview because they either forget or it
seems too trivial to mention. A Systems Analyst can sometimes find out information by spending
time watching people go about their job. People can be very aware of the presence of someone
that they know is watching what they are doing and behave differently, although with skill and
time, this problem can be overcome.
32.7.5 Questionnaires

Questionnaires can be used to collect very focused answers to questions from a large number of
people relatively quickly and without using up a lot of manpower (compared to interviews, for
example). However,

 Writing good questions in a questionnaire is very difficult indeed.

 Most people do not return them.

An improvement, if resources are available, is to have someone 'interview' people using a

questionnaire. The person interviewing asks the questions on the questionnaire and records the
answers. If the person doesn't understand a question, it can be explained to them. More
questionnaires will be completed this way.

32.7.6 Letters, email and phone

Phone calls can be useful because you can actually speak to the person you need to without
having to spend time travelling to see them. Email is immediate compared to letters but whilst
everyone can be sent a letter, not everyone has an email address. Even if someone has an email
address, they may not use it and you may not realize they don't! Letters are more time-
consuming to prepare and write compared to email, which tend to be written in a quick, matter-
of-fact way. Both emails and letters give you answers in writing compared to phone calls, where
you are relying on your ability to take good notes and understand what someone is telling you.
Emails and the phone, and to a lesser degree letters, are especially useful to quickly clarify points
made during an interview.

The Systems Analyst, then, needs to find out about current methods used and to find out all
about the data used when investigating a problem in an existing system. If they are setting up an
entirely new system, they still need to form a 'picture' of how any proposed business will do the
jobs that need doing and will still need to fact-find.
TASK 13 - Explain why it is important to identify and eliminate any 'redundant' data from a
computerized system.
TASK 14 - Explain the importance of identifying the information needs of a company.
TASK 15 - Compare and contrast the advantages and disadvantages of a range of fact-finding
methods.
32.8 Analyzing the system requirements

We said previously that the systems analysis stage involved investigating the problem in detail
and how any proposed system would solve the problem. We have said that one of the first things
the Systems Analyst needs to do is become familiar with the business and expert in the area of
the problem that needs solving. They must understand:

 The way the system currently works.

 Problems with the current system.
 Aspirations of the company. What do they want the new system to do that the old system
doesn't do?

They find out about these things by using fact-finding methods such as interviews and collecting
existing documentation. They summarize what they find out and include these summaries in the
deliverable for this stage, which is the Systems Analysis Report. There are a number of ways that
information can be summarized in the Systems Analysis Report. These include:

1. Written descriptions of current methods and systems.

2. Dataflow diagrams (DFDs).
3. System flowcharts.
4. Jackson diagrams.
5. A data dictionary.
6. Written descriptions of problems.
7. Requirements specification.
8. Possible outline solutions.
9. Hardware and software constraints.

32.8.1 Written descriptions of current methods and systems

A good starting point for a Systems Analyst when investigating a new problem in an unfamiliar
business is to write out how each system in the problem area operates in as much detail as
possible. This should be done:

 By describing systems using the present tense.

 By describing systems as though the Systems Analyst is 'a fly on the wall', an observer.

For example, consider a school library that is completely paper-based. A Systems Analyst has
been asked to investigate computerizing the library. They would arrange an interview with the
librarian who would then explain how each of the sub-systems in the library work. One sub-
system might be the one used to take books out. The Systems Analyst would listen to what the
librarian says and then produce a written description of it. It might go something like this:
A pupil selects a book from the shelf and takes it to the checkout counter. They present the book
and their membership card to the librarian. The librarian retrieves the member's details from the
'members card index system'. She then checks how many books the pupil has out already. If it
exceeds 3 then the pupil is told that they must return a book before they can take any other out.
The librarian also checks to see if the membership has been 'blocked'. This can occur if a fine
hasn't been paid for an overdue book or if the pupil has been misbehaving. If the pupil has got
less than 3 books and the account has not been blocked, then the librarian transfers the title and
author details to the member's card and also the date the book is due back. This card is then
filed. The librarian then retrieves the 'book details' card from the 'borrowed book card index
system' and records the pupil's membership number on it and the return date. This is filed. The
book is stamped with the return data and returned to the pupil with their membership card.

Of course, the Systems Analyst will want to go back to the librarian and read back the
description after it has been written up, just to check that they have understood everything
correctly and that nothing has been missed out. The above example is for the 'Taking a book out'
sub-system. The Systems Analyst would also need to write descriptions for such sub-systems as:

 The 'returning a book' sub-system.

 The 'blocking a pupil' sub-system.
 The 'fine' sub-system.
 The 'adding a new book to the library' sub-system.
 The 'removing a book from the library' sub-system.
 The 'adding a new member' sub-system.
 The 'removing a member' sub-system.
 The 'reserving a book' sub-system.

Describing these sub-systems, arranging interviews, writing them up, summarizing them and
then checking that they are accurate and complete descriptions is not a 5 minute job! A lot of
information is going to be generated and, following on from written descriptions, the Systems
Analyst will want to use special diagrams to bring the information together.

32.8.2 Dataflow Diagrams (DFD)

Dataflow diagrams, or DFD diagrams, are used to summarize the flow of data around a system.
Written descriptions are fine, but pulling a lot of information together in the form of a diagram
helps everyone involved 'see' what is going on in the system a lot easier. Because systems such
as the library can get quite complicated, they should be broken down into sub-systems, as we
have already explained. Each one can then be described and then a DFD can be drawn for each
one. There are only four basic symbols in a DFD (not counting the big system box in the Level
zero diagram).
 1. An oval, representing an entity. This is someone or something that puts information into
the system or receives information from it.
2. An arrow, representing a flow of data from one place to another.
3. A box, which represents an action or processing on some data.
4. A long box, which represents a store of data.

In the example below, we can see how DFDs are produced. The diagram below shows the first
step in drawing a DFD. It shows the whole system as a box. It also shows the entities such as
people that interact with the system as well as any data that enters the system from an entity and
any data that leaves the system to an entity. This DFD is known as a 'level zero' or 'context
diagram'. Notice that the librarian is not shown because she is part of the system, not external to
it. Also notice that there are two ovals representing 'pupil'. They are the same entity - we could
have drawn just one. This would have cluttered the diagram, however, and made it less clear so
two have been drawn instead. To show that they are the same entity, a line has been drawn in the
top left of each one.

A context diagram

The context diagram above shows a simplified version of the whole system but doesn't show
what actually happens to the data, where it is stored and the processes that happen to it. It doesn't
show what is happening inside the box called 'Taking a book out' sub-system. The box needs to
be broken down to show some detail. The next stage is to produce a 'level one diagram'. A first
attempt is shown in the next diagram.
A level one diagram
See if you can read the description of the 'Taking a book out' sub-system and match it up to the
level one diagram. Try to follow what is happening. Do note that a Systems Analyst will take
quite a few attempts to get the DFDs right. When you do projects, don't expect to get these
diagrams correct at the first attempt. You need to have a go at it, then discuss it with someone,
then sleep on it, then have another go, and repeat the process until you get it right! The level one
diagram is a big improvement on the level zero diagram because it shows the processes that
happen to data and what storage there is. Some of the processes, such as '1.2 Valid' could be
broken down further into what are known as level two diagrams. These are beyond the scope of
this discussion. Interestingly, this diagram can be closely matched to a database. For example,
where there is a data store, you need to have a table in a database. Where there is a process, you
need to have a query. Where there is a flow into the system, you need to have a data input form
and where there is a flow out of the system, you need to have a report. We are starting to move
closer to designing a database!

32.8.3 System flowcharts

A similar but 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 (amongst others):

Some of the symbols used in systems flowcharts

Consider this example. An exam board marks a set of exam papers for pupils at a school. They
enter the marks into their system, validating each mark as it is entered. An error report is
generated for any problem marks and the marks are then re-entered. Once all the marks have
been entered, they are sorted. Pupils' information is then retrieved from its system, the new
marks entered and the records updated. Summaries of the results and certificates are then sent
out. A system flowchart for this system might look like the following:
An example of a system flowchart
Note that processes are shown (' Validate marks', 'Sort file' and 'Exam results' programs), data
stores can be identified and flows of data are also on view. In addition, however, we can see
some of the hardware needed (keyboard and hard disk) and some of the different types of files
(master and transaction files).

32.8.4 Structure diagrams

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).
Going back to the 'Taking a book out' sub-system, you could represent the sub-system using the
following diagram.
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. We have introduced the idea of structure diagrams above, but we have only just
scratched the surface. We will meet these diagrams again in another chapter and take them even
further.

32.8.5 Data dictionary

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
and so on).
 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 summarized using a data dictionary and then
used as a definitive reference.
32.8.6 Written descriptions of problems

As interviews progress and the Analyst become 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 labor-intensive and could be
easily automated.
 It might become obvious to the Analyst that some tasks which should be possible and
which an organization 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.

32.8.7 Requirements Specification (RS)

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
computerized 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 computerized system and the company who will make the new system.
It lists:

1. What the customer expects the system to be able to do.

2. 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.

[Link] SMART requirements

When you are writing a Requirements Specification, one way to help you write excellent
requirements as opposed to wishy-washy ones, is to ensure each requirement is SMART.
S Specific. Each requirement must be clearly described and easily
understood by everyone.
M Measurable. You should be able to write down tests that can
measure the requirement. Requirements such as 'user-friendly', ' easy
to use', 'effective' and 'pleasing to the eye' for example, are difficult
to measure. 'Fast' is easy to measure because you can set tests e.g.
must be able to display a customer's account details in under 0.5
seconds.
A Agreed. The customer and the Project Manager must agree on each
requirement and the way it will be measured.
R Realistic. Each requirement must be realistically achievable, taking
into account the resources and budget.
T Trackable. The project manager must be able to monitor and
measure the progress of the achievement of a requirement. For this to
happen, the requirement must be something tangible, something that
they can see being developing, something that they can tell has been
finished.
[Link] The process of producing an agreed Requirements Specification (RS)

The Systems Analyst will use the written description of problems as a starting point to producing
the RS. They will produce a 'draft RS'. In the draft RS, the Analyst will set out what she thinks
the customer should expect from the new system, what the new system will be able to do and
how success/failure will be measured. She will then arrange a meeting with the customer so that
they can discuss the draft. Both the customer and the Analyst may well want to make a few
changes as a result of the meeting. The Analyst then goes away and re-drafts the RS. Another
meeting is arranged and the re-draft is discussed. If everyone is happy, both parties sign and date
the RS. If more work needs to be done on it, then it is re-drafted again.

32.8.8 Possible outline solutions

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.

32.8.9 Hardware and software constraints

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 computerized system in the next stage
of the systems life cycle - the Design stage.
TASK 16 - Summarize using a diagram the documents you would expect to find in the systems
analysis chapter of an Analyst's final report.
TASK 17 - Outline the benefits of producing a diagram rather than a written description of a
system. In what situations might a diagram rather than a lot of writing come in handy?
TASK 18 - Draw and label the four symbols you would expect to find in a Dataflow Diagram.
TASK 19 - Explain how a DFD can help a database designer.
TASK 20 - Compare the information contained in a DFD with the information in a structure
diagram.
TASK 21 - Compare and contrast the information shown in a system flowchart with the
information shown in a DFD. What is a system flowchart used for?
TASK 22 - What is a 'data dictionary' and what is its purpose?
TASK 23 - What headings might you typically find in a data dictionary?
TASK 24 - What is a 'Requirements Specification'?
TASK 25 - What information would you expect to see in a Requirements Specification?
TASK 26 - Describe in your own words the process of producing a Requirements Specification.
TASK 27 - What stage follows on from the Systems Analysis stage in the systems life cycle?

32.9 Designing a system

By the time the analyst gets to the Design stage they will

 Understand the business and operations in detail.

 Understand the problem area in detail.
 Have agreed with the customer what they want the new system to do.
 Have outlined the solution.

They now need to go ahead and design the detail of the solution to the problem. Many of those
things done as part of the Systems Analysis stage of the project life cycle will be done again in
this stage, but this time for the proposed system. What the Analyst should be trying to do is
provide the best solution that meets the Requirements Specification. In the Analysis stage, they
will have outlined a proposed solution that will really help a company solve a problem. They
won't simply be trying to convert a paper-based system into a computerized one. They will be
trying to make the whole process more efficient, for example, by automating tasks, by adding
facilities that currently are not part of the system and using features in any new technology. The
areas that need to be considered are:
 1. Written descriptions.
2. Diagrammatic representations.
3. Data dictionary.
4. Input design.
5. Output design.
6. Program specification.

When the Design stage is complete, it should be possible to give all of the design documentation
to any programmer or builder of systems and they should be able to construct the system from
those documents alone! This statement is important. It tells you the amount of detail that is
needed and the clarity of communication that is required by the documentation.

32.9.1 Written descriptions

A good starting point for the design stage is for the Analyst is to write out in the future tense how
the proposed system will work. They should try to picture people using the system and describe
what they are doing. They should describe each task a user needs to perform and how it is carried
out. They need to paint very clear pictures with their descriptions so that they are understood by
anyone who needs to refer to them.

32.9.2 Diagrammatic representations

Once they have described the system in writing, they should then produce diagrammatic
representations of the design. This will involve producing Dataflow Diagrams and Structure
Diagrams of the proposed system. These were described earlier. It is useful to know that there
are other diagrams that could be used here as well as the ones already mentioned. Although we
will save the detail about these and how they are used for later chapters, we will briefly mention
them.

 Entity-Relationship diagrams. These diagrams summarize how records in a database are

to be organized into tables and how the tables are related.
 Entity Life Histories. These diagrams summarize what happens to a particular record in a
database. For example, they will show that at some point a new record is created, and it
gets amended, and it gets removed completely from the system.
 Normalization. This is a technique that helps produce an efficient database design.

Diagrams generally are good because:

1. They summarise information.

2. They clarify complex systems.
3. They can be used by teams to discuss a system in meetings.
 4. They may be used to help explain certain things to customers.
5. They will become part of the Technical Document, to help people make modifications to
the system in the future.

32.9.3 Data dictionary

A data dictionary needs to be produced for the new system. This may well involve simply
copying parts of the data dictionary produced for the old system to the new data dictionary and
then adding any additional items that are required. The data dictionary was discussed in detail in
the previous section.

32.9.4 Input design

When designing the way that data will get from the outside world into any computer system,
some questions need to be asked. These include:

 Will the data be collected first on paper forms, for example and then put in, or will the
data be entered in directly?
 In what form will the data be in if it is entered in automatically? For example, will it be
coded up in a bar code, or using MICR, or using OCR, or in some other way?
 What hardware exists, or will exist, to get the data into the computer? Will there be
keyboards, a graphics tablet, touch-screens, microphones for voice recognition, for
example?
 What skills will the operators have? Do any disabilities need to be taken into account, for
example?
 What kind of interface will be appropriate for the system? For example, is a command
line interface appropriate, or a menu-driven interface, or a different type of interface
appropriate?

You can remind yourself of the different kinds of user interface in a previous chapter.

32.9.5 Output design

When designing the way that data will get from the computer system into the outside world,
similar questions to the design of input methods need to be asked. Who are the users, what are
their skills, do they have any special needs, where will the output come out, where will it be used
and what will be done with it? The key question to remember here is, 'Who needs what
information from the system, when and in what form?' There are a number of output techniques
that could be considered.
  Audio could be used to signal alarms in noisy, busy factories or to signal a break-in in a
house.
 Key information on a VDU could be color-coded or a different font size or style used.
 Important information could flash.
 Pictures could be used to represent or reinforce information.
 Graphs can be used to display information such as temperature trends over a period of
time in a chemical factory.
 Printouts could be used so that information can be transferred from the computer to a
warehouse where it is needed to collect goods, for example.
 Plotters can be used to provide large accurate drawings in an engineering design
department.
 Dot matrix printers can be used to provide physical copies of key documents.

32.9.6 Program specification

Solutions may require some programming. Part of the design documentation, therefore, needs to
describe the functions that any code will perform. These can be described by

 Writing a description of each function in detail.

 Writing pseudo-code for each function.
 Producing diagrams such as a flow chart or a Jackson diagram.

The specification will also identify the language to use and program libraries needed along with
the routines within them.
TASK 28 - What stage comes before and after the Design stage in the systems life cycle?
TASK 29 - What is the purpose of the design stage?
TASK 30 - Outline the deliverables in the Design stage and state their purpose.
TASK 31 - In what ways can a diagram help the design process?
TASK 32 - What information would you expect to find about a piece of data in a data
dictionary?
TASK 33 - What is meant by a 'user interface'? What kinds of things need to be discussed?
TASK 34 - Suggest what areas need to be considered when designing the input and output of a
system.
TASK 35 - Summarize what is required in a design document to describe what a piece of
programming code does.
TASK 36 - Define an 'algorithm'.
TASK 37 - What is a 'program library'?
32.10 Evaluating a system

When a system has been completed, the customer needs to be sure that they have got what they
paid for. The company who made the system needs to be sure that they have delivered what they
promised. Checking this is known as the 'system evaluation'. The purpose of evaluating a system
is to check that the product meets the requirements as laid down in the Requirements
Specification.

32.10.1 The role of the Requirements Specification

When we discussed the Requirements Specification, we said that it was possibly one of the most
important documents in a project. The Requirements Specification constitutes the contract
between the company buying a solution and the company building the solution. When the system
evaluation takes place, the Requirements Specification is used in the evaluation. Each item in the
specification is checked to see if it has been done and performs to the standard written down in
the RS. If all items have been completed and completed to the standard in the Requirements
Specification, then the product is finished! It can be handed over and paid for! If some items are
not completed, or completed but not to the required standard then negotiations may need to take
place between the company and the maker of the product. They might agree a price reduction.
They might agree an extension to fix the problems. They might agree that the company created
the situation that has caused a problem and that they should pay more money than was originally
agreed. Or they might not be able to agree why the product is not doing what it is supposed to do
and they go to court to fight it out!!

TASK 38 - What is the purpose of a system evaluation?

TASK 39 - Explain the role of the Requirements Specification in the system evaluation.
TASK 40 - Describe the possible consequences when an item in the Requirements Specification
does not meet the standards set for it.

32.11 Documentation in the systems life cycle

As we have looked at some of the stages in the project life cycle, we have come across and
discussed lots of different types of documentation. We will recap them in this section and then
discuss the user documentation and the technical documentation.

32.11.1 Recap of documentation so far

We have seen that the Requirements Specification is the agreement between the company buying
a solution and the company building it. We know that it details what the system will do and the
standards by which the items in the Requirements Specification will be judged. We also know
that it is a key document used in the evaluation once the product has been built.

The design documentation details how the solution will be built. It includes written descriptions
of how the system will be designed so that it can do all of the things set out in the Requirements
Specification. It includes diagrammatic representations of some of these descriptions, other
diagrams that help the design of the system, a data dictionary, input and output designs and a
program specification. The design documentation itself needs to be detailed enough so that it can
be given to anyone skilled in building systems and they will be able to design the product from
the information given to them. Part of the design documentation is the program specification.
This specifies what programming language to use if appropriate and details what functions the
program code needs to perform. Algorithms could be used to describe these functions or
diagrams such as flowcharts or Jackson diagrams could be used.

32.11.2 User documentation

With any product, some help needs to be provided for the users to enable them to run the
software successfully. With many applications, those facilities are provided as software, as part
of the application. To access the on-screen help, a user might click on an icon or press a function
key, for example. A pop-up screen would then appear. A typical set of help features of an on-
screen help system include:

 An index to allow a user to scroll through help files.

 A search engine to allow a user to type in key words or use natural language to search for
solutions to problems.
 A FAQ (Frequently Asked Questions) facility so that users can find answers to the most
commonly-asked questions quickly.
 Internet links to helpful web sites and support groups so that a user can find further help
if they need to.
 Tutorials, to show users how to carry out tasks. These are often animated and interactive.
 Examples to help a user, such as a typical way to construct a formula.
 Provision of a README file to tell the user important information before they get started
using the product.
Paper-based manuals are still common. A typical set of features include:

 A contents page and an index, to help users find what they want.
 Annotated diagrams and writing, to explain how to use the functions within the software.
This might include how to enter data, print out copies, get on-screen help, for example.
 Examples, to show the user how to do typical things, such as writing formulas.
 A 'Getting Started Guide', to show users how to load up the software and configure it to
their system. This might include extra instructions on how to configure the software for a
network.
 How to get further help, who to contact.
 A 'Trouble-shooting Guide', to explain how to deal with common problems.
 A description of the licensing agreement for the user.
 An explanation of the user's right to make a back-up copy of the software.

32.11.3 Technical documentation

The purpose of the technical documentation is to describe how the system actually functions. It is
not written with a user in mind, but to assist a technical person in the future. The technical
documentation is needed by a technical person because software has a 'shelf-life'. Just because it
is 'finished', doesn't mean that it will never need to be re-visited again for 'maintenance'.
Maintenance is discussed shortly. Just as it would be difficult to maintain a car without the
technical manual, so it would be difficult to work on software in the future without the technical
documentation for the software. The technical documentation will typically contain:

 The Requirements Specification.

 The hardware and software specification.
 All of the documents from the Design specification, including any program
specifications.
 How to configure the system for different computer set-ups.

TASK 41 - Suggest typical facilities for an on-screen help facility.

TASK 42 - What documentation makes up the technical document?
TASK 43 - Describe the needs of the users of 'user documentation' and 'technical
documentation'.
TASK 44 - Clearly explain the meaning of the following words and phrases:

1. Pseudo-code.
2. Jackson diagram.
3. On-screen help.
4. Pop-up screen.
5. A search engine.
 6. FAQ.
7. A forum.
8. Shelf-life.

TASK 45 - Why are FAQ pages commonly set up by companies? In what ways do FAQ sections
benefit a company?
TASK 46 - Why is it important to keep a record of the hardware and software specifications of
any system?
TASK 47 - What is meant by an 'interactive tutorial'?
TASK 48 - Suggest what information you might find in a README file.

32.12 Testing and implementation planning

Ensuring that a system works is very important.

 A company that builds systems has a reputation to protect. They do not want to damage
this by producing products that get into the news for the wrong reasons! In some cases, it
could cause the company to go bust.
 They need customers to say good things about the product they bought because 'word of
mouth' will generate new business. This will help the company make bigger profits.
 A system that is unreliable will soon be avoided by users. They will find it frustrating to
use and will stop using it. Their company can only suffer because they have invested a lot
of money in a system that was supposed to bring benefits and a system that doesn't work
often makes matters worse.
 A system that causes accidents will leave a company open to legal action.
 Testing is a stage in the life cycle. The deliverable is the test plan. Test plans are written
to ensure that the product does what it is supposed to do, as laid out in the Requirements
Specification. It is usually written just after the Requirements Specification has been
agreed and should test all of the functions mentioned in the Specification using typical,
atypical, borderline, extreme and silly data. It should also be tested to ensure the whole
system works together to produce the correct output for some given input.

Testing of software products can be very difficult to do thoroughly because there are often so
many permutations through software. A strategy to testing must be developed. These were
discussed in an earlier chapter.
32.13 Implementation planning

Once a product has been built and tested, it needs to be implemented. It must be done in a way
that ensures minimum disruption to the business.

 Staff training on the new system must take place. This should include those who will use
the system and those who will support others in the initial phases of implementation, for
example the Network Administrator or the various managers. This has implications for
the business. If staff are training, they are not working! The cost of this should be taken
into account when the project is planned.
 When a new system is to replace an old system, the data files kept on the old system
needs to be transferred. Someone has to actually do this and this takes money, time and
resources. In addition, any data transferred to the new system should be current. It would
be of little use to transfer data from the old system to the new system one day but then
not use the new system for a week. There would be one week's worth of data out-of-date!
 The hardware and software must be in place. Any additional hardware and software must
be bought and stored somewhere until they are implemented. They then need to be set up
and checked.

There are 4 implementation strategies that could be used.

1. Parallel running. The new system is run alongside the old system. Both systems operate
together. This allows the new system to prove itself before the old system is abandoned -
data generated by the new system can be compared to data generated by the old system. It
also means that staff can be trained and gain confidence in the new system. Of course, if
you are running two systems together, that means twice as much work for everyone for a
short time!
2. Pilot running. The new system is run alongside the old system, but only a portion of the
data is actually used in the new system. This method is less of a drain on resources. Data
from part of the new system can be checked with the old system, but you cannot check
how the whole system will react until you have got the whole system up and running.
3. Direct changeover. The old system is stopped and the new system is started. This might
happen over a weekend, for example. If something goes wrong with the new system, then
it has to be sorted out because you cannot fall back on the old system. Staff training needs
to take place in advance with this method.
4. Phased implementation. Parts of a new system completely replace parts of an old
system, whilst the old system continues to be used as required. The part of the new
system that has been installed can be used for staff training and can prove itself before the
next part of the installation takes place. This method takes longer than the direct
changeover method. A company with 10 branches may install a new accounting system
in one branch first, for example. They run it in the branch until it has proven itself and
 possibly bring in staff members from other branches for training. Once the system has
proven itself in one branch, it can then be phased into the other branches.

TASK 49 - What is the purpose of a test plan?

TASK 50 - Explain why proving a product works properly is important.
TASK 51 - What is meant by

1. Black box testing?

2. White box testing?
3. Alpha testing?
4. Beta testing?

TASK 52 - Describe the possible implementation methods for a chain of supermarkets wanting
to install a stock control system.

32.14 System maintenance

When a system has been completed and is in use that is not the end of the life cycle. There will
be situations where the designers of the system, or others, have to go back and make changes.
This is referred to as 'system maintenance'.

32.14.1 Situations that trigger modifications

System maintenance may be required for a wide range of reasons.

1. A user has discovered a bug in a program. This needs to be rectified.

2. The law has changed. The system needs to be changed to ensure that it conforms to the
new law.
3. New technology. Some new technology has come into being which has provided new
opportunities. The system needs to be modified to take advantage of these new
opportunities.
4. A new function is needed. The company may decide that they would like the system to
do something that it cannot currently do so the system needs to be modified.
5. The business has 'outgrown' the system. For example, a business may have expanded and
now needs to be able to handle far more data than it used to do.
TASK 53 - Define 'system maintenance'.
TASK 54 - Draw a diagram that summarizes a range of situations that would trigger system
maintenance.

32.15 Hopper Ltd - a case study

Hopper Ltd is a company that makes a wide range of Space Hoppers! These were big in the
summer of 1971, faded away out of fashion but now they're back! (Do a search on the Internet to
find out what they are!) It has an office building, a factory site 100 meters from the office and a
warehouse next to the factory. All of the admin, sales and marketing are done in the office
building, the Hoppers are made in the factory and the warehouse is used to store the materials
used in the production of Hoppers and also the finished products. The office, the factory and the
warehouse are constantly communicating with each other throughout the day. For example:

 The office sends details of new orders to the factory.

 The office sends requests to the warehouse for orders to be parceled up and sent from
completed stock.
 The factory sends requests for materials to the warehouse.
 The warehouse sends details of completed orders to the office.

Currently, it keeps details of both its suppliers and its customers on a paper-based record-keeping
system. Messages are passed from one building to another by hand.
Miss Jones is the General Manager. She's had an idea! Could all of the communications be done
on a network, with a database to keep records? She feels sure there are lots of opportunities for
computers to make the business more efficient than it currently is, but isn't a computer expert. At
the next managers' meeting she outlines her ideas. It is agreed to call in IT-R-US Ltd, an IT
consultancy, to carry out a feasibility study. They send in their most experienced Systems
Analyst - you!
Remember - you have been given a scenario, so you must relate your answers to that scenario
wherever possible - and most of the time it will be possible. Make sure you know a few tricks
and tips to relate answers to scenarios.
1. If you don't relate an answer to the given scenario where ever you can, what is the
consequence for the marks you can be given for that question in an exam? (1)
2. What does a Systems Analyst do? (2)
3. Miss Jones has arranged a meeting with you to discuss the problem. Explain the importance
for both you and the company of defining the problem accurately. (2)
4. You spent one week at the company doing a Feasibility Study. Suggest five areas that would
appear in your Feasibility Report. Try and relate your answer to the scenario. (5)
5. You have now just completed your Feasibility Report. What happens next? (2)
6. As a result of your Feasibility Report, it has been decided to proceed with the project. The
Requirements Investigation and Analysis stage of the project is to start. What is the purpose of
this stage of the project and what is the end product of this stage? Be very specific about what
the end product contains! (4)
7. Write down five examples of methods you want to use at Hoppers Ltd to collect information.
Suggest one advantage and one disadvantage of each method. (10)
8. As part of your investigation, you drew up a Dataflow Diagram of how data flows around the
system at the moment. State exactly what a DFD shows you. (4)
9. You also produce a systems flowchart. What additional information compared to a DFD does
this show you? (2)
10. Generally, suggest reasons for producing any technical documentation. (4)
11. Give examples of the information you would expect to find in a data dictionary. (4)

NOTE: Some of what you produced in the Requirements Investigation and Analysis stage can
also be part of the Design stage. There is an overlap, but don't let it confuse you. The
Requirements Investigation and Analysis stage is all about finding out the information needs and
requirements of the new system, the starting point being to find out all about the current way of
doing things. The Systems Analyst needs to become a bit of an expert in the way the business is
run. The design stage is about specifying a design that will meet the Requirements Specification
produced at the end of the Investigation and Analysis.
12. Clearly explain what is meant by the 'user interface'. What things do you need to talk about to
describe fully the user interface? (1)
13. Without drawing any actual input forms or output screens, describe, with reasons, the typical
user interface for a secretary working in the office and a supervisor working in the dirty, noisy
factory. (5)
14. You have finished the design of the new system. You have specified the hardware needed,
the software needed, the user interface and output design. You have done system diagrams and
defined the data. You have handed over your design to a programmer, who has now built the
system. They are ready to test it. They are going to write a Test Plan, putting all the tests into a
table. Suggest appropriate headings for the table. (5)
15. What kinds of data should be selected when choosing data for test plans? (4)
16. The designer has finished testing the new database using black box and white box testing and
wants to move on to alpha and beta testing. Briefly describe what happens in each of these 4
types of test strategies. (4)
17. The new system has been fully tested. State the 4 possible implementation methods you
could select. Which one would you recommend and why? (6)
18. You have been asked to provide on-screen user guide. State 4 facilities provided by a good
on-screen guide. (4)
19. Give 6 different examples of areas of information that need to be covered in the on-screen
guide. For example, it should show a user how to produce a report of sales of Hoppers in any
month. (10)
20. You have also been asked to do the technical documentation. Who is it aimed at and what is
the purpose of the technical guide? (2)
21. State 8 documents or diagrams you would expect to find in the technical guide. (Do not
include an index or contents page, although these should be part of the guide). (8)
22. The project has now been installed and is running. Hopper Ltd, along with yourselves, needs
to evaluate it. State the purpose of the evaluation and state where the criteria for judging the
success/failure/degree of success of the project will come from. (2)
NOTE: Project evaluation refers to a company checking to see if what has been delivered is what
they actually ordered before paying for it, and for the IT company to check it has delivered a
product that does all the things it said it would. Don't confuse this with an IT company
evaluating its own performance in getting a job done, so it can learn lessons for future projects.
They may well do this but it isn't what the evaluation here is referring to.
23. The project has finished, although, as you know, all software has a limited life span. Explain
the meaning of the term 'software maintenance' and suggest 3 situations that might trigger some
software maintenance. (4)