CHAPTER ONE: BASIC INFORMATION

SYSTEMS CONCEPTS
INTRODUCTION
What is a system?
A system is simply a set of components that interact to accomplish some objective. It can
consist of tools, suppliers, machines, procedures and people and requires orderly
management.

The two main types of systems are business systems and information systems.

What is a business system?

A business system is aimed at accomplishing specific business goals e.g. a factory is a
business system with the goal of manufacturing products. A business system is usually
broken down into smaller components or subsystems. For example, in a factory business
system, subsystems can be: -
- Maintenance of the factory building.
- Controlling the assembly of products that the organization sells.
- Processing customers’ orders.
- Billing customers.
- Paying employees, etc,

However, the subsystems must be managed in an orderly fashion so as to accomplish the

company’s goal/mission.

What is an information system?

An information system is a set of components that manages the data needed by a business
system and hence is a subsystem of a business system.

An information system exists only to serve the business system of which it is a

component. It keeps records and maintains the various facts and figures needed to run the
business.

Information systems produce the information required by managers to make decisions

about the firm and therefore must satisfy the information needs so that accurate and
timely decisions can be made.

Example: An information system for the subsystem that bills customers would probably
keep track of each customer’s name and address, recent sales to the customer, recent
payments from the customer and the total amount the customer owes.

An information system consists of data, people, procedures and machinery (including,

but not limited to computers) as its building blocks.

Importance of information systems

An information system provides a competitive advantage to an organization. That is, an
organization is able to manage its resources better, giving it a competitive advantage over

Page 1 of 111
its competitors. Without accurate and timely information, it is difficult to make informed
decisions. The best information systems can actively contribute to business performance.
The concern of manages today is how information systems and the computers that are
part of them can add value by improving employee productivity, enhance customer
satisfaction, boost employee morale and increase profits.

Because information is critical, we need to be concerned about its function, management

and maintenance.

Measuring the success/effectiveness of a recently implemented system

• Does the system achieve the goals set for it? Some of these will be operational
running goals concerned with performance, some will be system goals concerned
with production of outputs and some will be system goals addressing the purpose of
the system development.
• How well does the system fit the business structure for which it was developed?
The new system will no doubt have been developed based on an understanding of the
present structure of the organization and some appreciation of how it might change in the
future. However it might not be an ‘albatross system’ that hangs around the
organization’s neck limiting it to movement and freedom to reorganize. Systems should
be designed in a flexible way so that they can meet changing business conditions.
• Is the system accurate, secure and reliable? There will be basic requirements for
financial controls and auditing but the system should also be robust so as to continue
in operation with degraded performance during partial failure. Security from
unauthorised access has also now become increasingly important with the growth in
the development of tactical and strategic information systems.
• Is the system well documented and easy to understand? Increasingly large proportions
and of the budget of systems development departments are being used in the
maintenance and updating of the existing systems. The biggest single way of limiting
these expenses in the future is to take account of it when we design today the systems
of tomorrow.
• What is the cost effectiveness of the system?

LEVELS OF MANAGEMENT AND THEIR INFORMATION NEEDS

An organisation’s management can be classified in three levels:

i) Operational management
ii) Tactical management
iii) Strategic management

Operational management
It deals with the day-to-day activities of the organization. These are the basic activities
that the organization must perform in order to remain in business. As such, the role of
managers at this level is supervisory. Examples of activities at this level are order
processing, inventory control, customer billing, production scheduling, etc.

Page 2 of 111
 - Information is derived entirely from internal sources and is relevant in the short
term.
- The information is highly detailed (lowly summarized), for example, a report of
daily orders, daily bank deposits, daily list of patients, etc.
- Decisions associated with these activities cover a relatively narrow time frame
and are also delegated to the lowest possible level of the organization where they
can be made quickly and effectively.
- Information is purely based on quantitative data.
- Decisions made at this level tend to be recurring and as a result, the decision
making process becomes routine and structured. A structured decision is one that
is predictable and can be made following a well defined set of procedures, for
example in inventory control, clerks will check inventory.

However, before this planning can be done, a thorough understanding of the old
system is required how best computers can be used to make operations more
effective.

Analysis specifies what they should do while design states how to accomplish the
objectives.

STRUCTRED APPROACHES TO SYSTEMS DEVELOPMENT

In the late 1970’s, a number of people in the IT industry begun to consider why so
many IS developments had gone wrong and failed to live up to their promise and,
mostly, they reached a similar conclusion: projects went wrong initially during the
analysis phase and efforts to improve the situation later were usually a waste of time
and even more money. Most of these authorities agreed that there was a need for a
new method of analysis and design that would offer:

• Greater formality of approach that would bring systems development nearer to the
scientific method or to an engineering discipline than had been common in IS
projects.
• More clarity of stated requirements by using graphical representation as well as
text.
• Less scope for ambiguity and misunderstanding.
• A greater focus on identifying and then satisfying business needs
• More trace ability, to enable a business requirements to be followed through
initial analysis, into the business level specification and finally into the technical
design.
• More flexible designs of system not unduly tied to specific technical platforms.
• Much more user involvement at all stages of development.

All the structured methods result from attempts to meet these requirements in one way or
another. As a result, there some features that are common to all structured methods and to
the structured approach in general.

Page 3 of 111
Focus on data structures
Most of the methods concentrate heavily on a thorough examination of the data
requirements of the proposed information system. The reasons for this concentration on
data are twofold:
• Processing requirements of the organisations can change often and may change
significantly, the underlying data is relatively stable; therefore the data provides the
soundest base for the development process.
• An inflexible data structure can act as a constraint on an organisation wishing to
change its system to match changing requirements. Evolving flexible data structure
early during development yields may benefit later on in the life of a system.
With a sound a flexible data structure in place, it is possible to amend the processing to
meet the changing needs of the organisation.

Use of diagrams and structured English

Another common feature of the structured methods is their heavy reliance on diagrams to
convey information. The reasoning here is that:
• Diagrams are generally easier for people to assimilate than large quantities of text
thereby providing an easier means of communication between users and developers.
• It is less easy to commit sins of omission or ambiguity with diagrams; for instance,
failure to mention an important dataflow, on an incorrect statement about the
direction of flow on an incorrect statement about the direction of flow, may not be
noticed in along written specification but it will be immediately obvious on a
dataflow diagrams.
Together with diagrams, many make use of ‘structured English’. This aims to reduce the
complexity of the language and reduce the written component of the documentation to
brief, terse, unambiguous statements.

Concentration on business requirements

Another important feature of structure methods is the separation of the logical and
physical aspects of the analysis and designs process. This is done so that both analysts
and developers focus on the business requirements of the proposed information system,
rather than considering too soon the technical details of its implementation.

So, with a structured method, the developers will focus for much of the time on the
business requirements of the proposed system. They will look at the data needed to
support the system and at the kind of processing which the users will want to support
their business. Only once these things have been clearly established will they consider
how these features may be implemented.

Benefits of structured methodologies

• Structured methodologies concentrate on system’s data requirements. Since these are
more stable than the processing requirements, a system built around a flexible data
structure will approve amenable to change and have a longer life.
• The use of diagrams and structured English improves communications between users
and developers and increases the chances of the users getting the system they really
need.

Page 4 of 111
• Because technical issues are addressed relatively late in structured development
projects, much of the design will be suitable for implementation in a number of
environments. Should the users’ hardware or software policy change, it should be
possible to go back to the logical documentation and –re-develop from there for the
new platform.
• A system built using structured methods will have complete, rigorous and consistent
documentation, which will greatly help in maintaining and enhancing the system over
time.
• Using a recognised structured method means that the users are not tied to any one
developer. This means that one could, for instance commission one firm to carry out
the analysis and another to produce the design.

Disadvantages of using structured methods

• Users seem to have to wait for a long time before they actually see any concrete
results for the development such as actual screens or reports. This is because with a
structured method, more effort is expended earlier in the project, during analysis and
design and a decrease in the programming effort (though not testing).
• With a structured method, user involvement is usually explicitly set out and the users
will be asked to contribute to review and approvals at various stages. This should
result in the production of higher-quality systems, which better meet their users’
needs. The amount of user involvement must however be carefully explained at the
beginning of the project and the necessary commitment, to the time and effort
involved, must be obtained. In addition, it may be necessary to provide suitable
training so that key user can fully understand the documentation being presented to
them.
• Some structured methods remain the intellectual property of their designers and
developers who will provide advice, training and consultancy and sometimes support
tools for their use. The dangers in this will provide advice, training, and consultancy
and sometimes support tools for their use. The dangers in this are that one can get,
‘locked-in’ to the single source of supply and that the high prices charged for the
various services may add a considerable extra cost to the development budget.
• CASE tools are becoming more widely used in systems developments and some of
the structured methods become very difficult to use without some form of
computerized support. The development of CASE tools has not quite kept up with the
development of the structured methods themselves.

Examples of structured methods

• INFORMATION ENGINEERING (IE)
• OBJECT ORIENTED DESIGN (OOD)
• SSADM

Structured Systems Analysis and Design Methodology (SSADM)

The method presents a ‘three-view’ model of an information system. The method views:
• The data in the system
• The events to which the system must respond
• The functions in the system, as perceived by the users.

Page 5 of 111
SSADM is documented in a set of classic manuals which describe:
• The structure of an information system project, in terms of the modules, stages, steps
and tasks by which the work is tackled.
• A set of analysis and design techniques, to be applied at various stages of the project.
• A series of product definitions, including the quality control to be applied at each
stage.
• ‘Hooks’ so that the method can be coupled with structured approaches to project
management and to programming, mainly to Jackson Structured Programming (JSP)

The major techniques employed are:

• Requirements analysis
• Dataflow modelling
• Logical Data modelling
• User/User role modelling
• Function definition
• Entity/Event modelling
• Relational data analysis

Page 6 of 111
 SSADM life cycle

USERS DEVELOPERS
TORs’ Information, Decisions

TERMS OF FEASIBILITY
REFERENCE STUDY
REVIEW OPTIONS Questions, Options

FEASIBILITY
REPORT

ASSIST/CHECK Information, Decions REQUIREMENT

ANALYSIS ANALYSIS
SELECT OPTION
Question, Options

SELECTED
BUSINESS
SYSTEM
OPTIONS

Questions
ASSIST/CHECK REQUIREMENT
SPECIFICATION SPECIFICATION
Information, Decisions

REQUIREMENT
SPECIFICATION

Questions, Options
CHECK
LOGICAL LOGICAL
DESIGN DESIGN
Information, Decisions

SELECTED LOGICAL
TECHNICAL DESIGN
SYSTEM
OPTION

CHECK Designs
PHYSICAL PHYSICAL
DESIGN DESIGN
Review Responses

PHYSICAL
DESIGN

To program specification coding, etc

Page 7 of 111
THE SYSTEM ANALYST’S ROLE IN SYSTEM DEVELOPMENT
Formal duties of a System Analyst
a) Identify and define the problem area following discussion with the users and
management. The objectives of the project must be clearly studied and the terms of
reference agreed and written down.
b) Carry out a feasibility study to establish whether a full study of the problem would be
worth while. These findings will include a careful weighing of the costs and benefits
of any new system.
c) Carry out a detailed analysis of the proposed system by employing a variety of
analysis techniques. This results in the Set of Requirements.
d) With approval from the management, the analyst proceeds to design a computer
based information system to be documented in a design specification.
e) Guide programs as they write the system’s programs or recommend the type of
packaged software to buy.
f) Introduced the new system and prepare a detailed plan for implementation. This will
cover file conversion, training, method of changeover, documentation, etc.
g) Monitor the system during its early weeks of operation. Thereafter, period review will
be required and amendments done on the system when circumstances demand.
h) Prepare the documentation and plan for user training.

Characteristic of a good analyst

a) The analyst must enjoy working with people, for he or she must serve as a translator
between the technical staff (such as programmers) and the non-technical staff (users
and managers). The analyst must therefore be able to communicate with the two
widely differing audiences; people who frequently speak computer jargon and people
who are baffled by it. Excellent communication skills are therefore critical.

b) He/she must be a diplomat and a good motivator

He/she must try to elicit co-operation or enthusiasm from everyone involved in the
project, from team members to users. If an analyst is to build an effective system and then
‘sell’ it to the users, motivational skills are required.

c) Must be able to work in a project team, both as a team member and as a team leader.
All team members must forget their egos i.e. they must put aside personal prejudices in
order to help the team as a whole function more effectively. As a team leader, the analyst
co-ordinates the efforts of programmers, estimators, testers and other analysts, as well as
resolves conflicts and monitors the results of the team effort. In order to do this, the
analyst must be a good manager.

d) Must have well developed problem solving skills

The analyst must be able to identify symptoms, determine the cause of the symptoms, and
to find a solution to the problem. All of this requires an organised approach to problem
solving as well as a great deal of creativity. Without organization, the analyst can easily
become overwhelmed by the scope and details of the problem. Without creativity, the
analyst may be tempted to solve new problems with the same old solutions.

Page 8 of 111
e) Must be a business generalist, maintaining a broad perspective at all times. A good
analyst needs to know as much about business systems as about computer systems, in
order to be able to link the two. He or she must be able to look at a system from multiple
points of view; as a programmer, as a manager, as a user and as a company financial
officer. For example, a programmer might insist that, for efficiency, she needs to use
assembler language to code a particular module. But the analyst having greater
knowledge of how hard an assembler routing will be to maintain in future, must convince
the programmer that perhaps in this case, programming efficiency is not the primary
concern.

Problems encountered by a systems analyst

a) The process of analysis and design is full ambiguity
There is rarely a right or wrong solution to a design problem. Instead, there are
multitudes of solutions, some more right or wrong than others and the chosen one if often
a compromise. Picking the best design is not an easy task to analysts.

b) It is often difficult to choose the appropriate analysis and design tool.

Analysis and design involves choosing among the variety of tools available to the analyst.
No single tool is perfect for all projects. Each project has a different personality and
needs to be tackled differently. Therefore, it is up to the analyst to know what tools are
available and choose among them intelligently.

c) The analyst must keep up with the latest development in the fast changing world of
computer hardware and software.
The analyst should know what is currently available in the market. This is to enable the
analyst recommend appropriate specific hardware and software. This does not mean that
the analyst needs to know every little technical detail about every product as long as he or
she knows where to go or with whom to talk to in order to get the information when it is
really needed.

d) Technology may change quickly but so does the typical business environment.
Analyst may talk of ‘freezing the specifications’ or not allowing any changes to the
requirements after the project has begun. Yet freezing the specifications is impossible
because the business organization cannot be frozen. New products are always being
developed, new government regulations are always being handed down and new reports
are always being needed. For example, no sooner are the specifications for the general
leader system almost done than the revenue authority decides that the income tax forms
will be radically changed, so the specifications for the new system must be changed too.

e) The analyst usually spends more time dealing with people rather than technology.
• The analyst works with individual personalities
People are more ambiguous than the process of analysis and design itself, and analysts
must solve more people-related problems than technology related ones. Every person in
the organization has his or her personal quirks, prejudices, likes and dislikes. One person
may fear a new system because he thinks it may make his job obsolete and put him out of
work. Another one might be afraid she won’t be able to learn the new system, thereby

Page 9 of 111
making a fool of herself, etc. Most people tend to prefer the status quo; its far less
threatening than something new and untried.
• Working with group dynamics
Any time people are put into groups; they tend to form political entities with different
goals and personality conflicts. Employees may align themselves against a supervisor
they don’t like or office mates may quarrel over who is doing the most work.

The analyst should be aware of the political situation, but should never get personally
involved in such politics because this can affect the implementation of a new system. For
example, the person afraid of making a fool of herself may be too shy to ask necessary
questions and might therefore be using the system incorrectly. A supervisor who distrusts
the computer might be passing that message on to his employees, who then do everything
they can to maker the new system fail. On the positive side, if the analyst gains the
support of key people in the organisation, their enthusiasm can often sway those who are
less eager.

SYSTEM DEVELOPMENT LIFE CYCLE

Information systems of all types go through a predictable series of phases namely: -

- Problem Recognition
- Feasibility Study
- Analysis
- Design
- Construction
- Conversion
- Maintenance

The system development life cycle is a recognised sequence of tasks, decision points
and supporting documentation leading to the successful implementation of a system.

Problem Recognition
The birth of a new system occurs when managers or/and users realise that an
information system is needed for new business or that an information system for an
existing business no longer reflects the organisation’s functions. For example, a
business might have expanded considerably while its information system remained
the same, or perhaps the current information system does not offer functions that
management believes are necessary for the future growth of the business. In any case,
awareness of this inadequacy could come about as a result of a formal review of the
system or complaints from users.

If the difference between the business needs and what the information system can do
are sufficiently serious, management may decide to call in a systems analysts to
examine the problem in depth.

Page 10 of 111
 Feasibility Study
The purpose of a feasibility study is to define the problem and to decide whether or
not a new system is feasible, spending a minimum amount of time and money in the
effort.

During a feasibility study, a systems analyst quickly studies the problem to assess its
magnitude and at the same time, attempts to resist (or at least identify) the scope of
the project. Since a change to one part of a system can quickly mushroom throughout
other areas of the company, it is critical to decide upfront exactly what will and what
will not be included in the current project.

The analyst lists precisely what is wrong with the current system as well as what will
be required of any new system. For example, he may indicate the current number of
records that the system is able to maintain. He may also list a set of reports that the
management may require but are not available within the current system.
- The analyst must determine if the needed system is technically, humanly
(socially) and economically feasible for the company.

- Technical questions are those that deal with equipment and software. For
example, can a system be developed using the organisation’s current computer
facilities? If the current facilities are not adequate, are the necessary hardware and
software technologies available in the market place?

- The analyst must decide whether the new system is humanly feasible given the
organization’s personnel. Some of the issuers to be tackled are. Are there enough
trained personnel to build and install the system? If so, is this really the way they
should spend their time? What do users think about the system? What is the
management’s option?

- The analyst next determines the system’s economic feasibility, roughly estimating
the time it will take to develop the system, the cost to build and maintain it, and
the benefits it will deliver.

Note: It is impossible to deliver exact estimates in a feasibility study, since the

system has not been fully specified and designed. After the estimates are prepared,
the analyst must correlate the costs with the benefits. Cost-benefit analysis is a
procedure for evaluating costs to see if they are justified by the benefits the deliver.

After management has examined the cost-benefit analysis, it can choose either to
abort the project because it is not worth the cost or to proceed to the analysis phase.

Analysis
If the outcome of the feasibility study is positive, the project continues into the
analysis phase.

Page 11 of 111
 Next, the analyst defines the requirements of a new system. The analyst uses fact-
finding techniques such as reading existing documentation, examining current
procedures and interviewing users and managers who deal with the system.

- From the existing documentation, the analyst can extract reference manuals,
listing of programs, organization charts and glossaries of error messages. These
items reveal to the analyst why the system was designed in the present structure as
well as its strengths and weaknesses.

- Examining the current procedures shows the system analyst how the system
actually works, which may or may not be the same as how it was intended to
work. Procedures can include anything from what is followed in deciding what
bills to pay, to how a clerk enters a vendor into the computer. Watching the users
at work may reveal the problems and the strong points of the system.

- Interviewing users and management allows an analyst to tap the expertise of the
people most involved in the system. These people provide valuable information
on what is currently working well and what is lacking in the present system as
well as what is needed from a new one. There may, however, be some users who
are uncertain of what a new system should do, or who are unable to conceptualize
and verbalize it. These people must be interviewed skilfully if the analyst is to
extract the needed data. This requires that the analyst must have the
communication skills. Without such skills, the analyst cannot expect to obtain the
co-operation that is so vital.

- After the necessary facts are gathered, they are used to complete the analyst’s
understanding of the current system and the ‘wish-list’ for the new one.

- Diagrams are made that document the current system. These diagrams are studied
as the analyst considers the functions of the new system. The analyst then
prepares another set of diagrams incorporating the new functions that users need
without specifying how those functions are to be performed.

- The analyst may use the facts that have been gathered to prepare a prototype,
which is an abbreviated version of the new system. A prototype may be developed
quickly using systems development tools such as fourth generation languages.

- The analyst can then show the prototype to users, letting them ‘play’ with it and
make suggestions. At this point, users can evaluate how close the prototype comes
to satisfy the ‘wish-list’. In some cases, the prototype may actually evolve into the
finished system. In others, the system may need to be rewritten using more
traditional programming tools, such as COBOL or PASCAL.

Design

Page 12 of 111
 Early in the design phase, the analyst uses the management decisions from the
analysis phase to make final equipment decisions. Purchased hardware and software
must be ordered early in the design phase if it is to arrive on time for the construction
phase, which follows.

- Next, the analyst transforms the functional diagrams of the analysis phase into
hierarchical diagrams of the design phase. This transformation allows the analyst
to see exactly what programs are needed and how they are related to one another.
At the same time, the analyst evaluates the entire design for quality, using such
criteria as how completely each program achieves a unified function and how
straightforward the user interface is.
- The functional requirement detailed in the system specification is translated into
the plans for a series of computer programs that will perform the required
functions. The analyst decides on program structure, program interfaces and the
hierarchy, or order in which programs will be arranged. While the analysis phase
is concerned with what must be done, the design phase is concerned with how it
will be done.
- Analysts are also responsible for ensuring design. One of the primary tools is the
structured walkthrough, which is a group review of a program or design. Group
reviews can find errors that the program author may have missed. Users should be
involved in these group reviews since they are the people who understand exactly
how the new system should perform.
- When designing the programs, the analyst must also incorporate security
measure, into the system to guard against potential errors and computer crimes.
Security can include such safeguards such as requiring passwords for users,
keeping backup copies of all files and encoding of sensitive data.
- The analyst also designs the user interface, including all the input forms, output
reports and the formats of displays on terminal screens. Input forms must be
designed in such a way that it is difficult for the user to make a mistake and easy
for any data entry person to enter information into the computer. The primary
concerns when designing output reports are clarity and east use.
- The analyst designs the procedure to be used, specifying for example, exactly ho
an input transaction is entered into the system. The analyst also determines
staffing requirements, such as the data entry people needed and how many hours
the computer will be in operation each day.
- During design, a database designer plans a database i.e. data and file
requirements. The analyst works with the designer, clarifying the requirements
but as merely a consultant.
- The Design Specification is the primary output and documentation of the design
phase. When completed, it contains all the information the programs will need.

Construction
In the construction phase, the computer environment is prepared, the program
required for the new system are written and tested and the user documentation and
training material are developed. The output of this stage is a coded and tested ready
for conversion.

Page 13 of 111
 - Early in the stage, the analyst must see the technicians prepare the computer
environment this can entail installing electrical lines and outlets, communications
lines, furniture, air conditioning etc. Finally, the computer hardware is installed
and tested, usually by the firm for which it was purchased.
- The programmers use the problem and design specifications as a guide for writing
the programs. The more accurate and complete the specifications are, the easier
the programmer’s task becomes and the better the programmers may have to
modify the purchased system at this time.
- The analyst helps to plan the testing process, although the actual testing is usually
done by programmers or a testing group. A rigorously chosen set of test data is
used to ascertain that the new system performs as intended and that it is free of
defects.
- The analyst supervises the writing of the user documentation and training
materials. Documentation can include user manuals, quick reference guides and
on-screen ‘help’ facilities. Users can be trained by instructors on a one-to-one or
group basis or by tutorial programs run on the computer. Thorough
documentation and training are critical if the new system is to be used correctly.

Conversion
During this phase, the company converts from the old system to the new one. The
analyst plans and supervises the conversion, the data entry staff enters any required
data, and finally the operation staff begins using the system on the specified data.

- In many instances, data file from the old system can be moved electronically to
the new system, using some type of software to direct the transfer. In other
situations, particularly if the old system is not computerized, data entry staff must
input the necessary data manually. There must be a way of ensuring that critical
data have been entered correctly.
- Conversion can be done gradually, with part of the new system one month, and
more of it the next month, or it can be done abruptly, by turning off the old
system and turning on the new one on the same day. The safest conversion is the
parallel operation, where both systems are in use simultaneously, for some
period of time. Both are given the same input data and the outputs are compared
to make certain that the new system parallel the old.

Maintenance
In the maintenance phase, system modifications are made after the system is
operational. Maintenance is necessary for two reasons:
• Defects in the system when it was delivered.
The system as delivered may have been specified incorrectly; perhaps
requirements were missed, or the programs as delivered had “bugs”
• Changing nature of the business environment.
A system must also continually evolve to keep pace with the changing business
environment. The business may also introduce a new product line that has
different information needs than existing products do. On the other hand, the

Page 14 of 111
 management may ask for a new report that will greatly aid in decision making.
Whatever, the type of change, the information system must be able to adapt.

The process of maintenance should be controlled by the analyst. When a manager

or user suggests a change to the system, regardless of the reason, the analyst
prepares diagrams and estimates of its impact. Then, the management or a change
control boards decides whether or not to implement the change. If the verdict is
positive, the analyst modifies all system documentation by merging the diagrams
and estimates into the existing problem and design specifications.

The programmers and testing team are responsible for incorporating any change
into the programs and testing the system to make sure problems have not been
introduced as a result of the change. After the change has been certified to be
defect-free, the revised system goes into operation.

Limitations of the cycle approach to system development

(a) It is resource intensive
A long time must spent gathering information and preparing voluminous
specification and sign-off documents. It may take years before a system is finally
installed. If development time is prolonged, it may take years before the system is
operational. Moreover, a system that spends large amounts of time and money to
build may become obsolete while it is still on the drawing board.

(b) The approach is inflexible and inhibits change

The life cycle approach allows for revision to the system to ensure that the
requirements are met. Whenever requirements are incorrect or an error is
encountered, the sequence of life cycle activities can be repeated. But volumes of
additional documents must be generated, thereby increasing development time
and costs. Because of this possibility, the methodology encourages freezing of
specifications early in the development process. These means changes cannot be
made. Once users approve specification documents, specifications are frozen.
However, users traditionally have had trouble visualizing a final system from
specification documents. In reality, they may need to see or use a system to make
sure they know what it is that they need or want. Because this is not possible with
the life cycle, it is common for users to sign off specification documents without
fully comprehending their contents, only to learn during programming and testing
that the specifications are incomplete.

(c) It is not suited to decision oriented applications.

Decision-making can be rather unstructured and fluid. Requirements constantly
change or decisions may have no well-defined models or procedures. Decision-
makers often specify their information needs in advance. They may need to
experiment with concrete system to clarify the kind of decisions they wish to
make. Formal specification of requirements may inhibit system builders from
exploring and discovering the problem structure. This high level of uncertainty
cannot be easily accommodated by the life cycle approach.

Page 15 of 111
 Some of these problems can be solved by alternative approaches to system
building such as prototyping.

CHAPTER TWO: SYSTEM ANALYSIS

What is system analysis?
The oxford Dictionary defines analysis as ‘the separation of a substance into parts for
study and interpretation: detailed examination.

In the case of system analysis, the ‘substance’ is the business system under investigation
and the parts are the various sub-systems which work together to support the business.
Before designing a computer system, which will satisfy the information requirements of a
company, it is important that the nature of the business and the way it currently operates
are well understood. The detailed examination will then provide the design teams with
the specific data they require to ensure that all the client’s requirements are fully met.

The following guidelines will assist the analyst during analysis:

• Check and agree the terms of reference before beginning your work.
• Involve the client as much as possible, both formally and informally, in developing
your understanding of the system.
• Don’t take information at face value.
• Be prepared for some resistance. The analyst is concerned with change and this is
uncomfortable with many people.
• Be aware of political issues in the organisation, but don’t get involved.
• Remember that ownership of the system must always stay with the users.

A structured approach to analysis

Analysis can be considered to be a four-stage process.

1. Understanding the current physical system. This will involve fact-finding activities
and the recording of information about how the current system operates. As part of
this process, the analyst will also be constructing models to show the data and the
processing within the system as well as documenting problems and requirements as
described by the users of the system. The users are required to review and agree the
analysis results.

2. The next stage requires the analyst to move away from the constraints, which
determine how the current system is physically implemented, and to put together a
clear picture of the logical functions carried out by the system. In other words, to state
exactly what the system is doing rather than how it is doing it. This view is described
as the current logical system. Again, the users are asked to review and agree the
logical system description.

3. The required/new logical system. The customer’s requirements for a new information
system must be mapped onto the current logical system. This will state what the new

Page 16 of 111
 system will do. By discussing the requirements with users who specified them,
priorities can be assigned and a number of alternative version can be presented of the
required logical part of the system proposal.

4. The required physical system. This involves specifying in detail exactly how the
system will work. All the business requirements are transformed into a physical
design for implementation on a specific hardware and software platform. As the
issues dealt with here are mainly technical, user involvement will be less than during
earlier stages, but user approval must still be obtained to the final specification.

CURRENT LOGICAL SYSTEM

REQUIRED LOGICAL SYSTEM

REQUIRED PHYSICAL SYSTEM

Structures systems analysis, which is based on the four-stage model described above, also
has associated with it the following principles

• Modelling
• Partitioning
• Iteration
• Documentation
• Review

Modelling refers to the use of graphics models, which are employed wherever possible, in
place of narrative text, to provide clean and unambiguous information about the system.

Partitioning describes a method of breaking the system down into a number of smaller
parts so that it can be more easily understood, so that work can be allocated to the
members of the project team. The system is first considered as a whole to establish the
system boundaries. Once these have been agreed with the users, the system is portioned
on a top-down basis.

Iteration: Since it is unlikely that the first representation of the current system and the
requirement for the new system will be completely accurate the first time, structured
systems analysis provides opportunities for revisiting and amending the models of the
system. If this iteration of the process of analysis is carried out in close consultation with
the users, it will ensure that our understanding of the existing system is correct and
agreed with client before development of the new system begins.

Documentation: Keeping a written record. It is hard to control a project that is recorded

only in the memories of the team members. Team members are not necessarily

Page 17 of 111
permanent. Consistent and up-to-date documentation serves as a permanent record of all
aspects of the project. Without written documentation, it becomes difficult to train new
project team members, to verify the project is fulfilling its original goals and to determine
if it is on schedule.

Review: Using the diagrams of the finished system to uncover errors or misconceptions
before they are incorporated into the end product. This is because, it costs less to abandon
or change a system that exists only on paper. In contrast, finished system are expensive to
modify or even costly to throw away. The earlier in the project life cycle that the
problems are uncovered, the less expensive they are to repair. Therefore the validation
process must begin during the feasibility phase and must continue during each of the
phases that follow.

Planning the analysis process

As part of the planning process, analysts must ensure that:
• They understand the objectives and terms of reference agreed with the client
• They are aware of the constraints which impact the analysis process
• They plan the research, initial contact and other tasks to be completed during the
investigation and manage time appropriately.

Objectives and terms of reference

To understand more about the client’s expectations, you need to ask a number of key
questions at the beginning of the analysis phase of the project:
• Who initiated the project?
• What is their role in the organisation?
• What are their objectives for the project?
• What are company’s objectives?

The main areas of the terms of reference are:

• System boundary – This will define the area of the organisation under investigation
and may also specify the limit of any new system implemented as a result of the
project.
• Constraints – Factors, including budget, time scale technology, which may restrict the
study, or the solution in some way.
• Objective – An ambiguous statement of the expectations of those in the client’s
organisation who have initiated the project. These may be broken down by function
of department. Well-defined objectives are clear and measurable.
• Permission – This will indicate who in the client’s organisation is responsible for the
supervision of the project and, if permission needs to be granted – for example to
extend the scope of the analysis who has the authority to do so. Points of structure
and the appropriate reporting structure may also be defined.
• End products – A clear description of the deliverable or end products of the
investigation. This will usually take the form of a written report and a supporting
presentation to the managers of the client organisation.

Page 18 of 111
THE FEASIBILITY STUDY
A feasibility study is a small-scale analysis and differs from a full analysis in the level of
detail. The results of the study helps the user to decide whether to proceed, amend or
postpone or cancel the project particularly when the project is large, complex and costly.

Analyst should concentrate on providing answers to four key questions:

How much? The cost of the project
What? The objectives of the system
When? The delivery timescale
How? The means and procedures used to produce the new system.

During the feasibility study, a number of structured techniques can be used to record the
finding in an effective way, and later to present data in a graphical form. At the end of the
study a report is prepared for the client.

The feasibility study report has to address three levels of feasibility:

• Technical feasibility Is it going to work?
• Business/Economic feasibility Are cost and timescales right for the business and
Will potential returns justify the initial outlay?
• Functional specification Will the solution satisfy the end users

Sections of a feasibility report

• Background
- Terms of reference
- Reasons for the study
• The current situation
- Overview of current situation
- Problems and requirements identified
• Proposed solution
A description of the requirements of a new system along with a number of options
explaining how this situation might be implemented. Each option will address:
-Technical implications – how it meets the requirements, the hardware and software
needed.
- Operational Implications – The impact the solution will have on the business in terms
of human, organisational and political aspects.
Cost implications – Both initial (capital) and continuing (operational)
• Cost/benefits analysis
A comparison of the costs and benefits prepared using whatever evaluation technique is
favoured by the organisation.
• Recommendations
- Summary of the previous section of the report
- Recommendations as to how the client should proceed; either:

i) Progress with the full detailed analysis

ii) Review the terms of reference or the scope of the study before proceeding
further or making any judgement on feasibility

Page 19 of 111
 iii) Scrap the project as it is not feasible, that the resources could be better spent
elsewhere.

SYSTEM INVESTIGATION/FACT FINDING

Various methods are used to gather facts about the existing system:
• Document inspection
• Questionnaires
• Interviews
• Observation
• Sampling
(The first four are the most popular and are discussed below).

Interviewing
In this technique the analyst personally questions managers and users about the
current system and solicits their options about any new system.

Principle of interviewing
-The analyst must display a likeable character to the user. A user who dislikes an
analyst will almost certainly dislike the proposed system regardless of its merits.
Good user-analyst relationships can contribute to the success of new systems.

- The analyst must project an image of sincerity to the user. We must try to show
that we want the user to solve his or her problems. The best thing is to make a
sure involvement is critical in systems development today.

- During the interview, the analyst should never offer opinions, suggestions or
promises. An interview only a fact-finding session. Solutions are premature. Rash
promises may return to haunt the analyst by causing deep embarrassment. The
best thing is to make a sincere, but general promise.

- The analyst must always behave professionally. He must remain in control of

himself; without antagonising the user or showing anger.

- The analyst should not apply rigid approach to the interview, since the clients as
individuals have unique personality. A method or attitude that may work with one
client may fail dismally with another.

- The analyst needs to be aware of the environment in which he is working. A

business has its own politics and as such the analyst should avoid any
involvement in such internal affairs.

The following point are important to remember as an analyst prepares for an

interview with any user client.

• He should obtain copies of all report that could be discussed during the interview
session.

Page 20 of 111
 • Make an appointment at a convenient time and confirm the appointment with the
client before the interview.
• Define objectives, specifically what information needs to be obtained in order to
concentrate on those areas that are most important.
• The questions should be limited so that the interview takes one hour or less, since
any longer tires the client and the analyst too.
• The analyst should allow the user sufficient time to prepare so that he (analyst)
can have verifiable statistics rather than just estimates for some facts.

Conducting the interview

The interview can be conducted in one of three places: the client’s workplace, the
analyst’s office, or a neutral area such as a conference room. Using the client’s
workplace has the advantage of putting the client at ease. On the other hand, the client
might be distracted such things as phone calls and visitors. Using the analyst’s office
may eliminate the distractions but may have the effect of intimidating some clients. A
neutral area such as a conference room may be less intimidating, yet still minimise
distractions.
- The analyst sets the interview tone. A good first impression is likely to last and
therefore the analyst should strive to make each impression a good one.
- The analyst should explain the purpose of the interview; first that the client has
the business expertise that analyst lacks and second that they must both work
together to develop an effective system. The intent of this introduction is to
convince users that the system will be their system, not the analyst’s system. This
introduction can lay a good foundation for trust and co-operation. The client
should also be assured that any specific request for confidentiality will be
honoured.

Question and Answers period

- The analyst must have some means of recording the information gathered from
the client. As he takes notes, he should maintain eye contact as much as possible.
Alternately, he can use a tape recorder because it frees the analyst so as to be able
to maintain eye contact and concentrate on what the client is saying and how it is
being said.
- Question should be slanted toward the duties and responsibilities of the clients;
abstract, policy directed questions directed to a manager; more detailed
procedure-directed questions to a clerk. We could ask a company vice-president
about the company policy regarding bad-debt collection, but we should ask a
company vice-president about the company policy regarding bad-debt collection,
but we should ask a clerk about the precise procedures used to determine what a
bad debt is and how to collect it.
- The analyst can start with broad and open questions, such as questions to do with
clients’ responsibilities and duties. This is an are which the clients are familiar
with and would enjoy talking about. As the interview progresses, the questions
should become increasingly specific. The ‘specific’ approach will mean asking
many questions, but will also garner more detailed and useful information.

Page 21 of 111
 - After posing a question, the analyst should listen to the answer. Rather than
listening carefully to the answer, picking up shadings of meaning and undertones
as well as the overt response, an analyst may instead be interpreting the answer to
suit some perceived notion or be thinking ahead to the next question. This may
lead to wrong deductions being made.
- The analyst should not accept superficial answers to questions. If he does not
understand the answer or he feels it is incomplete, he should probe for more
information.
- The analyst should also observe the non-verbal communication of the client, for
instance, does the client sit with open arms and uncrossed legs? If so this might
signify that the client is relaxed and open to ideas. On the other hand, a closed
posture and crossed legs could mean nervousness. Eye contact can also give clues
as to what the client is thinking.
- The analyst must avoid doing more talking than listening and asking leading
questions. The types of question depend largely on the objectives of the interview.
Appropriate questions may deal with system controls, current job practices,
analyses of work volumes, data that are available or not available to the client,
data sources, data timelines and accuracy and future information requirements.
- In addition to factual questions, the analyst should ask the client to evaluate and
criticise the current system and offer suggestions for the new one. The analyst
should also allow the client to raise any further points, which the analyst may
have missed.

After the interview:

- The conversation should be transcribed immediately (before the conversation is
forgotten). The transcript should be written on a word processor with a narrative
or question-and answer format. This should include the information considered to
be important from the conversation.
- A copy of the transcript, with a thanks acknowledgement should be sent to the
client for final verification. The transcript should be made available to other
project team members.
- The final stage in interviewing is analysing the information collected to judge
how accurate and unbiased it is.

Advantages of interviews
- They provide instant feedback.
- Closer contact between analyst and interviewee. Both can ask clarification for
questions and answers.
- Helps overcome the fears and resistance to change that may be felt by the
employees and to gain their trust.
- Most appropriate for senior executives, who will have views about what the new
system should achieve overall, and who will have particular information need, but
who are unlikely to be greatly involved in its day-to-day operation or concerned
about the detail of how it does what it does

Page 22 of 111
QUESTIONNAIRES
Sometimes the users are remote from the analyst. Indeed from the development of
products for an anticipated for an anticipated market, the user may not be accessible at
all. In these circumstances, questionnaires can be used to gather facts, attitudes and
suggestions about the system.

Questionnaires are inevitably limited in the information detail that can be collected when
compared with interviews. However, they are valuable in acquiring information from a
large sample of users.

The adoption of questionnaires as a fact-finding tool is not as straightforward as the

inexperienced system analyst might assume. It is wise to give careful consideration to
their employment/application and design.

Situations Suited to Questionnaires

• Where the system analyst is located at considerable distance from the staff to be
questioned e.g. managers for the widespread branches.
• Where there is a large number of respondents such that interviews is prohibited by the
time available e.g. a large sales force.
• As a means of verifying information found by other methods. The questions in this
case must be framed so as to avoid leading the respondent.
• When the questions are simple and call for direct answers, preferably when they are
to be selected from a list of answers shown on the questionnaire i.e. multiple choice.
• When a full set of replies is not necessary in order to determine the facts. People tend
to give low priority to filling out questionnaires, and therefore the response is rarely
100 percent. The sample returned must, however be large enough to provide a
reasonably accurate picture of the situation.

Guidelines to questionnaire design

• Clearly explain the purpose of the questionnaire
• Phrase the questions so that they are unambiguous, concise and unbiased
• Avoid long questionnaires with many different types of information being sought.
• Machine readable questionnaires should be used if at all possible. This permits
accurate and faster tabulation of results. It also dictates using a special machine-
readable form as well as limiting the questions to either true/false, multiple choice or
ranking type of answers. Open (essay questions) must be evaluated manually.
• The surveyor should use terminology the same way it used by the organisation. For
example an employee called a sales representative by one organisation is called a
territory manager by another. It requires sufficient time to learn the organisational
vocabulary before constructing a questionnaire.
• Test the wording and structure of the questionnaire and ask sample respondent to
explain their understanding of each question.
• Decide how the results are to be analysed beforehand. A questionnaire can be set out
in a way which permits direct input of answers into a computer system, where results
can be analysed with an appropriate statistical package.

Page 23 of 111
• Impose a deadline for the response and include a prepaid envelope for postal
respondents.
• Group questions by topics and structure the questionnaire so that the groups follow a
logical order as far as possible.
• Give instructions for answering questions, and if the reply set is known, then make
this explicit and ask the user to underline or circle their choice, e.g. please select one
of the following: novice/experienced/expert.
• Avoid biasing the answer in a question.
• Design the questions; a list of open and closed questions can be used, although it is
useful to restrict the scope of open questions so that the questionnaire focuses on the
area under investigation.

Advantages of questionnaires
• It is relatively cheap, particularly when there is a scattered group of users and
operators.
• It is free of interviewer distortion and error.
• It permits time to refer to document and documentation. Questions which concern
detailed factual data e.g. how many customers live in the Southwest? Are suited to
questionnaire collection.
• It may be possible to ask more personal and controversial questions particularly is the
response is to be anonymous.

Drawbacks
• Low response rates to the questionnaire may lead to unrepresentative responses being
analysed to draw incorrect conclusions.
• Lack of direct contact with the analyst may mean that questions are interpreted in
different ways. There is no opportunity to clarify ambiguities unless a follow-up-visit
or phone call is made.
• There is no possibility of the analyst observing the user staff work place or work
practices.

RECORDS SEARCHING AND DOCUMENT ANALYSIS

Time constraints can prevent systems analysts from making as thorough investigation of
The current system as they might wish. Conclusion can be drawn from a sample of past
And present results of the current system. It involves looking through written records to
Obtain quantitative information, and to confirm or quantify information already supplied
By the user staff or management. Information can be collected about:
- The volume of the file data and transactions, frequencies and trends
- The frequency with which the files are updated
- The accuracy of the data held in the system
- Unused forms
- Exceptions and omissions

The major objective of this exercise is to determine how accurate the documentation is;
Has the organisation made any attempt to update it as its methods have changed?

Page 24 of 111
Therefore, the documentation’s age is a clue to reliability; the older it is, the less reliable
it
is likely to be.

Using this information, as assessment of the volatility of the information can be made and
the existing information can be questioned if it appears that some file data is merely
updated, often inaccurate or little used. All of the information collected by record
searching can be used to cross check information given by the users of the system. While
this does not imply that user opinion will be inaccurate, discrepancies can be evaluated
and the reasons for them discussed.

Where there is a large number of documents, statistical sampling can be used. This will
involve sampling randomly or systematically to provide the required quantitative or
qualitative information. This can be perfectly satisfactory if the analyst understands the
concepts behind statistical sampling, but is a very hazardous exercise for the untrained.
One particular misleading notion is to draw conclusions from the evidence of the sample.

When inspecting data flow through a system, we can collect documents which show how
this information is organised. Such documents might include reports, formal list,
organisation charts and forms. In order to understand the purpose of a document in an
organisation, the analyst must ask questions about how, where, why and when it is used.
This is called documentation analysis.

Observation
Here, the analyst observes in person the current procedures. This shows us how the
system really operates, as opposed to the theoretical procedures detailed in the system
documentation. In many cases, there is little resemblance between the two.
The following issues are pertinent if observation is to be employed for fact gathering:
- Before beginning, we should get permission from the person to be observed and
the supervisor.
- Planning our observation in order to take note of the cross sample of the variety
in a procedure such as when work volume is high, low or moderate and unusual
conditions, like what happens when there is a special order from a customer.
- An explanation to the people we are observing is also necessary. They need to
know that we are evaluating their personal job performance, but instead trying to
understand job procedure and incorporating them, changed or unchanged into the
new system. We should solicit the people we are observing for their opinions on
the current procedures. This is because they will be the people most affected by
the changes we might make.
- Observation should not interrupt or disrupt the activities in progress. By
observation, analysts change the environment that they observe. Their presence
makes the people they are watching to behave differently; being nervous and self-
conscious, people work more conscientiously than they normally would, or they
may panic and may do it more carelessly. For instance factory workers under
observation might follow safety regulations than they would otherwise ignore.

Page 25 of 111
 - Participatory observation in which the analyst actually performs the activity in
question can be a valuable fact gathering technique. Learning by observation can
help one understand more thoroughly than passive observation can.

METHODS/TOOLS OF FACT RECORDING

The analyst collects a considerable amount of information during the investigation phase,
which may include interviewing reports, observation records, sample documents,
completed questionnaires and a list problems and requirements. Some of these relate to
the current system, and some to the new system required by the client.

It is important for the analyst to record this information in an unambiguous, concise

manner which will be clear and accessible to others and which can be used by other
analysts and designers involved in developing the new system. Structured techniques
were developed to help system developers to record information in this way, using
diagrams (or popularly known as models) and a limited amount of text.
Structured techniques are used to model the existing manual or computer system using
information gathered from users. These models are then modified and extended with new
user requirements in order to produce new models of the new, required system. The
model of the required system is based on the current system because there is usually a
core set of processing which will still be required unless there has been a drastic change
in the way the enterprise operates. The data held by the existing system is unlikely to
change although in most cases new data will be required.
Data Flow diagrams and Entity models are two useful tools or techniques. To create and
edit these diagrams, the analyst will also have to make use of CASE tools and data
dictionaries.

DATA FLOW DIAGRAMS (DFDS)

The data flow diagram is the primary graphic tool in the analysis phase of the system
development life cycle. Analysts use DFDs to show what happens to data items as they
flow through a system. In other words it is a model of the processes that transforms data
in a system. DFDs can be understood by uses and are less prone to misinterpretation
than textual description. A complete set of DFDs provide a compact top-down
representation of a system which makes it easier for users and analysts to visualise the
system as a whole.

DFD Components
Entity
External entities represent the source of data that enter the system or the recipients of
data that leave the system. Examples are clerks who receive and enter the data into the
system or customers who receive the letters produced by the system.
Since the entities are not part of the system with which the DFD is about, we are not
concerned with the internal working of an entity, only the data it supplies or receives.

Symbol Customer

Page 26 of 111
 e.g.

Data Store
Data stores represents stores of data within the system. Examples are computer files and
databases, or in a manual system, paper files in filing cabinets. They are drawn as open-
ended rectangle with a unique identifier, a box at the closed end and the name of the store
I the open section. Manual data stores are identified by the letter M followed by a number
and identifiers for computerised stores are prefixed by a D.
A data flow entering a data store indicates an Update (Add, Change, and Delete) to the
file, while a data store from a data store indicates a Read activity.
e.g.

Order

Data Flows
They represent the movement of data between other components, for example a report
produced by a process and sent to an external entity. They are shown as named arrows
connecting the other components of the diagram. Data flow are generally shown as one-
flow only.

e.g.

Stock Evaluation Report

All flows must either begin or end at a process symbol. In logical DFDs, no two data
flows should have the same name. If two flows, separated by a process, appears to be
identical, then it is likely that the process that separated them is not transforming data in
any way and so should be discarded. Data flows moving out of stores do not necessarily
require names because the store name may be sufficient to describe them.

Processes
Processes are transformations, changing incoming data flows into outgoing data flows. In
other words, a process is work that must be done or a function that must be completed.
They are shown as larger rectangles with a numeric identifier in a box at the box at the
top left corner. The location where the process takes place is recorded in a box in the top
right corner and is only used in diagrams of the current physical system. The name of the
process is recorded in the remaining area at the bottom. Process names should be
unambiguous and should convey as meaning as possible without being too long. In
general, names should take the form of an imperative and its object e.g. ‘Open Account’.
Generalised verbs such as Process or Update are not usually helpful. The name of a
process tells its general function.

Symbol:

Page 27 of 111
 e.g.
2 Sales Dept

Note: Compare
(I) A data flow is not permitted between (to or from) a data invoice
store and another
store or a data store and an external entity, only between a data store and
process.
(II) A data flow is not permitted between (to or from) an external entity and
another external entity or an external entity and a data store, only between an
external entity and a process.
(III) Data flows are permitted between processes and data stores and external
entities.
(IV) Note: A boundary is sometimes drawn around a DFD to show (perhaps
arbitrarily) the limits of the system, which is being charted.

DFD Hierarchies/levels
A system is rarely simple enough to be shown on a single DFD and so a hierarchical set
is produced. This consists of a top-level DFD in which the processes are major system
described in more detail by one or more associated lower-level DFDs. The process of
breaking down a higher – level (parent) DFD into its constituent lower-level (child)
DFDs is known as levelling.

Example:
Level 1 DFD for a library system

Delivery note Reservation Card

4 Loans Counter
Supplier Lend Books
1 Acquisition Loan
Order Details
Book
Acquire Books Recall
Supplier Book D1 Book Reservation
Details
Catalogue Borrower

Membership
M1 New Details
Advertised Book Acquisition D2 Borrowers
Details
Membership Card

2 Cataloguing 3 Loans Counter

Catalogue Books Register Borrowers

Publications

Page 28 of 111
 D2 Borrower

4 Lend Books Borrower

Details
Loan
Details
Book Details
4.1 Loans Counter 4.2 Loans Counter

Record loan Record Reservation D1 Box Catalogue

C
Borrower Reservation
Book Retail

D4/1 Loans File C

Borrower
Loan Retail

Reservation Card

4.3 Loans Counter D2 Borrowers File

Record Returns
Borrower
Details

Book Details D1 Books Catalogue

A context diagram is similar to a top-level DFD but with the whole system shown as
‘black-box’. In other words, external entities and data flows in and out of the system are
drawn but no process or data stores are shown. They are used early in a project as a
means of describing and agreeing the scope or boundary of the system to be developed.

Context diagram (Level 0 DFD) for the library system.

Page 29 of 111
 Supplier Publication

Delivery Note

Order
Advertiser
Book Details
Supplier Details

Library System

Reservation Loan
Card Details

Member-
Book ship card
Recall
Borrower
Reservation Details

Borrower

Exercises
1. A purchasing department receives a purchase requisition from the stores. The
requisition is checked, and an individual requisition is returned to the stores for
correction. An order is made out using a file of approved suppliers, and sent to the
appropriate supplier. A copy order is filed. The requisition is filed.

When the goods are received, the invoice is compared with the order copy, and an invalid
invoice is returned to the supplier. Valid invoices are passed to the accounts department
for payment and fulfilled orders are filed.

Draw a DFD for the above

2. When an invoice is received from a supplier, it is checked against a file of authorised

purchases.

Page 30 of 111
3. An electrical wholesale company stocks 20,000 different items and have 1,000
customer accounts. It receives average 150 orders per day with an average of 10
unique items per order.

Orders are taken by telephone, mail and fax in the administration department and over the
trade counter in the warehouse.

The order details are transferred to a 4-part ‘OPD’ (Order/Picking/Dispatch) document

set. The fourth copy is retained in the administration department in a file and remaining
three copies are sent to the warehouse for processing. The store-man assembles the
delivery and amends the OPD set with any alterations necessary due to the unavailability
of stock.

Copy 1 of the OPD (dispatch note) goes with the goods to the customer, Copy 2 goes to
the accounts department for invoice preparation and Copy 3 is returned to the sales
administration where the information is used to update stock records and then filed with
Copy 4 in the order file. Re-order levels are held on the stock record cards and sales
information inform the purchasing department when stocks fall below the re-order level.

If an item goes out of stock, the warehouse will inform the purchasing department who
will raise a purchase order, a copy of which is passed to the goods inwards area of the
warehouse.

Customer returns are inspected by the warehouse staff and return notes are raised and
passed to the accounts for credit notes to be issued.

Supplier deliveries are checked against copies of the purchase order in the goods inwards
area of the warehouse and a goods received note is raised. This is passed first to sales
administration to update their stock records and then to accounts department.

The company has already computerised its accounting system, i.e. Invoicing/Sales
ledger/Purchase ledger and Payroll and is now looking to computerise its order
processing and stock control activities.
You are required to design a computer system to cover the order processing and stock
control activities.

(i) Draw a context diagram showing the external inputs and outputs of the order
processing and stock control system.
(ii) Draw a Level 1 DFD of the current system, showing the processes, flows, stores
and the interfaces with existing other external entities.

Advantages of DFDs
(i) Simple to draw since they use only a set of four standard symbols.
(ii) They help substantiate the logic underlying the flow of the organisation
(iii) Identification of error (in structured walkthroughs).
(iv) They give an overview of the system as a guide to later fact finding.

Page 31 of 111
(v) They show in detail how the system works from overview to minute detail using
the levelling technique.
(vi) They demonstrate in overview terms how various solutions might appear.

ENTITY MODELLING

An entity model representing the network of relationships between classes of things

which need to have data recorded about them in the system. The term ‘entity’ or ‘entity
type’ is used to describe a ‘class of things’. Having drawn an entity model, it is possible
to show how the system can use the relationships by following them as paths for
obtaining related pieces of data either for update or for reporting and enquiry purposes.

One of the commonly used diagrams in entity modelling is the Entity Relationship (ERD)
/Logical Data Structures.

Entity relationship models use 3 major abstractions to describe them. These are:

(i) Entities: These are classes of distinct things about which data is recorded in a
system. It is usually represented as a rectangle containing its name, written as a
singular noun.
(ii) Relationships: Meaningful interactions or associations between the entities e.g. an
entity department may be associated with an entity employee via a relationship
employs. They are shown as lines linking entities. They can be traversed in both
directions and so each end of the relationship is named in order to describe it from
the point of view of the entity at that end.
(iii) Attributes: These are the properties of the entities and relationships. A descriptive
value associated with an entity e.g. Employee Number, Employee Names might to
be attributes of the Employee entity.

The ER modelling, an entity is usually represented as a rectangle

The degree of a relationship

The degree of a relationship specifies the number of relationships in which an entity can
appear. The degree can be:
(a) One-to-One (1:1)
For entity type A, there may only be one member of entity type B and for any entity type
B, there is only one member or entity type A associated with it.
e.g.
MANAGING
DIRECTOR COMPANY

One to One relationship is uncommon as it is usually found that two entities which are
linked in this way can be combined to form a single entity.

(b) One to Many (1:M)

Page 32 of 111
For entity type A, there may be many members of entity B and for any B, there is only
one A associated with it.
e.g.

comprises
DEPARTMENT EMPLOYEE
Works in

(c) Many to Many (M:N)

For any A, there may be many members of B and for any B, there may be many members
of A associated with it.
e.g.

RAW
PRODUCT MATERIAL

Note: Whenever the degree of a relationship is many to many, we must decompose the
relationship to One-to-many or Many-to-one. The decomposition process will create new
entity.
e.g.

BOOK BORROWER

BOOK BORROWER

LOAN

Relationships can also be classified in terms of their optionality is where the analyst
considers whether an entity occurrence at one end of a relationship can ever be present in
the system without the presence of a corresponding occurrence of the entity at the other
end of the relationship.

Page 33 of 111
e.g.

Responsible for
(a) Patient
Doctor
Registered
with

Responsible for
(b) Doctor Patient
Registered
with

Responsible for
© Doctor Patient
Registered
with

(d) Responsible for

Doctor Patient
Registered
with

From the above entity occurrence diagram:

(a) A doctor must be responsible for one or more patients and a patient must be
registered with one and only one doctor.
(b) A doctor may be responsible for one or more patients and a patient must be registered
with one and only one doctor.
(c) A doctor must be responsible for one or more patients and a patient may be registered
with one and only one doctor.
(d) A doctor may be responsible for one or more patients and a patient may be registered
with one and only one doctor.

Relationships can be described as exclusive. One type of exclusively occurs if a detail

entity has two (or more) masters and an occurrence of the detail may only be linked to
one of the masters but not both. The other is the converse situation where a master may
be linked to only one of two or more sets of details.
e.g.

Page 34 of 111
 Doctor Nurse Midwife

Appointment

An appointment may only be made with one doctor or one nurse or one midwife.

Doctor

Research Patient
Programme

A doctor may have responsibility either for one or more research programmes or for one
or more patients, but cannot have responsibility for both patient and research
programmes.

It is possible for entities to be related to themselves in what are called recursive

relationships. That is, individual occurrence of entities can be related to other occurrence
of that entity. For example the relationship between managers in a company. The senior
manager has a number of middle managers working for him, each of whom has a number

Page 35 of 111
of low-level managers working for them. This can be shown by identifying three entities,
senior manager, middle manager and lower manager or by a single entity called manager
which has a recursive relationship with itself.

Example of a recursive relationship

Senior
Manager

Supervisor of
Reports to Supervisor of

Middle Middle
Manager Manager

Reports to
Supervisor of
Reports to

Lower
Manager

Representing attributes
Although E-R diagrams describe many of the important features of the logical model,
they do not show the attributes associated with each entity. This additional information
can be represented conveniently in form of a table.

Tables may be used to represent attributes associated with each entity type. Consider the
following entity relationship:

Assignment of patients to hospital wards.

Assume the key attribute for ward and patient are Ward_Name and Patient_No
respectively.

Ward Patient

Assigned to

WARD TABLE
WARD NAME WARD TYPE
LONGONOT ORTHOPAEDIC

Page 36 of 111
TANA CARDIAC
ELGON MENTAL
KIRINYAGA ORTHOPAEDIC
PATIENT TABLE
PATIENT_ NO PATIENT_ NAME WARD_ NAME
1294 JAMES ELGON
1201 MARY LONGONOT
1301 CAROL LONGONOT
1152 TED TANA
1350 SMITH KIRINYAGA

Types of attributes
Key attribute
This is an attribute that uniquely identifies each type e.g. Patient_No, COURSE_
CODE, STUD_ NO, WARD_NAME. It is also called a primary key.

Candidate keys- Is a set of all possible unique identifiers. Each entity type must have a
least one-candidate key. For a given entity type, we choose one of the candidate keys to
be the primary key. The remainders are called alternate keys.

Composite key- When the primary key is a combination of more than one key, we call the
combination a composite key.

Foreign key- An attribute in one table whose values are required to match those of the
primary key of a different table. Foreign keys are means of maintaining relationships
between entities in relational DBMS e.g. in the PATIENT table above, the Ward_Name
is a foreign key since it is the key since it is the key attribute of the WARD table.

Another way of representing attributes are underlined while the non-key attributes are
not.

DATA DICTIONARY

The Data Dictionary (DD) is a storehouse of data about data. It is the single place in the
system where one can go to learn more about any piece of data in the system.

The Data Dictionary defines templates for the data that the finished system itself will
eventually store. These templates tell the format, where and how data items are used and
any components that make up the data item. For instance, the data dictionary entry for
invoice number would not give specific invoice numbers, but it would instead state that
the invoice number is a numeric field, five digits long that is used within certain files in
the system.

A DD serves all phases of the System Development Life Cycle from analysis onwards. It
is not merely documentation that is haphazardly created at the end of the project; rather it
is a tool to be used from very beginning (of analysis). It may start out small, but it can

Page 37 of 111
expand at a high rate as a project progresses through design into programming.

A data dictionary may be manually compiled or it may be fully automated (The

automated DD is referred to as the Data Dictionary Software (DD), but for simplicity it
is known as the Data Dictionary).

Usually data is held about three of the four main components of the Data Flow Diagram;
the Store Process, and the Flow. It is also necessary to record information about the entity
descriptions that support the logical data structure and the attributes (data elements or
data items) contained in each description. Thus in a DD, it is necessary to hold entries
about data elements, data structures, data flows, data stores and processes. The structure
of the Data Dictionary for each of these will vary.

Basically, a data dictionary provides a method for looking up the items of data held in the
database, to establish the following:
• A list of the entity, attribute and relationship types.
• A list of the aliases
• A list of all processes which use data bout each entity type
• How to access the data in whatever manner is required
• What the data codes and symbols mean
• The origin of the data
• Possible range of the data
• Other comments

Data Dictionary: Data Element

Name: A meaningful unique name.

Description: A short description of the meaning of the data element. An example might
be included.
Aliases: Several departments may refer to the element by a different name or term.
This has to be explicitly recognised and may require a large amount of
detective work. Different employees in an examination system may be
using the terms “Unit” and “Module” to refer to the same data element.
This was can only be recognised through the analysis work required in the
compilation of the Data Dictionary.
Type: Usually Character, Numeric or alphabetical.

Format: To prepare for Format Checks in the subsequent system design. A

convention for representing numbers by nines (9) and characters by Xs
can be adopted.
Values: Discrete data elements have a meaning associated with each value. Listed
below are some example from a payroll system.
33 Area of Pay
701 Sickness Benefit
52 Maternity Pay

Page 38 of 111
Security: Who (or which level of employee) is allowed to modify, add or delete a
given data item. This will be important in the design of security features
such as passwords and audit checks.

Editing: This may concern the way in which data is produced from the system For
example, should a credit of £30 be shown as –30, +30,30CR or (30)
Comments: A final section in which to record special information about this data
element.

Example:

Data Element Name: ENROL NO

Short Description: Student Enrolment number, this is
Made of COLLNO, YEAR, ADMIT

Aliases: STUPID, APPLICNO Type: Positive integer

Plus check letter
Format 999-9999999-A
VALUES
Part A is a discrete value assigned to 1. Part C is continuous within year
identify this college. This is the same 00000- 99999
for all students attending this college. 2. Positive values only

Part B is the year of enrolment 3. Last enrolment number assigned is

e.g. ‘93’ stored as LASTENR

Part D is a check letter

Validation
1. Check college ID matches COLLNO
2. Check ENROLNO does not appear on X ENROL list
3. Use algorithm to validate check letter
4. Check is < LASTENR
Editing
1. Once assigned, ENROLNO is never changed

2. When a student leaves ENROLNO is not assigned to another student, it is added

to the XENROL list of unused enrolment numbers

Where used

Programs Common routine

Enrol student (ENROL) Validate enrolment number
Record exam result (RECRES) (VALENROL)
Assign tutorial groups (ASSTUT)

Page 39 of 111
ENTITY LIFE HISTORIES

An entity Life History is an analysis technique within SSADM that is concerned with
- Identifying events that cause change in stored data.
- Establishing the sequence of these events
- Defining valid states for entity occurrence.

Events and Effects

An ELH shows the events, which may have an effect on a particular entity occurrence (or
record). An event can be defined as something that triggers a process to update system
data. An event is not a process, it is the stimulus which causes that process to be invoked.
So, for example, the process might be Create Order but the event is Receipt of Order
or Order Received. In practice, due to the diagram space constraints, event names are
frequently shortened. Examination Results, Examination Notification, Resignation, etc.
However, care should be taken that the name reflects the event rather than the DFD
process, otherwise there is a danger that other events triggering the same process may be
missed.

Three types of events can be distinguished:

• External event – A transaction arriving from the outside world. For example Receipt
of Order. These events are normally associated with data flows of the Data Flow
Diagram.
• Internal process event- This occurs when a predefined condition within the stored
data has been met. For example, the Ship Cleared event takes place when all the
timber has been sold from the timber berth.
• Time based event – This occurs when a particular process is to be triggered at a
regular time interval: a set time of day, month, year, etc. For example, the event Pay
wages on each Friday at 1400 Hrs.

A single event instance may cause more than one entity occurrence to change. The
changes within a single entity occurrence caused by an event is called an effect.

An effect can lead to the:

- Creation of a new entity occurrence:
For example receipt of order causes the creation of an entity occurrence Order.
- Deletion of an existing entity:
For example, Resignation may cause the deletion of an entity occurrence of
Member.
- Modification of existing entity occurrence:
For example, Payment Receipt causes the modification of the data item
Amount_Due in the entity occurrence Customer.

Entities Life Histories Notation

The ELH is a tree-like structure where:
• Nodes are drawn as square-cornered boxes.
• The root node represents an entity type and contains the name of the entity.

Page 40 of 111
• The elementary (leaf) nodes represent events, which have an effect on the life of an
entity occurrence of the entity type.
• The elementary nodes (effect) contain the name of the event.

The typical life of an entity starts with an event which triggers processing to create a new
entity occurrence. Once an entity occurrence has been created then an event can trigger
processing whose effect is to modify attribute values of that occurrence. At some later
time in the life of the entity occurrence an event will occur which will trigger processing
which have the effect of terminating the life of that occurrence. A terminating event
means that the occurrence is archived or transferred to another file for use by other
systems. The typical life of an entity illustrates the fundamental structure of an ELH.

Sequence
The sequence is fundamental to all ELSH. This structure is shown below. It shows the
chronology of events for a Course Attendance. Notification of Enrolment (create
occurrence event) always takes place before the Written Examination Result can be
notified. The Written Examination Result event occurs before the Notification of
Graduation (terminate occurrence event).

Course Attendance

Notification of Written Notification of

Enrolment Examination Result Graduation

Sequence of events

Selection
In the figure below, the small circles in the two Assessment events denotes that these are
alternate events. Thus an assessment event is either a notification of a written
Examination Result or a notification of an Oral Examination Result. The alternative
events are grouped under a selection node.

Page 41 of 111
 Course Attendance

Notification of Assessment Notification of

Enrolment Graduation

Written Examination Oral Examination

Result Result

Iteration
The asterisk (*) in the figure below denotes that the event may affect an entity occurrence
zero or more times. Continuos Assessment Result may result before the Notification of
Graduation occurs.

Course Attendance

Notification or Assessment Notification of

Enrolment Graduation

Continuous
Assessment Result

The figure below illustrates the iteration of a substance of the ELH. In this case, the
sequence of events notification of Written Examination Result and notification of Oral
Examination Result may not occur, may occur once, or may occur many times. Each
instance of the iterated sequence must be complete before the next sequence can begin.

Page 42 of 111
 Course Attendance

Notification of Course Life Notification of

Enrolment Graduation

Assessment

Written Oral
Examination Examination
Result Result

QUALITY IN SYSTEMS
A good system should:
- meet the needs of the user
- be cost effective.
- Be produced on time and within budget.

Quality Concepts
The term ‘quality’ means different things to different people, depending on their
perspective. To some, it means, ‘finding the error’ or ‘making sure it is correct’ and
involves checking the deliverable of a system. For others, it is about the process of
production and means ‘doing it right first time’, achieving the standard’ or getting the job
done in the best possible way’. All these definitions point to the fact that there are a
number of dimensions to the concept of quality.

Our working definition is:

Conforming to the customer’s requirements’
Where ‘customer’ can be either an external customer ( a client) or an internal customer (a
colleague) and ‘requirements’ relate to both the product and the service delivered.

The following general principles about quality apply in organisations:

• Quality is a continuos process for an organisation
• Building quality into the production process- prevention- is more effective than just
testing or checking the product at the end of the process- inspection.
• The management is the agent of change, and that training and education should be
continuous processes at all levels.

Page 43 of 111
What are the implications of these ideas for software developers?
• There needs to be a greater investment of time and effort in the early stages of system
development, if the correcting at the end is to be reduced. Research has shown that
75% of software development cost are associated with testing, debugging and
maintaining software, and if this figure is analysed, over 80% of the testing,
debugging and maintenance cost can be traced back to problems introduced during
analysis. A more systematic approach to analysis could make a dramatic difference to
these figures, and this is the purpose of the structured methods.
• Their cost of correcting an error during implementation is many times greater than
the cost of putting it right during analysis. The use of reviews and walkthroughs at
every stage of development would help with the early detection of errors.
• By investing in the training and training and development of their staff, a company
will be raising the chances of doing the job right first time and also building the
client’s confidence.
• Management as an agent of change, must take the lead in making quality an intrinsic
part of the development process. Often software development project managers don’t
give the projects a chance to achieve this because they only focus on two issues: “Is
the project running according to budget?” and “Is it on schedule?” rather than first
asking the key question. “Are we meeting the customer’s needs?” Once this has been
addressed, the other questions about schedule and budget can then be asked.

Quality Management
To ensure the quality is maintained when developing software so that products and
services are delivered which conform to the customer’s requirement, three concepts are
important – quality control, quality assurance and quality management.

Quality Control is the task of ensuring that a product has been developed correctly – to
requirement and to standard – and that the procedure identified for its development is
effective and has been followed.
- It is done best by the person or team who did the work, but it should include an
independent contribution from a peer – someone who could have done the work,
but who didn’t. For instance, a complete system design document should be
reviewed, not just by the person who has written it, but also by an independent
person.
- It also covers the procedure and methods used for the work. These must be
identified beforehand, even if they are the usual ones, in a quality plan, and any
deviation from them must be explained and assessed.
- Records should be maintained on how quality control has been carried out, and to
indicate on the product or if this is not possible, on an associated record that this
has been done successfully.

Quality Assurance is the responsibility of a smaller group of people. Someone

independent of the work area or project checks that quality has been performed, that it
has been effective, and that the products are complete and suitable for delivery or for
further use by someone else within the project.

Page 44 of 111
 Quality Management is the establishment and maintenance of a quality system within
the organisation, the company, the division or the project and is usually the
responsibility of senior people in that areas.

Quality pyramid

QUALITY
MANAGEMENT

QUALITY ASSURANCE

QUALITY CONTROL

The foundation of an organisation’s quality management system is a statement of its

objectives and policy for quality, which should, of course correspond to the type and
scope of product or service being offered. The must be a description of the
responsibilities and the internal organisation for the QMS, to ensure that quality
control and quality assurance practices are understood and are operated effectively. A
major reason for doing this is to allow an external customer to assess the supplier’s
attitude and approach to quality, both before work is placed with the supplier, and
throughout the progress of the work. A QMS is a company’s framework, within
which all the work is performed, using only procedures and methods, which are
defined, checked and visible.

Standards
A QMS will specify the standards to be used for tasks carried out within the
organisation.

Why are standards necessary in organisation

- To help people do the job right the first time (prevent mistakes)
- As a means of communication

Page 45 of 111
 - Making it easier for teams to work together
- Ensure that products developed will be compatible and contribute to producing
consistent maintainable system.

Benefits of a formal Quality Management Systems

- It helps the to identify the company
- It helps to ensure repeat business
- It makes practices coherent (rational)
- It helps new joiners settle in more easily.
- It gives greater confidence in the company’s ability to deliver.
- Products get the stamp of quality.
- It brings companies closer to their customers.
- Businesses become more professional in their approach.
- A sense of ownership is created within the organisation.
- A quality culture attracts quality people to work for the company.

A quality manager will usually have a day-to-day responsibility for the QMS, although
this may not need to be a full-time role once the quality system is established and running
effectively.

The QMS is documented in a quality manual which also includes or refers to descriptions
of the methods and procedures used on work tasks. This manual also becomes a valuable
marketing and selling aid, as it provides evidence to the outside world of the means by
which a supplier achieves quality of work and product, and is part of the basis on which
the quality system can be assessed.

Quality in the Structured Life Cycle

In the traditional approach to developing an information system, there was little or no
quality checking at each stage of the development process. There was ample testing of
programs, interfaces, sub-systems and finally the complete system, which ensures that
when the system went live, it worked. However the quality system did not ensure that the
working system satisfied the requirements of the customer who has asked for it.

If testing is properly designed and planned, it can be very effective as locating defects.
However, testing has the following disadvantages:
• It can never be completely comprehensive.
• Checking every path through even a simple program can take a large amount of time.
• It is particularly difficult to trap defects introduced in the earliest stages of analysis
and design, or facilities that have been ‘lost’ between one stage of development and
the next. Such defects are the ones that cause the most concern.
• It can only be done in the later stages of development at it actually exercises code.

Various studies show that at the testing phase the cost of correction may be many times
greater than correction made before the coding begins.

Page 46 of 111
With the introduction of structured approaches to system development, each stage of the
project became a ‘milestone’, the deliverables of which had to be signed off by the
developer and the customer before the next stage began. This ensures that not only does
the system work when it finally goes live, but also that the client is in full agreement with
the interpretation of the requirements – from the earliest stage to final implementation. A
procedure for agreeing and signing off milestones which is part of many structured
methods is the structured walkthrough, while a more formal technique which is also used
on software development project is the Fagan inspection.
Structured Walkthrough
It is the review of products at the end of a stage in the development of a system by a
group or relevant and competent persons.

The prime objective of a Structured Walkthrough (SWT) is to identify problems and

initiate the necessary corrective action.

Structured walkthroughs are done at all stages of a project, from the models of the
analysis phase to design and onto the programs and documentation of the
implementation. Organisations that subject all systems to stringent walkthroughs can
reportedly reduce the program error.

Types of Walkthroughs
(i) Formal- It is a full review of the work done in one stage of the structured
development and involves the client.
(ii) Informal- It is internal to the development project and reviews each step of the
development within a stage. User involvement is optional.

Roles in a walkthrough
Presenter Is the person who has done all the work and is now submitting the relevant
documentation for quality assurance.

Chairperson Is the person responsible for:

• Circulating the documentation prior to the meeting
• Choosing the time and the location
• Chairing the meeting

He must familiar with the appropriate standards.

Secretary Is the person responsible for documenting the problems raised and then
reading them back at the end of the meeting so that priorities can be
assigned and follow-up action agreed.
Reviewer Is a person from the same project as the presenter.

In formal walkthroughs, there will be extra reviews:

A user representative mandatory for the formal agreement and signing off of a
development stage.

Page 47 of 111
An extra observer from another project, an optional role which can be useful in providing
objectivity.

Even though each team member has a primary function, all are equally accountable in
terms of examining the quality of the system and offering comments and criticism. The
responsibility of the team is to give an accurate appraisal/assessment, good or bad of the
product being reviewed. All criticism should be specific, indicating exactly where more
work is needed. The participants should identify defects, but should not attempt to correct
them, since correction is the responsibility of the author.

Stages of a structured walkthrough

Preparation, Meeting, Follow-up.

Preparation
- This should be done at least three days before the walkthrough meeting.
- The presenter prepares documentation on the product to be reviewed.
- Presenter passes documentation to chairperson who then distributes the
documentation and notifies the reviewer of the time and location of the
walkthrough meeting.

Meeting
- It should be kept short – preferably 60-90 minutes.
- Presenter walks the reviewer through the product. The prime purpose is to ensure
the product meets the requirement and conforms to the appropriate standards and
that any defects are identified. Additional benefits is to spread information,
knowledge, ideas and new approaches.

Follow-up Actions:
- Accept and sign off product.
- Recommend minor revision with no need for a further review.
- Recommend major revision and schedule another walkthrough to review the
revised product. In this case, the person creating the product will have a written
record of the identified problems produced by the secretary, and the actions
required. The necessary corrections are then made for resubmission in the next
walkthrough.

Problems associated with Structured Walkthroughs

- Inadequate preparation by the reviewers
- Too much time spent discussing solutions rather than identifying defects
- Author being defensive about his work
- Walkthrough rambling on for too long.
- The tendency of people to forget the important points in favour of arguing over
the inconsequential parts.
- The tendency to fix blame on others; and the tendency to behave as prima donnas,
upstaging everyone else in an attempt to discredit the work of another member.

Page 48 of 111
Solutions to problems
It is the chairperson’s responsibility to avoid these problems by:
- Enforcing a time limit.
- Ensuring walkthrough standards are adhered to.
- Reminding attendees, before the meeting of the purpose of the walkthrough and
the importance of preparation.
- Careful selection of team members
- A checklist of specific topics for review should be available to keep a team on
track.

The outcome of the walkthrough is the walkthrough report prepared by the scribe. On
the first page; the summary, all participants must sign the report to show that they are in
agreement with it. This reinforces the ideas of shared responsibility for the quality of the
product. At the bottom of the summary page, the final verdict is given. The product is
accepted as it is or with minor revisions, or it is rejected. Rejection is broken down into
three categories; the product has so many flows that it must be completely rebuilt, the
product needs major revisions, or the review was incomplete and must be continued later.

Fagan Inspections
A Fagan inspection is a formal review technique developed by Michael Fagan, a British
Engineer who worked for IBM. It was based on established review methods, such as the
structured walkthrough, but was designed to eliminate the problems with walkthroughs.

An inspection can be defined as a formal examination of an item, against a previously

produced item, by a group of people led by an independent chairperson with the
objectives of:
(i) Finding and recording defects, using standardised checklist and techniques.
(ii) Initiating rework as necessary, monitoring the rework.
(iii) Accepting the work based on stated exit criteria.
(iv) Adding to and utilising a base of historical defect data.

The objectives of a Fagan inspection is to identify and correct as many defects as possible
early in the development process, so that the next stage can proceed with confidence, and
to minimise the number of defects in the final system so that maintenance costs are
reduced.

The inspection process consist of a number of fixed stages:

(i) Planning – The inspection team is appointed and any administration is performed
(ii) Overview – Ensure that those inspecting the document understand how it fits into
the system as a whole.
(iii) Meeting – The document is formally examined
(iv) Rework – All defects found are corrected, performed by the author of the
inspected item.
(v) Follow-up – Checking that the rework has been performed adequately.

Page 49 of 111
MOVING FROM ANALYSIS TO DESIGN
In structured methodologies, a lot of emphasis is placed on the need to spend
considerable time and effort ensuring that analysis is rigorous so that the design process,
and later the implementation, will be straightforward. A key factor is the use of structured
techniques and they help in ‘bridging the gap’ between analysis and design.

BRIDGING THE GAP

In traditional approaches to system development, there was frequently a gap between the
information about the system document by the analyst, and the detailed technical task
which lay ahead for the designers. While the existing physical was described in detail,
usually in the form of a lengthy narrative, it still the designer, who had to produce designs
for files or databases, processes or interfaces and controls, with a lot of unanswered
questions. Analysis ends with a description of what the system must do, while design
must specify how this will be done by selecting one of the many possible ways of doing
it. The gap between the end of analysis and the beginning of design is shown below.

ANALYSIS DESIGN

Describing WHAT Describing HOW

the system will do THE GAP the system will do

All structured methodologies share the view that logical models must be integral to the
process of system development in order to ease the transition between analysis and
design, and also to enable intermediate views of the system to be discussed with the
users.

A logical model describes exactly what the system does rather than how it does it, by
ignoring the physical constraints, which determine how the current system is physically
implemented. A required logical model. The structured techniques during analysis which
provide this logical view include:

Page 50 of 111
• Data flow diagrams
Representing the processes, which manipulate the data as it, passes through the system.
• An entity model
Showing the relationship between the data items held within the system.
• A data dictionary
Providing an overall consistent definition of the data used by the organisation. This
definition can include the content of the data stores, data flows and processes shown on
the data flow diagrams, and the entities, which make up the entity model.

ANALYSIS
DESIGN

P lanning Data Flow Diagrams Of CONTROLS

A sking INTERFACES
R ecording Entity Model
I nterpreting DATA
S pecifying Data Dictionary

THE BRIDGE

These logical models provide a sound basis for the process of design and the designer
will use, amend and develop these models to create design documentation. For example,
data flow diagrams is the starting point for designing input to the system such as an order
form, outputs from the system such as a sales report and human computer interfaces such
as an on-line enquiry screen.

In this way the logical model support both the current system which is in operation. And
the new system being developed, and can be used to overcome the analysis/design gap by
providing a ‘bridge’ of techniques central to the process of analysis and design.

PROBLEM SPECIFICATION

By the end of the analysis phase, the analyst has accumulated a lot of separate
documents, from process descriptions to data models. At some point, these need to be
bundled together to from the problem specification, which will be used by designers and
programmers throughout the life of the project.

Components of Problem Specification

Typical contents of a problem specification are:

Page 51 of 111
• Table of Contents
A list of what the problem specification contains is a necessity.

• Current System Deficiencies

Going through the feasibility study, the interviewing, and the creation of system
models, the analyst found many problems in the current system. These problems must
be set down in a formal list.
• New system Restrictions
The analyst must document any restrictions that will limit the choice of system,
including the resources available (machine, people, and money) and the maximum
time until the project completion (because of external deadline, such as a new product
going into production). Sometimes there are other restrictions such as stipulation that
the new computer must be compatible with the computer in the home office, which
might dictate the purchasing of the new hardware from a particular vendor.

Acceptance Criteria
The analyst has also to indicate what must be delivered by any new system. This is
detailed in the acceptance criteria. The acceptance criteria will later be referred to
when the analyst tries to prove to the users that the system meets the users’ stated
requirements. These criteria serve as a protection for the users, ensuring that the
requirements have been met.

In order to be effective, the acceptance criteria must be measurable. For instance, how
could we prove to the user that the system has managed to “improve collection of
overdue accounts”? Precisely what does “improve” mean? Can we measure it,
quantify it? Hardly. This requirement could be more clearly stated in this form:
“lower the percentage of bad debts from the current 10% of the accounts receivable to
36%. Reduce the average days overdue from the current 120 days to 90 days. Reduce
the average account balance from the current $5,400 to $3,500”. That these
requirements have been met can be verified to the users’ satisfaction.

Nevertheless, the analyst must keep in mind that the users’ expectations of what the
system can do for them will change as a project progress. One reason for this is that
the business environment cannot remain static until the system is complete. One
reason for this is that the business environment cannot remain static until the system
is completed. Another reason is that as the users become acquainted with the system,
they will gradually discover more ways in, which could help them if only those
functions could be incorporated. Analyst must work closely with the users so there is
some means of modifying the system and its acceptance criteria and its project
progress.

System models
Each proposed system model consists of DFDs (showing the evolution from the
current physical model to the new physical model), process specifications, data
models, and cost-benefit analysis.

Page 52 of 111
 The chosen model is not put into problem specification. It should be accompanied by
management’ written authorisation to continue forward with this option and
documentation as to why management felt this was the best choice.

The rejected system models are included in an appendix to the problem specification,
where they will be out of the way yet available for reference. Analysts never throw
away anything on which they have expended a great deal of work; it might be needed
again. Perhaps two years from now the president of the company will decide to go
with that high-cost option that was currently rejected. If so it will be ready.

Data Dictionary
The data dictionary has been modified as the project have progressed, so it should be
in its finished form at this point.

Guide to problem specification

The guide to problem specification contains whatever information is necessary to
tutor a new member in using the problem specification. It includes the explanation of
each document and the conventions adopted for each one. The guide should be
reusable from project to project.

Index
All key concepts and the terms should be included in the index.

Anything else required by the users, management, or good sense.

No two projects are alike, and each will have peculiarities that need to be documented
at this stage. For example, a user may have a pet report that she absolutely has to see
designed at this point. Although report formats are not parts of conventional problems
specification, in the interest of user satisfaction, the format should go in.

CHOOSING SOFTWARE AND HARDWARE

This decision must be made at the end of the analysis phase, for much of the design
phase can be omitted if the decision is made to purchase. Once the requirements of
any new system have been specified, the analyst can then look at available software
packages to see which ones most closely fit the user’s needs, all without actually
‘designing’ that system.

Even though most analyst and programmers are more pleased in designing and
building a new system from scratch (since it is what they are trained for), it is
economically more feasible for a many businesses, especially smaller ones, to buy
rather than to build software. Commercial software has several

Page 53 of 111
 Advantages.

- They are cheaper. The cost of development is distributed among many

purchasers, rather than being carried solely by one organisation.
- They are already debugged. If several organisations have been using the software
for some time, it is reasonably. Safe to assume most of the bugs have been found
and fixed.
- They are available sooner.
- User personnel can bring up the new system in less time. Most organisations have
other activities on which the staff should be working, so this can be a critical
consideration.
- Users can try out the product without investing a great deal of money.

Disadvantages
- Only rarely will it meet the needs of the users. Users may have to adapt their
procedures to the requirements of the software, or analysts may be obliged to
modify the software, (which can be expensive if not impossible).
- It may not be compatible with existing software applications in the organisation.
- Different applications from different vendors will mean that each application will
have a different user interface, making it difficult for users to use various types of
software.
- There may be no in-house expert on board from the first day the application goes
to use.
- They cannot be easily modified if the needs of the users change in the future.

When evaluating commercial software, an analyst might use a decision table format
to consider the following:

• How closely does the package with what is needed? Will it be necessary to
modify the programs, or the proposed system procedure, or both?
• How stable is the software vendor? Will the company still be I the business in a
year or two in case any problems arise?
• Does the vendor give prompt, courteous, and reliable support when problems
arise? A toll-free 24 – hour telephone line is a good omen, but test by calling with
a question to see what kind of response is given and how often the line is busy.
• Will the vendor be providing ongoing enhancements and upgrades to the
software? At what cost?
• Are source programs supplied so that the organisation can do its own
modifications?
• Is there a trial period during which the package can be returned for a full refund?
• How many other installations have used the software package? For how long? (A
vendor should supply a list of users’ names, but it is not always helpful to ask
those users for evaluation. The vendor would not likely be likely to give out the
names of dissatisfied customers. We could ask those users for second level-

Page 54 of 111
 reference- other organisations they are using the package, but which the vendor
has failed to mention. There is where the skeletons can be uncovered.)
• How flexible is the software? Can it change along with the changing business
environment? Are there any growth limits on file size, number of transactions, or
embedded tables?
• Is the software user-friendly? With what other applications currently used by your
organisation does this application communicate? With what other applications
currently on the market (both from the vendor and others) does it communicate?
Do these various compatible application packages have similar user interfaces?

Only after collecting data on the various software packages available does the analyst
begin to worry about choosing hardware. The software is really what determines how
well the computer meets the user’s needs, so there is less anxiety connected with
choosing the hardware on which that software runs. There are a few constraints on
hardware selection which are much the same as many of those detailed for software;
stability of the vendor, existence of a trial period, satisfaction of the users, flexibility
and user-friendliness. In addition, machinery should be upwardly compatible,
meaning that the user organisation can easily upgrade to a larger or faster model in
the future without scrapping existing data or programs.

When shopping for hardware, the analyst sends out a Request for Proposal (RFP)
vendors that might be able to supply the necessary equipment. In return, interested
vendors return a proposal listing the specifications for their hardware and its cost.

Of course the organisation is always concerned with the comparative costs of the
various system solutions in both hardware and software selection. The costs and
benefit to the alternative solutions to a system problem need to be evaluated in depth
regardless of whether the solutions involve commercial or custom-programmed
software, or hardware from one of several vendors.

Page 55 of 111
 CHAPTER THREE: SYSTEM DESIGN
Objectives of System Design
It is important, right at the start of the design process, for the designer, or design
team, to set clear objectives. The primary objective will always be to design a
system, which delivers the functions required by the client to support the
business objectives of their organisation. For example, the system may be required
to speed up the production of accurate invoices, so that the company’s cash flow can
be improved; or to provide up-to-date, detailed management information to improve
the managing director’s control over the business; or to help senior managers to make
strategic decisions. In other words, to be a quality product, a system must conform to
the customer’s requirements, and to be delivered in a way that meets their
expectations.

Other objective which must be considered if a good design is to be produced:

(i) Flexible
The design should enable future requirements of the business to be
incorporated without too much difficulty. Often, during the analysis phase
users may not be clear about exactly what they will require from the new
system for example which reports will be most useful to them. However,
during the evaluation period after the new system becomes operational, the
real needs often merge and a flexible design will be able to accommodate
these new requirements. In addition, businesses change over time and a good
design enables the system to reflect these changes.
(ii) Maintainable
This is closely linked to the previous objective because it is about change. A
good design is easy to maintain and this reduces the client’s maintenance
costs, which usually represent a high proportion of the total lifetime cost of
the system.

(iii) Portable
A client who has bought a software system may wish to change the hardware
on which the system runs. A good design is portable – in other words it is
capable of being transferred from one machine environment to another with
the minimum amount of effort to convert it.

(iv) Easy to use

With the increasing exposure of people to computer applications at home as
well as in the office, expectations of computer systems in terms of their ease
of use are also increasing. A good design will result in a system that is ‘user
friendly’ – easy to understand, not difficult to learn how to use and
straightforward to operate.

(v) Reliable

Page 56 of 111
 This objective is about designing systems which are secure against human
error, deliberate misuse or machine failure, and in which data will be stored
without corruption. While this is desirable in any computer system, for certain
systems in the areas of defence, process control or banking, it will be a key
design objective.

(vi) Secure
In order to protect the confidentiality of the data, particularly if it is
commercially sensitive, it may be important to build in methods to restrict
access to authorised users only, for example by introducing passwords.

(vii) Programmer-friendly
While the other objectives are mainly about delivering benefits to the client,
the designer must also consider how easy it will be for the programmers to
produce the code from the program specifications. By producing a
programmer-friendly design, both the costs of production and the risk of
building in errors are reduced.

(viii) Cost-effective
This includes a number of the other objectives, and is about designing a
system, which delivers the required functionality, ease of use, reliability,
security, etc. to the client in the most cost – effective way.

Design Constraints
In addition to time, which is always limited, and money-the available budget will limit
the options available to designers – there are a number of other constraints, which need to
be taken into consideration. These are:

• Resources
The availability of resources – particularly the technology to be used in delivering a
solution to the client.

• The client’s existing systems

A major constraint would be the need for a new system to interface with other
system-hardware, software and manual – which already exist and will continue to be
used by the client organisation.

• Procedures and methods

The final design might also be constrained by internal or external procedures,
methods or standards. For example, it might be a company standard to develop
systems is SSADM, the CASE tool to be used in development might be specified, as
might the programming language in which the system must be coded.

• Knowledge and skills

Page 57 of 111
 The knowledge and skills of the development team may limit a designer’s options, as
might the competence or ‘computer literacy’ of the potential users. Also, financial
considerations may be important here – ‘how much does it cost to employ two
trainees compared to the cost of employing one expert?’

Elements to be designed
i) System security and controls
ii) Human Computer interfaces; Outputs, Inputs, Dialogues, etc.
iii) Logical data: entity modelling and normalisation
iv) Files
v) Databases
vi) Physical data design
vii) Programs
viii) Choice of hardware

Human-Computer Interface design

The specification of inputs, outputs and dialogues forms a key part of the designer’s task
because of the high visibility of these interfaces to the users. The output produced by the
computer is the main reason for developing the new system. If the users are clear what
they want from the system, the inputs needed to produce this output can then be
identified. Should the output fail to meet the requirements of those who have to use it, the
system can be seen as a waste of time by those users, who may little appreciation of the
internal, and therefore invisible, sound design or elegant code.

The layout of a screen and the consistency of the dialogue will be important to those
users who have to spend a lot of time sitting in front of terminals, and who will base their
evaluation of the whole system on these interfaces. If the method of entering data is
difficult, because of a poorly designed input form, for example, then the chances of
inaccurate data entering the system will be greatly increased, which will in turn affect the
value of the output produced. The time and efforts spent getting the design of forms,
screens and reports right will enable the designer meet the objective mentioned earlier of
making the system easy to use.

OUTPUT DESIGN

Having identified from logical model of the new system where the outputs will be, by
listing those data flows, which cross the system boundary as they leave the system, the
next stage in the process is to determine their content. Structured techniques play a useful
role here, because the designer can turn to the data dictionary to find the content of each
data flow, which represents an output. Considering an example from the DFD the output
is described as Stock Valuation Report. According to the data dictionary, the contents of
this data flow are as follows:

DATA ITEM TYPE LENGTH

Inventory group character 25

Page 58 of 111
Stock code 99999 5
Production description character 30
Unit cost 999.99 6
Quantity stock 99 2
Unit selling price 9999.99 7
Expected sales 999 3

A quality output is the one that meets the requirements of the end user, and which
presents the information in away which is clear, easy to read and visually attractive. In
order to decide on an appropriate method of presentation, and a suitable format, a number
of questions need to be asked:

• Who receives the output?

What profile can you create of your target population and their needs? The output
may be received, for example by users within the company, e.g. a listing of
accommodation available, or by people outside the organisation, such as a customer,
e.g. an invoice, or government departments, e.g. Inland Revenue returns, or by
management, e.g. a monthly report.
• Under what circumstances will the output be received?
Does the environment place constraints on the technology that can be used? For
example, if output is to be generated on a factory floor, the device used may have to
operate effectively in dust or dirty conditions, or in a noisy environment where an
error message ‘bump, which could be perfectly in an office setting, would be
inappropriate.

• When and how often is the output needed.

What implications will the required frequency of information have for the selection of
an output method? For example, a warehouse supervisor may require a daily stock
report, whereas senior management may only need to receive reports once a month.

The answers to these questions will help the designer make decisions about whether a
display or a printed copy of the output is required, the type of device needed to
produce the output required, and the layout of the information which best meet the
needs of the users.

OUTPUT TECHNOLOGY

Two methods exist:

• Printing
• VDU output

Printing
Types of printers: impact where a hammer strikes an inked ribbon to produce a character,
and non-impact which work in a number of ways to produce a character on paper,
without making physical contact with it (photocopy technology).

Page 59 of 111
 Impact printers; e.g. dot matrix, daisy wheel
Non-impact: laser, ink-jet.

While impact printers have traditionally been more commonly used in computer systems
because they are less expensive, new systems are increasingly using laser printers to
produce printed output because of the better print quality, the possibility of integrating
graphics and text and because the cost of technology is decreasing.

VDU output
It is appropriate where only a short-lived image rather than a printed document is
required. The display would be monochrome or colour. Colour monitors are now being
used more in developing system, and high-resolution graphics enable sophisticated
presentations of data to be displayed in the screen.

Other output alternatives:

• Plotters to produce coloured line drawings, such as graphs and maps
• Facsimile
• Sounds such as beeps or clunks for example music or video messages.
• Magnetic media such as magnetic, optical disks, microfilm, microfiche
• Speech output

Presenting information
Three important principles apply whether the output is printed on paper or displayed on
the screen:
• The content should be kept simple. This is achieved by presenting only that
information which is needed by the user.
• The page or screen should not be cluttered and easy to read. The use of white space
on a printed page significantly improves its readability.
The information should be arranged logically on the page on screen in such a way that it
can be easily and quickly used and understood by the user. Every output screen or report
should include a main heading which identifies the purpose of the output and
subheadings which identifies the various sections within it.

The use of tables and graphics

Reports are commonly arranged as tables, especially those containing financial
information, and this is appropriate if the detailed information is arranged in discrete,
labelled groupings, if totals are included and a few explanatory comments are needed.

Graphics can be effectively be used to present data in ways other than tables and low cost
technology is available to produce high-quality diagrams and charts. However, these
graphics need to be used with care if they are to be effective, and much will depend on
the designer’s judgement and the requirements of the users as described by the analyst.

Page 60 of 111
INPUT DESIGN

When designing input, the objective is to ensure that the data, which will be processed by
the system, is collected and entered into the system efficiently, according to the specified
requirements, and with the minimum of errors. In discussion with the client, the design
will choose a method of input, which is cost effective and acceptable to the end users.
The process of input design, like output design, which was described earlier, consists of
four stages.
• Firstly, identify the inputs into the system, by listing the data flows on the required
logical data flow diagram, which cross the system boundary on their way in.
• Then determining the content of these inputs by inspecting the data dictionary.
• Next choosing an appropriate input device to change the user’s data into a form, this
can be read and processed by the computer system.
• And finally completing the detailed design work involved in specifying forms, input
screens and any other data collection documents.

The first two steps are linked together, and involve the designer in looking at the data
flow diagram for the required logical system, and the data dictionary. If the data
dictionary for the system were to be inspected, the contents of the data flow, which
correspond to these inputs, could be determined. For example, the data items, which
make up the input called new customer details, are:
Customer number, customer type, sales region, discount code, name address, and delivery
instructions, while new product details contains the following data: Product number,
description, manufacture, origin, inventory group, product class, dispatch unit, re-order
level, discount prices, vat code and VAT rate. In this way the contents of each input can
be confirmed, as can information about the source, volume and the frequency of the
input.

The next stage is then to choose the appropriate technology for introducing the data
contained in each of these inputs into the system. There are a wide variety of different
ways of entering data, and the choice of the appropriate method will depend on a number
of factors, the two most important of which can be summarised in the following
questions:
• Which method will be most suitable to the needs of the users who have to enter the
data? While a keyboard will be appropriate in many situations, it may not be
appropriate to a checkout operator in the supermarket, where speed and accuracy are
important.
• Which method will be most suitable for the format and volume of the data to be
entered? If an educational institution has a large of multiple choice answer sheets
completed during examinations, and wishes to put these results onto the system, then
an optical mark reader – which can read the input directly from the students answer
sheets – would be the most suitable.

Whichever method is chosen; it will include some or all of the following steps:
1. The initial recording of significant data by the user;
2. The transcription of data into an input document

Page 61 of 111
3. The conversion of data from a ‘human-readable’ into a ‘computer-readable’ form;
4. Verification of this data conversion to pick up any errors;
5. The entry of the checked data onto the computer system;
6. The validation of the data by the system to ensure it is logically correct;
7. The correction of any errors highlighted by the data validation program.

As passing through all these steps makes data entry a costly process, the key guideline for
the designer is to make the process as simple as possible. If this can be done in a way
which minimises the cost to the user, minimises the chance of data transcription errors
occurring and minimises the delay in entering the data onto the system, then the designer
will once again be building quality into the system.

While there are a large number of different input devices, they can be grouped according
to the way in which data is entered: either by keyboard transcription from clerical
documents, by direct input onto the computer system via a peripheral device, by direct
entry through intelligent terminals or by speech or body movement.

DIALOGUE DESIGN

For most of computer systems, the main contact with the system is through an on-screen
dialogue and their perception of how ‘friendly’ the system is will depend on the
characteristics of this dialogue. Ambiguities and difficulties in the dialogue cause
problems in training and operation and lead to systems under performing.

For example, it is important that developers use style guides to ensure that screens which
are part of the same system, but which are designed or programmed by different
individuals, have a consistent layout. This area of systems design is important for the
developer who, in seeking to design an effective dialogue, will be concerned to ensure
that the conversation between the system and the user flows freely. This depends on
understanding the characteristics and requirements of the users, as well as the type
hardware and operating system available, and on having an appreciation of the principle
of screen design and the different ways in which the dialogue can be structured.

Screen Design
The quality of the screen can be a direct impact on the performance of the users of the
system, and the designer needs to consider the format as well as the content of the screens
on which the dialogue, or interaction, between the user and the system is based.

Screen features:
Text – Must be easily readable.
- Choose appropriate font and size for the character.
- Using lower and upper case letters can improve readability, rather than the
approach sometimes adopted in screen design of using all upper case.
- Evenly spaced text, with an unjustified right margin, is easier to read than right
justified text, which has spaces of varying sizes between the words.

Page 62 of 111
 - The use of concise phrases, familiar vocabulary and appropriate abbreviations
make it easier for the reader to understand the text.
- The most visible sections of the screen is the upper left-hand corner, and it is a
good idea to locate important messages in this area.

Highlighting – can be used to make parts of the text stand out from the rest. There
are a number of different ways of doing this. The text can be
In UPPER CASE
Underlined
In bold typeface
Enclosed in a box

Or in a shadowed box
Or it can be larger than the rest.

In addition, because the medium is a VDU screen, rather than paper, other techniques can
be used to highlight the important information. It can be made to flash, to be brighter than
the surrounding text, or reverse video can be used- creating an effect rather like a
photographic negative, with white text on a black background.

Colour – Being in a different colour to the rest or being enclosed in a coloured box can
highlight text. Background colours can be changed or a design convention can be used in
which different types of information are displayed in different colours. The consistent use
of colour on screens within the same system is important, and the designer must be wary
of using too many colours or creating lurid combinations as these will work against the
effectiveness of the screen design. In addition, the designer must also be aware of
avoiding colour combinations, which could cause problems for those users who are
colour-blind.

Graphics – can be used to good effect for displaying information, especially trends in
numerical data. They can be coloured, solid, three-dimension or animated, and the
designer must decide on what is appropriate to the purpose. Another use of graphics is as
an integral part of the structure of the dialogue known as graphical user interface (GUI).
A key feature of GUI design is the use of small pictures called icons, which are used to
represent entities such as files, documents and disks. An icon should communicate
exactly what it represents to the user without the need for accompanying text. Where they
are used, each icon should be easily distinguished from any others, and used consistently
to represent the same thing.

Animation – although this is little used in screen design, it can be a power technique for
attracting the attention of the user, because the eye is always drawn to a moving object; to
mark the position of an object, for example, a blinking cursor can be used; or to
communicate a message, a clock with a moving hand, or an hourglass with moving sand,
indicate to the user that they have to wait while some processing is carried out by the
machine.

Page 63 of 111
Dialogue types
There are a number of different approaches, which can be taken when designing the
conversation or dialogue between the user and the computer system. Essentially a
dialogue consists of user responding to a prompt from the computer by providing input.
This input is processed by the computer and a response is output to the screen, which in
turn may prompt the user for the next input.

Main dialogue types:

• Menus
In this approach, the user is presented with a set of alternatives from which one will be
selected. These alternatives can be displayed on the screen using text or graphics, and
usually each alternative has a number or a letter associated with it. When the user selects
an option, the letter or the number is entered through the keyboard, or the arrow keys are
used to move the cursor between the options. Alternatively, if a mouse is attached to the
computer, an option can be selected by pointing at it. An item on the menu can be
selected by typing either the appropriate number or the initial letter of the word.

Menus are widely used in screen design because they require minimal effort, and skill, on
the part of the user. This in turn reduces the training requirement when preparing to
individuals to use the system. A common approach is to structure the menus
hierarchically in a ‘nest’: selecting an option on the first menu takes a user to a second
menu from which another option is chosen, and so on. This allows the number of
alternatives on any one screen to be kept to a minimum.

When designing nested menus, it is important to build in shortcuts to allow experienced

users to move quickly through the system and avoid the frustration of having to go
through several, menu screen for each transaction, and to allow an exit which doesn’t
involve travelling back through each of the previous menus. The principals of good
design should also be applied by keeping the menus simple, with an upper limit of ten
choices per screen; minimising the number of levels of menus through which a user has
to navigate; and ensuring consistency in the way options are selected from each of the
related menus.

In some applications a menu is permanently displayed in a bar across the top of the
screen from which other menus can be pulled down as required. This is known as a pull-
down menu.

Questions and answer: This type of dialogue involves the system prompting the user by
asking a question, and then carrying out the processing associated with the user’s answer.
The question usually requires one of a limited number of answers, e.g. yes or no, which
eliminates errors and reduces the amount of validation of answers required.

Do you really want to delete this file? Type ‘Y’ or ‘N’

(Where the default is N)

Page 64 of 111
• Form-filling this is particularly appropriate for the user who has to enter information
into the system from a paper input form, and as closely as possible to minimise the
risk of errors. This type of dialogue is also called a template. The areas in which data
has to be entered will usually be highlighted in some way to stand out from the
background text-using colour shading or graphics for example.

Example of a form-full screen

Galaxy Electrical Products Limited

SCREEN LAYOUT

NEW PRODUCT INPUT/PRODUCT AMENDMENT

PRODUCT NO (-----------) DESCRIPTION (------------)

MANUFACTURER (-------) ORIGIN (------------)

INVENTORY GROUP (------) PRODUCT CLASS (--------)

DESPATCH UNIT (-----------) RE-ORDER LEVEL (--------)

DISCOUNT PRICES A (--------)

B (--------)
C (--------)

When data has been entered, the cursor moves to the next input area. Form-full is useful
when a large amount of similar information has to be entered quickly into the system.

• Common language. This type of dialogue can appear very ‘unfriendly’ to the
inexperienced user as the prompts are usually very limited, and response by the user
has to be syntactically correct in order to be accepted by the system. However, it is a
very fast and efficient dialogue for the experienced user and short commands or
abbreviated forms of these commands will initiate specific processing. There is a
great deal of freedom to move around the application, as the user rather than the
system is structuring and ordering the conversation. The designer should ensure that
there is a visible output on screen to show that the user’s input has been accepted by
the system and should endeavour to make error and help messages in such a dialogue
as meaningful as possible.

Example:
Type Exit to return to menu

Page 65 of 111
 C:\>A: DIR

Not ready reading drive A

Abort, Retry, Fail? R

General failure reading drive A

Abort, Retry, Fail? F
Invalid drive specification
Bad command or filename
Type EXIT to return to menu
C:\>
• Natural languages – They are much closer to the way people would speak. This type
of dialogue relies on artificial intelligence and translate them into instructions which
can be followed by the computer. The problem with natural language is that most
natural languages, like English are characterised by ambiguity and inconsistency in
their syntax. These dialogues therefore require the use of a limited vocabulary and
syntax, with which users need to be familiar before they use such a dialogue.

WIMP INTERFACES
This is an increasingly common interface used in many applications. The WIMP interface
is so called because it incorporates:

WINDOWS, several of which can be opened on screen at the same time.,

ICONS which represent entities such as files and documents, a
MOUSE to select and move icons around the screen and
Pull down menus.

ERGONOMICS AND INTERFACE DESIGN

In designing an ergonomically safe workstation, attention must be paid on to a number of

points, such as:
• The body should be upright and the body weight fully supported on the chair.
• There should be god lumbar support, and the seat back should be adjustable.
• The height of the seat should also be adjustable.
• When the height of the seat is correct, the fore arms should be horizontal, the
shoulders relaxed and not hunched up Feet should be flat on the floor, and the footrest
should be provided if required.
• Thighs should be supported by the front of the chair, but there should be no excess
pressure from the chair on the underside of the thighs or the back of the knees.
• Space should be allowed for changing the position of the legs and obstacles removed
from under the desk.
• Space should be provided in front of the keyboard to support hands and the wrists
during pauses in keying.
• The distance between the eye and screen should be in a good range so the data on the
screen can be read comfortably without squinting or leaning forward.

Page 66 of 111
• The height of the VDU screen should be adjusted according to the user’s typing
proficiency, and the needs of the task.
• For those with touch typing skills, or whose work is purely to screen without
referencing written material, the top of the screen should be level with the eyes,
should be angled approximately 15-20 degrees to the horizontal.
• Users who are trained touch typists, and switch between screen, keyboard and
reference material, should be as close as possible to 90 degrees from the line of sight.
• Contrasts and brightness should be set to produce a display, which is comfortable to
use, and should be adjusted to take account of varying light conditions during the day.
• The screen should be positioned to avoid glare from either direct sunlight or artificial
light. Where possible blind should be used to shield the screen.

DOCUMENTATION DESIGN

A software product is composed of code and documentation. Documentation includes a

wide range of technical and non-technical books, manuals, descriptions and diagrams.
The production of effective documents is sometimes overlooked. Documentation aimed
at three different audiences:

• The software developer – who will depend on the documentation from previous life
cycle stages to guide continued development and maintenance.
• The manager- who will use documents from past projects to plan and understand
current projects.
• The user – who will use learn how to use the software from the documentation.

In preparation documentation, careful consideration has to be given a number of factors:

(i) Documentation should be complete i.e. All known pertinent information should be
given or stated somewhere.
(ii) Documentation should be consistent. Inconsistency will destroy the readers’
confidence in the documentation. The biggest challenge is not the consistency in
the original documentation but maintaining consistency through all the changes
the product may undergo.
(iii) Documentation has to be pitched at the right level for its intended audience. A
training manual cannot demand as much from its readers as a design
documentation can. Hence, we have to identify the audience, determine its
characteristics, background, and needs and plan accordingly. We should use
appropriate level of formality, and appropriate vocabulary in our presentation.
(iv) We need to select the right approach in presenting information so that it will be
readily understood. This includes a choice of format: text, technical manual
(workbook) tutorial, video or audiotape, on-line help package etc. Illustrations
and tables are very important, since they organise and present large amounts of
material for quick comprehension. Adjunct material like indices, exercise,
appendices, and glossaries must also be considered.

LOGICAL DATA DESIGN

Page 67 of 111
Introduction
Data only has value to the organisation when it is accurate and properly controlled.
Business process change frequently but the underlying data is relatively stable and unless
the core business of an organisation changes, the data it uses will remain unchanged. For
example, the processes needed to control a warehouse stock is stored and retrieved by
forklift truck to being fully automated. In the new system, the incoming goods are
identified to the system by barcodes, the system decides where to store the item and it
controls cranes and automated goods vehicles to transport items from and to locations.
The core data, the item number and locations, remain unchanged, even though the
processing has changed dramatically.

During the 1960s, little attention was paid to data analysis and data design. Because no
thought was given to the fact that has a right to exist on its own, separately from any
processing that used it data came to be stored in the only system on its own, separately
from any processing that used it, data came to be stored in the system only when a
process required it. This also resulted in each user holding their own customised version
of the data. This means an increase of different names, sizes and formats for the same
data item. One piece of data could be held many times in different files in different
formats.

With the introduction of structured methods and database techniques greater attention
was paid to data analysis: a method which considers in its own right, independent of
processing limitations or hardware and software constraints. It also ensures that there is
only version of data, and any duplication is clearly agreed and controlled.

The resulting data model provides a complete picture of the data used by the
organisation.

A logical data model consists of:

- Data entities
- Key fields for entities
- A list of attributes for each entity
- Relationship between entities.

DATA NORMALIZATION

Normalization is a process of removing duplication, and grouping related data to

minimise interdependence between data groups. The less interdependence that exists
between data groups, the less impact a data modification has, such as increasing the size
of a data item. This approach to data analysis allows the analyst to build a data model
starting with the attributes and subsequently grouping these together to form entities.
The analyst then identifies the relationship between those entities. To take data through
the full normalisation process, you first need to access all data the organisation stores in
the system. Typically, this will be done by collecting one copy of every type of form and
report. If there is an existing computer system, screen printouts can also be used. From

Page 68 of 111
these inputs, every item that appears is listed. The analyst must then identify how these
data items relate to each other.

Normalisation stages
• First Normal Form
• Second Normal Form
• Third Normal Form

Firs Normal Form (1NF)

A table or relations is said to be in first normal form if and only if it contains no
repeating groups. That is, it has no repeated values for particular attributes within a
single record. If there are repeating groups of attributes, they should be isolated to form a
new entity.

Second Normal Form (2NF)

A table is said to be in 2NF if and only if it is in first normal form and every non-key
attribute is fully dependent on the key attribute. All non-key attribute that are not
dependent on the key attribute should be isolated to form a new entity.

Third Normal Form (3NF)

A table is said to be in 3NF if and only if it is second normal form and every non-key
attribute is not dependent on any other non-key attributes. All non-key attributes that are
dependent on other non-key attributes should be isolated to form a new entity.
Example: An invoice

Invoice No: ___________________ Date:

Customer _____________________ Delivery To:

Address

Product Code Description Qty Price Amount

1. ______
2. ______
3. ______
4. ______

Invoice Total _____________

Page 69 of 111
Unnormalised data
INVOICE (Invoice No, Date, Cust_Address, Del_Address, (Prod_Code, Prod_Desc, Qty,
Unit_Price, Amount) Inv_Total)

First Normal Form (1NF)

INVOICE (Invoice No, Date, Cust_Adress, Del_Address, Inv_Total)
PRODUCT (Prod_Code, Invoice_No, Prod_Desc, Qty, Unit_Price, Amount)

Second Normal Form (2NF)

INVOICE (Invoice_No, Date, Cust_Address, Del_Address, Inv_Total)
INVOICE-PRODUCT (Prod_Code, Invoice_No) Qty, Amount)
PRODUCT (Prod_Code, Prod_Desc, Unit_Price)

Advantages of normalisation
• It is a formal technique with each stage of normalisation process eliminating a
particular type of undesirable dependency, as well as each stage of normalisation
eliminationg a certain type of redundancy.

• It highlights constraints and dependencies in the data and helps in understanding the
nature of the data

• The 3NF produces well designed databases which provide a high degree of
independence.

Disadvantages:
• Demands a thorough understanding of the entities and their relationships.
• It is a complex process, particularly if the entities are many.

FILE AND DATABASE DESIGN

File Organisation
The two general methods of file organisation are sequential and random access. Records
in sequential files must be read and written in the sequence in which they are physically
stored in the files; that is the user must always start at the beginning of the file and work
to the end. With sequential files, users cannot jump to the middle even if they are looking
for just a single record. Sequential files reside on either tape or disk and are used only I
batch environments.

Page 70 of 111
Random access files, on the other hand, allow the user to get any record on key without
first reading the records preceding it. Random files must reside on disk and are required
for online environments.

There are tow basic types of random access; direct access and indexed sequential.
Direct access files allow for the fastest retrieval of a single record but sometimes they
waste space on disks and do not allow for easy access of the records in sequential order.
Indexed sequential files, on the other hand, are slightly slower to access, but they do not
waste quite so much space and they do allow for sequential access.
The trends in the last few years has been towards random access files (just as the trend is
towards on-line processing), but there will always be some applications where sequential
files are appropriate, particularly those with a large volume of transactions and infrequent
updating. Payroll data, for instance, usually needs updating only once a week or a month,
in time to produce paychecks. It is rarely necessary to know how many hours an
employee has accumulated as of the middle of the week. Therefore, sequential files might
be adequate for a payroll system.

Factors influencing file design

• Purpose of the file. If for example, a file is to be used for on-line enquiry, direct
access is needed and the file must be organised so as to permit this, perhaps using
indexed sequential organisation or random organisation. This will in turn mean that
disk or tape must be used to store the file. Files that are to be used for batch
processing only and where many of the records will require to be processed should be
organised serially or sequentially on tape as it is cheaper than disk.
• Constraints imposed by the system hardware? Does the available hardware support a
particular file organisation and method of access? What data storage media are
available?
• Updating required: It is either ‘in situ’ or using the ‘grandfather-father-son’ method.
In-situ involves updating inserting or deleting records on-line, without retaining the
old version of the file. There should, of course be back up copies of the old version, in
case something goes wrong, or as archive files. In-situ updating of records in a
random order requires direct access to a random or full indexed file.

The ‘father-son method involves taking a file and producing a new version, this resulting
in having two generations of the file, the father and son generations. The method is more
secure than in-situ because if the system fails the old version of the file should be
unharmed. Three generations of the file; grandfather, father and son are often created
before the oldest version is destroyed and the storage space re-used.

• Frequency of file accessing for enquiry or updating (Hit rate). How many records in
one file will have to be accessed in one process? If the hit rate is high, batch
processing of a sequential file may be the most efficient design.

• Volatility How often will records need to be inserted, amended or deleted. Some files,
for example library files may rarely change. An indexed file copes with high volatility

Page 71 of 111
 better than sequential files since these have to be constantly re-organised to bring
records to overflow areas back into sequence. An index file need only its index
updated when records are added to the file.

• Response time Online and real time systems require fast response times. Fast
processing of records can also be important in large batch systems because of the
sheer number of the records involved. Where fast responses or fast processing times
are required, the speed of access to records can be the dominant factor for the file
design and this usually means direct access methods with key transformation.
• The file expected file size.

DATABASE DESIGN

A database can be defined as a structured organisation of data in such a way that there is
minimum duplication to provide consistency of the data and also provide access for many
users, independently of the programs that are used.

Database management systems

Many installations are using database management systems (DBMS) to control data for
which random access is required. A DBMS is software that organises and controls the
reading and writing of data to the database. Its purpose is to automate and simplify the
accessing of data. With the DBMS, maintaining the database is so much easier that
programmers are free to spend more time on new applications.

Advantages of databases
• Avoidance of unnecessary duplication of data.
• Multipurpose data-data can be used for several purposes.
• Stores data for the organisation as a whole, not just for individual departments. The
database concept encourages management to regard data as a resource that must be
properly managed, just like any other resource. The installation of a database
encourages management to analyse data, relationships between data items and how
data is used in different applications.
• Consistency:- Because data is held only once, it is easier to ensure that it is up to date
so that no department in an organisation uses out of date data, or data that is different
from the data used in other departments.

Disadvantages
• Problems of data security and data privacy because data is accessible by many users.
Strict controls for access and sharing must be used.
• Since there is only one set of data, it is essential that data should be accurate and free
of corruption.
• Since data is held only once but its use is widespread, there are potential problems of
recovery of data in the event of systems failure.
• Costs of creating and maintaining the database.
• Complexity:- It requires expert knowledge, particularly of the capabilities of the
DBMS software, setting up and controlling the database.

Page 72 of 111
 Database structures/models
There are three database models.
In a customer database, for example, the hierarchical model might be used to show
customers and customer orders. An extract from a parts department database might be
structured as follows:

Parts

CUSTOMER B100 CUSTOMER B102 CUSTOMER B200

JAMES MARY SMITH

ORDER ORDER ORDER ORDER ORDER

2 x product P4 1 x product N9 4 x product P4 3 x product N9 1 x product B6
1 x product P2

The biggest drawback to files organised in this structure is that the user is limited in the
number of ways he or she can look for the records; the file organisation makes it much
easier to search for certain items in the file records than for others. In the example above,
in order to access an order record, it is necessary to specify the customer to which it
belongs, which is straightforward. However, if we were required to obtain a listing of all
customers who have ordered a particular part number, this would require a search of each
customer record, which is a long and tedious process.

Network model
Whereas a hierarchical structure allows a one –to many relationships between data items,
a network database is a database in which the logical structure allows many-to-many
relationships, as follows:

B100 B102 B200 SMITH

B100: 2 x P4 B100: 1 x N9 B100: 4 x P4 B102: 1 x P2 B200: 3 x N9 B200: 1 x B6

Page 73 of 111
P2: Pin 2mm P4: Pin N9: Nuts B6: Bolt

Relational model
A relational model organises data elements in a series of two-dimensional tables
consisting of rows and columns. A row represents a record, and columns represent fields,
or a part of the record. In a relational data structure, the structure of the file is
independent of the actual data. The relationships between different entity types have been
determined at the outset, and are not embodied in the record themselves. A relational
database thus does not have to navigate through other data before reading the required
data. The normalisation process helps eliminate redundancies where records in any table
(relation) are identified using a key field.

CUSTOMER table
B100 JAMES
B102 MARY
B200 SMITH

PRODUCT table
B6 Bolt
P2 Pin
2mm
P4 Pin
4mm
N9 Nuts

ORDER table
B100 P4 2
B100 N9 1
B102 P4 4
B102 P2 1
B200 N9 3
B200 B6 1

There are six special properties of relational tables:

1. Entries in the column are single valued. This implies that columns contain no
repeating groups. In other words, they have been normalised.
2. Entries in columns are of the same kind.

Page 74 of 111
3. Each row is unique.
4. The sequence of columns is insignificant.
5. The sequence of rows in insignificant.
6. Each column has a unique name.

PROCESS DESCRIPTION TOOLS

Systems analysts use three documentation tools to create process descriptions:

• Decision trees
• Structured English
• Decision tables
Processes comprise of step-by-step procedures and decisions that are made as the process
progress.

Decision Trees
People will often have different ways of saying the same thing. This can create
difficulties in communication during system studies (analysts and manager may
misunderstand each other’s comments or forget to discuss all the details). Decision tree
are a method of describing decisions, while avoiding difficulties in communication.

A decision tree is a graphical documentation tool that represents conditions and their
resulting actions.

Characteristics
A decision tree is a diagram that presents the conditions and actions sequentially and thus
shows which conditions to consider first, second and so on. It is also a method of
showing the relationship of each condition and its permissible actions. The diagram
resembles the branches on a tree, hence the name.

The root of the tree, on the left of the diagram, is the starting point of the decision
sequence. The particular branch to be followed depends on the conditions that exist and
the decision to be made. Progression from left to right is the result of making a series of
decisions. Following each decision point is the next set of decisions to be considered. The
right side of the tree lists the actions to be taken, depending on the sequence of conditions
that is followed.
Decision trees are beneficial to analysts in two ways;
(i) The need to describe conditions and actions forces analysts to formally identify
the actual decisions that must be made. It becomes difficult for them to overlook
an intergral step in the decision process, whether it depends on quantitative or on-
quantitative variables.
(ii) Decision trees also force analysts to consider the sequence of decisions. The
analyst can subsequently determine which conditions are relevant and their order
for certain actions to be taken.

Page 75 of 111
Structured English

This method uses narrative statements to describe a procedure.

Structured English specifications still require analysts to identify the conditions that
occur in a process, decisions that must be made when these conditions occur and
alternatives actions to take. However, the method also allows analysts to list steps in the
order in which they must be taken. It does not show decision rules as in decision tables, it
states them.
No special format or symbol are used. Furthermore, entire procedures can be stated
quickly since only English-like statements are used.
Developing structured statements
Structured English uses three basic types of statements to describe a process: sequence
structures, decisions structures and iteration structures. They work well for decision
analysis and carried over into programming and software development.

Sequence structure
A sequence structure is a single step or action included in a process. It does not depend
on the existence of any condition and when encountered, it will always be taken. For
example, in an Accounts Payable processing system, the following sequence of five steps
would apply.

• Accept invoice for processing

• Prepare payment voucher using invoice
• Revise account balance sue using payment voucher
• Write supplier cheque
• Mail cheque to supplier

The steps are carried out in the order in which they occur.

Decision structures
Decision structures occur when two or more actions can be taken, depending on the value
for a specific condition. One must assess the condition and then make the decision to take
the stated actions or sets of actions, for that condition. Once the determination of the
condition is made, the actions are unconditional.

Through the use of IF/THEN/ELSE phrases, the structure points out alternatives in the
decision process quite clearly. From the invoice authorised example;

If invoice is signed
If goods not accepted
Rejected invoice
End if
If valid purchase order was prepared

If authorisation not received

Reject invoice

Page 76 of 111
 End If
If invoice is properly priced
Else
Reject invoice
End If
Then
Log invoice
Prepare payment voucher
End If

Iteration structures
In routine operating activities, it is common to find that certain activities are repeated
while a condition exists or until a condition occurs. Iteration instructions permit analysts
to describe these cases.

From the above example:

Do until all invoices are processed

If invoice is signed
Else
If goods not accepted
Reject invoice
End If
If valid purchase order was prepared
Else
If authorisation not received
Reject invoice
End If
If invoice is properly priced
Else
Reject invoice
End If
Then
Log invoice
Prepare payment voucher
End If
End do

Decision Tables

A decision table is a two-dimensional matrix with one horizontal row for each condition
and each action and one vertical column for each combination of value and resulting
actions

Condition stub Condition entry

Action stub Action entry

Page 77 of 111
 • Each vertical column of a decision table is called a rule and each rule symbolises one
combination of value. If constructed properly, the decision table has a rule to cover
every possible combination.

Rules are made of selectors symbolised by Y(Yes), N(No) and – (for redundant or
irrelevant rules).

Completing the table

• If the number of condition identified is c, the number of possible rules is found by
applying the formula; Number of rules = 2c.
• Entries opposite the lowest condition should be completed, using Y and N alternately,
until all the vertical rules have been dealt with.
• Entries opposite the second lowest condition should be completed next using Ys and
Ns in pairs until all rules have been dealt with.
• Entries for the next condition are then completed using Ys and Ns in fours
• This process continues, using twice the number of Ys and Ns each time until all
conditions are completed.
• Once entered, the rules are read vertically in each column and an X entered at the
action that approximately completes that rule. Actions which are mutually exclusive
can be combined on a single line.

Example 1
A student who passes the examinations and completes the course work and project
satisfactorily is awarded a pass. If the course work and the project are unsatisfactory, the
student is asked to resubmit the unsatisfactory work, as long as the exams have been
passed. A student who fails the examination is deemed to have failed the whole course
unless both the course work and the project are satisfactory, in which case the student is
allowed to re-sit the examinations.

Reduced

1 2 3 4 5 6 7 8
Exams passed Y Y Y Y N N N N
Course passed Y Y N N Y Y N N
Project passed Y N Y N Y N Y N
Pass X
Resubmit Course X X
Work
Re-sit X
Fail X X X
Resubmit Project X X

Page 78 of 111
Example 2
Candidates are accepted for employment if their qualifications and reference are
satisfactory. If they pass the interview and the qualifications or reference (but not both)
are unsatisfactory, a job for probationary period is offered. In all other circumstances the
candidates application is rejected.

Eliminate Redundancy
1 2 3 4 5 6 7 8
Qualifications Y Y Y Y N N N N
Satisfactory
Reference satisfactory Y Y N N Y Y N N
Passed the interview Y Y Y N Y N Y N
Employ X
Employ on probation X X
Reject X X X X X

CASE TOOLS

Definition
A CASE (Computer Aided Software Engineering) tool is a software package that
supports the construction and maintenance of logical system specification model. They
are often designed to support the rules and interaction of model defined in a specific
methodology. More sophisticated CASE packages permit software prototyping and code
generation.

CASE techniques aim to automate this document production process by ensuring the
automation of some of the analysis and design operation.

Although these tools may not completely automate the process of analysis and design,
they are certainly an improvement over the old ‘pencil-paper’ method.

There are two types of CASE tools;

• Analyst workbenches
• Programmers’ workbenches.

Analysts’ workbenches
These are software tools which perform several analysis tasks such as:
• Create design diagrams (eg. DFDs on screen)
This enables the production of high quality documentation that can be easily updated.
Maintenance of complex models such as DFD and E-R models can be made easy by the
use of diagramming facilities with the use of a mouse as in most graphic packages.

Page 79 of 111
CASE toolkits come with a bank of pre-designed symbols including those used in DFDs
and flowcharts. They also offer a simple word-processing facility to assist in the
production of the material such as system specification and other reports to be produced.
• Checking adherence to design and development standards.
A CASE tool will not allow for rules to be broken such as linking a data store within a
DFDS to an external entity.
• Consistencies and relationships are correct.
• They help generate input and output documentation
• Data dictionaries
They can create a logical data dictionary for the items identified. Entries will be made for
entities, data flows, data stores, processes, external entities and individual data items. The
dictionary can easily be maintained, checked for consistency, cross-referenced and
analysed. For example, it will be produced to produce a listing of all data flows where a
particular data item is used.

Programmers Workbenches
They provide similar features to ensure consistency of coding during the later stages of
the design cycle as follows:

• There is a code generator facility t automate the production of code in a high level
language, from say, Structured English.
• Diagnosis aids enable subroutines or modules to be tested independently of other
programs.
• A library of subroutines is also provided. These can be incorporated into programs.

CASE Advantages
• They make the construction of various analysis and design logical elements such as
DFDS, E-R models easy.
• Integration of the separate elements. For example, an analyst looking at a diagram can
pull up a dictionary definition for a piece of data without exiting the dictionary
screen. By pointing to a file symbol, the analyst can display the data model for that
file. Such integration allows the software to do additional rechecking, such as
notifying the analyst when a data flow diagram contains a piece of data that hasn’t yet
been defined in the dictionary.
• Streamline development of analysis documentation. CASE allows developers to use
graphics like data flow diagrams that were previously cumbersome to draw and
revise, particularly for large projects. Data dictionaries with thousands of entries,
which were also impossible to maintain manually, can be maintained and made
available to analysts.
• Allow easy maintenance of specifications, which in turn means the specifications will
be more reliably updated. Specifications that are up-to-date provide a documentation
trail for later system maintenance efforts.
• Enforce rigorous standards for all developers and all projects. In effect, everyone is
talking the same language, which makes communication between developers more
efficient.
• Check specification for errors, omission, and inconsistencies.

Page 80 of 111
• Provide everyone on the project team with easy access to the very latest update of the
project specifications.
• Encourage iterative refinement, since the specifications are easier to change. As a
result, a higher-quality system (i.e. one that has fewer defects and missed
requirements) that better meets the needs of the users is developed. This has a net
effect of increasing productivity by decreasing correction efforts.

CASE Disadvantages
• CASE products can be expensive.
• CASE is still in its infancy, and most practitioners are often in the position of being
pioneers. Because the technology is not yet fully evolved, CASE software is often
large, inflexible, and temperamental.
• Today’s CASE products do not yet provide a fully integrated development
environment. The user must often piece together different tools from different
vendors in order to serve all phases of the system development life cycle.
• Users often expect CASE to be overnight cure for system development problems, but
instead there is usually a long period of learning before the tools can be effectively
used. As a result, positive results may not show up on the organisation’s income
statement. It takes time to reap the benefits of CASE.
• The installation and implementation of a CASE product requires a great deal of
control and monitoring on the part of the management. If the proper training and
motivation are not provided for the practitioners, CASE may be used a little more
productively.
Analysts must have a mastery of structured analysis and design techniques if they are to
exploit CASE. If analysts are expected to learn these structures technique at the same
time they are learning CASE, all time and cost estimates for the project should be inflated
to allow for an extended learning period.

PROTOTYPING

Prototyping is the process of building an experimental system information system quickly

and inexpensively for evaluation and demonstration so that end users can better
determine information requirements.

The prototype is a working version of an information system or part of the system, but is
meant to be only a preliminary model. Once operational, the prototype will be further
refined until it conforms precisely to users’ requirements. For many applications, a
prototype will be extended and enhanced many times before a final design is accepted.
Once the design has been finalised, the prototype can be polished to a finished production
system.

-Building a prototype during the analysis and design phases can clarify the users’
requirements and verify that the finished system will meet those requirements. A
prototype also gives users the opportunity to see what they have asked.
-Prototyping is user centred, that is the user and the analyst work closely together as the
prototype evolves through a process of iteration, or incremental refinements.

Page 81 of 111
Steps in Prototyping
(a) Identify user’s basic requirements- The system designer (usually an IS specialist)
captures the users basic requirements.
(b) Develop a working prototype- The systems designer creates a working prototype
quickly, most likely using the 4GL, CASE tools, etc. The prototype may only perform
the most important functions of the proposed system or it may consist of the proposed
system with restricted files.
(c) Use the prototype- The user is encouraged to work with the system to determine how
well the prototype meets his or her needs and to make suggestions for improving the
prototype.
(d) Revise and enhance the prototype- The system builder notes all changes requested by
the user and refines the prototype accordingly.

Advantages of prototyping
a) It is only suited for applications that are oriented to simple data manipulation and
decision support. However, systems that are based on batch processing or that rely on
heavy calculations and complex procedural logic are generally unsuitable for the
prototyping process.

b) Rapid prototyping can gloss over essential steps in system development. Basic
systems analysis and requirements analysis cannot be short-circuited. The appeal of
an easily and rapidly developed prototype may encourage the development team to
move too quickly towards a working model without capturing even a basic set of
requirements.

c) The final steps to convert the prototype into a polished system may not be carried out.
Once finished, the prototype often becomes part of the system. If the prototype works
reasonably well, management may not see the need for reprogramming and redesign.
Some of these hastily constructed system may be difficult to maintain and support in
a regular production environment. Prototypes may not be very technically efficient to
accommodate large quantities of data or a large number of users in a production
environment.

d) Prototyped system still need to be documented and tested, but often these steps are
shortchanged. Because prototypes are constructed so effortlessly, managers may
assume that testing can be handles by users on their own and any further testing
requirements can handled later. Because the system is so easily changed,
documentation may not be kept up to date.

DEVELOPING SYSTEMS WITH APPLICATION SOFTWARE PACKAGES

Another alternative to information systems development is by purchasing an application

package. An application package is a set of prewritten, pre-coded application software
programs that are commercially available for sale or lease. When an application package
software is available, it eliminates the need for writing software programs when an

Page 82 of 111
information system is developed and reduces the amount of design, testing, installation
and maintenance work as well.

Examples of applications for which application packages are available.

• Hotel Management
• General ledger
• Inventory Control
• Payroll

Packages are chosen as a development strategy under the following circumstances:

(i) Where functions are common to many companies. For example, every company
has a payroll system and payroll system typically perform the same functions.

(ii) Where information systems resources for in-house development are in short
supply. With trained and experienced systems professionals in limited supply,
many companies do not have staff that is either available or qualified to undertake
extensive in-house development projects. Under such circumstances, packages
may be the only way to enable a system to be developed. Most companies also
lack a budget to develop all their systems in house and consequently, the most
effective development strategy is likely to involve use of an application package.

(iii) When desktop microcomputer applications are being developed for end users.

SECURITY AND CONTROL DESIGN

Data processing by computer creates extra problems for controls because of its special
characteristics, which are that:
(i) Large volumes of data are concentrated into files that are physically very small.

(ii) Large volumes of data are processed without human intervention, and so without
humans knowing what is going on. This places greater reliance on the accuracy of
programs and of data and data on files.

(iii) It is easy to lose data on files. Equipment can malfunction, data files can become
corrupt and store meaningless data, data can get lost when files are copied, and
data files are susceptible to loss though theft, flood or fire.

(iv) Unauthorised people can gain access to data on files, and read confidential data or
tamper with the data. This is a particular problem with on-line systems because
access to a computer program and master file can be from any remote terminal. It
is even possible for ‘hackers’ to use their home computers to gain access to the
files and programs of other systems.
(v) Information on a computer file can be changed without leaving any physical trace
of the change.

Risk to data

Page 83 of 111
The dangers associated with information storage on a magnetic medium include the
following.

(vi) Physical security; Tapes or disks can be stolen, mislaid or damaged, or destroyed
by fire, flood or vandalism.

(vii) Environmental security; Tapes and disks are susceptible to magnetic fields, dust
and extremes of temperature and humidity.

(viii) Loss of confidentiality; Information stored in magnetic files may be accessed by

unauthorised persons. This is particular problem in larger systems, with remote
terminals.

(ix) Processing the wrong file; Since data in magnetic form, and not visible, the
wrong file could be read, or a file could be overwritten when its data is still
needed.

(x) Hardware or software corruption; Hardware or software faults may damage or

destroy the data on files.

Types of controls
(i) Administrative controls which are designed to ensure the smooth running
operation of the system.

(ii) System development controls, which are designed to ensure that any new system
does not present new risks to the environment.

(iii) Application controls are built into operations and ensure that processed data is
accurate and complete.

Administrative controls
These are controls over data and data security that are achieved by administrative
measures.
They include:
(xi) Controls over personnel;
(xii) The segregation of duties
(xiii) Physical security
(xiv) Access controls
(xv) Protection against viruses and hacking
(xvi) Good office practice
(xvii) Back up and standby facilities

Personnel
Controls related to personnel, which were developed before the advent of computers,
include;

Page 84 of 111
(i) Job rotation, so that employees change at random interval, thus making it
uncertain that an individual will be able to set up a breach of security in the time
available.
(ii) Enforced vacations.
(iii) Access to information granted, not on the basis of rank in the management
hierarchy or precedent but on a need-to-know basis.

The segregation of duties

Work should be divided between systems analysts, programmers and operating staff, and
operations jobs themselves should be divided between data control, data preparation and
computer room operations. The functions of an organisation structure, as far as control is
concerned, are:
(i) To assign responsibility for certain tasks to specific jobs and individuals. A
person in a given job is responsible for ensuring that certain controls are applied.
Some jobs are specifically control jobs. These are the jobs of the data control
clerks, and to a large extent, of the file librarian.
(ii) To prevent fraud. It is easier for a person to commit fraud if he can input data,
write programs and operate the computer all by himself. By dividing up the work,
it is made harder to commit fraud or tamper with data, except in collusion with
others.

Duties may be segregated by ensuring that no member of staff on more than one of:
(i) Data capture and entry
(ii) Computer operations
(iii) Systems analysis and programming

An organisation chart and manuals which sets out clearly who does what, and what
practices are forbidden, should be forbidden.

Data processing staff should be properly trained in security and control measures and the
need for them.

Physical security
Physical security comprises two sorts of controls:
(i) Protection against disasters such as fire and floods
(ii) Protection against intruders gaining physical access to the system.

Fire is the most serious hazard to computer system. The destruction of data can be even
more costly than the destruction of hardware. A proper file safety plan is an essential
feature of security procedures, in order to prevent fires, detect and put out fires. Fire
safety includes:

(a) Site preparation (appropriate building materials and fire doors)

(b) Detection (smoke detectors)

Methods of controlling human access:

Page 85 of 111
(i) Personnel (security guards)
(ii) Mechanical devices (such as keys, whose issue is recorded)
(iii) Electronic identification (such as card-swipe systems, where cards are passed
though readers).

Physical security installation

Measures to ensure physical security in the computer room are as follows:
(a) Computer rooms should be kept locked when not in use. Only authorised personnel
should have keys. Locks to computer rooms should be secure.
(b) Computer files should be kept locked in a safe place, such as fireproof safe.
(c) The physical conditions in which the hardware and files are kept should be suitable,
that is too hot, dump or dust.
(d) Measure should be taken to minimise the risks of fire. Waste paper should not be
allowed to pile up. Computer rooms should have smoke alarms and be fully equipped
with fire extinguishers.

Access controls
Access controls are controls designed to prevent unauthorised access to data files or
programs. Access controls which can be built into system’s software are:

(a) Passwords
(b) Encryption and authentication

Passwords
Passwords can be applied to data files, program files and parts of a program. The
computer does not allow a user access to the relevant facilities until he or she has typed
the appropriate password.

(a) One password may be required to read a file and another to write new data.
(b) The terminal user can be restricted to the use of certain files and programs.

Many password systems come with preset passwords. It is essential that there be changes
if the system is to be at all secure, since such common passwords may become widely
known to people in the industry.

Password ought to be effective in keeping out unauthorised users, but they are by no
means foolproof.

The following are reasons why.

- Passwords can be guessed especially when simple passwords have been used.
- Authorised users of passwords can reveal them to unauthorised people.
- When carelessly handled; for example hiding password codes beneath keywords
or stashing them in drawers.

The following should be observed when passwords are used.

(i) Keep your password secret. Do not reveal it to anyone else.

Page 86 of 111
 (ii) Do not write the password down.
(iii) Change your password regularly.
(iv) Change and use your password discreetly.
(v) Do not use an obvious password. (Such as your name)
(vi) Change your password if you suspect that anyone else knows it.

Data communication controls: Encryption and authentication

When data is transmitted over a communication link or within a network, there are
three security dangers:

(i) A hardware fault

(ii) Unauthorised access by an eavesdropper
(iii) Different intervention by someone who sends false messages down a line,
claiming to be someone else, so that the recipient of the message will thinks
that it has come from a authorised source.

Encryption is the only secure way to prevent eavesdropping (since eavesdroppers can
get round password controls, by tapping the line or by experimenting with various
likely passwords.) Encryption involves scrambling the data at on end of the line,
transmitting the scrambled data and unscrambling it at the receiver’s end of the line.

Protecting against hacking and viruses

As it becomes common for computers to communicate over long distances, the risks
or corruption or theft of data or even whole programs become much greater. Two
interconnected issues are hacking and viruses.

• Hacking
A hacker is a person who attempts to invade the privacy of a system. Hackers are
normally skilled programmers, and have been known to find out passwords with ease.
The fact that a lot of information can be transmitted over the public telephone
network has made it to trace individual hackers, who can therefore make repeated
attempts to invade systems. Hackers have in the past mainly been concerned to copy
information, but a recent trend has been their desire to corrupt it.

• Viruses
Computer viruses are currently the cause of much concern. A virus is a piece of
software which infects programs and data and which replicates itself. There are a
number of types of viruses.

A Trojan is a program that while visibility performing one function, secretly carries
out another. For example, a program could be running a computer game, while
simultaneously destroying a data file or program.

A logic bomb is a piece of code triggered by certain events. A program will behave
normally until a certain event occurs, for example disk utilisation reaches a certain
percentage. A logic bomb, by responding to such conditions, maximises damage, for

Page 87 of 111
 example it will be triggered when a disk is nearly full or when a large number of
users is using the system.

A trap door is not itself a virus, but it is an undocumented entry point into a computer
system. It may not be found in design specifications, but may be put in by software
developers to enable them bypass access controls while working on a new piece of
software. Because it may not be documented, it may be forgotten and used at a later
date to insert a virus.

Viruses can spread via disks, but have been known to copy themselves over whole
networks.

How can organisations protect themselves from viruses?

(c) Vaccine programs exist which can deal with some viruses, but if the lives in the
bootstrap program; the virus can work before the vaccine is loaded.
(d) Organisation should as a matter of routine ensure that any disk received from outside
with data on it is virus-free before the disk is used. Any flows in a widely used
program should be rectified as soon as they come to light.
(e) Establish procedures and reviews to minimise the chances of infection. Virus
protection controls should become part of the internal control system of an
organisation, as with controls to prevent fraud.

Good office practice

Data is often shared between users.
• There should be a designated data owner for each file responsible for:
(a) Keeping the data accurate and up to date.
(b) Deciding who should have access to the data.
(c) Developing security procedures in conjunction with the data security manager.

• If computer printout is to include confidential data, it should be shredded before being

thrown away.
• Disks should not be left lying around an office. They can get lost or stolen. More
likely, they can get damaged.
• The computer environment (humidity, temperature and dust) should be controlled.
• Files should be backed up regularly.
• Appointment of a system expert to be responsible for learning technical details about
the office computer user problems.
• Have a user support facility such as an information center.
• Have a binding, strong contract with the manufacturer or a third party for service and
repair of machines or insurance cover.

Backups and standby facilities

All master files should be backed up after each updating run. Back ups should be stored
in a different place from the original files.

Page 88 of 111
Standby hardware facilities
Hardware duplication will permit a system to function despite a hardware breakdown.
The provision for backup computers is costly, particularly where these systems have no
other function. Many organisations will use several smaller computer system and find
that a significant level of protection against system faults can be provided by shifting
operations to one of the systems still functioning. Where a organisation has only one
system to rely upon, this ready recourse to a back up facility is unavailable. In these
instances, one response would be to negotiate a maintenance contract which provides for
back up facilities.

System Development Controls

When a computer system is developed from scratch, either in house or a by a software
house, there, should be controls over the system design, development and testing.
Because of the time spent on systems development, the cost of it and the complexity and
the volume of work involved, it is essential to lay down high standards of control.

The main objectives of system development control are as follows.

(a) To ensure that new computer systems are developed only if they appear to be
beneficial. System justification should be on the grounds of favourable cost-benefit
analyses or other performance criteria.

(b) To ensure that each system under development has clear, specified objectives.

(c) To control the scheduling of development work. This can be achieved through
techniques such as critical path analysis.

(d) To ensure that suitable operational and administrative and controls are built into the
system design when it is being developed.

(e) To ensure that users acquire an understanding of the new system. The handover of the
computer system from the hardware and software experts to non technical staff must
be done in such a way that the computer users are able to learn as much about their
system as they need to know. Training of staff will be necessary, but there should also
be full, clear and non-technical documentation of the system.

(f) To establish a basis for management review of the system.

(g) To ensure that systems and programs are maintained when the system becomes
operational.
(h) To ensure that proper and complete documentation of the system is created and
maintained.

Many of these controls will be provided by the systems development methodology used.

Controls over amendments to the system design is needed. Once development has started,
it is all too easy for the system designer or the user department managers to think of new

Page 89 of 111
features to add to the system or improvements that can be made, with the result that
amendments get written into the system as development progresses. Some amendments
may be desirable; others may not be worthwhile.

Controls should be exercised over amendments so that if any amendments are proposed
which were not included in the system specification, they must be authorised at a suitable
managerial level. The authorisation and details of the amendment should be included in
the amendments section of the system specification.

Controls over file conversion

The conversion of a master file is one of the big problems of systems implementation and
proper procedures and controls must be laid down to ensure that there are no
unauthorised conversions and that the correct records are accurately and completely
transferred onto magnetic files. The procedures may include:

(a) Full planning of the file conversion, including staff to be used, records to be
converted (possibly via data preparation), controls to be set up and the date of
conversion.
(b) The establishment of a control group to follow up errors which may occur during the
conversion.
(c) Printing out master files after conversion and manually checking them back to the
original records.
(d) The reconciliation of accounting records to those kept under the old system.
(e) Division of responsibility among the conversion staff (additional staff may have to be
brought in to help with the conversion).
(f) Testing of the new master file using the test data and the control and documentation
of any changes necessary.

Data processing standards

Data processing standards are standards for the development; Procedures and
documentation of computer systems. The purpose of the standards is to minimise the
likelihood of errors and misunderstandings in both the development and operation of
operation of computer systems. More specifically, standards are helpful in the following
ways:

• The documentation of a computer system

Documentation is needed for system and program specifications, and also for operator
instructions. The existence of standards for documentation:
(a) Establishers the need to document a system:

(b) Provides a standard format for document the system, which helps to ensure that
nothing is left out of the specification:

(c) Gives the people operating a system somewhere to look up and learn the system’s
operating requirements:

Page 90 of 111
Usefulness of documentation standards
• Communication of information about the system

Standards documentation provides a means whereby information about a system can be

communicated, for example between programmers and analysts, and between system
developers and the users and the operators of the system.

• Continuity after the staff changes and an aid to training

People leave their job from time to time or are absent for one reason or another. Unless a
system is well documented in a standard way, or has been designed according to a
standard procedure, it might be difficult for a person’s stand-in or replacement to pickup
the job where his predecessors left out.

• Standards help people to learn the system. They are particularly helpful for staff
moving from one job to another because they will have some familiarity with the
format of the documentation standards e.g. if a computer operator moves from his job
in A Ltd to a new job in the computer center for B Ltd, he will be able to learn his
new job partly by referring to B LTD’s standard for computer operations. These
standards will be similar in format to the ones used in A Ltd and so the operator will
know how and where to look up information that he needs to know.

Documentation for a system includes user manuals, hardware and operating software
manuals System specification and program documentation. Documentation is a feature
for most systems analysis and designs methodologies.

Data processing standards should ensure that all the staff involved in the staff in the
computer system has proper instructions and that these have been fully documented. This
means that there must be:

(a) Operation instructions for each computer installation.

(b) Operation instructions for each program

(c) File library instructions, specifying how files should be labelled, safeguarded, issued
and if necessary, reconstructed.

(d) Data conversion instructions for the data preparation staff.

(e) Data conversion instruction for the data preparation staff.

(f) Data control instructions for the control section.

(g) User department instructions.

Page 91 of 111
The system specification is a complete description of the whole system and must be kept
up to date as part of the system are changed or added to. Many of the problems in
computer installations because of inadequate documentation and controls must be set up
to ensure the updating procedures are always carried out.

Program specification
Program specifications or program documentation describe programs using charts, full
listings of the programs and details of test data and results.

Program specification (excluding listings of programs themselves) is drawn up by the

system analyst. A copy of a program specification is given to the programmer responsible
for writing the program, and the programmer then uses the program as the basis for
writing and testing the required program. When the program has been written and tested
and, one copy of the final specification will form part of the overall systems specification
and the final copy will be retained by the programmer to form part of the programmer’s
own documentation for the program.

Computer operations manual

Computer operations manual provides full documentation of the procedures necessary to

run the system. Amongst the matters to covered by this documentation are:

(a) Systems set-up procedures. Including details for each application of the necessary file
handling and stationery requirements.

(b) Security procedures. Particular stress should place on the need to check that proper
authorisation have been given for processing operations and the need to restrict use of
the system to authorised operators.

(c) Reconstruction procedures. Precise instructions should be given for such matters as
file dumping and also recovery procedures to be adopted in the even of a systems
failure.

(d) System messages. A listing of all messages likely to appear on operators’ screen
should be given together with an indication of the responses, which they should
evoke.

(e) Operating systems manual. These are manuals that describe an operating system.

User manuals

User manuals or users documentation explain to users how to run a system, but do not
give unnecessary technical details such as program listings. Matters to be dealt with
include:

Page 92 of 111
(a) Acceptance testing: responsibilities for the preparation of test data and subsequently
checking the results.

(b) Input: responsibilities and procedures for the preparation of input including
requirements for the establishment of batch control total and for authorisation.

(c) Error reports; full explanation of the nature and form of error reports (such as reports
of items rejected by computer checks) and instructions as to the necessary action to be
taken.

(d) Master file amendment procedures: full explanations of the authorisation and
documentation required for master file amendments.

(e) Output: what is produced, what form it takes and what should be done with it.

System changes manuals

Amendments to the original systems specifications will almost inevitably occur, in

addition to the computerisation of additional activities. The objective of a system changes
manual is to ensure that such changes are just as strictly controlled as the original systems
development and introduction.

Application controls
Errors in data processing can easily occur. Application controls are intended to detect
errors and ensure that they are corrected before proceeds further.

Input data can get lost, or it might contain errors. Human error is the greatest weakness in
computer systems. The extensiveness of the input controls will depend on the method of
processing input data (for example keyboard input or OCR document input) and the cost
of making an input error. If the consequence of input errors would be costly, the system
should include more extensive input controls than if the cost of input errors were
insignificant.

Errors may occur at various stages of data processing.

Data capture
Mistakes include:
(a) Writing an incorrect figure, such as 1243 pounds instead of swapping 1234 pounds:
swapping figures around by mistakes is referred to as a transposition error:
(b) Spelling mistakes, such as getting a customer’s name wrong:

(c) Measuring mistakes, such as timekeeper writing down an incorrect time for job
because he read his watch incorrectly.

Page 93 of 111
(d) Classifying mistakes such a cost accountant recording a direct labour cost as an
overhead item or an expenditure in administration as a production cost.

Error in data capture are difficult to spot once they have been made, because they are
often error on the source document. Checking can reduce them. One person’s work might
provide a check on the accuracy of another’s. For example, getting another person to add
up to the total amount of invoices received that day, from the invoices themselves could
check the recording of suppliers’ invoices. This total could then be checked against the
total for invoices recorded.

Another way of dealing with errors in data capture is to reduce the likelihood of error
arising in the first place by including as much pre-printed information on the data
recording documents as possible and by giving clear instructions about how the
documents should be filled in.

The use of turnaround documents and OCR, MICR, bar coding or in some applications
plastic cards with magnetic stripes containing some of the input data reduces the need for
manually prepared input data, and so reduces data capture errors.

Transcription
Transcription errors occur when data is copied from one form to another. For example, a
person might jot down some data on a piece of scrap paper, and then copy it incorrectly
onto a formal document later on.

Data preparation errors occur when the original capture data has to be transcripted into a
form that the computer can read such as a magnetic tape or magnetic disk. Errors arise
because the original data can be copied wrongly in the machine – readable form. These
errors are sometimes referred to as data conversion errors.

If input data must be prepared manually, controls can be applied to minimise the number
of errors.

(a) Staff who prepare data for input should be well trained and properly supervised.

(b) Data input documents should be in a format which helps the person preparing the data
to fill them properly.

(c) When data is input by keyboard the screen should be formatted so as to help the
keyboard operator to input the correct data. User-friendly software packages might
provide on screen prompts and formatted for input data.

If data must be converted from one form to another for input, for example from a paper
document onto disk the data could be keyed to check for the copying errors. However,
this is expensive.
The staff that prepares the data should be encouraged to look for errors.

Page 94 of 111
(a) If input is done by keyboard the input data will be shown on the VDU screen and a
visual check on the data can be made.

The input record will often have a key field identification code. For example, a sales
ledger file will consist of customer records, which each customer having a code would be
part of input data and the program might search for the customer record on the sales
ledger file, and display it on the VDU screen. The input operator could then check
visually that the correct customer record is being processed.

(b) If input is done in batches, the program might produce a listing of the input data,
which could be checked for accuracy. Printed listings of input data also provide an
audit trail in computerised accounting systems so that internal and external auditors
can follow transactions through the system later.

Data transmission
Errors in transmitting data involve the loss or corruption of data, which is sent to the
computer, by post, courier or telecommunications link from a remote terminal.

When data is input from a terminal user should be able to check that the data has been
input fully and accurately by obtaining a printout back from the computer of all accepted
data.

When data input is batched and physically dispatched to a computer center processing,
batch control checks can be applied to ensure that all the data that has been dispatched is
safely received at the computer center. These checks involve:

(a) The user department giving each batch a unique identification number.

(b) The identification numbers of all batches being written on a batch control document,
by the user department supervisor. This document will be sent to the computer center,
with a copy being retained by the user.

(c) The data control clerks in the computer center checking that the batches that are
received tally with the numbers on the batch control document.

Processing
Errors might occur or come to light during data processing, for three broad reasons.

(a) It may become apparent during processing, when it would not necessarily have been
apparent at the data capture stage, that there is something wrong with the transaction
data. An attempt should be made to locate these errors as soon as possible, to prevent
the computer from acting on invalid data. A data validation (or data vet) program is
used to check the input data for errors that can be spotted by computer logic.

(b) It may become apparent during processing that there is something wrong with the
master file record. Example would be:

Page 95 of 111
(i) Trying to record an invoice sent to customer number 234, when no such customer
account has been opened.

(ii) Trying to delete employees number 678 from the payroll when there is no such
employee in the payroll records.

(iii)Trying to open a new account for suppliers number 372 when there is already an
account for that supplier.

These are referred to as errors because they come to light when the master file is updated.

(c) There may be a programming error i.e. a flaw in the logic of computer program.

Validation checks
Some check on the validity of input data can be written into the system’s programs.
These data validation checks (or data vet checks) might be performed by a separate data
validation program in a batch processing system. Alternatively, any program can
incorporate validation checks on input data for example on data keyed from a terminal
into an on-line system.

Data validation
The data validation program or program which incorporate data validation routines, will
be the first program in each batch processing application. The program attempts to find
errors in the input record or batch to prevent them any further.

The checks, which can be made, are logical checks, which prevent some of the worst
types of error form getting through to be processed. Data validation does not provide a
comprehensive error check, however and some error on source document are likely to go
undetected. This emphasises the need for control over source document creation.

The main types of data validation checks are outlined below. Note that the same type of
check can be made on different fields of a record and not all types of check need appear
in a data validation program. However, a single program might carry out dozens of
validation checks on different records and fields.

(a) Range checks are designed to ensure that the data in a certain field lies within
predetermined limits. For example, in wages application, the program may contain
instructions to reject any clock card with ‘hour worked’ outside from the range from
20 to 80 hours and to print out a special report (for checking) on any clock card with
hours worked outside the range from 35 to 60 hours.
(b) Limit checks sometimes called credibility or reasonable checks are very similar to
range checks, but check that data is not below a certain value. In the previous
example the check of hours worked might be that the value in the record field does
not exceed 80 with a rage check, there is an upper bound but not both.

Page 96 of 111
(c) Existence checks are checks on record field to ensure that to the data is valid for that
field. For example:

(i) Check that the record type is 1,2 or 3

(ii) Check that the stock code exists by looking up the stock code number of the record in
reference file.

(d) Format checks (picture checks) check that the record has the required data fields and
that each data field has data in the correct format. For example,
i) Check that the format is all numeric 9999 (here, four figures).
ii) Check that the format is all alphabetical AAAAA (here, five letters).
iii) Check that format is alphanumeric A999 (here, one letter followed by figures).

(e) Consistency checks check that the data in one field is consistent with data in other
field. For example, in a payroll system there might be a check that if the employee is
a Grade C worker, he or she belongs department 5, 6 or 9.

(f) Sequence checks check that records and batches are processed in the correct
sequence.

(g) Complete checks

(i) A check can be made to ensure that all records have been processed. For example,
if a weekly processing run must include one record for each of the five working
days of the week, a completeness check can ensure that there are five input
records.
(ii) Completeness checks on individual fields would check that the item of data has
not been omitted from an input record.

(h) Check digits are numbers (or perhaps letters) added to a code to give it some special
mathematical property, which can be checked by the computer.
(i) Batch total checks. In a batch processing system, the number and/ or the total value of
the record processed by the computer from each batch, including rejected records,
should reconcile with the control total(s) in the batch control slip, which will also
have been input to the program.

When validation checks identify an error, there are a number of possible outcomes.

(a) The record concerned will probably be rejected and processed no further with perhaps
a message on screen. Rejection reports may be printed out at some stage during
processing.

(b) The record concerned may not be rejected, but an exception report might still be
output or the operator advised in some way on screen. This may happen, for example,
where a range or limit check is not satisfied. Just because a record is not within pre-

Page 97 of 111
 set limits does not automatically mean that it is incorrect. If it is valid, then not
processing it would be a waste of time. However, administrative controls must ensure
that all exception reports are followed up.

(c) If an error is revealed by batch controls, the whole batch must be checked.

Output controls
There should be controls over outputs from computer processing.
(a) In a batch processing system, where data is batched and sent off to a computer center
there should be a check to make sure that the batches that were sent off have been
processed and returned.

(b) All input records that have been rejected by data validation checks and master file
update checks must be looked at to find out the reasons. Correct data should then be
prepared for re-input. Some errors might need immediate correction, such as those on
input records, which have been, rejected by data validation checks in a payroll
program for preparing salary payments to staff.

(c) Output should be correctly distributed and a log should be kept of the distributions
that have been made. In a computer center, this is the responsibility of the data
control staff. In an office, someone has to be responsible for dealing with output from
the printer.

(d) Output onto magnetic files should be properly labelled and stored.

File controls
Controls can be applied to ensure that:
(a) The correct files are used for processing.
(b) Data is not lost or corrupted
(c) If data is lost or corrupted, then it can be recreated.
(d) Unauthorised access to data is prevented.

In a large computer center, the administrative responsibility for the physical security
should be assigned to a member of staff.

Software controls over files

The computer will check that the correct file has been loaded for processing before it will
begin its processing operations. It can do this by checking the file header data written on
the file in magnetic form, and comparing this data with data about the file that it has been
instructed to process. If the computer has been instructed to process master file A, it will
first of all check the master file A has been loaded for processing, and that correct
generation of the file has been loaded.

Page 98 of 111
Checkpoints and recovery procedures
A checkpoint or restart program is a utility that intervenes at certain point (checkpoints)
during the running of a program and dumps the entire content of memory onto a storage
device.

Should anything turn out to be wrong with the running of the application program the
application program can be taken back to the checkpoint before the error occurred and
restarted with conditions exactly as they were before.

Control totals
A control total could be:
(a) The number of record on a file

(b) The total of the value of a particular field in all the records on a file for example the
total of debts outstanding in all the customer records on a sales ledger file.

(c) The number of records in a batch (batch control total)

(d) A harsh total. This is a total that has no meaning except as a total check; for example,
the total of customer account numbers.

Control total checks are written into programs to ensure that:

(a) No records have been lost
(b) No records have been duplicated
(c) Input files have been read fully
(d) All output records have been written to output files.

Control totals are established into two different ways, for example by adding up the
account number after the most recent run, by taking the total after the previous run and
adjusting it for new account for accounts closed. Any different between the totals can be
investigated.

Database controls
Databases present a particular problem for computer security. Databases can often be
accessed by large numbers of people, and also there is a risk of alteration, unauthorised
disclosure or fraud.

It is possible to construct complicated password systems, and the DBMS can be

programmed to give limited views of its content to particular users. However, there are
problems in ensuring that individuals do not circumvent the controls by means of
inference. For example, an employee database might forbid you to ask whether John is an
employee in category A. However, if you know there are only three employee categories,
A, B and C, you can work out the members of category A by elimination. Interference
controls may make this difficult by limiting the number of queries, or by controlling the
overlap between questions.

Page 99 of 111
PROGRAM DESIGN

A ‘program’ has many synonyms: process, module, unit, routine, subroutine, macro, etc.
All of these are lines of code with a beginning and an end, they serve one purpose, such
as validate customer number, and have a well defined interface with the rest of the
system.

The following points are important in program design:

• One function. Systems are portioned by a hierarchy of programming modules. Each
program should carry out only one function. Modularity makes the program easier to
maintain.
• Size. The fewer the number of lines of code in a program, the more efficient the code
will be (in term of storage pace and execution time) and the easier it will be to
maintain.
• Cohesion measures the strength of relations within a program. This mans that what
happens in one subroutine affects the other subroutines of that program. A program
that performs more than one function will have low cohesion. A high degree of
cohesion within programs results in a more maintainable system, and therefore a
higher quality solution.
• Coupling is a measuring of the strength of the bonds between programs. Ideally
programs should have little dependence on other programs in the system. This is so
that any amendments to the program have little or no impact on the other programs in
the system.

Why break the system into programs?

• One program should be written by one programmer, so if the system was just one
program, it would take one programmer months or years to write.
• Smaller programs are easier to specify, test and modify because errors or the impacts
of a change are contained within fewer lines of code.
• Programmers are more motivated to code in the areas of the system that interests
them.
• A large number of small programs makes rescheduling the work easier. If one
programmer is taking longer than estimated on a program, one of their later programs
can be assigned to someone else to write.

What’s in a good program specification?

A program specification is like any other document in that it should be accurate, brief and
clear. The specifier also needs to know who the specification is written for. Apart from
the programmers(s), programs specifications are also used by system maintenance and
quality auditors. Both of the latter two groups welcome the move towards a consistent
approach to documenting program specifications. It also allows the programming team
leader to reschedule work more easily.

Processing outlined in any program design is one of three categories: processing

sequence decision or iteration. A processing sequence is a number of instructions that
must be programmed in the order detailed in the sequence. A decision indicates that there

Page 100 of 111

more than one possible path through a program and that the path will depend on whether
the decision criteria are met. Iteration indicates that a section within the program will be
executed zero, one or more times until exit condition is met.

Suggested Program Specification Contents

The following is a suggested contents list for a program specification.
• Document details This consists of header information which uniquely identifies this
specification: title, author, reviewer, circulation list, release date, system identifier,
program identifier and version number.
• Introduction One of the most frequently discussed aspects of program design is the
level of explanation it should contain. Here again the argument of stifling creativity
arises: the specifier defining the process at too low a level is doing the programmer’s
job. We suggest using three levels of description within the document. The
introduction is the first of these and gives a brief summary of what the program does
in business terms. Data referred to in the program overview should be at the data file
level, not lower. This is because the overview will be read by users, project managers,
team leader, and maintenance programmers who need a short summary of what the
program does.
• Assumption and restrictions This section lists any constraints on the program such
as ‘normal path processing must complete within 0.2 seconds’. It will also add
information which affects the logic of the program. This could be ‘the program will
be cloned to run on each user’s terminal or ‘a maximum of 10 messages will be
queued to this program’.
• Attributes This section outlines the program’s environment and will cover aspects
like the hard ware it will run on, the operating system used and the programming
language to be used. If this information is the same throughout the project, this
section might simply refer to a higher-level design document containing this
information.
• Data The input to the program and any output it generates is detailed here. It provides
a data – driven view of what the program does. The section also refers to the data
dictionary to cover the format and validation rules for all shared data used in the
program.
• Functional description This intermediate level of process description may not be
necessary for small, simple programs but the default is to include it. It provides a ‘big
picture’ view of the program’s input, outputs and processing before going on to
explain the detail. Data in this description is referred to at the record level.
• Detailed processing This section expands on the previous description to give a low-
level detailed view of the processing paths through the program but continues to
focus on what has to be done. Data is referred to at the data field level.
• Errors and exception conditions this deals with anything other than the normal
case, such as events occurring out of sequences. It describes how the program will
cope with these, lists any error messages and identifies the destination of each
message.
• Operational considerations Information from this section may be incorporated into
the user manual later. It describes how the operator interacts with this program in the

Page 101 of 111

 normal case and how the operator can recover to a safe state or restart the program if
anything should go wrong.
• Subroutines Common routines used by the program are identified as are their input
parameter. Input parameter could again simply be referred to if they are denied in a
higher-level document. Calls to the system executive (i.e. manufacturer-supplied
functions/procedures) are also listed here. The reason for having a separate section on
subroutines is so that if a subroutine changes-let’s say an extra parameter is added-
the modifier need only check this section rather than read through the whole
document to find out whether this program must be amended.
• Messages This section identifies messages sent and received by the program. It lists
the message identifier and its purpose.
• Print layouts detailed print layouts or screen layouts are included here. Sometimes
the document only includes a pro forma layout and the details are added by the
programmer.

The design specification

The design specification is the primary document of the design phase. It should contain
everything needed by the programmers in order to program the system. The design
specification is both the documentation of the finished system design and the tool used to
create the design. In other words, the documentation is not created after the fact, but
instead it is a result of the design itself, when the design is complete, so is the
documentation.

Content of the design specification

• Table of contents
• Process description
• Data dictionary
• Screen Report and Source Document Design
• Detailed and software specifications
• Security requirements
• Programmer’s handbook
• Guide to using the design specification
• Index

Page 102 of 111

CHAPTER FOUR: SYSTEMS POST
IMPLEMENTATION

INTRODUCTION
Research has shown that 79% of organisations are currently performing post
implementation evaluation of some or most of their installed CBIS. It has been observed
that post implementation evaluation is performed only on a small fraction of the system
developed.

Research findings reveal that much of evaluation is performed and managed by the
members of the system development team. These are the people who have the most say in
determining evaluation criteria and evaluation methodology. Since the design ideals and
the values of the developers are instrumental in shaping the system design and the
systems development process, it is unlikely that an evaluation managed and performed by
the team will discover any basic flows in the process or the product design.

Evaluation of the system as they are developed and implemented may take place at the
completion of various stages of the SDLC. Formative evaluation produces information
that is fed back during development to help improve the product under development. It
serves the needs of those who are involved in the development process.

Summarative evaluation is done after the development is completed. It provides

information about the effectiveness of the product to those decision makers who are
going to be adopting it. Post implementation evaluation include evaluations performed
just before installation, just after installation, and considerably after installation i.e. after
the system has a chance to settle down.

Use/purpose of Post Implementation

(i) To verify that the installed system meets user requirements.
(ii) To provide feedback to the development personnel.
(iii) To justify the adoption, continuation or termination of the installed system.
(iv) To clarify and set priorities for needed modifications.
(v) To transfer the responsibility for the system from the development team to the
users.

What is evaluated?
The criteria evaluated include:
(i) Accuracy of information
(ii) Timeliness and currency of information
(iii) Users satisfaction
(iv) Attitudes towards the system
(v) Internal controls
(vi) Projects schedule compliance

Page 103 of 111

(vii) System fit and impact upon the organisation structure
(viii) Quality of programs
(ix) Net operating costs
(x) Savings of system
(xi) System impact on user and their jobs
(xii) Quality and completeness of system documentation.

Benefits of post implementation evaluation

(i) Improvement of systems development practice decisions; to adopt, modify or
discard information systems.
(ii) Evaluation and training of personnel responsible for system development.
(iii) Ensure compliance with user objectives.
(iv) Improvement in the effectiveness and productivity of the design.
(v) Realisation of cost savings by modifying system through evaluation, rather than
after a real operation.

Page 104 of 111

 CHAPTER FIVE: SYSTEM
IMPLEMENTATION
The handover between analysis, design and development is becoming more and more
informal especially with the accessibility of 4 GLs and CASE tools to produce code.
Artificial boundaries between analysis, design and development are becoming
increasingly irrelevant.

However, whatever software is used or organisational arrangements adopted, the newly

developed system must now be delivered and implemented. Some practical tasks must be
completed. i.e. testing, conversion, documentation and training. Also a consideration
should be done of the different implementation strategies that can be adopted.

Testing
During the programming stage, each programmer or programming team will perform
their own program testing to the specifications laid out by the designers. The completed
programs are then passed to the designer for further testing, who will examine them and
approve their interfaces with the rest of the system.

Testing will be performed by:

• Desk checking –comparing programming flowcharts with original specifics.
• Running with test data.
Test data should be manually compiled and the results produced by the system compared
with the appropriate clerical figures of the current computer system.

Common input errors to test for:

• Oversize and undersize data items.
• Incorrect formats
• Out of range items
• No data at all
• Invalid combinations
• Negative numbers.

Errors may be caused by:

• Incorrect programming
• Misunderstanding specifications
• Omissions in original design

After the required amendments are coded by the programmer, the programs and system
must be retested. This is because fixing of a fault can be a source of another fault in a
program.

Some timing aspects of the system can also be clarified during testing e.g.
 Response times e.g. retrieval speed of a record
 Processing time
 Output schedules.

Page 105 of 111

Any related problems may be solved by file restructuring or the use of faster
programming languages. Problems due to hardware not achieving what is claimed in the
specification must be taken up with the supplier.

A modular approach permits progressive testing as follows:

a) Module testing – Validating the internal code of a module.
▪ Desk check
▪ Compile
▪ Test data
b) Suite testing – Seeks to test that a logical sub-system is working correctly and that
data is passed properly between the modules in this subsystem.
c) System testing – Designed to ensure that the sub-system is working correctly and that
data is passed properly together. It should pass through the following phases:
▪ Single run – Testing the system over a single pass of data.
▪ Cycling tests – Testing the system over several cycles of processing to ensure it
correctly deals with end of period routines.
▪ Clerical tests – Tests all aspects of the interface between the user and the system.
d) User Acceptance Testing – This is the testing of the system by the user department,
after the system has passed the test. This test seeks to:
- Find out exactly what are the user demands of the system
- Find out whether any major changes in the system will be necessary
- Find out how the system responds to large volumes of data (as expected to be
input by the user) and at the same time use the tests as an opportunity to train staff
in the new system, etc.

Optimisation
What if the system fails its acceptance test because it is too slow? What if, for
instance, it has a five-second-response time on a critical function for which a one
second response is required?

Prior to the testing stage, we would have had no reason to be concerned with the
efficiency of the program unless we were working with a system in which speed was
a requirement. After all, for a standard business application, it is futile to worry about
efficiency when we have not yet made sure that the system will even work. We
should wait until the system is complete, find the places where it is too slow, and then
perform optimisation, modifying it so that it is faster in those places where more
speed is required.

We try to optimise the parts of the system in which the change will give us the
greatest benefits. Maybe we have determined that optimising one small subroutine
that is used repeatedly within a slow program will speed up the entire program
considerably. Conversely, changing a statement that is executed only once will have
no appreciable effect.

We should be careful in attempts at optimisation, since our actions may sometimes

have the opposite effect from what we intend. Recording in assembler language, for

Page 106 of 111

 instance, will make a program more efficient only if the programmer is good at
writing efficient assembler code.

Optimisation Techniques.
There are many ways to optimise a system, including the following:
• Acquire improved hardware in order to improve system performance. This might
be a cost-effective solution in that the hardware might be less expensive than the
cost of paying programmers to optimise the code.
• Use an optimising compiler
• Record in assembler language
• Improve input and output speed (Traditionally among the slowest of computer
task) by changing file access methods, increasing buffer and block size to
minimise accesses, or eliminating unnecessary accesses.
• Eliminate subroutine calls by replacing them with macros.
• Curtail the use of fourth –generation languages.
• Improve the algorithm of the module.
• Denormalise files. That is, combine files that are often accessed together, with
that access happening frequently.

If the analyst decide that the software needs optimisation, the organisation’s very best
programmers should be given the assignment, because optimisation is an extremely
delicate task. It is also the programmers, not the analysts, who should decide what is
the best way to attack the problem, although the analysts should retain the right to
veto any methods that have been shown to be especially difficult to maintain. In the
process of optimising a system, programmers may reduce its ease of maintainability.
If a COBOL routine is recorded in assembly language, for example, that routine will
become harder for the average programmer to maintain. It is for such reason that we
optimise only when we are forced to do so, and even then we try to limit the changes
to only those that are necessary.

File Conversion
The movement of data from one format to another may lead to both programming and
management tasks. If the files are currently held on a computer system, then it should
be possible to move the data from the present implementation to the target hardware
and software. However, a thorough investigation should be done on cost and
compatibility. Some routines may need to be written to modify the data after
conversion.

The task of organising the creation of files must be approached carefully. It may
require extra clerical resources. File conversion creates important technical and
operational requirements which have to be planned for by the designer.
Documentation
Documentation is a constant task in system development. The documentation during
system analysis and design prompts for action, not just a record of action.

Page 107 of 111

 Implementation documentation
Three types of documentation are associated with implementation.
a) Training Documents
i) Easing the transition from the current system to successor.
ii) Providing detailed tuition in the operations of the proposed system.
Such documentation may use conventional media and methods i.e. handouts, lectures and
tests in the traditional setting of a training course.

b) User Documentation
- Reference documents rather than learning documents.
- Reflects the expertise and vocabulary of the variety of users involved in the
system.
- It should concentrate on the issues that concern users the most i.e. functions and
errors.
c) Operations Documentation
- Responsible for the day-to-day running of the system.
- It teaches the normal operating procedures and how to respond to errors.

Training
- It covers the retraining of current staff and the recruitment of new personnel. The
latter involves job specifications, advertising, salary advice and interviewing.
- For training to be effective, it must be clear what it is trying to achieve. The
training objective suggests ways of delivering that training e.g. lectures, tutorials,
case studies, practice etc.

In summary, the tasks of implementation require careful planning and co-ordination.

Lack of this will undo months of good system and programming work.

Implementation Strategies
There are four possible strategies available.

i) Parallel running
- Old and new system are run simultaneously for an agreed period of time and
results from the two systems are compared. Once the user has complete
confidence in the new system, the old system is abandoned.

Disadvantages
- Large administrative overhead – double work
- Time consuming

Advantages
- Security – fall back
ii) Pilot running
Two possible exist.
a) Retrospective parallel running – Uses historical data and the output procedure is
compared with the known results.

Page 108 of 111

b) Restricted entry data running – Involves a complete logical part of the whole system
being chosen and run as a unit on the new system. If it works, the remaining parts are
then transferred.

iv) Direct changeover – Implement the new system completely and withdraw
without any sort of parallel running at all. It demands thorough testing and well
planned file creation and training strategies.

Advantages
- Quick and most complete.

Applicable where:
- There is little similarity between the old and the replacement system(s), cross
checking not possible.
- Cost of parallel running is so prohibitive that is cheaper to pay for the mistakes of
a direct changeover.
v) Phased changeover
Takes 2 possible forms
a) Where the organisation is divided into various divisions and the system is
implemented in phases.
b) Where the information system is divided into components and the components are
installed in stages.

Applicable where:
- Large projects
- Where distinct parts of the system are geographically dispersed.

Page 109 of 111

 CHAPTER SIX: SYSTEMS POST
IMPLEMENTATION

INTRODUCTION

Research has shown that 79% or organizations are currently performing post
implementation evaluation of some or most of their installed CBIS. It has been observed
that post implementation evaluation is performed only on a small fraction of the systems
development.

Research findings reveal that much of evaluation is performed and managed by the
members of the systems development team. These are the people who have the most say
in determining evaluation criteria and evaluation methodology. Since the design ideals
and the values of the developers are instrumental in shaping the system design and the
system development team will discover any basic flows in the process or the product
design.

Evaluation of the systems as they are developed and implemented may take place at the
completion of various stages of the SDLC. Formative evaluation produces information
that is fed back during development to help improve the product under development. It
serves the needs of those who are involved in the development process.

Summarative evaluation is done after the development is completed. It provides

information about the effectiveness of the product to those decision makers who are
going to be adopting it. Post implementation evaluation include evaluations performed
just before installation, just after installation, and considerably after installation i.e. after
the system has a chance to settle down.

Use/purpose of Post Implementation

i. To verify that the installed system meets user requirements.

ii. To provide feedback to the development personnel.
iii. To justify the adoption, continuation or termination or the installed system.
iv. To clarify and set priorities for needed modifications.
v. To transfer the responsibility for the system from the development team to the uses.

What is evaluation?

The criteria evaluated include:

i. Accuracy of information.
ii. Timeliness and currency of information.
iii. User satisfaction.
iv. Attitudes towards the system.
v. Internal controls.

Page 110 of 111

 vi. Project schedule compliance.
vii. System fit and impact upon the organization structure.
viii. Quality of programs.
ix. Net operating costs.
x. Savings of system.
xi. Systems impact on user and their jobs.
xii. Quality and completeness of system documentation.

Benefits of Post implementation evaluation

i. Improvement of systems development practice decisions; to adopt, modify or discard

information systems.
ii. Evaluation and training of personnel responsible for system development.
iii. Ensure compliance with user objectives.
iv. Improvement in the effectiveness and productivity of the design.
v. Realization of cost savings by modifying system through evaluation, rather than after
a real operation.

Page 111 of 111