INFS 328

Systems Analysis and

Design
Session 1 – Systems Theory

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

To have a good appreciation of the techniques of Systems

analysis and design, it is essential to examine; what we
mean by a system, the essential nature of a system and the
characteristics of a system to the study of Systems Analysis
and Design. This can best be understood by studying what
System Theory is.

Slide 2
 Session Outline

The key topics to be covered in the session are as follows:

• Systems Theory – Definition and Types of Systems
• System Elements
• The Relationship of Systems Theory to the Study of Systems
Analysis and Design

Slide 3
 Reading List
Checkland, P. (1999). System Thinking, System Practice.
Chiches: John Wiley

Slide 4
Topic One

SYSTEMS THEORY

Slide 5
 Systems Theory
DEFINITIONS OF A SYSTEM
• In its simplest form a system is a set of components that
interact with one another for some purpose.
• A System may be considered as an assembly of
components united by some form of regulated
interaction to form an organized whole.
• Lastly, a system may be an organized set of procedures
required to accomplish a specific function.

Slide 6
 Systems Theory
EXAMPLES AND TYPES OF SYSTEMS
Society and nature abound in systems. For example
Nervous system, digestive system for a body, society,
organizes legal system, political systems, educational
systems, tax systems etc. Organizations have information-
order systems, management information system, product
information system, personal data system, Information
system etc. Hospitals have record keeping systems – health
insurance systems etc.

Slide 7
 Systems Theory
TYPES OF SYSTEMS

There are two (2) types of systems namely;

• Abstract and
• Physical.

Slide 8
 Systems Theory

TYPES OF SYSTEMS - ABSTRACT SYSTEM

This is conceptual. It is a product of the human mind. It is
not a system that can be seen or pointed to as an existing
entity. Examples of abstract systems include, social
systems, theological systems, cultural systems etc. Bear in
mind that none of these entities can be photographed,
drawn or otherwise physically pictured. However, they do
exist and can be discussed, studied and analyzed. An
example is the conceptual design of a systems project.

Slide 9
 Systems Theory
TYPES OF SYSTEMS - PHYSICAL SYSTEM
In contrast to an abstract system, a physical system is a set
of elements rather than ideas or constructs that operate in
relation to each other to accomplish a common goal or
purpose. Examples are computer systems and
communication systems. Computer systems are collections
of hardware elements that work interdependently under
some means of control to process data and produce output
reports and communication systems are collections of
components that can represent and transmit bits of
information from one point to another.
Slide 10
Topic Two

SYSTEM ELEMENTS

Slide 12
 Systems Theory
SYSTEM ELEMENTS
Within the basic definitional framework of a system are the
elements that are necessary for the very existence of the
system.

These may be identified to include; the Environment,

System Boundaries, Input/ Output, System Components.
Input – Process – output characteristics, Interfaces and
many more which will not be discussed here.

Slide 13
 Systems Theory
SYSTEM ELEMENTS - Environment
All systems operate within an environment. The
environment surrounds the system, both affecting and
being affected by it. The environment defines its external
relationships. Closed Systems do not interact with the
environment. Open Systems interact with the environment
by taking information and putting it out. They are
dependent on the environment and sensitive to changes
within it.

Slide 14
 Systems Theory
SYSTEM ELEMENTS – System Boundaries

These distinguish or separate the environment from the

system. The system exists within the boundaries, and
anything lying outside them constitutes the environment.
The system boundary line determines what is included
within the system and what is not.

Slide 15
 Systems Theory
SYSTEM COMPONENTS

System components are sub systems or smaller systems

lying within a bigger system. That big system has several
components and these smaller units work together with
each other to accomplish the goals of their individual units
and the goal of the larger system.

Slide 16
 Systems Theory
SYSTEM ELEMENTS – Input/Output

The system interacts with the environment by means of

input and output. Input is anything entering the system
from the environment. Output is anything leaving the
system, crossing the boundaries to the environment. In a
computer system, data enters the system as processed
data

Slide 17
 Systems Theory
INPUT – PROCESSING – OUTPUT CHARACTERISTICS
A System has an input, process and output. Input/ Output
have already been explained. Processes are methods of
converting input into output.

Interfaces are the meeting points for the systems or sub

systems. In other words interfaces are created when
system or sub system boundaries meet. This usually
involves some form of resource exchange often in the form
of an input – output relationship
Slide 18
 Systems Theory
A system may be represented by the following diagram
THE ELEMENT OF A SYSTEM

Slide 19
 Topic Three

RELATIONSHIP BETWEEN SYSTEMS THEORY

AND SYSTEMS ANALYSIS AND DESIGN

Slide 20
 Systems Theory
The Relationship Between Systems Theory and Systems
Analysis and Design
The following aspects of the systems theory explain why
some techniques are adopted in system projects.
• The Environment
• Interfaces
• Systems boundaries
• Input – Process –Out characteristics

Slide 21
 Systems Theory
The Relationship Between Systems Theory and Systems
Analysis and Design
When a newly designed system is implemented it has to be
done in an environment which will make the system
operational. The design is based on the input – process –
output characteristics. The inputs to the system should be
identified as well as the process the input will have to go
through to yield the desired output. The outputs then will
determine the type of output designs either print or electronic.

The system boundaries will define any limits and constraints

that the system to be designed would have. They will also
determine the types of interfaces that the new system to be
designed will have in order to be operational.
Slide 22
 Systems Theory
INFORMATION SYSTEM
This is an arrangement of people, data, processes,
information presentation and information technology that
interact to support and improve day-to-day operations in a
business as well as support the problem solving and
decision making needs of management and users.

Examples are payroll system, inventory system, account

receivable system, sales system etc. Systems that are
normally automated as far as system analysis and design is
concerned are information systems.
Slide 23
 References

Checkland, P. (1999). System Thinking, System Practice.

Chiches: John Wiley

Slide 24
 INFS 328
Systems Analysis and
Design
Session 2 – Classical Approach to Systems Analysis
and Design

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

Systems Analysis and Design presents a practical approach

to information technology and systems development. It is a
step by step process for developing high quality
information systems. An information system combines
information technology, people and data to support
business requirements

Slide 2
 Session Outline

The key topics to be covered in the session are as follows:

• Historical Overview
• Systems Development Life Cycle
• Structured Systems Analysis and Design

Slide 3
 Reading List
• Refer to students to relevant text/chapter or reading materials
you will make available on Sakai

Slide 4
Topic One

HISTORICAL OVERVIEW

Slide 5
 The History of Systems Analysis and
Design
In the mid-sixties, a number of large electronic data
processing applications failed, costing companies lots of
money.

This was due to the poor systems development

techniques. Systems development methodologies were
found to be significant as solutions to these problems.
Proposals emerged and designers adopted the
engineering development process.

Slide 6
 The History of Systems Analysis and
Design
Engineering Development Process
The engineering development process in that era was
used for the construction and operations of various types
of buildings, power transmission lines, various machines
and chemical plants. The success with which engineers
performed these activities led to the adoption of a similar
process by systems designers

Slide 7
 The History of Systems Analysis and
Design
Phases of the Engineering Development Process
The engineering development process is summarised as:
• Planning
• Analysis
• Design
• Implementation or construction
• Maintenance

Slide 8
 Questions
Individual Assignment:
What steps would an engineer adopt to develop an
engineering system?

Forum Question
Discuss the steps involved in the engineering development
process.

Slide 9
 Topic Two

SYSTEMS DEVELOPMENT LIFE CYCLE

Slide 10
 Systems Development Life Cycle
Introduction
Based on the Engineering development process systems
designers came up with the systems development life cycle
as activities and functions that all information systems
developers perform regardless of which approach they use.
All life cycle methodologies prescribe phases and activities.
The number and scope of phases and activities varies from
author to author, expert to expert and company to
company

Slide 11
 Systems Development Life Cycle
We are adopting a five step systems development
approach. This model therefore, includes the following
steps:
• systems planning
• systems analysis
• systems design
• systems implementation
• systems operation, support and security

Slide 12
 Systems Development Life Cycle
Systems Planning Phase
Systems planning phase usually begin with a find request to
the IT department called a system request that describes
problems or demand changes in an information system. He
request leads to a preliminary much further to identify the
nature and scope of the business opportunity or problem. A
feasibility study is an aspect of the phase that reviews the
anticipated cost and recommend a course of action based
on operation, technical, economic and time factors.

Slide 13
 Systems Development Life Cycle
Systems Analysis
The purpose of the systems analysis phase is to build a
logical model of the new system starting with a
requirement modelling where you investigate business
processes and demand what the new system must do. The
end product for the system analysis phase is the system
requirements document.

Slide 14
 Systems Development Life Cycle
Systems Design
The purpose is to create a blue print that will satisfy all
documented requirement for the system. At this stage you
design the user interface and identify all necessary outputs,
inputs and processes. The result of this phase is
documented in the system design specification and
presented to management and users for approval.

Slide 15
 Systems Development Life Cycle
Systems Implementation
During the systems implementation phase the new system
is installed. Programs are written, tested and documented
before installation. The objective of the systems
implementation phase is to deliver a completely functioning
and documented information system.

Slide 16
 Systems Development Life Cycle
Systems Operation, Support and Security
During this stage, the IT staff maintains, enhances and
protects the system. Maintenance changes connect errors
and adapt to changes in the environment, such as tax rate.
Enhancements provide new features and benefits. The
objective during this phase is to maximise return on the IT
investment. Security controls safeguard the system from
both external and internal threats.

Slide 17
 Systems Development Life Cycle
Diagram of the systems development life cycle

This model focuses on the interaction of planning, analysis and design tasks, which leads to
implementation, followed by operation.
Slide 18
 Questions
Individual Assignment:
Briefly explain the systems development life cycle (SDLC)

Forum Question
Discuss the systems development life cycle.

Slide 19
 Topic Four

STRUCTURED ANALYSIS

Slide 20
 Structured Analysis
Introduction
Structured systems analysis uses the phases of the systems
development life cycle to plan, analyse, design, implement
and support an information system.

Structured analysis uses a set of models to describe a

system graphically. Because it focuses on process that
transform data into useful information, structured analysis
is called a process-centred technique.

Slide 21
 Structured Analysis
Introduction
In addition to modelling the processes, structured analysis
includes data, organisation and structured relational database
design and user interface issues.

Process modelling identifies the data flowing into a process, the

business rules that transform the data, and the resulting data
flow.

Structured analysis introduced a modelling tool called Data

Flow Diagram and a design tool called structure chart.
.
Slide 22
 Structured Analysis
For example, the following is a process model for a school
registration system.
A Process Model for a School Registration System

The Register Students’ process accepts input data from two sources
and transforms it into output data
Slide 23
 Questions
Individual Assignment:
Draw a process model for a payroll system

Forum Question
Discuss another way of doing Systems Analysis

Slide 24
 Object-Oriented Analysis
Introduction
Object-Oriented analysis (O-O) is also another technique
for developing information systems. It combines data and
the processes that act on the data into things called object
while structured analysis threat processes and data as
separate components.

Slide 25
 Object-Oriented Analysis

OBJECTIVES
Upon completion of this topic, you should be able to
• Understand some elements of software objects that lead
to object oriented programming language
• Develop another technique to solve Systems analysis and
design problems.

Slide 26
 Object-Oriented Analysis
OBJECT – ORIENTED - Terms and Concepts
Object – Oriented (O-O) analysis describes an information
system by identifying things called objects. An object
represents a real person, place, event or transaction (similar to
an entity, a thing of principal interest). For example, when a
patient makes an appointment to see a doctor, the patient is an
object, the doctor is an object and the appointment itself is an
object. The end product of object – oriented analysis is an
object model, which represents the information system in
terms of objects and object – oriented concepts. During the
implementation phase of the Systems Development Life Cycle
(SDLC) system developers can translate O–O program code
modules using languages such as C++ and Java.
Slide 27
 Object-Oriented Analysis
Overview of O – O Analysis
Object models are developed using UNIFIED MODELING LANGUAGE
which is a widely used method of visualizing and documenting an
information system. To be able to do this we have to understand
some basic object – oriented terms and how they are used to
describe information systems.

OBJECT – represents a person, place, event or transaction that is

significant to the information system. Example, a customer which is
an object may have data such as name, address, account number and
current balance and can perform specific tasks such as placing an
order, paying a bill or changing their address. An object has
attributes which are characteristics that describe the object eg. A car
will have make, model and color as attributes or properties

Slide 28
 Object-Oriented Analysis

OBJECT – An object also has methods which are tasks or

functions that the object performs when it receives a
MESSAGE OR command to do so. A message is a command
that tells an object to perform a certain method. The
components are illustrated below using a car object

Slide 29
 Object-Oriented Analysis
The components are illustrated below using a car object

Class:- a collection of
similar objects eg. Car is a
class then we have
Toyota, Mercedes benz
etc.

Instance:- is a specific
member of a class the
blue Mercedes Benz E200
CDI is an instance of the
CAR class or Toyota Yaris

Slide 30
 Object-Oriented Analysis
Representing the Terms and Concept Using UML
UML (Unified Modeling Language) represents an object as a rectangle with the object
name at the top followed by the objects attributes and methods. Example is using a
family with children.

Slide 31
 Object-Oriented Analysis
Narrative on UML:
In this, the child object has certain attributes such as name,
age and sex. The family has 3 children i.e. 3 instances of the
child object. A child object performs certain methods such as
EAT, PLAY, GOING TO BED. To signal the CHILD object to
perform these tasks, you send certain messages that the
child object could understand such as Kofi come and eat, Go
and play, go to bed.

Slide 32
 Object-Oriented Analysis
NB: Objects are similar to NOUNS
Attributes are similar to Adjectives and method defines
specific tasks that an object can perform. Message is a
command that tells an object to perform certain methods
e.g. ADD STUDENT directs – everything about the student
class to add a STUDENT number, name and other data about
the student. Similarly, a message named DELETE STUDENT
tells the STUDENT class to delete student instance. The
student class understands that it should add the student
number, name and other data about that student as shown
below:
Slide 33
Object-Oriented Analysis

Slide 34
 Object-Oriented Analysis

The message ‘ADD student’ in the diagram above, signals the

STUDENT class to perform the ADD STUDENT method. The
message DELETE STUDENT signals the STUDENT class to
perform the DELETE STUDENT method.

Slide 35
 Object-Oriented Analysis

Polymorphism
The same message to two different objects can yield different
results. The idea that a message gives different meanings to
different objects is called Polymorphism.

Slide 36
 Object-Oriented Analysis
Polymorphism
The message Goodnight means different things to the 3 objects
and produces different results.
MESSAGE

OBJECTS

METHODS

Slide 37
 Questions
Individual Assignment:
Demonstrate your understanding of the object – oriented
approach using a Unified Modeling language.

Forum Question
Explain the following concepts in object – oriented
analysis: class, instance, message and methods.

Slide 38
 Research Process
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin.
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill.
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley.
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill.

Slide 39
 INFS 328
Systems Analysis and Design

Session 3 – Information Workers and Systems

Analysis and Design

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

This session explains systems analysis and design as a

concept. It also discusses the major stakeholders who are
responsible for systems development, their individual role,
skills required and expertise.

Slide 2
 Session Outline

The key topics to be covered in the session are as follows:

• Systems Analysis and Design – The Concept
• Information Workers and Systems Analysis and Design

Slide 3
 Topic One

SYSTEMS ANALYSIS AND DESIGN AS A

CONCEPT
Slide 4
 Systems Analysis and Design as a
Concept
Introduction

This section explains systems analysis and design as a

concept.

Slide 5
 System Analysis and Design – the
Concept
Systems Analysis and Design
The term systems analysis and design is usually reserved
for the process of analyzing business procedures with a
view to using a computer as a tool for improving efficiency
and effectiveness. The concept is therefore made up of
two components;
• Systems Analysis
• Systems Design

Slide 6
 System Analysis and Design – the
concept
• Systems Analysis
Systems Analysis may be considered as a problem solving
methodology. It decomposes a system into its component
pieces for the purposes of studying how well the
component parts work and interact to accomplish their
purposes.

Slide 7
 System Analysis and Design – the
concept
• Systems Design
Systems Design on the other hand is defined as a problem
solving techniques that reassembles a system component
pieces into an improved system.

The concept has evolved from the classical approach

(system life cycle) to the use of structured system analysis
and design approach to provide effective and efficient
information systems. These techniques are used by
different information workers to develop new information
systems
Slide 8
 Questions
Individual Assignment:
Relate your study of the System theory to System Analysis
and Design.

Forum Question
Discuss systems analysis and design as a concept.

Slide 9
 Topic Two

INFORMATION WORKERS AND SYSTEMS

ANALYSIS AND DESIGN
Slide 10
 Information Workers and Systems
Analysis and Design
Introduction

This topic discusses the major stakeholders who are

responsible for systems development

Slide 11
 Information Workers and Systems
Analysis and Design

Information Workers
Information Workers responsible for the development of
system projects are; system owners, system users, IT
vendors and consultants, system designers, system builders
and systems Analysts

Slide 12
 Information Workers and Systems
Analysis and Design

System Owners

They pay for the system to be developed and maintained.

They are the owners of the system and they determine the
working framework and design policies for the use of it.
Owners also participate in system design and analysis.
They usually initiate the systems process and do provide
information for the fact finding stage of the analysis.

Slide 13
 Information Workers and Systems
Analysis and Design
SYSTEM USERS - these actually use the system to perform
or support the work to be completed. System users also
participate in the system project by defining business
requirements and performance expectations for the system
to be built.

IT Vendors and Consultants – these sell hardware,

software and services to businesses for incorporation into
their information systems but are useful when it comes to
selecting hardware and software for the organization.
Slide 14
 Information Workers and Systems
Analysis and Design
System Designers – design the system to meet the user’s
requirements. Examples are Database administrators,
Network architects, Security experts.

System Builders - Construct, test and deliver the system

into operation . Examples are Application programmers,
Network programmers, Security Administrators, System
programmers, Software integrators.

Slide 15
 Information Workers and Systems
Analysis and Design
System Analysts
these facilitate the development of an information system
and computer applications by bridging the communication
gap that exists between non-technical system owners and
users on one hand and the technical system designers and
builders on the other. Most of the mainstream textbooks
assign all these responsibilities to one person called the
Systems Analyst but for large information systems the
divisions are necessary.

Slide 16
 Information Workers and Systems
Analysis and Design
System Analysts
They facilitate the development of information systems
through the interaction of their information workers. They
understand both business and computing. They solve
business problems and opportunities and then transform
business and information requirements into specifications
for information systems that will be implemented by
various technical specialists including computer
programmers.

Slide 17
 Information Workers and Systems
Analysis and Design
Skills of a System Analysts
In addition to formal system analysis and design skills a
Systems Analyst must also have the following knowledge,
skills and traits:
• System analyst is an agent of change. He shows users
and management how the new technologies can benefit
their business and their operations. Analyst must be
fully aware of both existing and emerging information
technology.

Slide 18
 Information Workers and Systems
Analysis and Design
Skills of a System Analysts
• Computer Programming Experience and Expertise - A System
Analyst must have programming experience in order to
appropriately prepare adequate business and technical
specifications for a programmer.

• General knowledge of business processes and terminology - The

System Analyst must be able to communicate with business
experts to understand business problems. The skill may be
acquired through basic business literacy courses in college. Such
courses may include financial accounting, management or cost
accounting, finance, marketing, business law, economics, quality
management etc.
Slide 19
 Information Workers and Systems
Analysis and Design
Skills of a System Analysts
• General problem-solving skills – these are skills acquired
in college philosophy courses whose content may
include problem solving skills, critical thinking and
reasoning. These skills will enable one to take a large
business problem, break it down and determine problem
causes and effects in order to recommend a solution.

Slide 20
 Information Workers and Systems
Analysis and Design
Skills of a System Analysts
• Interpersonal Communication Skills - The Analyst must be able to
communicate effectively in written and verbal form.
Communication skills may be learned in college. These skills will
be in technical speaking, interviewing and listening.

• Good Interpersonal relations Skills – the job of a System Analyst

involves an interaction with all stakeholders therefore it requires
effective interpersonal skills that allow the analyst to deal with
group dynamics, business politics, conflict and change.
Interpersonal skills development courses in subjects such as
teamwork, principles of persuasion, managing change and conflict
and leadership are very useful.
Slide 21
 Information Workers and Systems
Analysis and Design
Skills of a System Analysts
• Flexibility and adaptability – A System Analyst must be
flexible and must adapt to unique challenges and situations
as no two projects are alike.

• Character and Ethics – A System Analyst must be able to

discern between right and wrong. Must abide by standards
for computer ethics. He has to be discreet about confidential
information of the organization he is working for. He/she
must follow the Ten commandments of computer ethics as
outlined by Computer Ethics Institute of USA. Eg. 1. Thou
shall not use computer to harm others. 2. Thou shall not
interfere with other people’s computer work etc.
Slide 22
 Questions
Individual Assignment:
Relate your study of the System theory to System Analysis
and Design.

Forum Question
Discuss the skills of s successful Systems Analyst

Slide 23
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin.
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill.
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley.
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill.

Slide 24
 INFS 328
Systems Analysis and Design

Session 4 – Systems Planning

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

Systems planning begins the process of analysing and

designing an information system. In introducing a
computer-based system in a big factory or restructuring a
corporation, the following issues constitute the planning
phase which also constitutes the topics of this sections.
The Section is therefore divided into six topics.

Slide 2
 Session Outline

The key topics to be covered in the session are as follows:

• System Request
• Feasibility Study
• Operational Feasibility and Technical Feasibility
• Schedule and Economic Feasibility
• Feasibility Report
• Preliminary Investigation

Slide 3
Topic One

SYSTEM REQUEST

Slide 4
 System Request
System Request
The system request stage of the system planning phase is
the beginning of the systems analysis and design process.
It is a very interesting stage involving formal request to an
IT department responsible for system design. This act you
can conveniently call system request.

The system request describes problems or desired

changes in an information system or a business process.
This can come from a top management, a planning team,
a department head or IT department itself.
Slide 5
System Request

Slide 6
 System Request
After designing your system request form, a systems analyst
or IT manager examines it to determine what IT resources
(staff and time) are required. This evaluation of the systems
request information involves getting priorities if there are
many requests requiring services. Questions relevant for
the evaluation are - Which of the projects should the
company pursue? What criteria should be applied? How
should priorities be determined?

To answer these questions, the systems analysts must

assess the feasibility of each system request form.
Slide 7
 Questions
Individual Assignment:
Develop a sample systems request form

Forum Question
Discuss the importance of the system request process to
the development of information systems

Slide 8
 Topic Two

FEASIBILITY STUDY

Slide 9
 Feasibility Study
Feasibility Analysis
You might have heard about feasibility study in other
courses. The principles are similar. Feasibility is a
measurement of how beneficial or practical an information
system will be to an organisation. This is done through
feasibility analysis which is the process by which feasibility
is useful throughout the life cycle. Initially, a system
request must pass several tests and this is due to see
whether it is worth while to proceed with the system
development project or not.
Slide 10
 Feasibility Study
Feasibility Analysis
The scope and complexity of an apparently feasible project
can change after the initial problems and opportunities are
fully analysed or after the system has been designed. Thus
a project that is feasible at one point may become
infeasible later. Feasibility analysis therefore can be due at
any of the phase of the life cycle.

Slide 11
 Feasibility Study
Feasibility Analysis
The basic question that should be answered is that do the
problems (or opportunist) warrant cost of a detailed study and
analysis of a current information system? Realistically, feasibility
can not be accurately measured with the problems (and
opportunities) and requirements are better understood. After
estimating benefits of solving the problems and opportunities,
analysis estimate costs of developing the expected system.

Most analysts agree that there are four categories of feasibility

tests. These are technical feasibility, economic feasibility,
operational and schedule feasibility. These are explained in the
next sections.

Slide 12
 Questions
Individual Assignment:
Identify the points in a system life cycle when feasibility
analysis should be done

Forum Question
Discuss some benefits of carrying out a feasibility analysis

Slide 13
 Topic Three

OPERATIONAL AND TECHNICAL FEASIBILITY

Slide 14
 Operational and Technical Feasibility
Introduction
This section explains two of the four tests for feasibility-
operational and technical feasibilities.

Operational Feasibility
Operational feasibility is a measure of how well the system
solution will work in an organisation. It is also a measure of
how people feel about the system project.

Slide 15
 Operational and Technical Feasibility
Operational Feasibility
Operational feasibility criteria measure the urgency of the
problem or the acceptability of a solution. How do you
measure operational feasibility? There are two aspects of
operational feasibility to be considered.
• Is the problem worth solving, or will the solution to the
problem work?
• How do the end users and management feel about the
problem (solution)?

Slide 16
 Operational and Technical Feasibility
Operational Feasibility
PIECES is the end-user framework for identifying problems.
It can be used as the basis for analysing the urgency of a
problem of or the effectiveness of a solution. The following
is a list of the questions that address these issues.
• P - performance – does the system provide adequate
through put and response time?
• I - information – does the system provide end users and
managers with timely, pertinent, accurate, and usefully
formatted information?
Slide 17
 Operational and Technical Feasibility
Operational Feasibility - PIECE
• E - economy – does the system offer adequate service level
and capacity to reduce the costs of the business or increase
the profits of the business?
• C - control – does the system offer adequate control to
protect against fraud and embezzlement and to guarantee the
accuracy and security of data and information
• E - efficiency – does the system make maximum use of
available resources including people, time flow of forms,
minimum processing delays and the like?
• S - services – does the system provide desirable and reliable
service to those who need it? Is the system flexible and
expandable?
Slide 18
 Operational and Technical Feasibility
Operational Feasibility
Note: the term system, used throughout this discussion
refers either to the existing system or a proposed system
solution depending on which phase you are currently
working in.

How do the end users and managers feel about the

problem (solution)? It is important not only to evaluate
whether a system can work but also to evaluate whether a
system will work. A workable solution might fail because of
end-user or management resistance
Slide 19
 Operational and Technical Feasibility
Operational Feasibility
The following questions address this concern.
• Does management support the system?
• How do the end users feel about their role in the new
system?
• What end users or managers may resist or not use the
system? Can this problem be overcome? If so how?
• How will the working environment of the end users change?
Can or will end users and management adapt to the change?
Essentially, these questions address the political acceptability of
solving the problem or the solution. Now let me turn your
attention to the other test.
Slide 20
 Operational and Technical Feasibility
Technical Feasibility
Technical feasibility is a measure of the practicality of a specific
technical solution and the availability of technical resources and
expertise.

Today, very little is technically impossible. Consequently

technical feasibility looks at what is practical and reasonable.
Technical feasibility addresses three major issues

• Is the proposed technology or solution practical?

• Do we currently process the necessary technology?
• Do we posses the necessary technical expertise?
Slide 21
 Operational and Technical Feasibility
Technical Feasibility
Is the proposed technology practical? You will realise that
the technology for any defined solution is normally
available. The question is whether that technology is
mature enough to be easily applied to our problems. A
mature technology has a larger costumer base for obtaining
advice concerning problems and opportunities. Do we
currently posses the necessary technology?

Slide 22
 Operational and Technical Feasibility
Technical Feasibility
Assuming the solution’s required technology is practical,
you must ask yourself, is the technology available in our
information systems steps in Ghana? Even if the technology
is available, you must ask if you have the capacity. For
instance, will the current printer be able to handle the new
reports and forms required of a new system? If the answer
to either of these questions in no, then you must ask
yourself, can I get the technology? Then the alternative that
requires the technology is not practical and technologically
infeasible so consider another solution to the problem
Slide 23
 Questions
Individual Assignment:
• Explain operational and technical feasibilities

• Choose any information system and identify the

technology required to design such a system.

Forum Question
Discuss the benefits of Operational and Technical
Feasibility.
Slide 24
 Topic Four

SCHEDULE AND ECONOMIC FEASIBILITIES

Slide 25
 Schedule and Economic Feasibility

Introduction
In the last section you studied technical and
operational feasibilities as tests to evaluate a
systems solution. In this section you will learn
about two other tests; Schedule feasibility and
Economic Feasibility. These will enable you to
understand and be able to determine if a project is
economically viable and if it can be accomplished
on schedule.
Slide 26
 Schedule and Economic Feasibility
Schedule Feasibility
Schedule feasibility is a measure of how reasonable the
project time table is. Having the available technical
expertise (see section 3), are the project deadlines
reasonable? Some projects are initiated with specific
deadlines. It is necessary to determine whether the
deadlines are mandatory or desirable. For instance, a
project to develop a system to meet new government
reporting regulations may have a deadline that coincides
with the project completion. Here the new reports must be
initiated.
Slide 27
 Schedule and Economic Feasibility
Schedule Feasibility
Penalties associated with missing such a deadline may
make meeting it mandatory. If the deadlines are desirable
rather than mandatory, the analyst can propose alternative
schedules. It is preferable to deliver a properly functioning
information system two months later than to deliver an
error prone, useless information system on time. While
missing deadlines can be problematic, developing
inadequate systems can be disastrous. It’s a choice between
the lessons of two evils.
Slide 28
 Schedule and Economic Feasibility
Economic Feasibility
Economic feasibility is a measure of the cost
effectiveness of a project or solution. It deals with
the costs and benefits of the information system.
The bottom line in many prefects is economic
feasibility. During the early phases of the project,
economic feasibility analysis amounts to little more
than judging whether the possible benefit of solving
the problem are worth while.
Slide 29
 Schedule and Economic Feasibility
Economic Feasibility
Costs are practically impossible to estimate at that stage
because the end user’s requirements and alternative
technical solutions have not been identified, the analyst can
weigh the costs and benefits of each alternative. This is
called a cost—benefit analysis.

Let me quickly run through a single way of doing cost

benefit analysis. The following are some of the costs and
possible benefits as a result of implementing a new
information system.
Slide 30
 Economic Feasibility

Economic Feasibility

Slide 31
 Schedule and Economic Feasibility
Economic Feasibility
Tangible costs (TC) are added to intangible costs (IC). Total
benefits are also made. If the costs outweigh the benefits
that is TC+IC>TB+IB then economically it will not be worth
pursuing the development at that stage. However, this
decision is taken by combining the cost benefit analysis and
the results of the other tests, thus, schedule, technical and
operational feasibility before declaring a project feasible or
infeasible.

Slide 32
 Questions
Individual Assignment:
Choose an information system and list some of the possible
benefits and costs to be incurred.

Forum Question
Discuss the benefits of undertaking schedule and economic
feasibilities to the design of information systems

Slide 33
 Topic Five

FEASIBILITY REPORT

Slide 34
 Feasibility Report

Introduction
You have learnt about the four tests for
feasibility and the results have to go into what
is termed feasibility report which this section
discusses. You should at the end be able to
write a feasibility report and also put together
details of the various feasibility tests
Slide 35
 Feasibility Report
The Structure of a Feasibility Report
Major sections of the feasibility report is as follows:
• Executive summary: is made up of an introduction to the
report, a summary of findings and recommendation
made
• Description of the problem: this is a summary of the
produce and functions of the existing system obtained
from interviews, questionnaires and other
documentation
• Solution objectives: this is statement of the objectives of
a new or proposed system.
Slide 36
 Feasibility Report
The Structure of a Feasibility Report
Major sections of the feasibility report is as follows:
• Constraint: this is a statement of restrictions on the
development of the system
• Feasibility study results: this is where the results of the
feasibility analysis are presented
• Development plans: this involves scope of development
activities, detailed list of costs and activities, timetable of
lasts and about the system development team.
• Potential solutions: description of all the possible solution
the analysis has thought of at that juncture
• recommendations
Slide 37
 Questions
Individual Assignment:
What are the sections of a feasibility report?

Forum Question
Discuss the importance of a feasibility report to systems
development

Slide 38
 Topic Six

PRELIMINARY INVESTIGATION

Slide 39
 Preliminary Investigation

Introduction
After you have described that the proposed project meets
all the required feasibilities, you proceed to do a
preliminary investigation.

This involves a study of the systems request and then

recommendation of the necessary action(s)

Slide 40
 Preliminary Investigation
The following is a model of a preliminary investigation

Slide 41
 Preliminary Investigation

Model of a Preliminary Investigation

The diagram shows that an analyst gathers facts about the
problem or opportunity, project scope and constraints,
project benefits and estimated development time and cost.
The end product of the preliminary investigation is a report
to management.

Slide 42
 Questions
Individual Assignment:
1. Give a model of the preliminary investigation stage of the
analysis phase of a systems development life cycle

2. Choose any information system and do a feasibility analysis

of it.

3. Describe the sections in the planning phase of a systems

development process

Slide 43
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin.
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill.
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley.
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill.

Slide 44
 INFS 328
Systems Analysis and Design

Session 5 – Systems Analysis

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview
In session 4, you were introduced to planning for the development of
an information system. After a systems analyst has decided to proceed
with his systems project after the systems planning phase, he/she
moves on to the systems analysis phase.

In the system planning phase, preliminary request was done. In this

phase, the process of gathering facts about the systems project,
preparing documentation and creating modules that will be used to
design and develop the system are considered. System analysis is the
stage where an analyst attempts to study the old system of the
organisation in order to understand the workings, inputs, outputs and
other processes and services. This will help him/her to evaluate the
old system in order to propose a more efficient system for the
organisation.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Requirements Modelling
• Data and Process Modelling
• Development Strategies
• Other Analysis Techniques – Requirements Discovery
Method
• Joint Requirements Planning
• Preparation of System Requirements Document

Slide 3
 Major Activities of the Analysis Phase of the
SDLC
Figure 1.1 Major activities of the Systems Analysis

Slide 8
Topic One

REQUIREMENT MODELLING

Slide 4
 Requirements Modelling
Introduction
There are three major activities of the analysis phase as can
be seen in figure 1.1. These are requirements modelling,
data and process modelling and development strategies.
We shall look at these three and other ways of doing
analysis.

Upon completion of this topic, you should be able to

recognise the principal activities of the systems analysis
stage, and also the elements required to begin a formal
analysis of an old information system.
Slide 5
 Requirements Modelling
Requirements Modelling
This involves fact finding to describe the information system you
are working with. It also involves the identification of the
requirements for a new system you are about to design. Such
requirements include outputs, inputs, processes, performance
and security.

• Outputs refer to electronic or printed information produced

by the system. Inputs refer to necessary data that enter the
system either manually or in an automated manner.

• Processes refer to the logical rules that are applied to

transform the data into meaningful information.
Slide 6
 Requirements Modelling
Requirements Modelling
• Performance refers to system characteristics such as
speed, volume, capacity, availability and reliability.

• Security refers to hardware, software and procedural

controls to safeguard and protect the system and its data
from internal or external threats.

Slide 7
 Questions
Individual Assignment:
Describe the major sections of the analysis phase of a
systems project.

Forum Question

Slide 9
Topic Two

DATA AND PROCESS MODELLING

Slide 10
 Data and Process Modelling
Structured Analysis as a Data and Process Modelling
Structured analysis identifies the data flow into a
process, the business rules that transform the data,
and the resulting output data follow. It is used to
develop a logical model of the proposed (new)
system and document systems requirements. This
logical modelling show what the system must do
regardless of how it will be implemented physically.

Slide 11
 Data and Process Modelling
Structured Analysis as a Data and Process Modelling
Later in the next phase (design phase), a physical model is built
that describes how the system will be constructed an example of
a structured analysis is a Data Flow Diagram – see appendix.

Other models that are also used to analyse the information

systems are Process Descriptions and Object – Oriented
Analysis.

Others include Information Engineering tools such as Entity –

Relationship diagrams and system flowcharts. These have been
illustrated in the in the Appendix.
Slide 12
 Questions
Individual Assignment:
Name any three techniques used to analyse information
systems.

Forum Question

Slide 13
 Topic Three

DEVELOPMENT STRATEGIES

Slide 14
 Development Strategies
Strategies for the Analyses of Information Systems
This is the third part of the analysis phase. Activities involved in
this include; evaluation of alternative solutions, preparation of
the systems requirements document, and presentation of the
system’s requirements document to management.

The skills that are required to accomplish these are analytical

skills and interpersonal skills. In addition, team –oriented
strategies have to be considered because information systems
affect people throughout an organisation. The traditional model
for developing systems had been an IT department using a
structured analysis and gathering information about the current
system by consulting users for inputs into the new system.
Slide 15
 Development Strategies
Strategies for the Analyses of Information Systems

With the Rapid Application Development (RAD) users are

involved in every step of the systems development. While
JAD focuses only on fact finding and requirements
determination, RAD provides a fast-track approach to a full
spectrum of system development tasks including planning,
design, construction and implementation.

Slide 16
 Questions
Individual Assignment:
Describe the three activities involved in developing
strategies

Forum Question

Slide 17
 Topic Four

OTHER ANALYSIS TECHNIQUES –

REQUIREMENTS DISCOVERY METHOD

Slide 18
 Requirement Discovery Method
Introduction

There are other techniques that are also used for analysis.
For example, Requirements Discovery Methods, which
consist of;
• fact finding techniques and
• Joint Requirements Planning (JRP)

Slide 19
 Requirement Discovery Method
Requirements Discovery

Requirements Discovery Methods are used to discover the

problems and opportunities that exist in the current
information system. They are also used to discover the
requirements for the improved system. Fact finding
technique is an example

Slide 20
 Requirement Discovery Method
Requirements Discovery – Fact Finding Technique
Fact finding techniques also called Information Gathering. It is a
classical set of techniques used to collect information about
system problems, opportunities, solution requirements and
priorities. It may include the sampling of existing documentation,
reports, forms, files, databases and memos as well as research of
relevant literature benchmarking other solutions and site visits to
similar information systems. Others are observation of current
information systems, surveys of management and information use
community and interviews of appropriate managers, users and
technical staff.

Information gathered helps the analyst to understand the

information system and gives the analyst an idea of what the
system to be designed will be like.
Slide 21
 Questions
Individual Assignment:
Name other techniques used in analysing information
systems

Forum Question
Discuss the fact finding technique and it’s importance in
the analysis stage of the systems development.

Slide 22
 Topic Five

JOINT REQUIREMENTS PLANNING (JRP)

Slide 23
 Joint Requirements Planning
Joint Requirements Planning
The classic fact finding techniques described earlier, can be
time consuming. An alternative way to accelerate
requirements discovery and management is Joint
Requirements Planning. These use facilitated workshops to
bring together all the system owners, system users, system
analysts, system builders and system designers to jointly
perform system analysis. The analyst engages them in
discussion, questions are asked and at the end of the
workshop the analyst gets to understand what the
information system is about.
Slide 24
 Questions
Individual Assignment:
What do you understand by Joint Requirements Planning?

Forum Question
Discuss the differences between the Requirement
Discovery Method and Joint Requirement Planning

Slide 25
 Topic Six

PREPARATION OF THE SYSTEMS

REQUIREMENT DOCUMENT

Slide 26
 Preparing the Systems Requirement
Document
System Requirement Document
This section is about documenting the requirements of a
new system based on your understanding of the
information system you analysed.

A system requirement is a characteristic or feature that

must be included in an information system to satisfy
business requirements and be acceptable to users. A
system requirement serves as a bench mark to measure
overall acceptability of the finished system.
Slide 27
 Preparing the Systems Requirement
Document
Examples of System Requirements
• Output – the website must report on-line volume statistics
every four hours and hourly during peak periods.
• Inputs- the department head must enter over-time hours on
a separate screen.
• Process – the human resource system must interface
properly with the existing payroll system.
• Performance –system must support 25 users on line
simultaneously.
• Controls –the manager of the sales department must
approve orders that exceed a customer’s credit limit.
Slide 28
 Preparing the Systems Requirement
Document
System Requirements Document
These requirements constitute the necessary specifications
for the new system. System requirements specification
therefore contains the requirements that will enable us to
design our new system. It will describe the alternatives that
were considered in a document, making specific
recommendations to management. This document is also
the starting point for measuring the performance, accuracy
and completeness of the finished system before entering
the next phase which is the design phase.

The system requirements document is like a contract that

identifies what the system developers must deliver to users.
Slide 29
 Questions
Individual Assignment:
Distinguish between the various forms of development
strategies as outlined in analysis stage of systems
development project.

Forum Question
Discuss some examples of systems requirement

Slide 30
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin.
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill.
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley.
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill.

Slide 31
 INFS 328
Systems Analysis and Design

Session 6 – System Design – Part 1

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

In the Analysis phase, you studied how to analyse a current

information system by coming up with a logical model of the
new system and other development strategies.
With this phase you will learn about physical design of an
information system that will meet the specifications
described in the system requirements document.
System design tasks include output and user interface
design and data design.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Output Design
• User Interface Design
• Input Design
• Data Design

Slide 3
Topic One

OUTPUT DESIGN

Slide 4
 System Design – Output Design
Output Design
As a system analyst, you will have to design the screen for your users
and other output printed forms. The following are the essential
elements of the output design.
1. Purpose of the output.
2. Audience of the information and why the information is needed
and how the information will be used.
3. Specific information needed.
4. Form of output either printed, screen view or both or the type of
device the output will go to.
5. When the information will be provided and update frequency
6. Security and confidentiality.
.

Slide 5
 System Design – Output Design
Types of output
The type of output needed and the technology
needed usually are decided during the analysis
phase based on user requirements. In the
design phase, actual reports, screen forms and
other delivery methods are designed. Some of
the other delivery methods are: Internet, E-
mail, Audio output, automated facsimile
systems, computer output microfilm, computer
output to laser disk..
Slide 6
 System Design – Output Design
Types of output
• Internet-based information delivery. Some organisations use the
internet to reach new customers and markets so web designers
must provide user-friendly screen interfaces that display output
and accept input from customers. For example, a system provides
customised responses to product inquiry or requests technical
support, the system responds with appropriate information from
an on-site knowledge base.

• E-mail – This is an essential means of internal and external

business communication. E-mail has virtually replaced traditional
memos and printed correspondence. Companies send new product
information to customers via e-mail and financial services
companies use e-mail messages to confirm on-line stock trades.

Slide 7
 System Design – Output Design
Types of output
• Audio Output – This can be attached to an e-mail message or
inserted as an audio clip in a Microsoft word document. In
addition, many organisations use automated systems to handle
voice transactions and provide information to customers. For,
example, by using a telephone keypad, a customer can confirm an
airline seat assignment, check a credit card balance or determine
the current price of a commodity.
• Automated Facsimile System – Some companies use automated
facsimile, sometimes called faxback systems to allow a customer to
request a fax using e-mail via the company’s website or by
telephone. The response is transmitted in a matter of seconds back
to the user’s fax machine.
Slide 8
 System Design – Output Design
Types of output
• Computer Output Microfilm (COM) – Examples of these are
Microfilm and Microfiche. These capture an image of a
document and produce film output. Users then retrieve, view
and print the images. Microfilm records the images on a roll
of film, and microfiche records images using a small sheet of
film.
• Computer output to laser disk (COLD) – This is another way
to store images of paper documents. Using COLD technology
a paper document is scanned and the digital image is stored
on a high density laser disk medium. COLD technology also
enables rapid information retrieval of formatted information.
Slide 9
 System Design – Output Design
Other Specialised Forms of Output – There are other
specialised forms of output. Some of them are briefly described
below:
• retail point–of –sale terminals to handle computer based
credit card transactions, print receipts and update inventory
records
• automatic teller machines
• special purpose printers that produce labels, photos driving
licenses and even lottery tickets
• plotters that produce high quality images such as blue prints
maps
• digitised photos that companies can print on employee
identification cards
Slide 10
 System Design – Output Design
Printed and Screen Output
Reports can be printed outputs or screen outputs. Whether
printed or viewed on screen, reports should be attractive and easy
to understand. Managers and users judge an entire project by the
quality of the reports. Reports can be classified into: Detail reports,
Exception reports and Summary reports. The users of an
information system must approve all report designs in advance as
the information is delivered to them. In designing a report, a
sample report called Mock-up or prototype is normally prepared
for review by users. Reports can be created using word processor,
report generator or a printer spacing chart.

The principles for report design include report headers and

footers, page headers and footers, column headings and
alignment, column spacing, field order and grouping of detail lines.
Slide 11
 Questions
Individual Assignment:
List eight delivery outputs.

Forum Question
Explain the difference between printed and screen output

Slide 12
Topic Two

USER INTERFACE DESIGN

Slide 13
 User Interface Design
Guidelines for User Interface Design
A good user interface design is based on ergonomics,
aesthetics and interface technology. Ergonomics describes
how people work, learn and interact with computers.
Aesthetics focuses on how an interface can be made
attractive and easy to use. Interface technology provides the
operational structure required to carry out the design
objectives.
Every interface should therefore be designed to make it easy
to use, be attractive and efficient and must be guided by the
following points.
Slide 14
 User Interface Design
User Interface Design Guides
• Focus on basic objectives. Facilitate the system design
objectives rather than calling attention to the interface
• Build an interface that is easy to learn and use.
• Promote features that promote efficiency by organising
tasks commands and functions in groups that resemble
actual business operation.
• Make it easy for users to obtain HELP or correct errors.
Ensure that HELP is always available. HELP screens should
provide information about menu choices, procedures,
shortcuts and errors.
Slide 15
 User Interface Design
User Interface Design Guides
• Minimise input problems by providing messages, for
example, an ID number not found.
• Create an attractive layout and design by using
appropriate columns to highlight different areas of the
screen, avoid gaudy and bright columns.
• Use familiar terms and images. For example, file, exit,
help. Use familiar commands such as cut, copy and print
etc.

Slide 16
 Questions
Individual Assignment:
Design a printed output for a student registration system.
The output should include statement name, name of
residence, course, department and name of faculty. Let the
heading be student registration system.

Forum Question
What do you understand by user interface?
Slide 17
 Topic Three

INPUT DESIGN

Slide 18
 Input Design
Input Design
After designing the output, the input should also be
designed as a second part of the interface. Input technology
has changed dramatically. Businesses use the new
technology to speed up the input process, reduce costs and
captured data in new forms such as digital signature.

A good input design ensures quality, accuracy and

timeliness. Input design is about how data will be captured
and entered into the information system.
Slide 19
 Input Design
Input Design
Data capture uses an automated or manually operated
device to identify source data and convert it into computer
– readable form. Examples of data capture devices include
credit card scanners and bar code readers.

Data entry is the process of manually entering data into the

information system, usually in the form of key strokes or
mouse clicks. Every input design must have the following
objectives.
Slide 20
 Input Design
Six Main Objectives of Input Design
• Select a suitable input and data entry method. An
example is batch input (entry on a specified time
schedule) or online input such as source data
automation.
• Reduce input volume. (Reduce the number of data items
required for each transaction in order to reduce volume).
This avoids unnecessary labour cost as data capture or
data entry require time and effort.
• Design attractive data entry screen.
Slide 21
 Input Design
Six Main Objectives of Input Design
• Use validation checks to reduce input errors. Reducing errors
improves data quality.

• Design required source documents. A source document is a form

used to request and collect input data, trigger or authorise an
input action, and provide a record of the original transaction.
During the input design stage, you develop source documents that
are easy to complete and inexpensive.

• Develop effective input controls. Input control includes the

necessary measures to ensure that input data is correct, complete
and secure. There are some common types of input devices you
should be familiar with.
Slide 22
 Input Design
Common Types of Input Devices
The following are some input devices:
• Biological feedback device –this creates digital image of
biological data such as finger prints, retina patterns etc.
• Digital collection device –this is a fixed or portable
device that can read data on site, like ATM.
• Digital camera.
• Electronic whiteboard – this is an electronic version of
traditional white board that can capture and store text or
graphics written or drawn on the board.
Slide 23
 Input Design
Common Types of Input Devices
The following are some input devices:
• Graphic input devices –include light pens, digitisers and
graphics tablets that allow drawings to be translated into
digital form.
• Hand held computer stylus – device that allows users to
form characters on the screen of a hand held computer.
• Input devices for physically challenged
• Internet workstation – enables user to provide input to
web-based intranet or internet recipients
• Key board -
Slide 24
 Input Design
Common Types of Input Devices
The following are some input devices:
• MICR (magnetic ink-character recognition) technology used
to read magnetic ink
• Mouse – pointing device that allows the user to move the
insertion point to a specific location on a computer screen
• Micro phone – a microphone converts sound waves into
digital information
• Scanner – device that reads printed bar codes, characters or
images
• Terminal – device such as screen on monitor
Slide 25
 Input Design
Common Types of Input Devices
• Video input – video camera input, in digital form that can be
stored and played later
• Touch screen – sensors that allow users to interface with the
computer and select options by touching specific locations on the
screen
• Voice input device – device that allows users to enter data and
issue commands using spoken words
• Wireless input – wireless input devices are wireless versions of
traditional scanners, barcode readers and data collection devices
• Radio Frequency Identification (RFID) –this is a technology used to
track down items in a wide range of information systems including
inventory control, point- of-sale and monitor peoples movement in
security management system
Slide 26
 Questions
Individual Assignment:
List ten common types of inputs.

Forum Question
Discuss five input devices and their uses

Slide 27
 Topic Four

DATA DESIGN

Slide 28
 Data Design
Introduction
Data Design touches on the physical design plan for data
organisation, storage and retrieval. It is exactly the same as
data base management course you studied in the first
semester of level 300. Because of this, the section will provide
only a summary of what you have already studied in level 300.

Summary of Data Design

Before constructing an information system, you must
understand basic data design concepts, including data
structures and the characteristics of file processing and
database systems including Web-based database design. The
following is a summary of the essential facts you should know.
Slide 29
 Data Design
Files and tables
These usually contain data about people, places, things or
events that affect the information system. File processing
systems also file-oriented systems, manage data stored in
separate files including master files, table files, transaction files,
work files, security files and history files.

A database consists of linked tables that form an overall data

structure. A data base management system is a collection of
tools, features, and interfaces that enable users to add, update,
manage, access and analyse data in a database.
Slide 30
 Data Design
Database Management Systems (DBMS)
These are more powerful and flexible than traditional file – oriented
systems. A database environment offers scalability support for
organisation-wide access, economy of scale, data sharing among user
groups, balancing of conflicting user requirements, enforcement of
standards, controlled redundancy, effective security, flexibility, better
programmer productivity and data dependence.

Database management system components include interfaces for

users, database administrators and related systems, a data
manipulation language; a scheme, and a physical data repository.
Other data management techniques include data warehousing, which
stores data in an easily accessible form for users access and data
mining which looks for meaningful patterns and relationships among
data.
Slide 31
 Data Design
Data Design Task
Data design tasks include creating an initial entity –
relationship diagram; assigning data elements to an entity,
normalising all table designs; and completing the data
dictionary entries for files, records and data elements. Files
and database tables should be sized to estimate the
amount of storage space they will require. File and
database control measures include limiting access to the
data, data encryption, backup/recovery procedures, audit-
track files and internal audit fields.
Slide 32
 Questions
Individual Assignment:
1. What factors would you consider when designing a
database

2. Design a database of students in your class. The data items

should include student name, student ID, course, faculty
department, hall of residence. Using the student ID,
manipulate this data use on your computer screen

Forum Question
Describe the r ole of data design in a systems development
project
Slide 33
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill

Slide 34
 INFS 328
Systems Analysis and Design

Session 7 – System Design – Part 2

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

This session is a continuation of the systems design phase.

With this session, you will learn about systems architecture
and systems design specification, which are all part of the
physical design of an information system that will meet the
specifications described in the system requirements
document.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• System Architecture
• System Design Specification

Slide 3
 Topic One

SYSTEM ARCHITECTURE

Slide 4
 System Architecture
This section of the systems design phase, translates the
logical design of an information system into a physical
structure that includes hardware, software, network
support, processing methods and Security. The end
product of the systems design phase is the system design
specification document. This document if approved by the
owners of the information system allows you to move to
the next phase called System Implementation.

The section will enable you to provide a checklist of issues

to consider when selecting a system architecture;
understand the environment of a new information system;
describe the system design specification document and
explain the contents of each section.
Slide 5
 System Architecture
SYSTEM ARCHITECTURE CHECK LIST
In a similar manner to the way an architect design a plan using
the owner’s requirements, a system analyst must approach
system architecture with an overall checklist. The following
specific issues affect the architecture choice:
• Enterprise resource planning (ERP)
• Initial and total cost of ownership (TCO)
• Scalability
• Web integration
• Legacy system interface requirements
• Processing Options
• Security issues
Slide 6
 System Architecture
ENTERPRISE RESOURCE PLANNING
This establishes an enterprise-wide strategy for IT
resources and specific standards for data, processing,
network and user interface design. ERP describes a specific
hardware and software environment, also called platform
that ensures connectivity and easy integration of future
systems including in-house software and commercial
packages. Many companies use ERP software. They are
and extending ERP systems to suppliers and customers in a
process called Supply Chain Management. ERP can help
companies achieve faster response, better customer
service and lower operating cost.
Slide 7
 System Architecture
INITIAL AND TOTAL COST OF OWNERSHIP (TCO)
During the final design stage, you make decisions that will have
a major impact on the initial costs and TCO for the new system.
At this point, you should review all previous cost estimates and
ask he following questions:
• If in-house development was selected as the best alternative
initially is it still the best choice? Is the necessary technical
expertise available, and does the original cost estimate
appear realistic?
• If a specific package was chosen initially, is it still the best
choice? Are newer versions or competitive products
available? Have any changes occurred in pricing or support?
• Have any new types of outsourcing become available?
Slide 8
 System Architecture
INITIAL AND TOTAL COST OF OWNERSHIP (TCO)
• Have any economic, governmental, or regulatory events
occurred that could affect the proposed project?
• Have any significant technical developments occurred that
could affect the proposed project?
• Have any new trend occurred in the market place? Are new
products or technologies on the verge of being introduced?
• Have you updated the original TCO estimate? If so, are there
any significant difference?

The answers to these questions might affect the initial cost and
TCO for the proposed system. You should reanalyze system
requirements and alternatives now, before proceeding to
design the system architecture.
Slide 9
 System Architecture
Scalability
Scalability, also called extensibility refers to a system’s
ability to expand, change or downsize easily to meet the
changing needs of a business enterprise. A scalable system
is necessary to support a dynamic, growing business. For
example, a scalable network could handle anywhere from a
few dozen nodes to thousands of nodes, a scalable DBMS
could support the acquisition of a new sales division.
When investing large amount of money in a project,
management is especially concerned about scalability
issues that could affect the system’s life expectancy.
Slide 10
 System Architecture

WEB INTEGRATION
You should know if your new system will be Web-centric
and should realize that a web-centric architecture follows
that internet design protocols and extranets.

Slide 11
 System Architecture
LEGACY SYSTEM INTERFACE REQUIREMENT
The new system might have to interface with one or more
legacy systems, which are older systems that typically run
on mainframe computers. For example, a new marketing
information system might need to report sales data to a
mainframe based accounting system and obtain product
cost data from a legacy manufacturing system.

Interfacing a new system with a legacy system involves

analysis of data formats and compatibility. To select the
best architecture, the analyst must know if the new
application eventually will replace the legacy system.
Slide 12
 System Architecture
PROCESSING OPTIONS
Designers must consider how the system will process data
online or in batches. For example, a high-capacity
transaction processing system such as an order entry
system, requires more network, processing and data
storage resources then a monthly billing system that
handles data in batches

Slide 13
 System Architecture
SECURITY ISSUES
Security is a concern at each stage of system development.
As the logical and physical design is translated into specific
hardware and software the systems analyst must consider
security issues that relate to system design specifications
and determine how the company will address them.

Slide 14
 Questions
Individual Assignment:
What is enterprise resource planning (ERP) and why is it
important? What is supply chain management?

Forum Question
Define the term system architecture. Define the term
scalability, and explain why it is important to consider
scalability in system design.
Slide 15
 Topic Two

SYSTEM DESIGN SPECIFICATION

Slide 16
 System Design Specification
Introduction
This section is the final activities of the system design
phase which also include, obtaining user approval and
delivering a presentation to management. It explains what
system design specification is about in the system design
process.

Slide 17
 System Design Specification
The Structure of System Design Specification
The system design specification is also called the technical
design specification. It is a document that presents the
complete design for the new information system, along
with detailed costs, staffing and scheduling for the
implementation phase.

It is the baseline against which the operational system will

be measured. Unlike the system requirements documents,
which is written for users to understand, the system design
specification is oriented toward the programmers who will
use it to create the necessary programs.
Slide 18
 System Design Specification
The structure of the system design specification is made up
of the following:
• Executive summary
The specification starts with an executive summary which
provides a brief overview of the project for company
managers and executives. It outlines the development
efforts to date, provides a current status report,
summarises current project costs and costs for the
remaining phase. It also has reviews of the overall benefits
of the new system, presents the system development
phase schedule and highlights any issues that management
will need to address.
Slide 19
 System Design Specification
• System components – This section contains the complete
design for the new system, including the user interface,
outputs inputs, files, database, and network specifications.
Source documents report and screen layouts. Data Flow
Diagrams (DFD’s) and all other relevant documentation
should be included. It also must include requirements for
support processing such as back up and recovery, start up
processing and file retention. Software information is also
included.
• System environment – This section describes the constraints
or conditions affecting the system, including any
requirements that involve operations, hardware, systems
software or security
Slide 20
 System Design Specification
• Implementation requirements – they specify start up
processing, initial data entry or acquisition, user training
requirements and software test plans.
• Time and cost estimates – This section provides detailed
schedules, cost estimates and staffing requirements for the
systems development phase and revised projections for the
remainder of the system development life cycle. It also looks
at total costs-to-date for the project and compares those
costs with earlier estimates.
• Appendices – Supplemental material can be included in
appendices at the end of the system design specification.
Documents from the first three phases that may provide a
helpful reference for readers can be included.
Slide 21
 Questions
Individual Assignment:
1. Describe in detail a system design specification.
2. Describe the major activities in the design phase of a
systems development project.
3. Using any database software such as visual basic design
the output for a payroll system on your computer.

Forum Question
Discuss the difference between system requirement and
system specification
Slide 22
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill

Slide 23
 INFS 328
Systems Analysis and Design

Session 8 – Systems Implementation –

Part 1 – Systems Testing
Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies
Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

After designing the system you are now ready to implement

the system. System implementation involves writing and
testing programs and procedures required by the approved
system design document; completing the user manuals both
for training purposes and for continued use during
operations; testing of the system and carrying out
installation effectively and efficiently.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• System Testing

Slide 3
Topic One

SYSTEM TESTING

Slide 4
 System Testing

Now that the software packages and in-house programmes

have been installed, you need to conduct a final test. All
software packages, custom built programmes, and any
existing programmes that comprise the new system must
be tested to ensure that they all work together.

The knowledge acquired will enable you to test your new

system on the computer, and also understand how to apply
effectively any of the implementation tests on a system.

Slide 5
 System Testing
Testing the New Information System
This test usually involves analysts, owners, users, and
builders. The system analyst facilitates the completion of
the testing process. The systems analyst typically
communicates testing problems and issues with the project
team members.

Slide 6
 System Testing
Testing the New Information System
The system owners and system users hold the ultimate
authority on whether or not a system is operating correctly.
System development team members of various specialties,
are involved in the systems testing. For example,
application programmes, database programmers, and
networking specialists may need to resolve problems
relating to their respective specialties during systems
testing.

Slide 7
 System Testing
Several types of testing are done in the following sequence.

• Realistic tests – You present the system with a realistic

example of the environment in which the system is to
operate. This tests the system and the understanding and
training of users. It also gives the users confidence before
they take over the system.

Slide 8
 System Testing

• Contrived tests – This test deals with as many unusual

and unexpected events as possible such as incorrect
codes, wrong amounts, inappropriate commands and so
on. The intention is to see how the system reacts and
whether all answerable anomalies have been centred for
in the system.

Slide 9
 System Testing

• Volume tests – This test is about presenting the system

with a large volume of transactions to see how it reacts,
particularly in operating and response times

Slide 10
 System Testing

• Acceptance testing is undertaken by users after all other

system testing is complete. It is designed to test the
complete system so that the users can see if the new
system is satisfactory. As the final system test, it is
probably the most important and elaborate. It is
performed by the users using realistic data over an
extended time period. It is an extensive test that
addresses three levels of acceptance testing – verification
testing, validation testing and audit testing.

Slide 11
 System Testing
Levels of Acceptance Testing:
• verification testing - uses the system in a simulated
environment using simulated data. The simulated test is
sometimes called alpha testing. The simulated test is
primarily looking for errors and omissions regarding end-
user and design specification that were specified in the
design phase but not fulfilled during the development of
the system.

Slide 12
 System Testing
Levels of Acceptance Testing:

• validation testing - runs the system in a live environment

using real data. This is sometimes called data testing.
During this validation, a number of items are tested:

Slide 13
 System Testing

• systems performance – performance in terms of

response and processing times. If those are not
acceptable then the programs may have to be re-written

Slide 14
 System Testing

• Peak workload processing performance – can the system

handle the workload during peak processing periods? If
not improved hardware and software may be needed to
increase efficiency

Slide 15
 System Testing

• Human engineering test – is the system as easy to learn

and use as anticipated, if not it is inadequate

• Methods and procedures test – methods and procedures

must be tested and may have to be modified if they
prove awkward and inefficient

Slide 16
 System Testing

• Backup and recovery testing – all back up and recovery

procedures should be tested. This should include
simulating a data loss disaster and testing the time
required to recover from the disaster

Slide 17
 Questions
Individual Assignment:
What is systems acceptance test? When is this test
performed?

Forum Question
What are the three levels of acceptance testing? And what
is their importance in the implementation process.

Slide 18
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill

Slide 19
 INFS 328
Systems Analysis and Design

Session 9 – Systems Implementation –

Part 2 – User Training
Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies
Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

This session looks at another aspect of systems

implementation. Thus, the design of user manuals and
training of end users. Completing the user manuals both for
training purposes and for continued use during operations

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Training – User Interface
• Training of Middle and Senior Management

Slide 3
Topic One

TRAINING – USER TRAINING

Slide 4
 Training - User Training
User Training
After you have tested your system you should follow the
activities with the necessary training. No system can be
successful without proper training whether it involves
software, hardware etc, a successful information system
requires training for users. In the training section, the
organization selects the personnel who will both operate
and manage the new system and must train them in the use
of it and its related activities. The organization must select
the appropriate training delivery method depending on who
is being trained. So if you are training users, the method will
be different from training that of non-users.
Slide 5
 Training - User Training
User Training
Training for users will include the following:

• If the information system is manual and you have

computerized, then the users will need training in basic
computer literacy.

Slide 6
 Training - User Training
User Training
Training for users will include the following:

• Users will have to learn how to use specific applications

and modules quickly and in great detail, examining
important procedures, commands and data entry
requirements.

Slide 7
 Training - User Training
User Training
Training for users will include the following:
• Users should have on the job training i.e. training while
they are actively using the new system.
• Training updates may be required as the users become
more familiar with the system and require further
knowledge and skills development or consolidation

Slide 8
 Training - User Training
Guidelines for Developing a Training Programme for Users
When developing a training programme for users, you
should keep the following guidelines in mind:
• Train people in groups as this is a better use of your time,
and it encourages group learning possibilities as you will
master specific skills through practice with large groups
where common problems and issues can be addressed.

Slide 9
 Training - User Training
Guidelines for Developing a Training Programme for Users
• Select the most effective place to conduct the training.
Training employees at your company’s location offers
several advantages. Employees incur no travel expenses
and training can take place in the actual environment
where the system will operate.

Slide 10
 Training - User Training
Guidelines for Developing a Training Programme for Users
• Provide for learning by hearing, seeing and doing. Some
people learn best from lectures discussions and question
– and- answer sessions. Others learn best from viewing
demonstration or reading documentation and other
materials. Most people learn best from hands-on-
experience. You should provide training that supports
each type of learning.

Slide 11
 Training - User Training
Guidelines for Developing a Training Programme for Users

• Prepare effective training materials including interactive

tutorials and user manuals.

Slide 12
 Questions
Individual Assignment:
Explain the procedure for user training

Forum Question
Training can be performed one on one, however, group
training is generally preferred. Discuss.

Slide 13
 Topic Two

TRAINING OF MIDDLE AND SENIOR

MANAGEMENT
Slide 14
Training of Middle and Senior Management
Having learnt that training of users is essential, you will
have to also realise that training differs from one level of an
organisation chart to the other. In this section you will learn
how to train both the middle and senior managers to use
your newly designed information system.

You should then be able to state the kinds of training

deeded by middle and senior management of an
organisation for which the information system is designed.

Slide 15
Training of Middle and Senior Management
Middle Management Training

Middle management will be trained on elements of the

system for which they are responsible. They will need an
understanding of the particular business issues and security
and control features related to a particular system.

Slide 16
Training of Middle and Senior Management

Senior Management Training

Senior management should be trained on a much
structured manner and should be business focused.
Training takes the form of short demonstrations, power
point presentations, video demonstrations and executive
seminars.

Slide 17
 Questions
Individual Assignment:
Describe the principles involved in training middle level and
senior managers to use a newly designed information
system.

Forum Question
Discuss why it is necessary to train middle and senior level
management separately.
Slide 18
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill

Slide 19
 INFS 328
Systems Analysis and Design

Session 10 – Systems Implementation – Part

3 – File Conversion & System Changeover

Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies

Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview

This section of the systems implementation phase, focuses

on the preparation and conversion of the old manual or
computerised files into a format that is compatible with the
new system. It also touches on the various approaches by
which the system change over is carried out to ensure a
smooth transition from the old system to the new and
improved one.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• File Conversion
• System Changeover

Slide 3
 Topic One

FILE CONVERSION

Slide 4
 File Conversion
This section is about file conversion. Files and
programs need to be converted into a suitable
format for the new system and for completing
documentation.

Slide 5
 File Conversion

It involves converting large amounts of manual files into

computer based files, by means of transcription into
specially designed forms which then have to be keyed into
the computer individually. New files must be checked
thoroughly for accuracy and completeness.

Slide 6
 File Conversion

Also, if the files are already computerised, then the above

difficulties are usually reduced. Transcription of old
computer files to a new computerised format is carried out
using conversion programs. Sometimes a computer
bureaux is used to carry out the conversion process.

Slide 7
 Questions
Individual Assignment:
What is involved in file conversion?

Slide 8
 Topic Two

SYSTEM CHANGEOVER

Slide 9
 System Changeover
System changeover. Once the organisation is
satisfied that all testing is complete and that file
conversion has been carried out accurately, the
next stage is to make the system operational. Four
main methods of system changeover can be used
and these are Parallel Approach, Direct Approach,
Pilot Approach, and Phased or Modular Approach.

Slide 10
 System Changeover
Types of System Change Over
• Parallel Approach
This is the most common form of changeover where the
old and the new systems operate together for a period of
time, processing the same current data. The outputs of the
two systems can then be compared to determine whether
the new system is operating as expected and that there are
no processing errors occurring.

Slide 11
 System Changeover
Types of System Change Over
• Parallel Approach

Slide 12
 System Changeover
Types of System Change Over
• Direct Approach
This has the highest risk. The new system completely replaces the old
system. The old system ceases to operate as illustrated in the
following diagram

Slide 13
 System Changeover
Types of System Change Over
• Pilot Approach
There are two types of changeover under this approach. The
first one is:
Restricted data which involves taking one whole part of the
complete system and running it as the new system. If it
operates properly, then the remaining elements of the system
can be transformed gradually.

The second one is retrospective data which involves operating

the new system with data already processed by the existing
system. The results produced by the new system can be readily
cross checked with the pre-processed results from the existing
system.
Slide 14
 System Changeover
Types of System Change Over
• Modular Approach
Modular or Phased Approach – This approach is often used
by large system projects or in organisations which are
geographically dispersed. It involves implementing one
sub-system at a time or the whole system into one
organisational unit at a time i.e. it is a gradual approach. A
modular approach allows pilot testing to be carried out on
a system or sub-system prior to full implementation. An
illustration is as follows:

Slide 15
 System Changeover
Types of System Change Over
• Modular Approach

Slide 16
 Questions
Individual Assignment:
Write short notes on the following:
• Systems changeover
• File conversion
• Define systems implementation and explain its purpose
• What are the major tasks in implementing a new system
• Briefly describe the strategies commonly used to * from
an old system to a new system

Slide 17
 Questions
Individual Assignment:
You are preparing to meet with your end users to discuss
converting from their old system to a new system. In this
meeting you might have to discuss possible strategies.
Prepare a brief description of the alternative strategies
along with a description of situation for which each
approach would be preferred and required

Forum Question
Distinguish between the three main tests done at the
implementation phase of systems development project
Slide 18
 References
• Checkland, P. (1999). System Thinking, System Practice. Chiches:
John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today. Boston: Mc
Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and Design for
Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design Methods. 6th
ed., Boston: Mc Craw-Hill

Slide 19
 INFS 328
Systems Analysis and Design

Session 11 – Systems Operation and

Support – Part 1
Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies
Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview
Successful systems often need the most support because
users want to learn the features, try all the capabilities, and
discover whether the system can help them perform the
business functions. In most organisations, more than half of
all IT department effort goes into supporting existing
systems and making them valuate to users. Systems
operation – defined as the day-to-day, week-to-week,
month-to-month, and year-to-year executive of an
information systems business, processes and application
programs. Systems support – is defined as the ongoing
technical support for users, as well as the maintenance
required to fix any errors.
Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Post Implementation Review and Report
• User Support activities

Slide 3
Topic One

POST IMPLEMENTATION REVIEW

AND REPORT
Slide 4
 Post Implementation Review and Report
As part of a successful continuous operation of your new information
system, the analyst will have to do a post implementation report for
management.

Post Implementation Report

A post implementation review should be carried out as soon as the
new system is fully operational and fully functional possibly between
one month to one year after changeover. The review actually
examines the processes, procedures and effective running of the
information system to establish the satisfaction of user needs, the
performance of the new system and also review the original cost
benefit analysis. A post implementation report is then written
Slide 5
 Post Implementation Review and Report
Structure of a Post Implementation Report
The structure of the report may include the following:
• The system’s goals and an analysis of how successful the
new system achieved those goals.
• A Summary of the overall quality of the system
• A Summary of those areas where the system is
considered to be unsatisfactory together with
recommendations for improvement.

Slide 6
 Post Implementation Review and Report
Structure of a Post Implementation Report
The structure of the report may include the following:
• An assessment of overall systems performance and systems
development processes and recommendations for
improvement if necessary.
• A cost-benefit analysis comparing the costs and benefits
identified at the feasibility study stage, with actual costs and
benefits.
• A final section summarizing the recommendations for
improving the performance of the system and
recommendations for improving future system development
projects.
Slide 7
 Questions
Individual Assignment:
Why should a system analyst perform a post
implementation review?

Slide 8
Topic Two

USER SUPPORT ACTIVITIES

Slide 9
 User Support Activities
Four Major Support Activities
System support consists of four ongoing activities. Each
activity is a type of support project that is triggered by a
particular problem, event, or opportunity encountered
with the implemented system. The activities are:
• Program maintenance
• System recovery
• Technical support and
• System enhancement.
Slide 10
 User Support Activities
Program maintenance
Regardless of how well designed, constructed and tested the
computer programs may have been, errors or bugs will
inevitably occur. Bugs can be caused by any of the following:
• Poorly validated requirements
• Poorly consummated requirement
• This interpreted requirements
• Simple misuse of the programs

Slide 11
 User Support Activities
Program maintenance
To fix these bugs you will need a good understanding of the
programs you are fixing and of the applications in which the
programs participate. Lack of this understanding is often the
downfall of programs. When users discover that part of the
system is not working properly, you the analyst will then
have to review that segment, identify the area and debug
the program.

Slide 12
 User Support Activities
Program maintenance
The following tests are essential before making the corrected
programs operated:
• Unit testing – ensures that the standard program fines the
bug without undesirable side effect to the program
• System testing – ensures that the entire application of
which the modified program was part, still works
• Regression testing – extrapolate the impact of the
changes on program and application through put and
response time from the before- and-after result using the
test data and arrest performance
Slide 13
 User Support Activities
System recovery
This is the next support activity from time to time, a system
failure may result in a program crook and or loss of data.
Human error or a hardware or software failure may have
caused it. The system analyst or technical support specialists
may then be called on to recover the system that is to
restore a system’s files and database and to restart the
system.

Slide 14
 User Support Activities
Technical support
Another relatively routine ongoing activity of systems
support is technical support. No matter how well users have
been trained or how well documentation has been written
users will require additional assistance. The system analyst is
generally called to assist users with the day-to-day use of
specific application.

Slide 15
 User Support Activities
Technical support
The most typical tasks involved in technical support include:
• Observing the use of the system
• Conducting user-satisfaction surveys and meetings
• Changing business procedures for clarification
• Providing additional training as necessary
• Logging enhancement and report in repository

Slide 16
 User Support Activities
System enhancement
new requirement may become necessary as the
system become operational. Some of those
requirements may include new business problems,
new technical problems or new technology
requirements. The system will therefore have to be
enhanced and this is an adaptive process to meet
the new change and requirements.

Slide 17
 Questions
Individual Assignment:
What are the four different system support activities?
Discuss the purpose of each activity.

Forum Question
System support is one of the most essential activities in the
system development live cycle, discuss.

Slide 18
 References
• Checkland, P. (1999). System Thinking, System Practice.
Chiches: John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today.
Boston: Mc Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and
Design for Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design
Methods. 6th ed., Boston: Mc Craw-Hill
Slide 19
 INFS 328
Systems Analysis and Design

Session 12 – Systems Operation and

Support – Part 2
Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies
Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview
Systems must be maintained and improved continuously to
meet changing business demands, and users constantly
require assistance. In addition to performing maintenance, a
systems analyst is like an internal consultant who provides
guidance and support. This session is a continuation of the
systems operation and support activities, aimed at ensuring
the successful operation of the information system.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Systems Maintenance Task
• Types of Systems Maintenance
• Managing System Support

Slide 3
 Topic Three

SYSTEMS MAINTENANCE TASKS

Slide 4
 Systems Maintenance Tasks
Systems maintenance is much an important
arrangement of system operation and support. This
aspect is also an important component of TCO (total
cost of ownership) because ongoing maintenance
expenses can determine the economic life of a
system. Computer system must be maintained
carefully by trained professionals, and must be
serviced by skilled technicians. In both cases the
quality of the maintenance will directly affect the
company’s return on its initial investment.
Slide 5
 Systems Maintenance Tasks
Cost of Operating an Information System
As I stated in the introduction, maintenance cost can cripple a
company. The following, shows a pattern of operation and
maintenance expenses during the useful life of a system.

Slide 6
 Systems Maintenance Tasks
Time
Operational costs include items such as supplies, equipment,
rental, and software. The lower area of the diagram represents
fixed operational expenses while the upper area represents
maintenance expenses. Maintenance expenses may significantly
increase during the system operational life, and include
spending to support maintenance activities. Activities include
changing programs (as seen in the last section), procedures or
documentation to some correct system performance; adapting
the system to changing requirement; and making the system
operate more efficiently. Those needs are met by corrective,
adaptive, perfective and preventive maintenance. These will be
elaborated upon in the next section.
Slide 7
 Systems Maintenance Tasks
Goals of systems maintenance
System maintenance has the following goals.
• Ensures that systems changes are appropriate to the
organisation’s current processing environment
• Ensures that systems changes are carried out quickly and
effectively
• Perfect systems maintenance and development
procedures by collecting and using information about
systems change.

Slide 8
 Topic Four

MAIN TYPES OF SYSTEMS MAINTENANCE

Slide 9
 Main Types of System Maintenance
Main Types of System Maintenance
The main types of maintenance tasks employed to fix
errors in an information system are;
• Corrective
• Perfective
• Adaptive and
• Preventive maintenance.

Slide 10
 Main Types of System Maintenance
Corrective Maintenance
This diagnoses and corrects errors in an operational system. In
addition to errors in the original version of the system.
Corrective maintenance often is needed to resolve issues
created by * maintenance changes. Corrective maintenance is
done in various ways, depending on the nature and severity of
the problem. Most organisations have standard procedures.
Four main errors, such as an incorrect report * or an improper
format for a data element. In a typical procedure a user submits
a systems request that is evaluated, printed and scheduled by
the systems administrator or the systems reviewed committee.
If the request is approved, the maintenance team designs tests,
documents and implements a solution.
Slide 11
 Main Types of System Maintenance
Adaptive maintenance
This adds enhancements to an operational system and makes
the system easier to use. An enhancement is a new feature
capability. The need for adaptive maintenance usually arises
from business environment changes such as new product or
services, new manufacturing technology or support for a new
web-based operator.
The procedure for minor or adaptive maintenance is similar to
routine corrective maintenance. A user submits a systems
request that is evaluated and prioritised by the system review
committee. A maintenance team then analyses, designs, tests
and implements the enhancement. Although the procedures for
the two types of maintenance are alike, adaptive maintenance
requires more IT resources than minor corrective maintenance.
Slide 12
 Main Types of System Maintenance
Perfective Maintenance
It involves changing an operational system to make it more efficient,
reliable, or maintenance. Requests for corrective and adaptive
maintenance normally come from users while the IT department
usually initiate perfective maintenance.
During system operations, changes in user activity or data pattern can
cause a decline in efficiency, and perfective maintenance might be
needed to restore performance. Perfective maintenance also can
improve system reliability. For example, input problems might cause a
program to terminate abnormally. By modifying the data entry
process, you can highlights errors and notify users that they must
enter proper data. When a system is easier to maintain support is less
costly and less risky. In many cases, you can simplify a complex
program to improve maintainability.
Slide 13
 Main Types of System Maintenance
Perfective Maintenance – Cont.
When performing perfective maintenance, analyst often
use a technique called software reengineering. Software
reengineering uses analytical techniques to identify
potential quality and performance improvements in an
information system. In that sense, software reengineering is
similar to business process reengineering, which seeks to
simplify operators, reduce costs and improve quality.
Depending on the results of software reengineering the
system might be revised, migrated to a different
environment or replaced altogether.
Slide 14
 Main Types of System Maintenance
Preventive Maintenance
To avoid problems, preventive maintenance requires
analysis of areas where trouble is likely to occur. Like
perfective maintenance, the IT department normally
initiate preventive maintenance. Preventive maintenance
often results in increase user satisfaction, decreased down
time and reduced total cost of operation (TCO). Preventive
maintenance competes for IT resources along with other
projects and sometimes does not receive the high priority
that it deserves.

Slide 15
 Questions
Individual Assignment:
Discuss the four main types of system maintenance.
Indicating how those activities are applied to a newly
designed information system.

Slide 16
 Topic Five

MANAGING MAINTENANCE SUPPORT

Slide 17
 Managing Maintenance Support
The Effective Management of System Support
System support requires effective management, quality
assurance and cost control. To achieve effective
management of system support, companies use a variety of
strategies such as maintenance team, a process for
managing maintenance requests and priorities, a
configuration management process and maintenance relax
procedure.

Slide 18
 Managing Maintenance Support
Systems Analysts - assigned to a maintenance team are like
skills detectives who investigate and *locate the source of a
problem by using analysis and synthesis skills.

Programmes – there are three types of programmes,

application programmes work as new systems development
and maintenance; a systems programmer concentrates on
operating system software and utilities and a database
programmer focuses on creating and supporting large-scale
database systems.

Slide 19
 Managing Maintenance Support
Managing maintenance requests – this is an aspect of
managing system support. It involves a sense of stages.
After a user submits a request, a system administrator
determines whether immediate action is needed and
whether the request is under a prescribed cost limit. In un-
emergency requests that exceed the cost limit, a systems
review committee assesses the request and either approves
it within a priority or rejects it. The system administrator
notifies affected uses of the outcome.

Slide 20
 Managing Maintenance Support
Establishing priorities – this involves in the entire
systems development project. The systems review
committee separate maintenance requests form new
systems development requests when evaluating request
and setting priorities.

In other organisations, all requests for systems services are

put into are group and considered together; the most
important project is given top priority, whether it is
maintenance or new development.
Slide 21
 Managing Maintenance Support
Configuration management (CM) – is a process for
controlling changes and costs after a system becomes
operational. Most companies establish a specific process
that describes how system changes must be requested and
documented.

Slide 22
 Managing Maintenance Support
Maintenance release – these are methodologies used to
hold non-critical changes until they can all be implemented
at the same time. Each change is installed as a new version
of the system called a maintenance release. When a release
method is used, a numbering pattern distinguishes the
different release. In a typical system, the initial version of
the set of maintenance changes is version 1.1. a change, for
example, from version 1.4 to 1.5 indicates relatively minor
version 1.0 to 2.0 or from version 3.4 to 4.0, indicate a
significant upgrade.

Slide 23
 Questions
Individual Assignment:
Assume that your company use a release methodology for its sales
system. The current version is 4.5. Decide whether each of the
following changes would justify a version 5.0 release or be included
in a version 4.6 update.
a) add a new report
b) Add a web interface
c) Add data validation checks
d) Add an interface to the marketing system
e) Change the user interface

Slide 24
 Questions
Individual Assignment:
1. What corrective measures would you adopt to
upgrade your newly designed information
system?
2. Explain how the systems operation and support
phase relates to the rest of the system
development process
3. Explain various techniques for managing system
operation and support
Slide 25
 References
• Checkland, P. (1999). System Thinking, System Practice.
Chiches: John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today.
Boston: Mc Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and
Design for Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design
Methods. 6th ed., Boston: Mc Craw-Hill
Slide 26
 INFS 328
Systems Analysis and Design

Session 13 – Systems Analysis and

Construction Tools
Lecturer: Prof. Ellis Edwin Badu, Dept. of Information Studies
Contact Information: [email protected]

College of Education
School of Continuing and Distance Education
2017
 Session Overview
As stated in session 1, a number of tools and techniques are
used by systems analysts and designers to analyse and
synthesise systems functions or units. Two were briefly
described. This session will demonstrate to you how to
construct some of the tools for analysing and designing
systems namely; systems flow chart, data flow diagram,
entity relationship diagram, entity life history and decision
tables.

Slide 2
 Session Outline
The key topics to be covered in the session are as follows:
• Systems Flow Chart
• Data Flow Diagram
• Entity Relationship Diagram
• Entity Life History
• Decision Table

Slide 3
Topic One

SYSTEMS FLOW CHART

Slide 4
 Systems Flow Chart
SYSTEM FLOW CHART
System flow chart is a physical modeling tool that has
various symbols to identify input and output operations,
represent data or files and show media such as disks,
documents and reports. It shows the overall structure of an
Information System. It is used mainly as documentation on
legacy systems

Slide 5
 Systems Flow Chart
Advantages of Using System Flow Chart
• It defines procedures for new operations

• It highlights physical media used in systems, the

various work stations through which data pass as
well as the sequence of activities.

• Helps to avoid duplication

• Helps with the allocation of resources of staff to

various jobs in the organization
Slide 6
 Systems Flow Chart
Advantages of Using System Flow Chart
• Uses very much in systems where the information flow
entails a large number of documents because it can show
all input files, processing and output for a system. It is
able to show origination, processing and destination of
each document and the procedures employed by users.

• It is flexible and versatile

• Procedures can be compared to see which is best and it is

very useful for feasibility study particularly when it is
used to establish that automation is beneficial
Slide 7
 Systems Flow Chart
DISADVANTAGES
• It provides little details on how processes are actually
accomplished – does not furnish the details of programs
for a system.

• It reduces an entire program or set of programs into a

single box.

Slide 8
 Systems Flow Chart
Symbols
There are many symbols used in systems flow charts. These
are standard set of symbols developed by the American
National Standards Institute (ANSI). Flow charts may also
be drawn using software like Visio Professional, Corel Flow,
System Architect, VISO Enterprise, Visible Analyst and ROSE.
Symbol shapes indicate their meanings.

Slide 9
 Systems Flow Chart
Symbols

Slide 10
 Systems Flow Chart
Symbols

Slide 11
 Systems Flow Chart
Symbols

Slide 12
Systems Flow Chart

Slide 13
Systems Flow Chart

Slide 14
Systems Flow Chart

Slide 15
Topic Two

DATA FLOW DIAGRAM

Slide 16
 Data Flow Diagram
Dataflow Diagram’s (DFD’s)
The basic purpose of dataflow diagrams is to describe the flow of
data between entities, processes and data stores. Analysts use
dataflow diagrams to understand the flow of data into, out of,
and within the organisation and to provide a basic understanding
of how a system works. The highest level DFD is called a context
diagram (or Level 0 DFD). This defines the system boundary and
shows how all information enters and leaves the system. DFDs
can be used on both manual and computerised systems, and can
b e used to model the existing system in order to highlight any
gaps in the current data flow or logic. The four symbols used in
dataflow diagrams are as follows.
Slide 17
 Data Flow Diagram
Dataflow Symbols:

Dataflow -
A dataflow indicates the movement of data from one
location in the system to another location. A dataflow could
be a letter, a verbal message, a telephone call an e-mail or a
fax (i.e. it may or may not involve the transfer of a physical
document).

Slide 18
 Data Flow Diagram
Dataflow Symbols:

External Entity –

An entity is either the destination or the source of data,

which is external to the system. It may be people, groups or
another organisation that either provide data to or receive
data from the system.

Slide 19
 Data Flow Diagram
Dataflow Symbols:

Data Store –

Data stores are where data is held within the system and
which receive dataflow. Examples of data stores are data
files (manual or computerised), reports, documents and
transaction records.
Slide 20
 Data Flow Diagram
Dataflow Symbols:

Data Process –

Data processes are processing activities carried out from a data

store or which produce data for a data store. Again, data
processes can be computerised or manual. A process simply uses
data from storage and performs some kind of operation upon
that data such as sorting, or re-calculating the data, then sends
the processed data back to storage or as output to an external
entity.
Slide 21
 Data Flow Diagram
Features of DFDs
As it is not possible to show all of the organisation’s
processes within one context diagram, it is necessary to
explore DFDs in order to show increasingly detailed levels of
processing. This decomposition has the following purposes:
• Shows clearly where data is stored
• Defines which processes change data
• Ensures data analysis is complete and thorough

Slide 22
 Data Flow Diagram
Features of DFDs
• Provides a basis for software specification by indicating
the processing functions required by systems software.

• Each DFD will take one of the processes within a higher

level DFD and draw further DFDs of its internal processes.
This is repeated until a level is reached whereby the
process has been described in sufficient detail to design a
computer program from the process description.

Slide 23
Data Flow Diagram

Slide 24
 Questions
Activity:
The stores department of X Ltd send purchase requisition orders
(PRO) to the purchasing department. The purchasing department
clerk checks the purchase requisition, and if incorrect it is returned to
the stores department for correction. If correct, the requisition is
accepted and an order is processed using an existing file of approved
suppliers. The order is then processed and sent to the supplier. The
original requisition order document is put on file and a copy of the
order is created and filed. Goods are delivered by the supplier and
checked on receipt and received. The supplier then sends an invoice.
The invoice is compared with the requisition order on file and if the
invoice is queried it is returned to the supplier. Accepted invoices are
passed to accounts who pay the invoice. Completed orders are filed.
Prepare a DFD for the above process.
Slide 25
Questions

Slide 26
 Topic Three

ENTITY RELATIONSHIP DIAGRAM

Slide 27
 Entity Relationship Diagram
Entity relationship modelling (ERM)
Entity relationship modelling is a tool used within data
analysis, and is structured around three basic concepts.

• An entity
This is an item (person, product, activity, job, department
or business) that is important to an organisation and about
which information must be stored. For example, customers
and suppliers are entities as are employees.

Slide 28
 Entity Relationship Diagram
• Attributes
An attribute is a fact or characteristic of an entity
which the business records. For example, the
attributes recorded about an employee could
include name, address, qualifications, department
and current salary.

Slide 29
 Entity Relationship Diagram
• Relationship
These are the logical links between entities. The degree of
relationship between entities may be one of three, as
shown below.
1. One-to-one relationship (1:1) means that the entity
only relates to one other entity.

That is, a student can only enrol on one degree.

Slide 30
 Entity Relationship Diagram
Relationship
2. One-to-many relationship (1:N) means that an entity
can relate to one or more other entities.

One degree will contain many modules of study.

Slide 31
 Entity Relationship Diagram
Relationship
3. Many-to-many relationship (M:N) means that a number
of entities may relate to a number of other entities.

These various modules are likely to be taught by a number

of lecturers.
Slide 32
 Questions
Activity:
Z Ltd has many departments (containing a number
of staff). Each department has only one manager,
and these managers form the Management Board.
The managers are all salaried and therefore are on
the monthly payroll. The other staff within the
department can either receive a salary (monthly) or
can be paid wages (received weekly).
Demonstrate the above using an ERM diagram.
Slide 33
Answer to Activity

Slide 34
 Topic Four

ENTITY LIFE HISTORY (ELH)

Slide 35
 Entity Life History (ELH)
ELH is also sometimes referred to as an entity life cycle
analysis. An entity life history is a representation of the
processes that occur in the life of each individual entity, and
is designed to show the way in which information within a
system changes over time. An ELH shows what happens to
an entity between its creation and its termination. The
entity can go through three phases of development:
recreation, amendment and termination.
The important function of ELH analysis is the identification
of the events and functions of an entity that cause the
entity to change, rather than the analysis of the entity itself.
Slide 36
Entity Life History (ELH)

Slide 37
 Entity Life History (ELH)
There are three main symbols used within ELH diagrams; there is a
rectangular box, within which can be placed either an asterix or a
small circle. The top level shows the entity itself, and at each
subsequent level the boxes read from left to right (in order of
create, amend, delete).
At the lower levels, the boxes represent events which occur within
the life of the entity. If an event affects an entity many times, this
can be shown by an asterix. For example, the above shows that
the student will study numerous modules during the life cycle.
Similarly, testing will consist of a number of examinations.
The boxes with small circles in the top right hand corner indicate
alternatives for particular events. For example, students may be
learning or being tested but not at the same time. Similarly, for an
examination, the student can either pass or fail, but not both.
Slide 38
 Topic Five

DECISION TABLES

Slide 39
 Decision Tables
Decision tables are used to describe the processing
logic of a system. The most useful application of
decision tables is in a situation where there may be
a number of alternative conditions to evaluate. A
decision table contains four quadrants: the
conditions quadrant, the conditions entry quadrant,
the action quadrant and the action entry quadrant.

Slide 40
 Decision Tables
Decision Table Quadrants

Slide 41
 Decision Tables
Method of Construction
The decision table begins with the posing of a question.
Starting with a basic example: do we offer credit facilities to
our customers?
From the question, establish the conditions and then
complete the condition quadrant of the table. The
conditions need to be formulated into a question format
that can be answered by yes or no answers only.

Slide 42
 Decision Tables
Method of Construction
Thus, for the above example, the conditions could be as follows:
• Customers with orders under GH¢100 do not receive credit
facilities
• Customers with order valued between 100 euros and249
Ghana Cedis receive credit for one year. Existing customers
rate of interest is 5 percent per annum, and new customers
rate of interest is 7 per cent
• Existing customers with orders above GH¢250 are offered
credit terms at 7 per cent for one year, but new customers
with orders over GH¢ 250 must undertake a credit check
procedure.

Slide 43
 Decision Tables
Method of Construction

Conditions order under

GH¢100? Conditions
Order between £100 – Entry
GH¢ 249?
Existing customer?
Action
Actions
Entry
Slide 44
 Decision Tables
Method of Construction
• The next stage is to fill in the condition entry quadrant.
The condition entry should contain the answers in yes or
no format that will cover every possible condition in the
condition quadrant. The condition entry quadrant is
completed in the form of’ columns’ of combinations of
yes and no answers. The number of columns is
determined by 2 to the power of’ n’, in being the number
of questions in the ‘conditions’ quadrant. In this case
therefore, the number of columns s 23=8

Slide 45
 Decision Tables
Method of Construction
• The next stage is to methodically complete the condition
entry quadrant by applying the ‘halving rule’.
Conditions order under
1 2 3 4 5 6 7 8
GH¢ 100?
YYYYNNNN
Order between £100 –
YYNNYYNN
GH¢ 249?
YNYNYNYN
Existing customer?
Actions
Actions
Entry
Slide 46
 Decision Tables
Method of Construction
• Now eliminate any impossible columns from the
condition entry quadrant
Conditions order under
1 2 3 4 5 6 7 8
GH¢100?
YYYYNNNN
Order between £100 –
YYNNYYNN
GH¢ 249?
YNYNYNYN
Existing customer?
Action
Actions
Entry
Slide 47
 Decision Tables
Method of Construction
• In this question, the first two columns are impossible situations and can
therefore be eliminated. The next stage is to complete the action quadrant, by
listing the possible alternative actions that can be carried out.

Conditions order under GH¢100? 3 4 5 6 7 8

Order between £100 - YYNNNN
GH¢ 249? NNYYNN
Existing customer? YNYNYN
Actions
No credit given
Action
Credit given 1 year at 5%
Entry
Credit for 1 year at 7%
Credit check Slide 48
 Decision Tables
Method of Construction
• Now complete the action entry quadrant by considering each
possible combination of conditions, and place an x in the action
entry quadrant to indicate action to be taken.
Conditions order under GH ¢100? 3 4 5 6 7 8
Order between £100 - YYNNNN
GH¢ 49? NNYYNN
Existing customer? YNYNYN

Actions
XX
No credit given
X
Credit given 1 year at 5%
XX
Credit for 1 year at 7%
X
Credit check
Slide 49
 References
• Checkland, P. (1999). System Thinking, System Practice.
Chiches: John Wiley.
• O’Brien, J. A. (2003). Introduction to Information Systems:
Essentials for E-Business Enterprise. Boston: Irwin
• O’Leary, I. and O’leary, T. I. (2004). Computing Today.
Boston: Mc Craw-Hill
• Rowley, J. (1990). The Basics of Systems Analysis and
Design for Information Managers. Ludin: Clive Bingley
• Whitten, J. et al (2000). Systems Analysis and Design
Methods. 6th ed., Boston: Mc Craw-Hill

Slide 50