CSC 223 New Information System Developments - Lecture Notes

The Systems Analyst.

A systems analyst is a person with unique skills who conducts a study, identifies activities and
objectives and determines a procedure to achieve the objectives and uses these skills to
coordinate the efforts of different type of persons in an organization to achieve business goals.
System Analyst can also be described as a computer Professional who study
Business System with the aim to improve on it by replacing faulty parts or to develop a new
System for an organization to achieve its set goals/Objectives

Function of a Systems Analyst

A systems analyst performs the following functions:
1. The first and perhaps most difficult task of systems analyst is problem definition. Business
problems are quite difficult to define. It is also true that problems cannot be solved until they are
precisely and clearly defined.

2. Initially a systems analyst does not know how to solve a specific problem. He must consult
with managers, users and other data processing professionals in defining problems and
developing solutions. He uses various methods for data gathering to get the correct solution of a
problem.

3. Having gathered the data relating to a problem, the systems analyst analyses them and thinks
of plan to solve it. He may not come up personally with the best way of solving a problem but
pulls together other people's ideas and refines them until a workable solution is achieved.

4. Systems analysts coordinate the process of developing solutions. Since many problems have
number of solutions, the systems analyst must evaluate the merit of such proposed solution
before recommending one to the management.

5. Systems analysts are often referred to as planners. A key part of the systems analyst's job is to
develop a plan to meet the management objectives.

6. When the plan has been accepted, systems analyst is responsible for designing it so that
management's goal could be achieved. Systems design is a time consuming, complex and precise
task.

7. Systems must be thoroughly tested. The systems analyst often coordinates the testing
procedures and helps in deciding whether or not the new system is meeting standards established
in the planning phase. The major role of the systems analyst is to communicate with the client,
their manager and the software team. This communication is intensive and the tasks involved
include:
i. Problem recognition
ii. Evaluation of the problem
iii. Production of the specification
iv. Review of the specification with the client.
For the analyst to be able to successful complete his assignment, he must be able to
v. Grasp abstract concept
vi. Absorb essential information from conflicting or confusing sources
vii. Understanding the customer's environment
viii. Derive hardware and software solutions
ix. Communicate well in spoken and written form

Managing Project Review and Selection

It is true that a number of requests for systems development are generated in the organization.
Someone in the organization must decide which requests to pursue and which to reject. The
criteria to accept or reject a request can be decided in a number of ways. One of the suitable
methods commonly in use is by committee.

Mainly three committees' formats are commonly used:

i. Steering Committee
ii. Information Systems Committee
iii. User-Group Committee

1. Steering Committee
This is one of the most common methods of reviewing and selecting projects for development.
Such a committee, consisting of key managers from various departments of the organization as
well as members of information systems group, is responsible for supervising the review project
proposals.
This committee receives requests for proposal and evaluates them. The main responsibility of the
committee is to take decision, which often requires more information than the proposal provides.
It is, therefore, desired to have preliminary investigation to gather more details. The steering
committee approach is generally favoured because systems projects are considered as business
investments. Decisions are made on the basis of the cost of the project, its benefit to the
organization and the feasibility of accomplishing the development within the limits of
information systems technology.

2. Information Systems Committee

In some organizations, the responsibility for reviewing project requests is entrusted to a
committee of managers and analysts in the information systems department. Under this method,
all a requests for service and development are submitted directly to a review commit within the
information systems department. This committee approves or disapproves projects and sets
priorities, indicating which projects are most important and should receive immediate attention.
This method can be used when major equipment decisions are required or when term
development commitments are needed to undertake a project, the decision authority is shared
with senior executives who decide finally whether a project should proceed or not.

3. User-Group Committee
In some organizations, the responsibility for project decisions is entrusted to the users
themselves. Individual department hire own analyst and designers who handle project selection
and carry out development. Although the practice of having user committees both choose and
development systems does take some of the burden from the systems development group, it can
have disadvantages for the users.
Some user groups may find themselves with defective or poorly designed systems that require
additional time and effort to undo any damage caused by the misinformation that such systems
could generate. Although user groups may find the decisions of steering committees and
information systems committees disappointing at times, the success rate for users who undertake
development job is not very encouraging.

Systems Development Strategies

Having known what systems analysis and design is, one would then wonder about the approach
to implement the study. There are a number of methodologies available for software
development.
We shall concentrate on Systems Development Life Cycle Method (SDLC) methodologies for
software development.
It must be stated that some of the approaches for software development can be used together. For
examples, available structured tools may be employed during the analysis and design stage of
system development life cycle.

System Development Life Cycle

System Development Life Cycle (SDLC)
The Systems Development Life Cycle (SDLC) method could be thought of as the set of activities
that analysts, designers, and users carry out to develop and implement an information system. It
is called a cycle because at any of the stages involved, one might return back (for one reason or
the other) to an earlier stage.

The cycle starts when the management or systems development personnel realize that a
particular business needs improvement and invites the system analyst to undertake the project.
Meanwhile there are different proposed models of (SDLC) all talking of the same thing.

A typical one consists of the following activities.

1. System Investigation/feasibility study
2. System Analysis
3. Systems Design
4. System Development
5. System Implementation
6. System Evaluation and maintenance

1. System Investigation /feasibility study

For systems development to occur there must be a request. The request could be made by a
manager, an employee, or a system specialist. A request usually arises from the perceived need
of the organization on the improvement of their operation in one way or the other. When this
activity could be divided into three parts, namely request clarification, feasibility study, and
request approval.

A. Request Clarification:
In most cases, many requests from employees and users are not clearly stated. Therefore, before
any systems investigations can be considered, the project must be examined to determine
precisely what the originator wants. This is to say, request clarification means understanding the
problem. The analyst needs to clarify the information therefore makes necessary contact with the
client in other to understand the scope of the project.

B. Feasibility Study:
The purpose of a feasibility study is to investigate the project in sufficient depth to be able to
provide information which either justifies the development of the new system or shows why the
project should not continue. The analyst wants to justify the feasibility of the project vis-à-vis
certain determining factors. This study is usually carried out by a small group of people
(sometimes two or three) who are familiar with the project (i.e. information system techniques,
understand the part of the business or organization that will be involved or affected) and are
experienced in the system analysis and design process.

Feasibility study is usually carried out for the purpose of re-appraising a system so as to
determining whether to retain, discard or improve the entire system or some of its components.
Where a new system is envisaged, feasibility study can be considered as the first stage of the
system development cycle or the computerization process. It can be stated that the process of
observing designing and implementing a system is the same as system development cycle. In
data processing environment, feasibility study is a management sponsored study that concludes
whether or not the use of electronic data processing equipment is feasible at the time of
investigation to warrant continuation of the system development process and whether a detailed
study should be done in depth in any particular area.

The purpose of feasibility study is to assemble information needed to provide understanding of

the system and show how men, materials, information users, use resources such as building,
machines, files to produce outputs and result.
This study which precedes detailed investigation and analysis in system development phase is
very important and is most-often glossed over.

Types of Feasibility
An important outcome of the preliminary investigation is the determination that the system
requested is feasible or not.

In the conduct of the feasibility study, the analyst will usually considered six distinct, but inter-
related types of feasibility. They are:
i. Technical feasibility
ii. Operational feasibility
iii. Economic feasibility
iv. Social feasibility
v. Legal feasibility
vi. Time feasibility

i. Technical Feasibility
Out of all types of feasibility, technical feasibility generally is the most difficult to determine.
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may vary considerably, but might include:
(i) The facility to produce outputs in a given time.
(ii) Response time under certain conditions.
(iii) Ability to process a certain volume of transaction at a particular speed.
(iv) Facility to communicate data to distant location.

ii. Operational Feasibility

It is mainly related to human organizational and political aspects. The points to be considered
are:
(i) what changes will be brought with the system?
(ii) what organizational structures are disturbed?
(iii) What new skills will be required?
Do the existing staff members have these skills? If not, can they be trained in due course of time?
Generally project will not be rejected simply because of operational feasibility but such
considerations are likely to critically affect the nature and scope of the eventual
recommendations. This feasibility study is carried out by a small group of people who are
familiar with information system techniques, who understand the parts of the business that are
relevant to the project and are skilled in system analysis and design process.
iii. Economic Feasibility
Economic analysis is the most frequently used techniques for evaluating the effectiveness of a
proposed system. More commonly known as cost/benefit analysis; the procedure is to determine
the benefits and savings that are expected from a proposed system and compare them with costs.
If benefits outweigh costs, a decision taken to design and implement the system. Otherwise,
further justification or alternative in the proposed system will have to be made if it is to have a
chance of being approved. This is an ongoing effort that improves in accuracy at each phase of
the system life cycle.

iv. Social Feasibility

This determination typically examines the probability of the project being accepted by the group
directly affected by the proposed system change.

v. Legal Feasibility
Legal feasibility is a determination of whether a proposed project infringes on known Acts,
Statutes, as well as any pending legislation or incurs liability
Although in some instances the project might appear sound, on closer investigation it may be
found to infringe on several legal areas.

vi. Time Feasibility

Time feasibility is a determination of whether a proposed project can be implemented fully
within a stipulated time frame. If a project takes too much time it is likely to be rejected.

C. Request Approval:
Based on the report of the feasibility study presented to management, would then decide whether
the request is both desirable and feasible before approving such a request. In most cases, not all
requested projects are desirable or feasible. Some organizations receive so many project requests
from employees that only a few of them can be pursued. However, those projects that are both
feasible and desirable would be put into a schedule. At this point of approval, the request then
turns to a contract for the development of the software.

2. System Analysis:
This is the analysis stage of system development when the analyst wants to study the existing
system with the view of understanding the requirement of the proposed system. It requires a far
more detailed and comprehensive study than the feasibility study. The purpose of this process is
to fully understand the existing system and to identify the basic information requirements.
This stage essentially involves a lot of communication between the software developer (analyst)
and the client (the organization requiring the new system).

The outcome of this phase is a target document or specification document that defines WHAT
the system is to do. During this phase, a lot of facts need to be gathered using appropriate fact
finding techniques (discussed later). The analyst focuses specifically on the software to be
developed. Documentation is highly required at this stage and the contents therein discussed with
the client to ascertain that the system requirement have been clearly understood. In this phase of
development, a lot of questions will be asked like:-
i. What is being done?
ii. How is being done?
iii. How frequently does it occur?
iv How great is the volume of transactions or decisions
v. Does a problem exist?
vi. If a problem exists, what is the underlying cause?

To answer these questions, systems analysts talk to a variety of people to gather details about the
project and their opinions of why things happen as they do and their ideas for changing process.
In some cases, questionnaires are used to collect this information from large groups of people
who cannot be interviewed individually. Detailed investigations also require the study of
manuals and reports, observation of work activities, and sometimes collections samples or forms
and documents to fully understand the project.

There are several methodologies that allow for successful analysis of customer requirements.
The main principle of analysis is that the problem (requirements) must be partitioned in a manner
that allows for its functional decomposition (i.e. the problem is split up into smaller problems
that when viewed together in a hierarchical form define the problem).
The outcome of the system analysis phase called the target/specification document then describes
clearly and unambiguously what the proposed system is meant to do.

System analysis tools

Some of the tools that are mostly used in system analysis and design are
* Flowchart
* Questionnaire
* Decision table
* Checklist
* Top-down Methodology

Flowcharting
The flowchart is a means of visually presenting the flow of data through an information
processing systems, the operations performed within the system and the sequence in which they
are performed.

A flowchart is a diagrammatic representation that illustrates the sequence of operations to be

performed to get the solution of a problem.
A flowchart can also be described as a schematic representation of an algorithm or a process, or
the step-by-step solution of a problem, using suitably annotated geometric figures connected by
flow lines for the purpose of designing or documenting a process or program
Flowcharts are generally drawn in the early stages of formulating computer solutions. Flowcharts
facilitate communication between programmers and business people. These flowcharts play a
vital role in the programming of a problem and are quite helpful in understanding the logic of
complicated and lengthy problems. Once the flowchart is drawn, it becomes easy to write the
program in any high level language. Often we see how flowcharts are helpful in explaining the
program to others. Hence, it is correct to say that a flowchart is a must for the better
documentation of a complex program.
Flowcharts are good examples of how diagrams can be used to explain a complicated process
with considerable clarity.
Flowcharts provide the analyst with an effective means of:
i. Illustrating the logical order in which things happened for a complex process
ii. Visual pinpointing what resources and major decisions are required throughout the process.
iii. Graphically explaining what could happen as a consequence of varying conditions and
decision alternatives.

Types of flowchart
We will consider flowcharts under the four headings:
i. Block charts (or diagrams)
ii. Systems flowcharts
iii. Procedure flowcharts
iv. Program flowcharts

Block Charts: The block chart (or diagram) shows the sequence of the main procedures in a
system and can be regarded as the simplest form of flowchart.
The object of such a chart is to give a broad picture only and it will contain no details of how
each procedure is carried out. Only one symbol (the rectangle) is used in its construction.

Systems Flowcharts: This represents a general overview of an entire system or process. It is

used by systems analysts in explaining a complex problem to nontechnical personnel or as a way
of introducing technical personnel to a new problem topic.

The systems flowchart shows in more detail the procedures outlined in the block diagram. It
provides a picture of the processing operations in the system. This is a detailed illustration of the
steps involved in solving a problem. They are commonly called logic or block diagrams.
The systems flowchart is concerned with the complete system (not just the part the computer
plays in it) and will therefore include both clerical and computer operations.
Because of the additional detail involved in constructing systems flowcharts they sometimes take
up more than lone standard sheet of paper.

Uses of System Flowchart

i. It is used for problem organization
ii. It is used for problem solving
iii. It is used for problem presentation
iv. It is used for problem review

Procedure Flowcharts These charts are in tabular form and normally contain NCC symbols.
They are often employed to describe an existing manual system which is a candidate for
computerization and act as, an aid to problem analysis.

The following example takes a written description of a manual sales ledger system and shows the
corresponding procedure flowchart.
Program Flowcharts: The systems analyst uses flowcharts when explaining complex logic
problems to technical personnel such as computer programmers.

Uses of Program Flowchart

It is used for presenting the programming logic
It is used for simplifying discussions between system and programming functions. Other types of
flow-chart are Block Flowchart and Procedure flow chart

Decision tables
Decision table is a tabular form that presents a set of conditions and their corresponding actions:

Advantages of Decision Table

i. They show causes and effect relations
ii. Complex table can easily be subdivided into simpler tables
iii. It facilitate analysis of combinations
iv. They use a standardized format
It is possible to check that all combinations of conditions have been considered
They are easily understood because people are accustomed to using tables.
Table users need not understand computer
Computer program may be written directly from decision table.
Decision tables offer a means of representations to management or when an extensive problem or
process is been dealt with.
Decision tables are most effective when the problem is one of selecting a single alternative or of
alternative out of many possibilities.

3. System Design:
The primary objective of the design, of course, is to deliver the requirements as specified to the
feasibility report. The design of an information system produces the details that state how system
analysts begin the design process by identifying reports and other outputs the system will
produce. Usually, designers sketch the form or display as they expect it to appear when the
system is complete. This may be done on paper or on computer display, using one of the
automated system design tools available. The system design also describes the data to be input,
calculated or stored. Designers select file structures and storage devices, such as magnetic disk,
magnetic tape, or even paper files. The procedures state how to process the data and produce the
output. The detail design information is passed on to the programming staff so that software
development can begin.

System design is a multi-step process that considers three distinct area of the software namely,
the data structure, the software architecture (using structure chart) and procedural design
(module specification using structured English).
The goal of the design phase is to translate the system requirements into a representation of the
software that can be assessed for quality BEFORE the actual coding (programming)
Design Objectives
In general, the following design objectives should be kept in mind:
i. Practicality: The system must be stable and can be opened by people with average
intelligence.
ii. Efficiency: this involves accuracy, timeliness and comprehensiveness of the system output.
iii. Cost: It is desirable to aim for a system with a minimum cost subject to the condition that it
must satisfy all the requirements.
iv. Flexibility: The system should be modifiable depending on the changing needs of the user.
Such modifications should not entail extensive reconstructing or recreation of software. It should
also be portable to different computer systems.
v. Security: This is very important aspect of the design and should cover areas of hardware
reliability, fall back procedures, physical security of data and provision for decision of fraud and
abuse.

System design involves first logical design and then physical consideration of the system. The
logical design describes the structure and characteristics of features, like the outputs, inputs,
files, databases and procedures. The physical construction, which follows the logical design,
produces actual program software, files and a working system.

Design Process
The computer system design process is an exercise of specifying “how” the system will work. It
is an iterative process which is based on “what” the system will do as shown in the feasibility
report.

Mainly, following five parts have been included in the system design process:
i. Output design: The starting point of the design process is the proper knowledge of system
requirements which will normally be converted in terms of output.
ii. Input design: Once the output requirements have been finalized, the next step is to find out
what data need to be made available to the system to produce the desired outputs. The basic
documents in which these data are available need to be identified. If necessary, these documents
may have to be revised or new documents may have to be introduced.
iii. File design: Once the input data is captured in the system, these may have to be preserved
either for a short or long period. These data will generally be sorted in files in a logical manner.
The designer will have to devise the techniques of storing and retrieving data from these files.
iv. Procedure design: This step involves specifications of how processing will be performed.
In this, there are two aspects:
- Computer procedure
- Non-computer procedure

The computer procedure will specify what functions will be carried out on computer, what will
be different programs and in what sequence the programs will be run. The non-computer
procedures will specify the manual procedures for feeding input data, receiving outputs etc.
v. Control design: The control design indicates necessary procedures which will ensure
correctness of processing, accuracy of data, timely output etc. This will ensure that the system is
functioning as per plan.
Generally, these steps as mentioned above are inter-dependent and some of them may have to be
used together and traversed many times until a satisfactory design is prepared.

4. System Development:
This stage concentrates on HOW the software system is to be implemented. In the development
phase, the computer-based business system is developed to conform to the design specification
prepared in the preceding phase. This phase involves heavy expenditure because of recruiting
additional staff for the purpose of software development, purchase of machine, materials and the
use of computer facilities.

The principal activities performed during the development phase are:

(a) External system development and (b) Internal system implementation planning, preparation
of manuals and personnel in-house training, and equipment acquisition and installation. Software
development and performance testing are considered to be the principal activities of internal
system development. Every detail of the design is to be properly documented. Designers are
responsible for providing programmers with complete and clearly outlined software
specifications. A limited number of users may be allowed to use the system so that analysts can
see whether they have tried to use the unforeseen ways. In many organizations, testing is
performed by persons other than those who wrote the original programs to ensure more complete
and unbiased testing and more reliable software. The goal of system testing is for the user to
ensure the workability of the new system.
The client wants to ascertain that there is no missing part, bugs and all the system requirements
are clearly implemented in the new system.

Hardware Selection
The decision to acquire computer hardware or software must be handled in the same way as any
other business decision. The variety of sizes and types of computing resources available puts
other burden on the analyst who must select suitable hardware, software or services and advise
the top management accordingly.
Today, selecting a system is a serious and time-consuming business. The time spent on the
selection process is a function of the applications and whether the system is a basic micro-
computer or a mainframe. In either case, planning system selection and acquiring experienced
help where necessary pay off in the long run.

There are various important factors which should be considered prior to system selection. They
are:
i. Define system capabilities that make sense for the business.
ii. Specify the magnitude of the problem; i.e. clarify whether selection entails a few peripherals
or a major decision concerning the mainframe.
iii. Assess the competence of the in-house staff.
iv. Hardware and software should be considered as a package.
v. Develop a time frame for the selection process.
vi. Provide user indoctrination. This is crucial, especially for first time users.
Selling the system to the user staff, provide adequate training and creating an environment
conductive to implementation is pre-requisite for system acquisition.
The selection process should be viewed as a project and a project team should be formed with
the help of management.

Software Selection
Software selection is a critical aspect of system development. There are two ways of acquiring
software: custom-made or “off- the-shelf” package. Today, there is great demand for these
packages because they are quite cheap. There are other benefits also:
i. A good package can get the system running quickly.
ii. MIS personnel are released for other projects.
iii. 'Home-grown' software can take more time and its cost cannot be predicted.
iv. Package can be tested before purchasing it.
Some drawbacks of software packages are:
I. These packages may not meet user requirements in all respect.
ii. Extensive modifications of a package usually results in loss of the vendor's support.
It can be observed that price alone cannot determine the quality of software. A systematic review
is crucial for selecting the desired software. Prior to selecting the software, the project team set
up criteria for selection.

The criteria for software selection are:

I. Reliability: gives consistent results without any failure for a specified time period.
ii. Functionality: functions to standards.
iii. Capacity: satisfies volume requirements of the user.
iv. Flexibility: adapts to the changing needs.
v. Usability: is user-friendly.
vi. Security: maintains integrity and prevents unauthorized user.
vii. Performance: delivers the results as required.
viii. Serviceability: has good documentation and vendor support.
ix. Ownership: has right to modify and share use of package.
x. Minimal costs: is justified and affordable for intended application.

5. System Implementation:
This is the stage where people actually begin to use a system. Implementation includes all those
activities that take place to convert from the old system to the new one. The new system may be
completely new, replacing an existing manual or automate system or it may be major
modification to an existing system.
In either case, proper implementation becomes necessary so that a reliable system based on the
requirements of the organization can be provided. It has been observed that even the best system
cannot show good result if the analysts managing the implementation do not attend to every
important details. This is an area where the systems analysts need to work with utmost care.
The goal of this phase is to eventually get the new system for the client to start using.
The important aspects of implementation are:
i. Training personnel
ii. Conversion procedures
iii. File and Data Conversion
iv. Post-implementation review
Training of Personnel
Even well-designed system can succeed or fail because of the way they are operated and used.
Therefore, the quality received by the personnel involved with the system in various capacities
helps or hinders and may even prevent the successful implementation of management
information system. Those who are directly or indirectly related with the system development
work must know in detail what their roles will be, how they can make efficient use of the system
and what the system will or will not do for them.

Conversion procedures
Conversion is the process of changing from the old system to the new one. It must be properly
planned and executed. Four methods are common in use. They are: direct conversion, parallel
systems, pilot system and systems phase-in. Each method should be considered in the light of the
opportunities that it offers and problems that it may create.
However, it may be possible that sometimes, we may be forced to apply one method over others,
even though other methods may be more beneficial. In general, systems conversion should be
accomplished in shortest possible time.
Long conversion periods create problems for all persons involved including both analysts and
users.
The changeover approach goes a long way to determine the successful implementation of the
new system.
Meanwhile, changeover may be done by applying any of the following approaches:
i. Crash approach (Direct Changeover)
ii. Parallel approach;
iii. Pilot approach and
iv. Phase approach (Staged)

i. Crash (Direct) approach: This is a method of changeover in which the old system is
completely replaced by the new system in one move. The scheme might be unavoidable where
the two systems are substantially different or the old system coincidentally crashed at the
installation of the new system. While this method is relatively cheap, it is risky and management
must have complete confidence in the new system.

ii. Parallel approach: this is a form of changeover whereby the old and new systems are
allowed to run in parallel for a period of time, both processing current data and enabling cross-
checking to be made. This scheme provides a degree of safety, should there be problems with the
new system. However, if there are differences between the two systems, cross-checking may be
difficult or impossible. Moreover, this approach may be quite expensive.

iii. Pilot approach: The pilot approach can be considered in two modes viz:
a. Retrospective Parallel Running:
Here, the new system operates on data already processed by the old system. The existing results
are available for cross-checking and the system can be tested without disturbing the normal
process of operation.
b. Restricted Data Running:
Here, a complete logical part of the whole system file is chosen and runs as a unit on the new
system. If that is shown to be working fine, the remaining parts are then transferred. This
approach is cheaper and easier to control than the parallel approach, and provides a greater
degree of safety than does the direct approach.

iv. Phase approach: This is in fact a form of parallel running. The different being that instead of
running two complete systems (old and new) in parallel in order to compare the result of live
processing on the new system with those generated by the old, only a portion of the data is run in
parallel (e.g. for one branch only). The use of this method of implementation is best suited for
very large projects and/or those where distinct parts of the system are geographically dispersed.
An important aspect of implementation is training of the end-users to be able to use the new
system. The modality for training the users depends on the agreement reached between the client
and the developer.

File and Data Conversion

Data and file preparation consumes a large proportion of conversion time. Not only must the data
be converted to a format acceptable in the new system, but analysts must ensure that this is due
without loss of detail or accuracy. By using record counts, financial controls and hash totals,
analysts are able to detect correct problems quickly, before they get out of control, even if the
conversion involves data transmission.

Post-Implementation Review
After the system is implemented and conversion is complete, a review should be conducted to
determine whether the system is meeting expectations and where improvements are needed. A
post implementation review measures the systems, performance against predefined requirements.
It determines how well the system continues to meet performance specifications. It also provides
information to determine whether major re-design or modification is required.
A post-implementation review is an evaluation of a system in terms of the extent to which the
system accomplishes stated objectives and actual project costs exceed initial estimates. It is
usually a review of major problems that need converting and those that surfaced during the
implementation phase.

The post-implementation study begins with the review team, which gathers and reviews requests
for evaluation. Unexpected change in the system that affects the user or system performance is a
primary factor that prompts system review. Once request is filed, the user is asked how well the
system is functioning to specifications or how well the measured benefits have been realized.
Suggestion regarding changes and improvements are also asked for.

6. System Evaluation / Maintenance

This phase involves keeping the system up to date, and the review of the system to make sure
that it conforms to the requirements identified in the feasibility study.
An important part of the implementation is a review of how the new system is performing once it
has been on and running for a period of time. A system, having been implemented, occasional
evaluation is needed in order to understand the performance of the system. Minor programming
errors may have to be corrected, clerical procedures, amendment or modifications are made to
the design of report or screen layouts. This begins the process of system maintenance.
System maintenance is a lifelong issue. As long as the system is in use, maintenance becomes
very necessary. Sometimes, it may be that the system requirements have changed or a bug is
discovered in the process of using the system. All these and other reasons call for maintenance of
the system.

The three types of maintenance are as follows:

Preventive maintenance: This implies that while the system runs satisfactorily, there is still
room for improvement. For example, extra management information may be needed so that new
report program has to be written.
Database queries may be very slow, and a change in a program may be able to improve response
time.

Adaptive maintenance: All system will need to adapt to changing needs within company. As
the business expands, for example, there may be a requirement to convert a standalone system to
a multi-user system. New and better hardware may become available, and changes to the
software may be necessary to take advantage of this. Also competition from other firms may
require upgrading the system in order to maintain a competitive edge.

Corrective maintenance: Problems frequently surface after a system has been in use for a short
time regardless of previous system testing. Such problems need to be corrected in order to put
the system in the correct shape.

DOCUMENTATION
A system cannot be completely effective unless it is adequately documented. It should be
documented as it is being created. That is, at various stages of the system development, status
reports should be prepared for those management personnel for whom the system is being
designed. Such reports could include flowcharts, decision tables, output forms and other
documents thus far developed.
It also includes various problems encountered, suggested solutions and resulting schedule
revisions. In this way, management remains fully aware of system's progress so that they can
offer criticisms or suggest change while it is still economically and physically possible to make
these changes without it being necessary to revise the entire system. These progress reports are
excellent basis on which to build additional documentation.

Characteristics of Good Documentation

Documentation is considered to be good if it has the following qualities:
i. Availability: It should be accessible to those for whom it is intended.
ii. Objectivity: It must be clearly defined in a language that is easily understood.
iii. Cross-referable: It should be possible to refer to other documents.
iv. Easy to maintain: When the system gets modified, it should be easy to update the
documentation.
v. Completeness: It should contain everything needed, so that those who have gone through it
carefully can understand the system.
Types of Documentation
There are five major types of documentation. They are:
i. Program Documentation
ii. Operation Documentation
iii. User Documentation
iv. Management Documentation
v. Systems Documentation

1. Program Documentation
Many companies discuss about programming documentation but fail to provide it adequately.
Before a program is developed, the systems analysts should provide the programmer with the
required documentation. The logic in some programs is best described by a flowchart.
Sometimes, decision tables are most appropriate for explaining the logic of a program.
Programmers should insist on proper documentation before starting a job.

Four items constitute normal documentation required for each program.

i. Copying in final form of all input/output documents affecting the program.
ii. Statement of standards for coding structures and input/output layouts.
iii. Clarification of the program's interface with other related programs.
iv. General flowchart or decision table.

The programmer's responsibility in documentation is to provide information to enable future

programmers to make necessary changes.
Personnel turnover is normal feature in any business, and turnover is particularly high among
programmers. A company can never think that a programmer assigned to a specific program will
be available in two years, when some modifications to that program are required. For continuity
of information a company must insist on complete and meaningful documentation. Typically a
documentation folder is provided for each program which contains all the input/output forms
associated with the program, a detailed flowchart or decision table for the program use a set of
operator and user instructions.

Maintaining this type of documentation is costly and time consuming, for, programmers do not
take interest in spending time for this type of work, program and all changes must be covered in
the documentation folder. But the very changes which require the updating of existing
documentation are the reasons for maintaining accurate documentation.

2. Operations Documentation
A well designed system may run for a long time with little or no assistance from the systems
department. This can happen only when the system has been documented in a proper way. For
smooth running of the system, the console operator must have complete knowledge about the
job. Providing the computer centre with a set of operating instructions will not serve the purpose.
The instructions must be in a form readily accessible to the console operator and written in
simple and understandable style. A systems analyst must thoroughly discuss all the requirements
of new jobs with the operations staff before the job can be properly transferred.
The run book is traditional in computer centres. It is a collection of operator instructions for each
program at an installation and typically contains:
i. Narrative, describing the run
ii. Listing of the programmed error conditions
iii. Detailed information for running the job, including:
a. input/output forms to be used
b. anticipated problem areas and how to handle them
c. detailed description of file assignment to fetch input/output device
d. disposition of data files after completing the job
e. general block diagram of the programming logic The run book generally takes the form of a
loose leaf notebook because of the case of substituting sheets as programs change. It should be
kept in mind that an operator in a multiprogramming environment must monitor many programs
simultaneously. Instructions must be simple and complete enough for executing the job correctly.

3. User Documentation
Systems users require proper documentation to prepare a developing system and to smoothly
carry out existing ones. To meet this requirement, each system should have a manual that spells
everything the users must know to do their job correctly. Users require two general types of
information; complete details to handle each case the system processes, and overall picture of the
system so that they can see their role in the total operation of the company.

The manual should supply the following information.

i. General flowchart of the system
ii. Assignment of responsibility for specific tasks
iii. Standards for work flow, including target dates and deadlines for specific tasks
iv. Simple input and output documents
v. Detail procedures
vi. Anticipated exceptions and instructions on how to handle them
vii. Accuracy standards for data in the system

The systems department must write a thoroughly detailed narrative of each system, including the
proper handling of routine cases, as well as exception handling. A staff member in the user
department must have an authority to consult when faced with a case not handled before.
Properly prepared manual which is always available can provide the information needed by user.
Supervising staff in user areas must understand the overall picture in each system just as staff
members must understand the details of their function. This requires documentation, in the form
of charts, graphs and illustrations, so that the supervising staff has a clear grasp of their
department's role in the total system.

4. Management Documentation
The documentation required by corporate management differs quite a lot from that required by
users. The systems designer must know the requirements of the management and provide
documentation to enable management to perform three functions:
i. Evaluate progress on systems development
ii. Monitor existing systems
iii. Understand the objectives and methods of new and existing systems
Management, in general, is primarily interested in knowing the system's overall objectives and
basic operations. A brief manual highlighting the key steps in each system may be prepared for
management. Good managers have an exceptional ability to get to the root of a system and, their
experience should enable them to retrieve information from a system's summary or chart which
may not be apparent to the systems analyst.

5. Systems Documentation
Each phase in the systems development cycle is accompanied by appropriate documentation. The
systems request, even if it is initially mark verbally, eventually must be written. It is desirable for
the client and a systems analyst to work jointly in writing the request since each can contribute
knowledge the other does not have. The written system's request is merely a statement of the
user's problem.

In documenting the results of its deliberations, the selection committee must specify the
following:
i. The objectives of the impending feasibility study
ii. The extent of the authority of the feasibility team
iii. The individual or group responsible for completing the study
A feasibility report is probably the most important form of documentation in the system
development cycle.

It accomplished the following two purposes:

i. It defines the objectives of the proposed system's change in reasonable detail after a
sufficiently detailed study.
ii. It gives a plan to attain these objectives.
The documentation of this plan must be thorough enough so that system designers could produce
a complete and effective system. At various points during systems design, the designing team
produces the following additional forms of documentation:
i. File Specification: detailed definitions of each file in the system, best done in graphic form.
ii. Transaction Specification: detailed descriptions of all output anticipated from the system.
iii. Output Specifications: detailed descriptions of all output anticipated from the system.
Documentation also includes plans to test the system and convert from the old to the new one.
The systems analyst must also provide a plan to train the personnel affected by the changes.
During the life cycle of the completed system, the system itself must provide documentation of
how well it is operating and consequently should be designed to yield data about itself as a
normal by-product.

Need for Documentation

Preparation of documentation is quite important as it depicts what the system is supposed to be
and how it should perform its functions. It illustrates both technically and economically how a
system would better serve the objectives and goals of the company. Documentation improves
overall operation in addition to management and audit control.
It also serves the following purposes;
i. Reviews the progress or development of application software.
ii. Communicates facts about system to users.
iii. Communicates between personnel working on a development project.
iv. Provides necessary guidelines to allow correction or revision of a system or its computer
programs.
v. Provides operating instruction to users and operating staff.
vi. Assists in the reconstruction of the system in case it is destroyed.
vii. It helps the management to determine if the new design achieves the objectives of the
company within the established constraints and if it is justifiable from a cost standpoint.
viii. Documentation serves as a focal point from which the analysts' design can be assessed and
as a standard to be utilized as reference once the system is implemented.

FACT FINDING TECHNIQUES

To study any system, the analyst needs to collect facts and all relevant information. The facts
when expressed in quantitative form are termed as data.
The success of any project is depending upon the accuracy of available data.
Accurate information can be collected with help of certain methods/techniques.
These specific methods for finding information of the system are termed as fact finding
techniques. Interview, Questionnaire, Record View and Observations are the different fact
finding techniques used by the analyst. The analyst may use more than one technique for
investigation.

1. Interview: This method is used to collect the information from groups or individuals. Analyst
selects the people who are related with the system for the interview. In this method the analyst
sight face to face with the people and records their responses. The interviewer must plan in
advance the type of questions he/ she is going to ask and should be ready to answer any type of
question. He should also choose a suitable place and time which will be comfortable for the
respondent.
The information collected is quite accurate and reliable as the interviewer can clear and cross
check the doubts there itself. This method also helps gap the areas of misunderstandings and help
to discuss about the future problems. Structured and unstructured are the two sub categories of
Interview. Structured interview is more formal interview where fixed questions are asked and
specific information is collected whereas unstructured interview is more or less like a casual
conversation where in-depth areas topics are covered and other information apart from the topic
may also be obtained.

2. Questionnaire: It is the technique used to extract information from number of people. This
method can be adopted and used only by a skillful analyst. The Questionnaire consists of series
of questions framed together in logical manner.
The questions are simple, clear and to the point. This method is very useful for attaining
information from people who are concerned with the usage of the system and who are living in
different countries. The questionnaire can be mailed or send to people by post. This is the
cheapest source of fact finding.

3. Record View: The information related to the system is published in the sources like
newspapers, magazines, journals, documents etc. This record review helps the analyst to get
valuable information about the system and the organization.
4. Observation: Unlike the other fact finding techniques, in this method the analyst himself
visits the organization and observes and understand the flow of documents, working of the
existing system, the users of the system etc. For this method to be adopted it takes an analyst to
perform this job as he knows which points should be noticed and highlighted. The analyst may
observe the unwanted things as well and simply cause delay in the development of the new
system.