Edited By. P.

Materu Jaffery Academy 2012 Page 1

SYSTEMS LIFE CYCLE (SLC)
The SLC consists of the following
stages:
1. Definition
2. Investigation and analysis
3. Design
4. Implementation
5. Testing
6. Installation
7. Documentation
8. Evaluation
9. Maintenance
Although all projects should start
with the definition stage and end with
the maintenance stage, the process is
not always completely linear. After
completion of one stage, it might be necessary to return to an earlier stage.
5. Definition
The very first part of the SLC is to define
the problem.
The system analyst must determine why a
new system is required.
After all, if there isn't a problem to start
with, why would an organisation incur
huge costs to develop a new one?
In the definition stage the role of the
analyst is to scope out the problem.
The analyst has a number of methods
available to do this:-
Interviews with management to get
their viewpoint
Interviews with staff to understand the limitations of the current system
Other methods that will be discussed later in this mini-web

Edited By. P. Materu Jaffery Academy 2012 Page 2

6. Feasibility Study - constraints
Once the system analyst is convinced that there is a problem which could be solved with a new
IT system they have to determine whether it is feasible to actually go ahead and develop the
system.
Some of the questions that will need to be answered are:
Cost How much would the new system cost to develop?
Budget Would there be enough money available in the budget to develop the
system?
Time How long would it take to make the system from start to finish?
Skills Does the company have the skills in-house or would it need to go to a
specialist software development firm?
Hardware to
develop
Does the company have the necessary hardware to develop the system?
Hardware to run Would new hardware be needed to run the system and if so how much
would that cost?
Software Does the company have the necessary software to develop the system?
Training What would the training implications be once the system had been
developed?
Technical
feasibility
After finding out what is required is it technically possible to create the
system
7. Feasibility Study - alternative solutions
The system analysis will consider all of the answers from the feasibility study and come up with
a number of alternative solutions to present to management.
It is then the management's job to consider going ahead with the new project.
Some possible solutions that might be suggested to management could be:

a) Company does not change anything
Benefit No disruption to the business.
Cost No cost.
Performance No change, system remains outdated. Process becomes increasingly less
efficient.


Edited By. P. Materu Jaffery Academy 2012 Page 3

b) Company makes alterations to half the system
Benefit Best parts of the system are retained whilst the least efficient aspects are
redesigned to enhance performance.
Cost Moderate, training moderate.
Performance Performance improvement: 30%
c) Complete overhaul
Benefit Reduces company cost base (more profitable).
Cost High, given that new equipment / software will be required. Training for
staff needed.
Performance 70% improvement over the old system.
As you can see, deciding on the best alternative is often not simple - management have to take
many factors into account. There are often complicated relationships between cost, performance
and benefit.
So at this point of the system life cycle, you know what the problem is and you are considering
options.
The various options are usually presented to management at this stage and it is up to them to
make a decision as to how much investment they wish to put into the project.
If the decision is made that it is worth developing a new system, the SLC will progress onto the
next stage, Investigation and Analysis. If management decides to stick with the current system,
the SLC will stop here.
8. Investigation and Analysis: investigating the system
In order to reach this stage in the SLC, management would have listened to the alternative
solutions presented by the system analyst and have decided to either commission a brand new IT
system or have changes made to their current system.
During the earlier 'definition' phase the analysis looked superficially at the current system and
the potential benefits of a new system.
During this 'investigation and analysis' phase they will carry out very detailed investigations in
order to fully understand the current system and the proposed new system.


The current system
Edited By. P. Materu Jaffery Academy 2012 Page 4

how staff / customers interact with the current system i.e. how tasks are carried out
how other systems interact with the current system
what is good about the current system
what causes problems with the current system
which parts of the system are critical to the business
The proposed new system
what the new system is expected to be able to do
how the new system is expected to do this
what people want from the new system
which working methods from the old system should be incorporated into the new system
9. Investigation and Analysis: investigation methods
In order to find the answers to the points on made on the previous page the system analyst will
do some or all of the following:
Face-to-face
Interviews
The analyst will interview selected staff who use the current system
in order to get a detailed overview of how things work.
They will want to know what the main problems are and whether
users have any suggestions on how to improve the way things work.
Observation The analyst will observe users actually using the system. They will
probably follow a complete process from start to finish and note
down every interaction that happens
Questionnaires Questionnaires enable the analyst to obtain the views of a large
number of staff/ users. Questionnaires are also easier to analyse than
face-to-face interviews but the trade-off is that they don't give as
much detail.

Examination of
business
documents
Most organisations have business documents and written processes/
procedures relating to the current IT system. These documents detail
how the system works and the processes which users should follow.
The analyst will examine these documents in detail.
Paper trail Following information from the point it enters the system and
observing what outputs are created at each point in the system.



Edited By. P. Materu Jaffery Academy 2012 Page 5

10. Investigation and Analysis: documentation
All of the information obtained through interviews, questionnaires, observations and paper trails
is carefully examined and analysed to determine the requirements for the new IT system.
The findings are translated into a set of specific diagrams which represent how the system will
work and the processes required.
The main diagrams are:
System
diagrams
These show the relationships between the various systems in the company
(or even outside if relevant) - how they interact, what depends on what
and so on.
Data Flow
Diagrams
Most systems deal with information in one way or another. What really
matters is how the information flows through the system. How does it
branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.
Process
diagrams
People handle information in a specific way - they have a 'process'. For
example, an employee makes an expense claim. First of all their manager
counter-signs the claim. It then goes to the account manager who
authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who
and when (and why).
Edited By. P. Materu Jaffery Academy 2012 Page 6


Once the diagrams have been completed,
two key documents/ reports are produced:
1. A full written analysis of the current
system, the processes and the problem it
causes
2. Detailed user requirements for the new
system

These documents will be used by the system developers and so must be clearly written,
broken down into relevant stages and contain all of the necessary details for them to create
the new system.
11. User requirements document
The 'User Requirements Document' does not define the hardware or software design but rather
seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:
An introduction....
"The project has been developed in order to create a new invoicing system to replace the AIX400
computer system..."
The introduction gives a broad description of the project and its aspirations.

Context....
"The project was developed in light of the up-coming new regulations and also the increasing
awareness that the existing system could no longer meet customer expectations ...."
This section provides the background to the project.
Specific details required
Having provided a broad description and some context to the project this section deals with
specific things that need to be included in the system.
Edited By. P. Materu Jaffery Academy 2012 Page 7

Examples:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.

Notice that these specific requirements are all measurable.
The document should NOT contain vague statements such as "The computer will run as fast as
possible..." because you cannot know if 'as fast as possible' has been met when the system finally
gets switched on.
The Requirements Specification is the 'contract' between project managers and the client. It will
be used at the testing stage to confirm that the system performs as the client expects.
12. Role of the user
The key point of the System Life Cycle Process is that it is the people who are actually going to
use the system who get a say in how it going to work.
They are called the 'user'.
This does sound like common sense but an amazing number of projects are carried out without
any regard to what the user actually wants - assumptions are made. And this is one of the key
reasons why a project fails.
This is the purpose of the 'User Requirement' document. The document tries to:
1. Eliminate misunderstandings
2. Reduce errors
3. Gain user agreement
The way it works is that the system analyst tries to understand what the user needs of the system.
The analyst then sets this out in a non-technical user requirement document. He may use a
number of diagrams and charts within the document to explain his understanding of their needs.
Users are then invited to comment on the document and provide feedback to improve upon it.
There may be several iterations of the User Requirements Document as users further explain to
the analyst what they need. Getting it right the first time is a rare thing!
This process continues until the user agrees that the system will do the job.
Edited By. P. Materu Jaffery Academy 2012 Page 8

This is called the 'sign-off'. It is saying that the user buys into the project, that they are confident
that the project will do the job.
Complications
This sounds simple, so why do project fail so often? In terms of the user it may be because

1. They are not the right user! For instance if it is a system that the public need to use then have
all the types of customers been included? Is it too complicated for some people or too long-
winded for others?
2. User requirement change within the lifetime of the project. This is a major problem as large
projects have a habit of becoming more and more complicated as people want it to do more and
more things. Sometimes this is called 'mission creep'.

13. Design phase
This is the next stage in the SLC and it follows on from the Investigation and Analysis stage.
Now that the project manager and the client have agreed on the requirements (Requirements
Specification) it is time to define how the project is going to be carried out.
This is the Design phase of the project. It is about planning the project in detail so that that
system will meet user requirements.
The following are tasks that must take place during this phase:
Edited By. P. Materu Jaffery Academy 2012 Page 9

Project planning
Project planning is all about
handling people: how many, where
and when are they needed. In
addition those people will need
resources to carry out their jobs:
computers, offices etc. There are a
number of different project planning
tools which will be used during this
stage in order to effectively plan out
the project, timescale and the
resources required. These include:
Gantt Charts
Critical Path Analysis (CPA)
Project Management
Software


System
requirements
specification
This document will include the following information:
Data capture methods for the system
Data inputs to the system
Data outputs from the system
Data processing within the system
The file structure for date storage
The user interface i.e. screen layouts, buttons, error messages
How information is accessed and indexed or sorted.

The operating system to be used

The hardware to be used to run the new system


Edited By. P. Materu Jaffery Academy 2012 Page 10

Data Dictionary A Data dictionary defines the:
tables, fields, records and relationships
constants, variables and data structures
validation that is required in the system
query structures

Testing
documentation
Once the user requirements document and the system requirements
specification have been written the analyst will know exactly what the
system should be able to do.
A test plan is written at this stage to test the key parts of the system
once it has been developed.

Prototyping A 'prototype' is something that represents what you will finally create
without having to worry about all the details - it captures the essential
details to confirm that the design is likely to work.
In software the prototype is often written in a kind of shorthand
English called pseudo-code, for instance 'Read in the record'.
The details do not matter at this stage but a record must be 'read in'.
14. Implementation (development)
Once the design stage has been completed the software developers can begin to write the code
and actually develop the new system.
The system could either be completely bespoke with every line of code being written by
specialist programmers or it could be developed from an 'off-the-shelf' application which is then
customised.
The developers will follow the system requirement specification exactly, if it states to put a
button 500 px by 100 px, colour #ffefdf in the top left hand corner that is exactly what they will
do.
They should not deviate from the specification in any way without consulting the analyst.
Edited By. P. Materu Jaffery Academy 2012 Page 11

During this stage some of the following
are developed:
the tables and data structures
validation routines
data capture forms
data input forms
automated processing routines i.e.
macros
queries
the user interface i.e. screen,
buttons, help messages
printing outputs

15. Testing
Once the system has been developed it must be tested to ensure that it is working as expected.
Testing Team
A team of testers will have been chosen to test the system. They are known as beta testers. Their
role is to check that the system does everything exactly as specified in the system and user
specification.
Although this team will check if the system is user friendly that is not their main role. A separate
team is usually appointed made up of front end users to 'user test' the system once it has been
passed by the beta testers.
Test Plan
In an ideal world a test plan will have been written during the design stage. However, sometimes
the test plan gets left until now.
The test plan is a detailed document which a team of testers must follow carefully. It will set out
every single test they are to do on the system, what data
they should enter and what result they should expect to
obtain.
For example one test might look something like this:
Edited By. P. Materu Jaffery Academy 2012 Page 12

Test
no.
Part of
system
What is being tested Test data Expected
result
Actual
result
Pass
/ Fail
23 Customer
input form
Input mask on
postcode to check that
numbers cannot be
entered where letters
should be.
45CV523 Fail - should
not be able to
enter postcode

The first five columns are already completed in the test plan. The final two columns are left
blank for the testers to complete when they do the test on the system.
The testers follow the plan exactly. They enter the data just as it is shown in the plan and then
they record what happened and whether the test passed or failed.
If the test was passed they go onto the next test. If it failed they fill in a form to tell the
developers that they need to look at that part of the system again.
The testers normally take screen shots of every test to provide evidence of what they have done.
These can be referred to by the developers if they cannot replicate the problem. They can also be
used by an audit team at the end of the project to check that the testing was done properly.
This stage may seem to you a bit pedantic - after all why couldn't the developer have run this test
when they were coding the software and then fix it instantly? - Answer: Human Nature!
It is a very bad idea to have the person who codes the software to test it! This is because they
know too much and so will tend to make assumptions about how real users will use their
software.
The best testers are those who know nothing about the system and will do things to the system
the developer never imagined! Just like real users!
16. Testing continued.
Test Selection
It is important to realise that with the best will in the world it is not possible to test every part of
the system.
Consider a system having 8 data inputs that can applied in any combination. The maths says that
there are over 16 million possible combinations of just 8 inputs!
So the skill of the testing team is to carefully select a practical number of tests that can be
carried out in the time available and yet be confident that the system is working.
This is why complicated software often has bugs even after being released. It is simply not
practical to test everything.
Edited By. P. Materu Jaffery Academy 2012 Page 13

Test Data
It is important that any testing which checks the validation routines should include:
Data that is within the normal range and will be accepted
Data that is on the extreme limits of the range but should be accepted e.g. if the validation says
that price <=100 then 100 should be tested as that is right at the outer limit.
Data that should fail (erroneous data) should be tested. For the test mentioned previously, the test
might be: enter 100.01
Iteration or Looping Around.
If an issue is found it may actually be a problem with the user requirement itself. It is quite
common for the user requirement to not consider an unexpected situation.
For instance, the document might state that the system is to be used by 10 people at the same
time. But by the time testing is underway something changes in the company and now the system
needs to deal with 20 people instead.
In which case the client has to agree to change the user requirement document.
Then testing continues with the modified user requirement document.
Changing user requirements part way through a project causes delays and extra cost. It is often
the most common reason a project fails especially on large projects.
Testing is usually an 'iterative' process.
17. Installation Stage: Methods
The system has been developed and tested. It is
working correctly and doing everything that was
agreed during the design stage. The business is
waiting in eager anticipation for the new system to be
handed over to them.
A key decision is which method of the four different
methods of installation will be chosen. These are:
1. Direct
2. Parallel
3. Phased
4. Pilot

Edited By. P. Materu Jaffery Academy 2012 Page 14

Direct method
This is where the company literally switches off the old system and switches on the new one.
This is probably the most straightforward method but is also probably the riskiest
Advantages Disadvantages
New system available to
everyone in company
immediately
Most risky method - if something goes wrong, there is
nothing to fall back on. Have to wait while the problem
is fixed.
Often the cheapest method
of installation
Have to transfer all of the data to the new one before
the old one can be switched off
Don't need to keep duplicate
sets of data
There will be a period of time where no system is
available because can't have old one working while
new one is being switched on
There will be a period of upheaval while the system is
brand new and staff are finding their way around it
Parallel method
This is a more popular method than the previous one. With a parallel changeover the
organisation runs both the old and new system in parallel for a time. Once the organisation is
sure that the new system is working properly and that staff are ready to begin using it they will
make the decision to completely change over. During a quiet period, perhaps during the night or
at a weekend, the data is fully transferred from the old system which is then shut down.
Advantages Disadvantages
Less risky than the direct method. If the new
system fails, the old system is still up-to-date
Time consuming as data has to be
entered onto both systems
Less stress for staff as they still have the
security of the old system
One system can become out of
synch. with the other.
Staff can take their time to learn to use the new
system
Maintaining duplicate sets of data
can lead to errors
Extra cost of running and
maintaining two systems
18. Installation Stage: Methods Cont.
Phased method
This is where the old system is still active but parts of the new system or modules are brought
online, for example, perhaps just the data entry screens and the printing modules are made
available but the 'back end' of the system remains the same. Once any problems are ironed out
with the new modules then extra modules will be introduced. Effectively the installation happens
in small chunks.

Edited By. P. Materu Jaffery Academy 2012 Page 15

Phased method advantages and disadvantages
Advantages Disadvantages
Less risk of the whole system going
wrong, if something happens, it will
only affect that specific part.
This method of installation can take a long
period of time
Staff are introduced to the changes in
small stages
As parts of the system are used, users ask
for changes which then hold up the
installation of the next phase
It might be difficult to integrate the old and
the new systems
Pilot method
This is where the complete new system is installed and tested in a small number of departments
or branches. They then use the system and report their feedback and any issues to the analyst.
Once the organisation is confident that the system is working as expected, it will be rolled out
across the whole organisation.
Advantages Disadvantages
Only a small part of the business is
affected. The rest of the business
continues using the old system for
now
Even though it is only introduced to a small
number of departments, those chosen will have
the same disadvantages experienced as for a
'direct changeover'
Any problems or issues are
identified without it affecting the
whole company
Those staff using the new system might not be
able to easily share data with the rest of the
company who are still on the old system
When the rollout happens, staff
from the pilot departments can be
involved in training other staff
Extra work for IT staff who are having to
support two different systems
19. Installation Stage: Training
Staff training is part of the installation phase.
Staff need to be shown how to use the new system and how to access help should they run into
difficulties. There may be member of the development team on call for a short period of time or
there may be a dedicated help line that staff can ring to get answers.
There should also be documentation such as a user manual and on-screen documentation
provided to act as a source of reference.


Edited By. P. Materu Jaffery Academy 2012 Page 16

20. Installation Stage: User Documentation
The development of the user documentation is left until after the testing phase is complete. If it is
created beforehand, parts of the system could change
as a result of faults being discovered.
User documentation is provided to the user which
gives an overview of how to use the system.
Paper based user documents are usually in the form
of a booklet or file.
The typical format of a paper-based user document
includes
Table of contents
Short introduction or overview of the system
Brief technical details such as the hardware
and software requirements to run the system
User Guide : this is the bulk of the document
Glossary of technical terms
Troubleshooting: usually a simple list of things to check before calling for further help
Index
User documentation is often used during staff training sessions in order to familiarise the staff
with both the system and the user documents.
21. Installation Stage: On-Screen Documentation
As well as paper-based user documentation, many systems now also have on-screen
documentation.
On-screen documentation can take the form of:
A help menu
Web pages
Popup help boxes
PDF documents
FAQ section
Video tutorials
Many help systems have a search facility to answer those 'How do I ....' type of questions the
user may have. Another popular format is the 'FAQ' or Frequently Asked Questions document.

Edited By. P. Materu Jaffery Academy 2012 Page 17

Typical features of the help system include:
Text search facility
Hyperlinks and navigation buttons to move around the help documentation
Buttons with relevant text
Worked examples of how to use a feature
Links to related features
Multimedia help in the form of video tutorials or spoken word
'Tool tips' which appear when you hover over a word or sentence
Pop-up instructions when you press a certain function key
The online version has the advantage that it can be easily updated with the latest information
compared to a published paper based system.
22. Installation Stage: Technical Documentation
This is intended for technical maintenance of the system. Engineers and software developers will
refer to the technical documentation in order to make changes to the system after it has been
installed.
Technical documentation is created from the very first stages of the development phase as the
original project team set down the details as they build the system.
Typical content of technical documentation includes
Source code with copious commentary explaining how that part of the code works
Data structures used within the system
File formats used
File naming convention
Validation ranges for data input
Macro scripts, including comments to explain each stage of the macro
Internal details of a database such as tables, relationships, records, queries used
Navigation layout such as a site map or link map of the system
Other technical details to help with maintenance include
Test logs and test results
Security details of the system
How to install the system
How to backup and restore the system


Edited By. P. Materu Jaffery Academy 2012 Page 18

23. Evaluation
The installation stage is over: The system is up and running. Staff are fully trained and bugs have
been ironed out.
This next stage is called the 'Evaluation phase'. The evaluation stage looks at the overall project
and considers how things went.
Evaluation involves all the key players in the
project. These include
Original client
Project manager
System Analyst
Designers
Developers
Testers
Support staff such as trainers
A selection of end-users
Each person role has a part to play in the
evaluation.

During the evaluation stage, two key questions are considered:
1. Does the finished solution meet its requirements?
2. Does it solve the problem?
The key document that drives the evaluation is the User Requirements Document. Perhaps not
every detail will be covered, but certainly failures and particular successes should be discussed.
Further to those two questions, the evaluation considers
Lessons learnt from the problems encountered so the next project will be even smoother
and successful
Any maintenance and support needed in the day-to-day running of the system
24. Maintenance
This phase continues for the lifetime of the system. The
technical documentation is essential to support the
maintenance stage.
Edited By. P. Materu Jaffery Academy 2012 Page 19

There are three kinds of maintenance needed:
1. Corrective maintenance
2. Adaptive maintenance
3. Perfective maintenance
Corrective maintenance
This is where problems are identified with the system after installation. Perhaps an item on the
template isn't printing out correctly or maybe one of the on-screen buttons isn't linking to the
correct form.
A fault report is raised and the developers fix the problem. It is then passed over to a team of
testers who check that the fault has been fixed. Once it has been passed by the testers, the fix will
be released to the live system.
Corrective maintenance can also involve fixing hardware faults or replacing equipment as
necessary.

Adaptive maintenance
This type of maintenance often occurs as a result of external influences or strategic changes
within the company. For example, the Government recently changed the VAT rate from 17.5%
to 20%. This change would have meant that many organisations had to make alterations to their
systems. Perhaps a bank decides to offer a new mortgage product. This will have to be included
in the system so that mortgage interest and payments can be calculated.
Perfective maintenance
The system has been in place and running fine for a while. However, over time, the end user will
often find tweaks or minor improvements which could be made to improve the way the system
works. Perhaps a slightly different screen or data input form. These tweaks are not major enough
to prompt a complete new system, so the maintenance team adapt the system to suit.

It is important to be aware that while the system remains in use the maintenance stage will be
ongoing.