Introduction

The concept of a system emerged from early psychologists who believed that the mind was a
whole unit, rather than a collection of psychological parts as the belief was by that time.
However, it was Ludwig von Bertalanff, a German biologist, who gave the name “general
systems theory” to the discipline that devoted itself to coming up with principles that apply to
all systems.
A system is a set of organised components which interact in a given environment and within
a specified boundary to achieve collective goals and objectives that are emergent. Emergent
characteristics are those that result from interaction of various components and may not exist
in the individual component. Therefore, once the components come together, they become
interrelated and generate new goals and objectives. For example, a bicycle system has all
the components working together to provide motion when ridden. The individual components
cannot provide these services to a rider when on their own!

Description of a system
A system can be described as being either soft or hard.

Soft systems
Human activity systems are said to be soft systems. They are described as soft because of
three main reasons:
1. Their boundaries may be fluid or keep on changing.
2. Their goals and objectives usually conflict and may not be captured clearly at anyone time
because they are based on human factors like attitudes and preferences.
3. It is difficult to precisely define exact measures of performance for them.
One example of a soft system is the political system. It is very difficult for instance to model a
system that will predict the political mood in a country over a period of time. Another example
is a sales tracking and prediction system in an organisation. Sales in an organisation depend
on human factors like attitude in the market place.
Hard systems
Hard systems are systems whose goals and objectives are clearly defined and the outcomes
from the systems processes are predictable and can be modeled accurately. Such systems
are based on proven scientific laws like mathematical formulas or engineering solutions.
An example of a hard system would be a stock management system in a supermarket. It is
possible to know exactly the stock levels, cost and sale price and to predict accurately the
profit if all the stock is sold.
A good system incorporates both hard and soft aspects of a system. For example, a stock
management system should be able to show when the demand for a certain item rises so
that a decision can be made to stock more. New demand is driven by soft aspects in people’s
lives like attitude and seasons!
Characteristics of systems
All systems have some common characteristics. Some of these characteristics are explained
below.
Holistic thinking
In holistic thinking a system is considered as a whole. Aristotle, a Greek philosopher, once
said that the whole is more than the sum of the parts. The various components that make up
a system may be simple in nature and process but their combination creates a complex
whole, whose overall goals are more sophisticated than those of the individual components.
Hence, a system should be considered as a whole unit rather than considering its parts
individually.

Subsystems
A system is made up of different components (subsystems). Therefore a system does not
exist in solitude but it may be a component of larger a system. For example, the classroom
system is part of a school system, which is part of the Ministry of Education. The Ministry of
education is part of the Government which is part of the global system!
Boundary and environment
Each system has a space (boundary) within which the components operate. Any entity that
falls outside the boundary but interacts with the system is part of the system environment.
Such entities are called external entities. They provide the inputs and receive the outputs
from the system. For example, the external entities to a school system may include the
parents, various suppliers and the society at large.
Purpose
The purpose of each system is to perform a particular task or achieve a goal. The objectives
that a system is supposed to achieve enable system developers to measure the performance
of a system during its operation. One main objective for a school system for instance is to
enable the students to excel in national examinations.
Process
A system usually will transform or process data from one state to another.
System entropy
The word entropy means decay. Systems “decay” naturally over time. This means that a
system slowly becomes useless to the user either due to improvement in technology, new
management
policies or change in user requirements. Therefore a system must be reviewed in order to
improve it or to develop a new one.
Inputs and outputs
A system communicates with its environment by receiving inputs and giving outputs. For
example, a manufacturing firm can be considered as a system that gets raw materials
(inputs) from the environment and transforms them into finished products (outputs) released
into the environment.
Open and closed systems
A system can be described as being open or closed. An open system receives input from and
gives output to the environment while a closed system does not. Open systems normally
adapt to changes in the environment.
Control
Control can be defined as the method by which a system adapts to changes in the
environment in order to give the expected output or to perform to the expected level. Control
is achieved through feedback which involves having outputs from the process of the system
being fed back to the control mechanism. The control mechanism in turn adjusts control
signals that are fed to the process which in turn makes sure that the output meets the set
expectations. Fig. 4.1 depicts a typical system that has feedback to the control function.
Imagine a motor vehicle manufacturing company that is producing several vehicles per day.
Assuming that the demand rises, then feedback would show that the company is
underperforming. Hence, control signals that would speed up movement of units on the
assembly line can be issued to increase production.

Information system
An information system is an arrangement of people, data processes and information that
work together to support and improve the day-to-day operations in a business and the
decision making process. The main purposes of an information system in an organisation
are:
1. Supporting information processing by enhancing tasks such as data collection, processing
and communication.
2. Helping in decision making by collecting operational data, analyzing it and generating
reports that can be used to support the decision making process. This process is referred
to as on-line analytical processing.
3. Enable sharing of information. Perhaps, this is one of the greatest powers of information
systems. For example, any departments in a given organisation can now share the same
electronic information stored in a central database at the click of a mouse button.

Why develop new information systems?

The need for developing information systems is brought about by three circumstances:
1. New opportunities: A chance to improve quality of internal processes and service delivery
in the organisation.
2. Problems: These are undesirable circumstances that prevent the organisation from
meeting its goals.
3. Directives: These are new requirements imposed by the government, management or
external influences.
Role of information system analyst
A system analyst is a person who is responsible for identifying an organisation’s needs and
problems then designs and develops an information system to solve them. The system
analyst does this by:
1. Reviewing the existing system and making recommendations on how to improve or
implement an alternative system.
2. Working hand in hand with programmers to construct a computerized system.
3. Coordinating training of the new system users and owners. P
Project management
The system analyst is the overall project manager of the information system being
implemented. His project management skills like assuring quality, keeping within schedule
and budget determine whether the system will be successfully implemented or not. For
example, a project that does not stick to its schedule will most likely overshoot its budgeted
cost leading to unsuccessful completion.

Theories of system development

Several theories or methods are used in system development. The aim of all these theories
and methods is to identify business requirements and to develop information systems that
effectively meet them. This helps to support the day to day operations and decision making
processes in an organisation.
Some of the most common system development theories include:
1. Traditional approach.
2. Rapid application development (RAD).
3. The structured approach.
At this level, we will concern ourselves mostly with the structured approach. However, we
shall briefly discuss the other two methods of system development.

Traditional approach
Traditional approach relies mostly on the skills and experience of individual staff members
carrying out the project. This means that there is no formal documented methodology to be
followed by all system developers in the organisation. This obviously presents a chaotic
scene in system development especially where more than one persons are involved in the
development effort. In most cases, success depends on the heroic efforts of an individual.
This means that all other projects heavily rely on a particular person for their success.
In this approach, the manual system is replaced with a computerised one without change in
overall structure of the former system. Hence the weaknesses of the former system are not
addressed and are carried forward to the new system. For example, in a banking hall, a
manual system is characterised by long queues and poor controls. If the traditional approach
is followed, each cashier will simply be given a computer. The long queues might remain and
lack of controls increase because no value was added to the former information system. This
method is not recommended for today’s business environment.
Rapid application development (RAD)
Rapid application development (RAD) model evolved from the theory that businesses today
heavily rely on information technology. Many information’ systems that were manual in nature
are now fully computerised. Therefore, development and implementation of information
systems needs to be quick enough for the organisation to maintain a competitive advantage
in the market place.
Recent developments in programming software have seen the release of fourth generation
languages (4GL’s) which are user-friendly because of their graphical interfaces. Rapid
application development makes it possible for system developers to quickly capture user
requirements by designing system interfaces in the presence of the user. This rapid
application development technique is known as prototyping, and assumes that the user
knows what they want when they see it. A prototype is a smaller working model of a real
world system. Other approaches used in rapid application development include small team
with advanced tools (SWAT) and joint application development (JAD).
The main disadvantage of rapid application development is that the working system may
have oversights and weaknesses due to the quick Development. For example, a system may
be working well but lack the necessary inbuilt security mechanisms. This would be
undesirable in today’s insecure operating environment.
The structured approach
Structured approach to system development defines a set of stages that should be followed
when developing a system. Each stage is well documented and specifies the activities to be
carried out by the system analyst and his team while developing a system.
Stages of system development
The main stages in system 4evelopment as depicted by the structured approach include:
1. Problem recognition and definition.
2. Information gathering.
3. Requirements specification.
4. System design.
5. System construction (coding).
6. System implementation.
7. System review and maintenance.
Figure 4.2 is a diagrammatic representation of the seven stages of the system development
lifecycle (SDLC).
The stages of developing a system are also called the system development lifecycle. Each
stage serves a role in the problem solving process. The lifecycle divides the life of an
information system into two major parts namely:
1. The development stage.
2. The operation and support stage.
To demonstrate how to undertake each stage, we shall consider a case study.

Case study
Computer-based library management system
Mutito high school library has 3000 text books. Each book is identified by its author, ISBN
number, book ID and title. The books are arranged on the shelves using their book ID. Card
catalogues are maintained for all the books. There are two types of catalogues, one arranged
according to the author’s names while the other is arranged according to the titles of the
books. Each member is issued with three borrower cards that have a registration number and
name of the member. To locate a book for borrowing, a member checks in the card catalogue
for its classification then moves to the shelve to retrieve it. The member surrenders a
borrower’s card .at the issue counter where the staff gives out the book and stamps the date
of return. A member is not allowed to borrow more than three books at anyone time.
Members are charged for overdue books at a fixed rate multiplied by the number of days
delayed.
We now look at each of the stages of system development in more detail with this case study
in mind.
Problem recognition and definition
Problem recognition is done during the preliminary investigation. During the recognition
phase, the system analyst seeks to answer two questions. The first is whether the proposed
project is worth looking at while the second is if the project is worth pursuing. After this, the
system analyst has to define the scope of the project and establish the constraints, budget
and schedule. The most common constraints are usually lack of finance, lack of enough
expertise and/or lack of appropriate technology to develop the system.
Problem definition, also called problem analysis is the process of identifying the problem,
understanding the problem and finding out any constraints that may limit the solution. This
stage requires the analyst to find out as much as possible about the current system in order
to draw up a good and relevant proposal for the new system. Remember that there is always
an existing system whether manual or computerised. After this, several alternative solutions
are modeled.
The main question asked at this point is whether the proposed solution is the right one.
Looking at our case of the school library management system, the problem at hand is to
replace the inefficient manual operations such as cataloguing with an efficient computerised
system. The system analyst tries to answer the following questions.
1. What are the shortcomings of the current systems?
2. What types of records are used for books and students in the library?
3. What procedure is followed to borrow/lend books?
4. How are overdue books handled when returned?
In this first stage, a special study will be carried out to establish the costs and benefits of a
new system. This study is called a feasibility study. A new system will only be developed if its
benefits are more than its costs. The end of this stage is marked by presentation of a
feasibility report to the management.
The feasibility of a system is assessed in four ways:
Operational feasibility: This establishes the extent to which the users are comfortable or
happy with the proposed or new system.
Schedule feasibility: This establishes whether the development of the proposed system will
be accomplished within the available time.
Technical feasibility: This establishes whether the technology available is sufficient or can be
upgraded for the new system. It also seeks to find out whether the staff has relevant technical
skills to develop and use the new system.
Economic feasibility: This establishes whether developing the new system is cost effective by
analysing all the costs and benefits of the proposed system.

Information gathering
After the feasibility study report has been approved by the management, the system analyst
can then proceed to the next stage referred to as information gathering or fact finding. Some
of the methods used to collect or gather data include:
1. Study of available documents.
2. Automated methods.
Studying available documentation
The available documentation describes the current system and all its procedures. It forms a
rich source of information for the analyst. Examples of such documents are card catalogues,
receipts, reports, technical manuals, organisational charts and archival or backup files.
Interviews
Interviews should be carried with the relevant stakeholders in order to get views about the
current system and gather information about the requirements for the proposed system. The
interview method is powerful because it enables the analyst to have face to face contact with
the interviewee.
Therefore in executing an interview, the following guidelines should be followed:
1. The interviewee must be informed in good time and the topic of discussion communicated
accordingly to allow for adequate preparation.
2. Avoid personal biases in your questions and perspectives.
3. Be careful about body language and Proxemics refers to things like sitting arrangement,
body closeness and how people react when their private distance is violated.
Figure 4.3 shows a verbatim introduction of sample interview with the library manager.
INTERVIEW TITLE
BRIEF INTRODUCTION Interviewer: ……………
Interviewee: … .
Interviewer: Hello…………
Interviewee: Hello. Welcome to my office.
Interviewer: Thank you. Please call me Pat. I would like to ask you a few questions about the
system that we are developing
Interviewee: …………………………………………………
…………………………………………………
…………………………………………………
Fig. 4.3: Example of an interview

Advantages of interviews
1. Non-verbal communication like facial expressions can be used and observed.
2. Questions can be rephrased instantly for clarification and to probe the interviewee further.

Disadvantages of interviews
1. It is difficult to organise interviews and they are time consuming.
2. The interviewee may not fully open up on some issues that may be personal or sensitive.

Questionnaires
A questionnaire is a special purpose document that allows a person to collect information and
opinions from the people who receive and respond to it. The main advantage of using this
method is that the questionnaires give the respondents privacy when filling them and they
can do so at their own pleasure. This may enhance the sincerity of the information given.
Figure 4.4 below shows an extract of a questionnaire used to gather data from library
attendants.
QUESTIONNAIRE
BRIEF INTRODUCTION Date: …,………….
.
………………………………………………………………………
QUESTIONS
1. How long have you worked as a library attendant: 1 yr. over 2 yrs.
2. How long does it take to rearrange books on the shelves?
days weeks months
Fig. 4.4: An example of a questionnaire

Advantages of questionnaires
1. Since they are filled and returned in privacy, more sincere responses are possible.
2. The respondent can fill the questionnaire at their own pace.

Disadvantages of questionnaires
1. Good questionnaires are difficult to prepare.
2. The respondent may not fully understand the questions because of ambiguity of language
hence give erroneous responses.

Observation
Observation requires the observer to participate or watch closely as a person performs
activities in order to learn about the system. This method gives the analyst first hand
experience about the problems and exposes him/her to the system requirements. The main
advantage of observation is that concepts that are too difficult for non-technical staff to
explain can be observed. However, this method has some drawbacks too. These include:
1. The person being observed might alter behaviour leading to wrong equirements being
observed.
2. The need to be on-site consumes a lot of time.

Automated methods
Automated data collection is mostly used when actual data is required but difficult to get
through interviews, observation or questionnaires. Such data may be collected using devices
that automatically capture data from the source such as video cameras, tape recorders etc.

Preparing and presenting the fact finding report

At the end of the information gathering stage, the analyst must come up with a requirements
definition report that has the following details:
1. Cover letter addressed to the management and IT task force written, by the person who
gathered the facts.
2. Title page which includes the name of the project, name of analyst and the date the
proposal is submitted.
3. Table of contents.
4. Executive summary which provides a snapshot of how the new system is to be
implemented. It also includes recommendations of the system analyst because some
people will only have to read the summary to make decisions.
5. Outlines of the system study which provides information about all the methods used in the
study and who and what was studied.
6. Detailed results of the study which provide details of what the system analyst has found out
about the system such as problems, constraints and opportunities that call for an
alternative.
7. Summary which is a brief statement that mirrors the contents of the report? It also stresses
the project’s importance.
This report is then presented to the management for evaluation and further guidance. fig 4.5
shows a sample general outline of the fact finding report presented to the management of the
school library and the head of the I

Library management information system

Fact finding report
1.0 Table of contents.
Executive summary.
Objectives: The new computerised system is intended to improve efficiency in the library
by:
Keeping an inventory of all the books in the library and automatically updating the stock
hence eliminating the tedious physical counting process.
Reducing the time needed to seek for a book by 60%. (c) Tracking overdue and lost
books.
Recommendation:
This system could result in efficient processing of library transactions. It will replace the
tedious manual system.
Methods used to study the system
Interviews: Used when seeking facts from management.
Questionnaires: Circulated to user staff.
Observation: Observed book search and issue.
Detailed results
Problems: Duplication of records, delays and book loss.
Opportunities: Efficiency, stock management etc.
Alternatives: Enforce controls in current system, more staff etc.

5.0 Summary.
The new system is highly recommended because the other alternative of enforcing controls
and employing more staff will add operating costs with little additional value.
Fig. 4.5: A sample outline of a fact finding report
NB: The sample report is simplified for purposes of instruction at this level and should not be
taken as a complete report. A complete report lay comprise of several bound pages.
Requirements specification
Requirement specification, the system analyst must come up with the detailed requirements
for the new system. Remember that in the long run the hardware and software used to
develop the system mainly depends on input, output and file requirements. For example, if
one of the input requirements is that the system would require data in picture format then one
input device that cannot be avoided is an image capturing device such as a digital camera or
a scanner. At this stage the following requirements specifications are considered:
1. Output specification.
2. input specification
3. File/data stores.
4. Hardware and software requirements.

Output specifications
As opposed to data processing cycle where we follow the input-process-output model in
system development, consideration is given to the output requirements of the new system
first. This is because; the main interest from a system is information (output). For example the
management of the library in our case study is interested in whether the system can generate
reports on overdue books, charges on late return, inventory etc.
The quality of system output depends on how well management and user requirements were
identified. The Output is usually in the form of reports either in hardcopy or softcopy form.
The following factors should be put into consideration when designing the output
1. The target audience. For example, top management would require a summary of overall
performance in the organisation while a user report may show only the transactions carried
out or transactions at hand
2. The frequency of report generation. Some reports are required daily, others weekly,
monthly or annually. However, some are required in an ad hoc manner i.e. at random.
3. Quality and format: The quality and format of information to be generated should be put
into consideration.
For our case study outlined earlier, the following outputs are needed from the library
management system:
1. A report about all the overdue books showing charges against each borrower.
2. A search report for a particular book showing its classification and whether its on the
shelve or not.
3. A search report about a particular member showing which books he/she is currently
holding. Table 4.1 below shows a sample report expected to be generated from the
computerised library system showing all the overdue books.
Input specifications
Once the system analyst has identified the information (output) requirement of the new
computerised system, he/she goes ahead to identify the input needed to obtain the relevant
information from the system. In our case of the library, the following inputs can be deduced
from the output specification:
1. The type of data needed to add a book to the books file or database in the library. For
example in the library database the following data items may be entered:
Title of the book.
Names of the author(s) of the books.
The ISBN number of the book.
Book ID
2. Determine data that is needed for someone who wishes to borrow a book.
After identifying all the inputs, the analyst designs the user interface by designing data entry
forms or screens. An example of an input form is the new member registration form as shown
in Figure 4.6.

The user interface is an important determinant of whether the system will be happily
accepted by the users or not. Hence, it must be designed with a lot of care. The following
guidelines should be observed:
1. Objects placed on forms like text boxes, labels and command buttons must be neatly
aligned and balanced on the form.
2. The size of the form must not be too small for user legibility or too big to fit on the screen 3.
The colour for the interface must be chosen carefully to avoid hurting the eye. Avoid
colours that are too bright.

File/data stores
File requirements specification involves making an informed decision on files required to
store data and information in the system. The system analyst should identify the number of
files that will be needed by the system and determine the structure of each of the files. For
example, will the files allow direct access? Will the files be sequential files stored on a
magnetic tape? The attributes of the records in a file should also be identified. An attribute is
a unique characteristic of a record for which a data value can be stored in the system
database. If it is a student, one attribute can be the name and the other is the student’s
registration number. For a book record, the attributes that can be identified include: Book ID,
international serial book number (ISBN), the title, publisher, year of publication, date of issue
and date of return.
However, only those attributes that are of importance to the system will be picked and used
to store data for each record. In our case study for instance, we only need the Book ID, title,
author, ISBN number, date of .issue and return.
These attributes will form the basis for table design in the database. Each attribute will
become a field in the table. For example, there will be a Books table that will have fields for
each record.

Factors to consider when designing a file

In order to design a good file, you need to consider the following aspects:
1. The key attribute or field: This is usually an attribute that is unique for each record.
2. The type of data: Each field has a data type. Book titles can be stored as data of type “text”
while the date of borrowing a book as of the type “date” in the database.
3. The length of each field: This is important because the longer the field, the slower the
system takes to process transactions. A name field can be specified to be 30 characters
long while the integer field can be 10 characters long. However, these vary depending on
the system developer’s perception of how the system should store the data.
4. Back up and recovery strategies: The updated copies of data and information files need to
be stored in a different place other than the location of the current system. This makes sure
that even if the current file gets corrupted or crashes, the backed up data can be used to
recover or reconstruct the original file.

Hardware and software requirements

The system analyst should specify all hardware and software requirements for the new
system.
Some of the factors to consider in hardware and software specification are:
1. Economic factors such as price and acquisition method.
2. Operational factors e.g. reliability, upgradeability and compatibility with the existing
resources.
3. User-friendliness.

System design
There are several tools for designing an information system. Examples of such tools
are flowcharts, data flow diagrams, entity relationship models and structured charts. In this
book, we shall concentrate on the use of the system flowcharts as the primary tool for system
design. A system flowchart is a tool for analysing processes. It allows one to break process
down into individual events or activities and to display these in shorthand form showing the
sequential or logical relationships between them.
After drawing the system flowchart, other algorithm design tools like pseudo codes and
program flowcharts can be used to extract the processing logic for each module in the
system before system construction.

The system flowchart has many similarities to the program flowchart covered earlier in the
book. However, it has its own set of symbols and it seeks to depict the whole system rather
than the individual program modules. Figure 4.8 shows some common system flowchart
symbols.
Other symbols that are of great importance at this level are as follows:
Rectangle with rounded corners: represents an event which occurs automatically and usually
triggers a chain of other events. For example, the book lending process is triggered by a
student request!
Kite: represents the sort operation.
Designing a system flowchart
Designing system flowcharts gives a concise picture of the way particular processes are done
within the business organisation. After this has been achieved, the next logical step of making
changes to the processes for the better can be handled easily.
Although there is no formal approach for designing a system flowchart, the following
guidelines are important:
1. Start by writing the title of the flowchart. For our case study, the title “Library Books
Management Information System” could be sufficient.
2. If possible, start drawing the flowchart with the trigger event. In this case, our trigger would
be a student request to borrow a book or to return an overdue book.
3. Note down the successive actions taken in their logical order until the event or process is
concluded. Use few words to describe the actions.
4. When there are many alternatives at the decision stage, follow the most important and
continue with it. Other significant but less important alternatives can be drawn elsewhere
and reference made to them by using the on/or off page connectors. Figure 4.9 shows the
system flowchart for the proposed computerised library management system for the
school.
Explanation
From the system flowchart, we observe that:
1. A member e.g. a student requests for a particular book.
2. The system checks for the students record in the system. If the student has more than
three books, a message to this effect is displayed and cannot borrow an extra book.
3. If the student has less than three books, then the book can be given out to him/her.
From the system flowchart, a program flowchart for a particular task can be extracted. Figure
4.10 illustrates the book lending process extracted from the library management system
flowchart.

System construction
System construction refers to the coding, installation and testing of the modules and their
components such as outputs, inputs and files.
The purpose of the construction phase is to develop and test a functional system that fulfils
the business and design requirements. Indeed, programmers come in at this stage and are
briefed on the system requirements as illustrated using various design tools in order for them
to construct a computerised working model of the same.
System construction methods
There are a number of programming techniques that can be used to construct a designed
system. These include:
1. Using the high-level structured language such as Pascal, COBOL etc
2. Using fourth generation languages (4GL) – These are easy to use programming
languages. Some of the fourth generation languages are Visual Basic, Visual COBOL,
Delphi Pascal etc.
3. Customising the standard packages – This involves the use of a ready made software
package mostly a database software, financial package or enterprise management system.
Due to the varied approach to system construction available, Chapter 5 in this book
introduces you to Visual Basic programming while Appendix I explains how a database
package can be customised to construct a system. Figure 4.11 shows a data entry form
constructed to enable entering a new book record into the library information database.
Testing the system
After construction, the system is tested by entering some test data to find out whether its
outputs are as expected. The system is tested using the requirements specifications and the
design specifications to find out whether it meets all requirements specified.
For example, if one of the requirements of the computerised library management system is to
ensure that no member is allowed to borrow more than three books at the same time, it must
do that without fail. Figure 4.12 shows a message box to this effect.

System implementation
System implementation is the process of delivering the system for use in day to day
operating environment for the users to start using it. The areas to be addressed during
system implementation include file conversion, staff training, and changeover strategies. File
conversion
Every time a new system is implemented, the format of data files might require modification
or change. This process is referred to as file conversion. A new system may require a change
in file format e.g. from manual to computerised. The factors to consider at this point are:
1. Whether the new system requires a new operating system and hardware. The best practice
today is to develop systems that do not need hardware change unless it is very necessary.
2. Whether you need to install new application software. For example if you have developed a
new system by Customising a database application software, you need to install that
software if it is not installed.
3. Whether you need to create new database files for the new system. For example, where
files are manual, electronic ones will have to be made. However, remember that we strive
to develop systems that are data independent That means that the systems can be
changed without affecting the organisational data structures in the databases.
Staff training
Availability of appropriate documentation like user manuals goes a long way to make staff
training easy, quick and effective. System implementation can fail if the staff are not trained
properly leading to great loss of company resources.
Changeover strategies
Changeover simply means how to move from the old system and start using the new. Most
businesses especially those that are driven by information technology need as smooth a
changeover as possible. Some of the system changeover strategies are:
Straight changeover
In straight changeover, the old system is stopped and discarded and the new system started
immediately. This sudden change of old to new means that the project faces higher risks in
case the new system faces problems. This is because the old system would not be there to
fall back to. The advantage of this method is that it is cheaper because you do not have to
run the two systems in parallel. Figure 4.13 shows the straight changeover strategy
diagramatically. At a time t, a switch is made from the old to new system.
Parallel changeover
In parallel changeover, both the old and new system are run parallel to each other for some
time until users have confidence in the new system then the old system is phased out. This
method is a bit costly because extra resources have to be engaged to run the two systems in
parallel. However, its lower risk to business operations and thorough testing of the new
system are some of its advantages. This method is not suitable for large systems because of
the high operational costs during changeover. Figure 4.14 depicts a parallel changeover
process.
Phased changeover
In phased changeover, a new system is implemented in phases or stages. A good example is
the way the education system is changed from the old to the new curriculum. Each year at
least one class level changes over to the new syllabus.
Sometimes, one phase may run a new system for testing before it is implemented into all the
other phases. This is called piloting. The main”, disadvantage of phased changeover is the
danger of incompatibility between various elements i.e. hardware or software of the same
system. However, its advantage is that it ensures slow but sure changeover.

Security control measures

Information and data security have become some of the most important aspects of
information systems. A lot of careful planning has to be done in order to have what is called
inbuilt security in the system. This is because information is under constant threat of being
illegally accessed or disclosed to unauthorised parties. Therefore, the system implementers
must make sure that the security features built in the system are properly configured during
the implementation stage.
System maintenance and review
System maintenance is the adjustment and enhancement of requirements or correction of
errors after the system has been implemented. Regardless of how well the system is
constructed and tested, errors may be detected when the system is in use.
System review is a formal process of going through the specifications and testing the system
after implementation to find out whether it still meets the original objectives. This act is
sometimes called review and audit. If the system does not meet the stated objectives, system
development might start all over again.
System documentation
System documentation is a life long process in the system development lifecycle. After a
system has been implemented, any maintenance work must be documented in order to
update the existing documentation. In this chapter, we have constantly provided sample
documentation in every stage of system development using the school library management
system case study. Generally comprehensive system documentation consists of the
following:
1. Report on fact finding
2. Requirement specification
3. System and module flowcharts
4. Table/file structures description
5. Sample test data and expected output
6. Output reports
Reports on fact finding
At the end of fact finding stage, the system analyst should prepare a well detailed report that
mainly outlines:
1. The methods used to collect data.
2. Weaknesses of the current system as evidenced by the collected data.
3. Recommendations: Why there is a need to replace or upgrade the current system.
Figure 4.5 on page 104 shows a sample fact finding report for the school library system.
Requirement specification
The report on requirement specification outlines mainly the:
1. Output requirements for the new system such as reports.
2. Input requirements.
3. Hardware and software required to develop the new system.
Table 4.1 on page 106 gives a sample report expected from a computerised library system,
while Figure 4.6 on page 107 gives a simple illustration of an input form for new library
members.
System flowchart
The system flowchart shows the overall functionality of the proposed information system.
Therefore at the end of the designed phase, the system analyst should write a report that
contains: 1. The system flowchart or data flow diagrams that shows the processing logic of
the information system.
Any module flowchart that may help programmers in construction of the required subsystem
or modules. a sample module flowchart.
Table file structures description
Depending on approach used in system construction, the report should contain file or table
structure definitions. For example, if you opt to construct a system using customisation
approach, details on table structures should be well documented (see Appendix I). Figure
4.15 shows a sample table structure of the Books table in a library system.
Sample test data
To test whether the new computerised information system is working as expected, you need
to use test data for every module (subsystem). For example, in our library case study, we
need to test sample data for books entry, book borrowing etc. Table 4.2 shows a sample test
data that can be entered in the database whenever a book is borrowed. Table 4.2

Output reports
To prove that the system is working and giving the desired result, you should provide a
number of sample output from various system modules. Figure 4.16 shows a sample report
showing a list of members who have borrowed books.
User manual
User manuals are supposed to help a person to use the system with as little guidance as
possible.
Therefore, the manual must contain information such as:
1. How to install, start and run the system.
2. How the system appears when running (interface).
3. How to carry out various tasks e.g. in our case study, this would include new books entry,
lending/borrowing, data entry etc.
4. Error correction and how to get help when faced by exceptions. This would be in a
troubleshooting guide.