SYSTEMS ANALYSIS

AND
DESIGN
 TABLE OF CONTENTS
TABLE OF CONTENTS 1
CHAPTER ONE 3
SYSTEM ANALYSIS AND DESIGN 3
1.0 Introduction 3
1.1 What Is a System 3
1.2 Types of System 6
1.3 A Formal Information System 8
1.4 An Informal Information System 9
1.5 Computer-Based Information System 9
1.6 Automated System 11
1.7 System Concepts 12
1.8 System Relations 12
1.9 Attributes Common to Most Systems 13
1.10 Why System Changes 13
CHAPTER TWO 15
SYSTEM ANALYSIS AND DESIGN 15
2.1 What Is System Analysis and Design 15
2.2 Objectives of System Analysis 15
2.3 Role of A Systems Analysist 16
2.4 Software Development Roles and Responsibilities 17
2.5 System Investigation 20
2.6 Software Crisis 21
CHAPTER THREE 23
SYSTEM DEVELOPMENT PROCESSES 23
3.1 Systems Development Life Cycle (SDLC) 23
3.2 Phases of Systems Development Life Cycle 24
CHAPTER FOUR 32
SYSTEMS DESIGN 32
4.1 Input Requirements 32
4.2 Output Requirements 32
4.3 Types of System Design 32
4.4 Conceptual Data Modelling 33
4.5 File Organization 36

1
CHAPTER FIVE 38
SYSTEM IMPLEMENTATION 38
5.1 System Conversion and Implementation 38
5.2 Operating Plan 41
5.3 Evaluation 41
5.4 System Maintenance 42
CHAPTER SIX 44
PROTOTYPING APPROACH TO SYSTEMS DEVELOPMEENT 44
6.1 Objectives of Prototyping 44
6.2 A Model to Prototyping Process 45
6.3 Applications That Are Good Prospects for Prototyping 47
CHAPTER SEVEN 48
SYSTEMS DEVELOPMENT METHODS 48
7.1 Structured Analysis and Design 48
7.2 Object-Oriented Analysis and Design 48
7.3 Function Oriented Design 49
7.4 Function Design 51
7.5 Software User Interface Design 53
CHAPTER EIGHT 60
STRUCTURED ANALYSIS & DESIGN TOOLS 60
8.1 Guidelines for Selecting Appropriate Tools That Will Suit Your Requirements 61
8.2 Flow Charts 61
8.2 Data Flow Diagram 62
8.3 Hipo Diagram 63
8.4 InputProcessOutput (IPO) 63
8.5 Decision Tables 64
8.6 Structured English 65
8.7 Pseudo-Code 66
8.8 Data Dictionary 66
8.9 Computer Assistant Software Engineering (Case) 68
8.10 Project Management Tools and Techniques 68
8.12 Gantt Chart 69

2
 CHAPTER ONE
SYSTEMS ANALYSIS AND DESIGN
1.0 Introduction
System analyst and design refers to the process of examining a business situation with the intent of improving it
through better procedures and methods. Systems development can generally be thought of as having two major
components; Systems analysts and Systems design. System design is the process of planning a new system or
replace or complement an existing system. But before this planning can be done, we must thoroughly
understand the existing system and determine how computers can best be used to make its operations more
effective. Systems analysis, then, is the process of gathering and interpreting facts, diagnosing problems and
using the information to recommend improvements to the system. In brief, we can say that analysis specified
what the system should do. Design states how to accomplish the objectives.

1.1 What is a System?

The word “SYSTEM” covers a very broad spectrum of concepts. This is derived from the Greek word systema,
which means an organized relationship among the functioning units or components. In our daily life, we come
into contact with the transportation system, the communication system, the accounting system, the production
system, the economic system and for over three decades, the computer system. Similarly, business systems are
the means by which business organizations achieve their pre-determined goals. A business system combines
policies, personnel, equipment, and computer facilities to coordinate the activities of business organization.
Essentially, a business system represents an organized way of achieving the pre-determined objectives of an
organization.
There are various definitions of the word system, but most of them seems to have common idea and
suggests that a system is an orderly grouping of interdependent components linked together according to a plan,
to achieve a specific goal. The word component may refer to physical parts (engines. Wheels of a car),
managerial steps (planning, organizing, controlling) or a subsystem in a multi-level structure. The components
may be simple or complex, basic or advanced. They may be a single computer with a keyboard, memory and
printer or a series of intelligent terminals linked to a mainframe. In either case, each component is a part of the
total system and has to do its own share of the work for the system to achieve the desired goal.

1.1.1 System Study, System Analysis and System Approach

Systems study may be defined as “a study of the operations of a set of connected elements and of the inter-
connections between these elements”. It shows clearly that one cannot ignore any part or element without first
finding out the effect that element has on the operations of the system as a whole. We can understand this with
the help of system analysis. There is a difference between “systems approach” and “system analysis” also. The
systems approach shows a set of procedures for solving a particular problem. It implies scientific methods to
observe, clarify, identify and solve a problem with special care being taken to understand the inter-relatedness
between elements and their system characteristics. However, systems analysis is a management technique which
helps us in designing a new system or improving an existing system.

3
1.1.2 Characteristics of a System
Based on the definition of a system, it is observed that following characteristics are present in all systems:
a) Organization: Organization implies structure and order. It is the arrangement of components that helps
to achieve objectives. In the design of a business system, for example, the hierarchical relation starting
with the president on top and leading downwards to the blue-collar workers represents an organization
structure. Likewise, a computer system is designed around an input device, a central processing unit, an
output device and one or more storage units. When these units are lined together, they work as a whole
system for generating information.
b) Interaction: Interaction refers to the procedure in which each component functions which each other
components of the system. In an organization, for example, purchasing must interact with production,
advertising with the sales and payroll with personnel. In a computer system also, the central processing
must interact with other units to solve a problem. In turn, the inter-relationship between these
components enables the computer to perform.
c) Interdependence: Interdependence means that component of the organization or computer system
depends on one another. They are coordinated and linked together in a planned way to achieve an
objective.
d) Integration: Integration is concerned with how a system is tied together. It is more than sharing a
physical part or locations. It means that parts of the system work together within the system even though
each part performs a unique function. Successful integration will typically produce a better result as a
whole rather than if each components works independently.
e) Central Objective: Central objective is the last characteristics of a system. Objectives must be real or
stated. Although a stated objective may be the real objective. It is quite common that organization may
set one objective and operate to achieve another. The important point is that users must be aware of the
central objective well in advance.
1.1.3 Elements of System
In most cases, systems analysts operate in a dynamic environment where change is a way of life. The
environment may be a business firm, a business application, or a computer system. To reconstruct a system, the
following key elements be must be considered:

control

input processor output

Boundaries and
feedback
Environment interfaces
Figure 1.1: Elements of a system

4
a. Outputs and Inputs
A major objective of a system is to produce an output that has value to its user. Whatever the nature of the
output (good, services, or information), it must be in line with the expectations of the intended user. Inputs are
the elements (materials, human resources, and information) that enter the system for processing. Output is the
outcome of processing. A system feeds on the inputs to produce output in much the same way that a business
brings in human, financial, and material resources to produce goods and services. It is important to point out
here that determining the output is a first step in specifying the nature, amount and regularity of the input
needed to operate a system. For example, in systems analysis, the first concern is to determine the user’s
requirements of a proposed computer system – that is specification of the output that the computer is expected
to provide for meeting user requirements.

b. Processor(s)
The processor is the element in a system that involves the actual transformation of input into output. It is the
operational component of a system. Processors may modify the inputs totally or partially, depending on the
specifications of the output. This means that as the output specifications change so does the processing, in some
cases, input is also modified to enable the processor to handle the transformation.

c. Control
The control element guides the system. It is the decision – making subsystem that controls the pattern of
activities governing input, processing, and output. In an organizational context, management as a decision –
making body controls the inflow, handling and outflow of activities that affect the welfare of the business. In a
computer system, the operating system and the accompanying software influence the behavior of the system.
Output specifications determine what and how much input is needed to keep the system in balance.
In system analysis, knowing the attitudes of the individuals who controls the area for which a computer
is being considered can make the difference between the success and failure of the installation. Management
support is required for securing control and supporting the objective of the proposed change

d. Feedback
Control in a dynamic system is achieved by feedback. Feedback measures output against a standard in some
form of cybernetic procedure that includes communication and control. Output information is fed back to the
input and/or to the management(controller) for deliberation. After the output is compared against performance
standards, changes can result in the input or processing and consequently, the output.
Feedback may be positive or negative, routing or information. Positive feedback reinforces the
performance of the system. It is routine in nature. Negative feedback generally provides the control with
information for action. In systems analysis, feedback is important in different ways. During analysis, the user
may be told that the problem in a given application verify the initial concerns and justify the need for a change.
Another form of feedback comes after the system is implemented. The use informs the analyst about the
performance of the new installation. This feedback often results in enhancements to meet the user’s
requirements.

5
e. Environment
The environment is the “supra-system” within which an organization operates. It is the source of external
elements that impinge in the system. In fact, it often determines how a system must function. For example, the
organization’s environment, consisting of vendors, competitors, and others, may provide constraints and
consequently, influence the actual performance if the business.
f. Boundaries and interface
A system should be defined by its boundaries - the limits that identify its components, processes and
interrelationship when it interfaces with another system. For example, a teller system in a commercial bank is
restricted to the deposits, withdrawals and related activities of customers checking and savings accounts. It may
exclude mortgage foreclosures, trust activities, and the like.
Each system has boundaries that determine its sphere of influence and control. For example, in an
integrated banking - wide computer system design, a customer who has a mortgage and a checking account with
the same bank may write a check through the "teller system" to pay the premium that is later processed by the
"mortgage loan system." Recently, system design has been successful in allowing the automatic transfer of
funds from a bank account to pay bills and other obligations to creditors, regardless of distance or location. This
means that in systems analysis, knowledge of the boundaries of a given system is crucial in determining the
nature of its interface with other systems for successful design.
1.2 Types of System
There are different types of System; almost everything we come into contact with on a daily basis is either a
system or a component or (both). It is useful to organize the many different kinds of systems into useful
categories. Systems have been classified in different ways. Common classifications are:
(i) Physical or abstract systems
(ii) Open or closed systems
(iii) Deterministic or probabilistic systems
(iv) Adaptive and Non-Adaptive System
(v) Permanent or Temporary System
(vi) Natural and Manufactured System
(vii) Social, Human-Machine, Machine System
viii) Man-made/information systems.
1.2.1 Physical or Abstract Systems
Physical systems are tangible entities that may be static or dynamic in operation. Abstract systems are
conceptual or non-physical entities which may be as straightforward as formulas of relationships among sets of
variables or models - the abstract conceptualization of physical situations.

1.2.2 Open or Closed System

An open system continually interacts with its environments. It receives inputs from and delivers outputs to
outside. An information system belongs to this category, since it must adapt to the changing demands of the
6
user. In contrast, a closed system is isolated from environmental influences. In reality completely closed
systems are rare.
1.2.3 Deterministic or Probabilistic Systems
A deterministic system is one in which the occurrence of all events is perfectly predictable. If we get the
description of the system state at a particular time, the next state can be easily predicted. An example of such a
system is a numerically controlled machine tool. Probabilistic system is one in which the occurrence of events
cannot be perfectly predicted. An example of such a system is a warehouse and its contents.

1.2.4 Adaptive and Non-Adaptive System

Adaptive Systems responds to the change in the environment in a way to improve their performance and to
survive. For example, human beings, animals. Non-Adaptive System is the system which does not respond to
the environment. For example, machines.

1.2.5 Permanent or Temporary System

The Permanent System persists for a long time. For example, business policies. Temporary System is made for a
specified time and after that they are demolished. For example, A DJ system is set up for a program and it is
disassembled after the program.

1.2.6 Natural and Manufactured System

These are systems that are not made by man/people. They exist in nature and serve their purpose. They can be
divided into two basic subcategories: physical and living systems.
I. Physical systems include:
(a) Stellar systems - galaxies, solar systems and so on
(b) Geological systems - rivers, mountain ranges etc.
(c) Molecular systems - complex organizations of atoms
The computer system developed by man must interact with the physical system. It is
important to be able to model those systems to ensure that we understand them as fully as
possible.
II. Living system:
The plants, animals around us and the human race are an example of a living system. According
to Chiemeke & Egbokhare (2006), there are 19 sub-systems in the living system either at the
level of the cell, the organ, the organism, the group, the organization or society. Some of the
examples are:
 The reproducer: is capable of giving rise to other systems similar to the one it is in.
 The boundary: holds together the components that make up the system; protects them
from environmental stresses, and excludes or permits entry to various sorts of matter,
energy and information.
 The Ingestor: brings matter-energy across the system boundary from its environment.
 The distributor: carries inputs from outside the system or outputs from its subsystems
around the system to each component.
 The converter: changes certain inputs to the system into forms more useful for the special
processes of that particular system.

7
  The producer: forms stable associations that endure for significant periods among,
matter-energy inputs to the system or outputs from its converter, the materials synthesized
being or growth, damage repair.

Other subsystems are; the matter-energy storage subsystem, the extruder, the motor, the supporter, the input
transducer, the internal transducer, the channel and net, the decoder, the associator, the memory, the decider and
the encoder.

1.2.7 Social, Human-Machine, Machine System

Social System is made up of people. For example, social clubs, societies. In the Human-Machine System, both
humans and machines are involved to perform a particular task. For example, Computer programming. Machine
Systems are where human interference is neglected. All the tasks are performed by the machine. For example,
an autonomous robot.

1.2.8 Man-made/Information Systems

(a) Man-made systems include:
● Social systems: these are organizations of laws, doctrines, customs, and so on.
● An organized, disciplined collection of ideas
● Transportation systems: networks of highways, canals, airlines and so on.
● Communication system: telephone, telex, etc.
● Manufacturing systems: factories, assembly lines, and so on.
● Financial systems: accounting, inventory, general ledger etc.

As a system analyst, the customer or user expects that you have an idea of how these systems can be
computerized. Hence, you must know all the duties of a Systems Analyst to be able to build an effective and
efficient system. This can only be achieved after modelling its essential behaviour. As a result of cost,
convenience, security, maintainability, some information processing systems may not be automated.
It is generally believed that information reduces uncertainty about a state or event. For example, information
that the wind is calm reduces the uncertainty that a trip by boat will be enjoyable. An information system is the
basis for interaction between the user and the analyst. It determines the nature of relationships among decision
makers. In fact, it may be viewed as a decision centre for personnel at all levels. From this basis, an information
system designed may be defined as a set of devices. procedures and operating systems designed around user-
based criteria to produce information and communicate it to the user for planning, control and performance.
Many practitioners fail to recognize that a business has several information systems, each is designed for a
specific purpose. The major information systems are:
● Formal information systems
● Informal information systems
● Computer-based information systems.

1.3 A Formal Information System

A formal information system is based on the organization represented by the organization chart.
The chart is a map of positions and their authority relationships, indicated by boxes and connected by straight
lines. It is concerned with the pattern of authority, communication and workflow.
8
1.4 An Informal Information System
An informal information system is an employee-based system designed to meet personnel and
vocational needs and to help in the solution of work-related problems. It also funnels information upwards
through indirect channels. In this way, it is considered to be a useful system because it works within the
framework of the business and its stated policies.
1.5 Computer-based Information Systems
The computer-based information system is the third category of information system, it depends mainly on the
computer for handling business applications. Systems analysis develops several different types of information
systems to meet a variety of business needs. There is a class of systems known collectively as
As we have different types of transportation systems such as highways systems, railways systems and airline
systems, computer-based information systems are of too many types. They are classified as:
● Transaction Processing Systems (TPS)
● Management Information Systems (MIS)
● Decision Support System (DSS)
● Office Automation Systems (OAS).
Figure 1.2 shows the organization chart of computer-based information systems (CBIS) and figure 1.3 shows
the hierarchical view of CBIS.

Planning, controlling decision making

And decision making

MIS DSS

Application
DATA COMPUTER program

TPS OAS

Sales, receipts clerical tasks

Figure 1.2: CBIS in an Organizational Context

Top
Management DSS

Middle Management MIS

First Line Management 9
 TPS
Clerical Personnel OAS
Figure 1.3: The Hierarchical View of CBIS
1.5.1 Transaction Processing Systems
The most fundamental computer-based system in an organization pertains to the processing of business
transactions. A transaction processing system can be defined as a computer-based system that captures.
classifies, stores, maintains, updates and retrieves transaction data for record keeping and for input to other
types of CBIS. Transaction Processing Systems are aimed at improving the routine business activities on which
all organizations depend. A transaction is any event or activity that affects the whole organization. Placing
orders, billing customers, hiring of employees and depending cheques are some of the common transactions.
The types of transaction that occur vary from organization to organization.
But it is true that all organization process transactions as a major part of their daily business activities.
The most successful organizations perform this work of transaction processing in a very systematic way.
Transaction processing systems provide speed and accuracy and can be programmed to follow routines without
any variance.

1.5.2 Management Information System

Data processing by computer has been extremely effective because of several reasons. The main reason
being that huge amount of data relating to accounts and other transactions can be processed very quickly. Earlier
most of the computer applications were concerned with record keeping and the automation of routine clerical
processes. However, in recent years, increasing attention has been focussed on computer applications providing
information for policy making, management planning and control purposes. MIS are more concerned with
management function. MIS can be described as information system that can provide all levels of management
with information essential to the running of smooth business. This information must be as relevant, timely,
accurate, complete and concise as is economically feasible.

1.5.3 Decision Support Systems

It is an information system that offers the kind of information that may not be predictable, the kind that
business professionals may need only once. These systems do not produce regularly scheduled management
reports. Instead, they are designed to respond to a wide range of requests. It is true that all the decisions in an
organization are not of a recurring nature. Decision support systems assist managers who must make decisions
that are not highly structured, often called unstructured or semi-structured decisions. A decision is considered
unstructured if there are no clear procedures for making the decision and if not all the factors to be considered in
the decision can be readily identified in advance. Judgement of the manager plays a vital role in decision-
making where the problem is not structured. The decision support system supports, but does not replace,
judgement of the manager.

1.5.4 Office Automation Systems

Office automation systems are among the newest and most rapidly expanding computer-based
information systems. They are being developed with the hopes and expectations that they will increase the
efficiency and productivity of office workers, typists, secretaries, administrative assistants, staff professionals,
10
managers and the like. Many organizations have taken the first step toward automating their offices. Often this
step involves the use of word processing equipment to facilitate the typing, storing, revising and printing of
textual materials.
Another development is a computer-based communications system such as electronic mail which allows
people to communicate in an electronic mode through computer terminals. An office automation system can be
described as a multi-function, integrated computer-based system that allows many office activities to be
performed in an electronic mode. Categories of different information systems with their characteristics is
described briefly in table 1.1:
Table 1.1: Categories of Information Systems
Category of Characteristics
Information systems
Transaction Processing System Substitutes computer-based processing for manual procedures.
Deals with well structured routine processes. Includes record
keeping applications.
Management Information System Provides input to be used in the managerial decision process. Deals
with supporting well structured decision situations. Typical
information requirements can be anticipated.
Decision Support System Provides information to managers who make judgements about
particular situations. Supports decisionmakers in situations that are
not well-structured.
Office Automation System It is a multi-function, integrated computer-based system that allows
many office activities to be performed in an electronic mode.
1.6 Automated Systems
These are man-made systems that interact with or are controlled by one or more computers. There are different
types of automated systems:
i. Computer hardware - these includes CPUs, disks, terminals, etc.
ii. Computer software - these are system programs such as operating systems, database systems, and
so on.
iii. People - these are the users of the system
iv. Data: the information which the system remembers over a period of time
v. Procedures: formal policies and instructions for operating the system
1.6.1 Categories of Automated System
Automated systems can be categorized by application. Here are some of the useful categorization of automated
systems:
i. Batch processing: this is the execution of series of jobs in a program on a computer without manual
intervention. It is a processing mode in which the execution of a series of programs each is on a set or "batch" of
inputs, rather than a single input. Here the information is usually retrieved on a sequential basis, which means
that the computer system read through all the records in its database, process and update the records for which
there is an activity.

11
ii. On-line systems: they accept input directly from the area where it is created. In this type of system, the
outputs, results of computation are returned directly to where they are required e.g. surfing, instant messenger,
gaming on-line etc.
iii. Real-time systems: these are systems which controls an environment by receiving data, processing them,
and returning the results sufficiently quickly to affect the environment at that time. In real-time, there is no
noticeable delay e.g. banks, ATM, POS (Point of sale), radar system etc. In a live telecast of a cricket online,
this is real time as you get to see a wicket falling or a ball being bowled after a lag of a few seconds.
Most on-line system today are almost real time. Another example is a railway reservation system Where you get
immediate booking as soon as you press the button 'confirm; and thus it is an online system that is also real
time.
iv. Decision-support system: These computer systems do not make decisions on their own, but instead help
managers and other professional "knowledge workers" in an organization make intelligent, informed decisions
about various aspects of the operation. These systems are passive i.e. they are not used on a regular basis.
v. Knowledge-based system: These systems are design to produce programs that imitate human
performance in a wide variety of intelligent" tasks.

Difference between batch and on-line processing

On-line processing involves entering a transaction directly into the computer and processing it immediately.
With on-line processing, information in the system is always up-to-date and current.
1.7 System Concepts
The three basic concepts of a system are:
i. System boundary mark out a system. System boundary is used to separate systems outside and inside.
The system environment is anything outside a system boundary and consists of other systems which exist with
yet other systems. The system is inside the boundary and a system is defined by where its boundary is drawn.
ii. System state: This is the condition in which a system exists at a particular moment. A simple system
exists in more than one state.
iii. System behaviour: This is the ability of a system to change from one state to another. A simple system
can exist in a large number of state, that is, its capable of displaying different behaviours.
The way a system behaves affects their environment. The system behaviour is therefore viewed as
crossing the system boundary.

1.8 System Relationship

System relationship describes the interaction between system and how they react to or are influenced by
behaviours of other systems.
a. Input/output relationship: The data fed into a system are referred to as input data while the result after
processing is output. In this situation, output from one system is the input to another system even though
they may be administered at different systems. To achieve administrative efficiency and convenience,
most systems take this structure e.g. personnel and payroll system.
b. Open systems: An open system is one where a quantity or series of quantities can enter or leave the
system to a significant degree. If you pour your hot drink into a mug instead of a vacuum thermos flask,
12
 the heat will escape relatively quickly into its surroundings. So a mug is most certainly an open system!
Open systems are a lot more complicated to understand than closed systems, and so scientists prefer to
work with closed systems when possible. These are systems that interact with their environment and
thus exchanges information, material, or energy with the environment, including random and undefined
inputs. Open systems are adaptive and require speedy reaction to competitive situations and other threats
in the most effective way. They include organisational and business systems.
c. Closed Systems: closed system is one where a quantity or series of quantities cannot enter or leave the
system. For example, a system might be closed to energy, meaning energy might not be able to enter or
leave the system. A vacuum thermos flask does a really good job of stopping energy from leaving the
system to keep your drink warm. So it might make sense to treat it as a closed system - but no system in
the real world is ever perfectly closed, so it will only be an approximation. This type of system does not
interact with its environment either for change of information or business transaction. Such systems, in
business world, are rare. No business system conforms with this category as most of them interact with
their environment to a great degree. Systems that are relatively isolated from the environment but not
completely closed are termed closed systems.

1.9 Attributes common to most systems

1. A system interacts with the environment. They receive input from and transmit to their surroundings.
Due to this interaction with their environment, they are often called open system.
2. A system has a purpose. In every system there is always a goal set out to achieve, which is referred to
as aim and objective. E.g. the purpose of a firm's payroll system is to deliver salaries to employee.
3. A system is self-regulating. Systems should be able to maintain themselves in a steady state. In other
words, they maintain themselves in a steady state. In other words, they ought to be able to adjust their
internal functions to accommodate externally imposed changes e.g. exercises.
4. A system is self-correcting: Systems must be able to respond to abnormal situations that cannot be
controlled by routine self-regulation. Such occurrences should be handled in ways that won't jeopardize
the system's whole purpose. E.g. clotting takes place when a blood vessel is damaged.

1.10 Why System Changes

Change is the only thing that is dynamic, we live in a world of constant change. Due to modifications of old
systems or development of new ones, change may be necessary. As such, business and organizations must stay
abreast of ever-changing laws and regulations. The idea for change originates in the environment or from within
the firm, Environment-based ideas originate from customers, vendors. government sources, and the like. For
example, new unemployment compensation regulations may make it necessary to change the restructures.
Customer complaints about the delivery of orders may prompt an investigation of the delivery schedule, the
experience of truck drivers, or the volume of orders to be delivered. When investigated, each of these ideas may
lead to a problem definition as a first step in the system life cycle process.
Tax laws may be changed by government or government may require that business provide certain new data
about their employees, this will prompt the modification of existing data processing systems. Ideas for change
may also come from within the organization- top management, the user, and the analyst. As an organization
changes its operations or faces advances in computer technology someone within the organization may feel the
need to update existing applications or impro procedures. Here are some examples:
 An organization acquires another organization.
13
  A local bank branches into the suburbs.
 A department spends 80 percent of its budget in one month.
 Two departments are doing essentially the same work, and each department head insists the other
department should be eliminated.
 A request for a new form discloses the use of bootleg (unauthorized) forms.
All these factors are crucial for prompt response to a user request for change. A systems analyst is in a unique
position to detect and even area of operations make him/ her a convenient resource for ideas. The role and status
of the analyst as a professional add credibility to the suggestions made.

Questions
1. What is a system?
2. Differentiate between system design and system analysis
3. What is the basic difference between 'systems approach" and "systems analysis"?
4. Discuss the various characteristics of a system
5. With a labelled diagram, discuss the various elements of a system
6. What are the common types of systems?
7. What is a computer-based Information System?

14
 CHAPTER TWO
SYSTEMS ANALYSIS AND DESIGN
2.1 What is Systems Analysis & Design?
The process of examining a (business) situation with the intent of improving it through better procedures and
methods.
System Analysis is the process of gathering and interpreting facts, diagnosing problems, and using the facts to
improve the system.
Systems Design is the process of planning a new system to replace or complement the old. Analysis
specifies what the system should do and design states how to achieve the objective.
Note: This examination should always be initiated by the people involved in the situation (or who will be
involved in a new situation). It is the job of the analyst to suggest solutions, but not make business decisions. (A
computer based solution is not necessarily the only one!).
What Systems Analysis is NOT
• Studying a business to decide which existing procedures should be handled by the computer and which
should be done by non-computer methods.
• Determining what changes should be made.
• Initiate new procedures and practices.

2.2 Objectives of Systems Analysis

1. System analysis help in identifying the conflicting objectives between or in the sub-systems
2. It helps in understanding or producing the inter-compatibility and purpose of sub-systems.
3. System analysis provides a clear path way in the understanding of the complex structures.
4. System analysis assist in installing each sub-system in its perspective and context, in result, the system
will achieve its who objectives with the least available resources
5. System analysis defines the clear function requirement of a sub-system (components) and its correlated
sub-systems.
Thus, systems analysis is one of the important techniques that provide a systematic and broader outlook to
understanding, examining and creating or modifying the system to meet specific objectives. System analysis
and design is an interactive and creative process.

2.2.1 People involved in System Analysis

1. Business Analysts (B.A.): Identification Feasibility Analysis, conducting system studies to learn the
relevant facts about a business activity. The emphasis is on determining information and processing
requirements. Their responsibilities do not include systems design.
2. Systems Designers (S.D.): Design begin after the initial investigation by Business Analysts and use that
information to design the system. The emphasis is on converting the requirements into processes
(programs) and data (files or database). They do not write programs but do investigate available
software and hardware.
3. Systems Analysts: They are all and all in the organization. They combine the responsibilities of
Business Analyst and System Designers
15
4. Analyst Programmers: They are also a major part of the organisation (or what they know) they
combine the responsibilities of System Analyst and Programmers, i.e. they also develop the software to
implement the design.
2.3 Role of a Systems Analyst
2.3.1 Who is a Systems Analyst?
A systems analyst is a person who conducts a study, identifies activities and objectives and determines a
procedure to achieve the objectives. Designing and implementing systems to suit organizational needs are the
functions of the systems analyst. He plays a major role in seeing business benefits from computer technology.
The analyst is a person with unique skills. He uses these skills to coordinate the efforts of different type of
persons in an organization to achieve business goals.

2.3.2 What does a Systems Analyst do?

A system analyst carries out the following job:
(a) The first and perhaps most difficult task of systems analyst is problem definition. Business problems are
quite difficult to define. It is also true that problems cannot be solved until they are precisely and clearly
defined.
(b) Initially a systems analyst does not know how to solve a specific problem. He must consult with
managers, users and other data processing professionals in defining problems and developing solutions.
He uses various methods for data gathering to get the correct solution of a problem.
(c) Having gathered the data relating to a problem, the systems analyst analyses them and thinks of plan to
solve it. He may not come up personally with the best way of solving a problem but pulls together other
people's ideas and refines them until a workable solution is achieved.
(d) Systems analysts coordinate the process of developing solutions. Since many problems have number of
solutions, the systems analyst must evaluate the merit of such proposed solution before recommending
one to the management.
(e) Systems analysts are often referred to as planners. A key part of the systems analyst's job is to develop a
plan to meet the management objectives.
(f) When the plan has been accepted. systems analyst is responsible for designing it so that management's
goal could be achieved. Systems design is a time consuming, complex and precise task.
(g) Systems must be thoroughly tested. The systems analyst often coordinates the testing procedures and
helps in deciding whether or not the new system is meeting standards established in the planning phase.

2.3.3 Attributes of an Effective Systems Analyst

Systems analyst must have the following attributes:

(a) Knowledge of people

Since a systems analyst works with others so closely, he or she must understand their needs and what motivates
them to develop systems properly.
(b) Knowledge of Business functions
A systems analyst must know the environment in which he or she works. He must be aware of the peculiarities
of management and the users at his installation and realize how they react to systems analyst. A working
knowledge of accounting and marketing principles is a must since so many systems are built around these two
areas. He must be familiar with his company's product and services and
management's policies in areas concerning him.

(c) Knowledge of Data processing principles

16
Most systems today are computer-based. The systems analyst must be fully aware of the potential and
limitations of computers.

(d) Ability to communicate

As a coordinator, a systems analyst must communicate properly with people of different levels within an
organization. Systems analyst must listen carefully to what others say and integrate the thoughts of others into
the systems development process.

(e) Flexibility
Systems analysts must be flexible in their thinking since they often do not get their own way. Different factions
in an organization have conflicting needs and most systems are the result of compromise. The analysts' goal is
to produce the system that will be the best for his organization. This requires an open mind and flexibility in his
ideas.

(f) An analytical mind

It takes an unusual person to see through problems facing an organization and develop solutions that will work.
Systems analysts often find themselves with more data than they can cope with. It requires an analytical mind to
select pertinent data and concentrate on them in defining problems and forming solutions.

(g) Well educated with sharp mind

Systems analysts are called upon to work with people at all levels virtually in every aspect of business.
They must know how to work with all of them and gain their confidence. Analysts must have sharp mind to
learn quickly how people do their jobs and develop ways for them to do it better.

2.4 Software Development Project Roles and Responsibilities

Software projects are difficult and they all take careful planning, a talented development team and collaboration
of a project's team members, both internally within the company and externally with the software development
company. Software projects can only move forward when the key stakeholders are all in place. One of the keys
to a successful software project is identifying and documenting this software project roles and responsibilities
for a project.
Among the key stakeholders of a software project are the following eight key roles in software development and
their corresponding responsibilities.

1. Project Sponsor
Project Sponsors play a critical role in all projects, they have the bandwidth to take on the Project Sponsor role,
their day job and no other project role, therefore Project Sponsors are not Project Managers, Serum Masters or
Product Owners. The Project Sponsor is the person or group that provides direction and resources, including
financial resources for the software project. The Project Sponsor works with the project management team,
aiding with wider project matters such as scope clarification, progress, monitoring, and influencing others in
order to benefit the software project.
The Project Sponsor leads the project through the software supplier selection process until it is formally
authorised. For issues that are beyond the control of the Product Owner, the Project Sponsor serves as an
17
escalation path. The Project Sponsor may also be involved in other important issues such as authorising changes
in scope, phase-end reviews, and go/no-go decisions when the stakes of the project are particularly high.
Sponsors of projects tend to be senior management or director level executives.
2. Subject Matter Experts (SME)
A Subject Matter Expert (SME) or Domain Expert is a person who is an authority in a particular area or topic. A
Subject Matter Expert has superior (expert) knowledge of a discipline, technology, product, business process or
entire business area. The SME role and responsibilities in software development could be summarised as
follows:
i. they are normally the people from whom technical requirements are captured.
Subject Matter Experts are the accountants, finance controllers, salespeople, production managers and so on
who roll up their sleeves each day. They know their roles inside and out and are rarely technical.
However, their lack of technical knowledge is their strength, as they are not bogged down in technicalities and
instead are purely focused on business outcomes.
It is imperative that discussions are held with Subject Matter Experts at the same time as the software
product vision statement is being created. Feedback from this group of experts can save a lot of back and forth
down the line. However, given that Subject Matter Experts tend not to be technical, the right amount and type of
engagement are necessary so as not to overwhelm them. One of the ways to get them involved is to have them
contribute to the creation of early-stage wireframes and prototypes.

3. Product Owner
Product Owner is a software development role for a person who represents the business or end-users and is
responsible for working with the user group to determine what features will be in the product release. The
Product Owner is also responsible for the prioritised backlog and maximising the return on investment (ROI) of
the software project. Part of this role's/responsibility includes; documenting user stories or requirements for the
software project.
They act as the main point of contact for all decisions concerning the project and as such, need to be
empowered to perform their responsibilities without the need to seek too much prior authorisation from the
Project Sponsors. Appointing the right person to this role, with the appropriate delegated authority to progress
the project, is fundamental to the success of the project, especially if an agile methodology approach is
undertaken.
In particular, the Product Owner is responsible for:

i. ensuring that the software product vision statement is adhered to

ii. making the final decision on all scope related decisions
iii. maintaining and updating the product backlog on a continuous basis by

 refining new requirements

 removing requirements that fall out of scope
 adding new requirements identified as being required to achieve the software product vision statement
 reviewing and setting the priorities assigned to the product backlog and heading up all project planning
meetings

iv. resolving any disputes either with the software development team or internally

18
 Failure to have a Product Owner in place usually means that the software project will execute in fits and
starts whilst the software developers are on hold waiting for crucial feedback. A slowdown in the
momentum of a software project can have long-term consequences, not least of missed milestones and
deadlines.

4. Project Manager (PM)

The Project Manager (PM) is responsible for knowing the "who, what, where, when and why" of the software
project. This means knowing the stakeholders of the project and being able to effectively communicate with
each of them. The Project Manager is also responsible for creating and managing the project budget and
schedule as well as processes including scope management, issues management and risk management. Some of
the Project Manager duties can include:
i. developing a software project plan
ii. managing deliverables according to the software project plan
iii. recruiting software project staff
iv. leading and managing the software project team
v. determining the methodology used on the project
vi. establishing a project schedule and determining each phase
vii assigning tasks to project team members
viii. providing regular updates to senior management

It does not matter if you are using an agile methodology or the waterfall method, once deliverables are defined,
it is critical that the Project Manager starts to actively exercise change management. Change should not be
perceived as negative or something to be avoided. Change is inevitable and is acceptable in a software project
as long as it is managed. The impact of any change needs to be assessed, measured and communicated. The
major factors are typically timeline and budget. If the impact is deemed acceptable by the Project Sponsor, then
the change can be incorporated.
The Project Manager also oversees software testing, delivery and formal acceptance by the customer.
Then the Project Manager performs a project review with the software development team to document any
lessons learned from the software development process.

5. Technical Lead
The Technical Lead translates the business requirements into a technical solution. Because of this:
responsibility, it is beneficial to have the Technical Lead involved in the planning phase to hear the business
requirements from the customer's point of view and ask questions. The Technical Lead is the development team
leader and works with the developers to provide technical details and estimates for the proposed solution. This
information is used by the Project Manager to create the Statement of Work and the Work Breakdown Structure
documents for the software project. It is critical that the Technical Lead can effectively communicate the status
of the software project to the Project Manager so that issues or variances can be effectively addressed as soon as
possible.
The Technical Lead is also responsible for establishing and enforcing standards and practices with the software
development team.

6. Software Developers

19
The Software Developers (front-end and back-end) are responsible for using the technical requirements from
the Technical Lead to create cost and timeline estimates. The Software Developers are also responsible for
building the deliverables and communicating the status of the software project to the Technical Lead or Project
Manager. It is critical that the other team members effectively communicate the technical requirements to the
Software Developers to reduce project risk and provide the software project with the greatest chance of success.

7. Software Testers
The Software Testers ensure that the software solution meets the business requirements and that it is free of
bugs, errors and defects, in the test planning and preparation phases of the software testing, software testers
should review and contribute to test plans, as well as be analysing, reviewing and assessing technical
requirements and design specifications. Software Testers are involved in identifying test conditions and creating
test designs, test cases, test procedure specifications and test data, and may automate or help to automate the
tests.
Some of the software testers duties can include:
i. they often set up the test environments or assist system administration and network management staff in
doing so
ii. As test execution begins, the number of testers often increases, starting with the work required to
implement tests in the test environment
iii. Testers execute and log the tests, evaluate the results and document problems found
iv. They monitor the testing and the test environment, often using tools for this task, and often gather
performance metrics
v. Throughout the software testing life cycle, they review each other's work, including test specifications,
defect reports and test results

8. User Acceptance Testers

A software solution provider should carry out a wide array of software testing to ensure that the new software
solution meets various quality assurance (QA) criteria. From that, representatives of a company will need to
perform the final checks to ensure that the software works for the business across a number of real-world
scenarios. User Acceptance Testing (UAT) is the final step prior to a new software solution being released to
production (live). It is absolutely essential that you have the resources to tackle user acceptance testing in a
timely and organised fashion, as it is often UAT that creates the bottleneck between the software solution being
completed and released to the business. It is an excellent idea to ensure that those employees participating in
UAT are brought in from the start, and understand, or perhaps better still contribute to, the design of the new
software solution.
Finally, it is important that a software solution provider has the necessary resources in place to operate a
project, it is equally as important that the customer understand the roles and responsibilities required within his
team to bring his project to successful completion. The key to project success is clear and effective
communication. A critical portion of this communication is identifying the stakeholders and their roles.
Whatever labels you apply to the software project roles above, clear communication of expectations and status
to the stakeholders throughout the life of the software project will increase the chances of your project's success.
2.5 System Investigation
Serious problems in operations, a high rate of labor turnover, labor intensive activities, and high reject rates of
finished goods can prompt top management to initiate an investigation. Other reasons can be:
20
• A report reaches a senior vice president and she suspects the figures.
• The company comptroller reads an IRS audit report and starts thinking.
• An executive read about decision support systems for sales forecasting and it gives him an idea
Many of these ideas lead to further studies by management request, often funneled downward and. carried out
by lower management.

User- originated ideas also prompt initial investigations. For example, a bank's head teller has been noticing
long customer lines in the lobby. She wants to know whether they are due to the computer’s slow response to
inquiries, the new teller's limited training or just a sudden increase in bank business.
To what extent and how quickly a user- originated idea is converted to a feasibility study depend on several
factors:
 The risks and potential returns.
 Management's bias toward the user.
 Financial costs, and the funds, available for system work.
 Priorities of other projects in the firm.
 The persuasive ability of the user.

2.5.1 People involved in Systems Investigation

The people involved in system investigation are;
• Systems Analysts - all types.
• Computer Systems Managers - in the areas of Data entry, Hardware selection, Database Administration,
Operations and Project Management.
• Users - all types.
• Systems Consultants - people with specialist expertise, e.g. a particular business activity or database selection.
Internal Auditors - to ensure adequate internal controls and that the systems output can be audited
Managers of the organisation - facilitating the required resource allocations and formally accepting the
developed systems.
2.6 Software Crisis
The translation of a familiarity with computer hardware and software into the development of useful
commercial or business information systems is not a straight-forward or intuitive task. For the last several
decades, tens of thousands of people, usually very intelligent and talented have been involved in the building of
computer systems. It is now well-known that the rate at which the hardware has been more and more accessible
and at lower and lower prices, has created a matching demand for development of software in a similar scale.
But the traditional intuitive and ad-hoc approach fails miserably when the quantities of data involved in
information systems exceeds say, 10 MB. This is a typical figure at which systems start crossing the barriers of
relatively simple and begin to enter 'he domain of significant complexity.
This has lead to the coining of the phrase "software crisis", and the search for methods and techniques to
be able to cope with the ever expanding demands for software. The present course, which is an attempt to teach
the ingredients of a structured systems development methodology, and elsewhere in the programme there is a
reference to the techniques of software engineering as well.

21
 It is useful and desirable to have some feel for the kinds of problems which the programmer and the user
face and collectively perceive as the software crisis.
Software crisis can be broadly classified in the following major areas:

2.6.1 From Programmer's Point of View

The following types of problems may contribute in maximum cases to software crisis:
 Problem of compatibility
 Problem of portability
 Problem of documentation
 Problem in coordination of work of different people where a team is initialling to develop software.
 Problems that arise during actual run time in the organization. Some time the errors are not detected
during sample run.
 Problem of piracy of software
 Customers normally expand their specifications after program design and implementation has taken place.
 Problem of maintenance in proper manner.

2.6.2 From User's Point of View

There are many sources of problems that arise out of the user's end. Some of these are as follows:
 How to choose software from total market availability.
 How to ensure which software is compatible with his hardware specifications
 The customerised software generally does not meet his total requirements
 Problem of virus
 Problem of software bugs, which comes to knowledge of customer after considerable data entry.
 Certain software run only on specific operating system environment
 The problem of compatibility for user may be because of different size and density of floppy diskettes.
 Problem in learning all the facilities provided by the software companies gives only selective
information in manual.
 Certain software run and creates files which expand their used memory spaces and create problem of
disk management.
 Software crisis develops when system memory requirement of software is more than the existing
requirements and/or availability.
 Problem of different versions of software (user as well as operating system).
 Security problem for protected data in software.

Questions
1. Who are the people involved in Systems analysis and Design?
2. What is System Investigation and who are the people involved in system investigation?
3. What do you understand by software crisis?

22
4. Suppose a system memory requirement is more than the available memory size. Will you call it a software
problem although the crisis is with the hardware? Why?
5. Which is in your opinion the most difficult job of a systems analyst?
6. List three important attributes of a system analyst.

CHAPTER THREE
SYSTEMS DEVELOPMENT PROCESS
3.1 Systems Development Life Cycle (SDLC)
This is a structured, step-by-step approach to the development of complex systems. It is ar. organisational
process of developing and maintaining systems. It helps in establishing a system project plan, because it gives
overall list of processes and sub-processes required in developing a system.
System development, a process consisting of the two major steps of systems analysis and design, it starts
when management or sometimes system development personnel feel that a new system or an improvement in
the existing system is required. The systems development life cycle is classically thought of as the set of
activities that analysts, designers and users carry out to develop and implement an information system. The
systems development life cycle consists of the following phases:
3.1.1 Objections to the life cycle model
A major criticism of the life cycle model is the time-scale associated with its linear progression of activities. The
gap between specification and delivery is often so long that requirements change dramatically in time. This
leads to the delivery of systems that "were required two years ago".
3.1.2 Methodologies for Systems Development
There are many methodologies for the development of information systems: Systems Development Life Cycle
(SDLC). Data Structure-Oriented design, Object-Oriented design, Prototyping, among others. We shall,
however be concerned here primarily with SDLC.
System development should follow three general guidelines; namely:
Use phases comprises of as the software development life cycle
Involve users throughout the entire system development process. Users include anyone for whom the system is
been built. If the system is to be successful, the user accepts a new system easily, if they contribute to its design.
Develop standards. Standards are set of rules and procedures a company expects employees to accept and
follow. If the SDLC has standards defined, then everyone involved uses one term.

Figure 3.1 shows the phases of the SDLC.

23
 System
Study Phase

Feasibility
Study Phase

System
Analysis

System Design

System
Development
Phase

System
Implementation
and Evaluation

Figure 3.1: System Development life cycle

3.2 Phases of Systems Development Life Cycle
The methodology SDLC is closely linked to what has come to be known as structured systems analysis &
design. It involves a series of steps to be undertaken in the development of information systems as follows:
 System study phase
 Feasibility study phase
 System analysis phase
 System design phase
 System development phase and
 System implementation and evaluation phase

3.2.1 System Study

24
This is the first stage of the system development life cycle. It gives a clear picture of what the physical system
is. The system study is done in two phases:
i. In the first phase, the preliminary survey of the system is done which helps in identifying the scope of
the system.
ii. The second phase of the system study is a more detailed and in-depth study in which the identification
of user's requirements and the limitations and problems of the present system are studied.
The next stage after the system study is the preparation of system proposal by a Systems Analyst, this proposal
is placed before the user. In the proposed system, we have the findings of the present system and
recommendations to overcome the limitations and problems of the present system in the light of the user's
requirements. The new systems requirements are defined, in particular, the deficiencies in the existing system
must be addressed with specific proposals for improvement.
Major activities in system study phase are:
1. Define the problem
2. Produce the project schedule
3. Confirm project feasibility
4. Staff the project
5. Launch the project

Problem Identification

During this phase, a feasibility study is conducted, here terms of reference laid down by management, is usually
conducted. The terms of reference (ToR) must include:

• A statement of areas to be included in the study

• Objective of the study
• The man-days allocated for the study
• The date by which the report should be produced
• Any comments relevant to the study
• Date and author
The ToR should be approved by the manager and a copy circulated to all management personnel who have
responsibility for an area included in the study. This serves to introduce the systems analyst and the reason for
the study.

Project Planning
As a project manager, it is important to create a project plan which allows you to focus on those things that are
most important in the organisation. It has:
i. Non routine tasks,
ii. Distinct start/finish dates, and
iii. Resource constraints (time, money, people, equipment), that result in a distinct product.
In general a systems analysts needs to be SMART when planning. A plan should be; specific, measurable,
achievable, realistic and time bound.

25
During project planning, the systems analyst needs to identify:
• The activities that make up the project
• The order in which these activities must be done
• The timing of each activity
• The resources needed at each stage

3.2.2 Feasibility Study Phase

A feasibility study, also known as feasibility analysis, is an analysis of the viability of an idea. It describes a
preliminary study undertaken to determine and document a project's viability. The results of this analysis are
used in making the decision whether to proceed with the project or not. This analytical tool used during the
project planning phase shows how a business would operate under a set of assumption, such as the technology
used, the facilities and equipment, the capital needs, and other financial aspects.

The feasibility study is basically the test of the proposed system in the light of its workability. meeting user's
requirements, effective use of resources and of course, the cost effectiveness. The main goal of feasibility study
is not to solve the problem but to achieve the scope. It involves a short period of observation and interviews
during which the analysts conducts a rapid investigation and makes series of value judgements on the possible
scale of the system requirements and what it would do. During this study, the cost and benefits are estimated
with greater accuracy. Important views and opinions as well as "facts" are identified during this phase.

Types of Feasibility
The systems analyst has four distinct but inter-related types of feasibility to consider;
a. Organizational feasibility
b. Economic feasibility
c. Technical feasibility
d. Operational feasibility
(a) Organizational feasibility: the extent to which a proposed information system supports the objective of
the organization's strategic plan for information systems determines the organizational feasibility of the
project.
(b) Economic feasibility (Cost Justification): In this study, costs and returns are evaluated to know
whether returns justify the investment in the system project. The purpose of cost benefit analysis is to
measure the costs associated with the development of the new system and compare this to the benefits.
Tangible costs/benefits refer to items which can be measured in monetary terms whereas it is difficult to
put monetary value upon intangible costs/benefits.
(c) Technical feasibility is concerned with specifying equipment and software that will successfully
support the tasks required. It takes into consideration if reliable hardware and software, capable of
meeting the needs of the proposed system can be acquired or developed by the organizations in the
required time. The technical needs of systems vary but they include;
• The facility to produce outputs in a given time scale
• The ability to provide certain response times under certain conditions
• The facility to input a large number of documents in a limited time scale
• The ability to process a certain volume of transactions at a certain speed
• The facility to communicate data to different locations
26
(d) Operational feasibility: it involves the willingness and ability of the management, employees,
customers, suppliers, etc. to operate, use and support a proposed system. In other words, the test of
operational feasibility asks if the system will work when it is developed and installed. e.g. it analyzes the
inside operations on how a deemed process will work, be implemented, and how to deal with change
resistance and acceptance. Among issues examined are;
• What job changes will the system bring?

• What organizational structures are involved?

• What new skills will be required?
• Do the current employees possess these skills?
• If not, can they learn them?
• How long will it take to learn?

Feasibility Report
The output from feasibility study is the feasibility report and it may be the basis upon which a project may (or
may not) be initiated. It is a document that assesses potential solutions to the business problem or opportunity,
and determines which of these are viable for further analysis. The purpose of feasibility report is to present the
project parameters and define the potential solutions to the defined problem, need, or opportunity.
Primary issues organizations should consider when compiling feasibility reports include:
a. Business considerations
b. Functional requirements
c. Cost/benefit analysis

3.2.3 System Analysis Phase

It is the focus of system development and is the stage when system designers have to work at two levels of
definition regarding the study of situational issues and possible solutions in terms of "what to-do" and "how to
do".
The goal of system analysis is to determine where the problem is, in an attempt to fix the system. This step
involves breaking down the system in different pieces to analyze the situation, analyzing project goals, breaking
down what needs to be created and attempting to engage users so that definite requirements can be defined.
Systems analysis is the most general form and it includes the following activities:
a. gather information
b. define the new system's requirements
c. build prototypes for the news system
d. prioritize requirements
e. evaluate alternatives
f. meet with management to discuss new options

Goals of System Analysis

The overall goal of System Analysis is to study procedural components and modules. The goal of System
Design is to design whole software, which fulfils all the requirements of customer. This leads to improve
organizational systems, by applying software, which helps employees to perform business, tasks more
effectively. Example: 'Banking'- Earlier days all the processes of banks used to be done manually or through
paper work which was time-consuming. While nowadays with the help of new technology and proper analysis
and design, everyone can do banking transactions easily and faster.
27
Investigation and Fact Finding
The systems analyst needs a statement from his organization known as Terms of Reference before n can start
investigation. The ToR sets out the:
• Objective of the investigation
• Boundaries

• Allowable expenditure and other resources available

• Time by which the investigation should be completed
• Fact Finding

Fact finding is process of collection of data and information based on techniques which contain sampling of
existing documents, research, observation, questionnaires, interviews, prototyping and joint requirements
planning. System analyst uses suitable fact-finding techniques to develop and implement the current existing
system. Collecting required facts are very important to apply tools in System Development Life Cycle because
tools cannot be used efficiently and effectively without proper extracting from facts. Fact-finding techniques are
used in the early stage of System Development Life Cycle including system analysis phase, design and post
implementation review. Facts included in any information system can be tested based on three steps: data- facts
used to create useful information, process- functions to perform the objectives and interface- designs to interact
with users.

Some techniques that can be used to determine requirements are discussed below:
Requirement techniques
• Document review
• Observation of the work environment
• Interviews
• Questionnaires
• Research and Site visits
• Rapid Application Development (RAD)
• Joint Application Development (JAD)
• Prototyping

Document review
The first document the analyst should seek out is the organisations chart, the history of the project should be
traced by collecting and reviewing documents that describe the problem.

Observation of the work environment

This is one of the most effective data-collection techniques for obtaining and understanding of a system.
It is a fact-finding technique wherein the systems analysts either participates in or watches a person perform
activities to learn about the system.

Interviews
Interviews are formal meetings where the analyst can obtain information about the operations of the present
system and requirement of any planned replacements. Successful interviewing is a skill that can be developed
through practice. The purpose of the interview will determine the balance of the discussion.

Types of Interviews
28
• Informal, conversational interview
• General interview guide approach
• Standardized, open-ended interview
• Closed, fixed-response interview

Advantages of Interview
i. It gives the analyst the opportunity to motivate the interviewee to respond freely and openly to questions
ii. Interviews allow the systems analyst to probe for more feedback from the interviewee
iii. Interviews give the analyst an opportunity to observe the interviewee's non verbal communication.

Disadvantages of Interview
і. It is time-consuming and an expensive fact-finding approach
ii. Success of interviews is highly dependent on the systems analyst's human relation skills.

Questionnaires
Questionnaires may be considered when it is impossible due to time constraint, distance or cost to interview all
the desired peopled involved in a system. It is a more structured and formal method of collecting data, but may
be the only viable option where there are a large number of dispersed users.

Problems associated with questionnaires

• Designing them so that they may be completed easily and accurately.
• Getting them filled in sufficient number makes the effort worthwhile
• Results depend entirely on the interpretation of the recipient
• Answers may be inaccurate, careless or indeed deliberately misleading
• Follow up questions are precluded. It is not possible to ask follow-up questions unlike the interview
method.

Research and Site visits

Research site visits involve exploring the internet and World Wide Web (www) via personal computers to
search for information. It can also involve going through computer journals and reference books.

Rapid Application Development (RAD)

It's a fact-finding technique for discovering user requirements. The technique allows systems analyst to quickly
create mock forms and tables to simulate the implemented system. Users can suggest changes to the prototype
real-time, The process may take several iterations to correctly capture the function necessary to automate the
required business process. After completion, a user's manual, requirement specification, and a template for test
plan is produced. RAD has shown an excellent technique in discovering and documenting the system data and
processes.

29
Joint Application Development (JAD)
This is an alternative to the one-to-one interview. A JAD session is a lengthy, structured, group worl meeting in
which users and IT professionals discuss an aspect of the project. The goal of JAD session: is to obtain group
agreement on an issue. E.g. the participants of the project try to identify problems associated with an existing
system.

Prototyping
Prototype: "an original or model on which something is patterned" and/or "a first full scale". Prototyping
Stresses the early delivery of an incomplete but working system and the use of prototypes may be valuable at
various stages of the life cycle.
Users have to specify their requirements in advance (unclear to a user how a system may help him,
either because the role of the computer is not understood, or because the information needed are unclear).
Difficult for most users to clearly envisage what they want and how they can use it until they are able to
experiment with a tangible system. So, a simple prototype designed to accommodate broad needs, together with
possibilities suggested by the designer using experience gained in other projects may be used to define
requirements more accurately.

Prototype: It is a live working system not just a paper based. Users can test its operation and explore its
facilities and so do not have to rely upon written descriptions. It is an iterative process.

3.2.4 System Design Phase

Based on the user requirements and the detailed analysis of a new system, the new system must be designed.
This is the phase of system design. It is a most crucial phase in the development of a system.
The design proceeds in two stages:
• Preliminary or general design
• Structure or detailed design
In the Preliminary or general design, the features of the new system are specified. The costs of implementing
these features and the benefits to be derived are estimated. While in the Structure or Detailed design stage,
computer oriented work begins in earnest. At this stage, the design of the system becomes more structured.
Structured design is a blue print of a computer system solution to a given problem having the same components
and inter-relationship among the same components as the original problem.

3.2.5 Systems Development Phase

In this phase, once the final go ahead has been given by management, the actual development of the proposed
system begins. This phase begins with the design specifications and ends when the system is ready for
installation. Four activities are carried out during this phase; scheduling, programming, testing and
documentation.
Scheduling: A time table is prepared to ensure that the system will be ready by a given date.
Programming: The system design specifications has to be properly prepared before talking of programming.
This is because coding can be the easiest and least time consuming part of program development. If
programming begins using incomplete or inadequate design specifications, the end. product is likely to be a
system that neither meets user needs nor fulfils management expectation.

30
Testing: Here, the system is put into use. This can be done in various ways. The new system can phase in,
according to application, location, and the old system gradually replaced. In some cases, it may be more cost-
effective to shut down the old system and implement the new system all at once
Documentation: These can be in form of reports to management, analysis and design aids, specifications and
charts. Documentation is an ongoing activity throughout the program development process. In addition to
compiling documentation that describe the data and logic of the programs a systems analyst must also arrange
for the preparation of a comprehensive user manual.

3.2.6 Implementation and Evaluation Phases

After the development phase is over, the system project is not complete. The new system must be implemented,
or installed, in the organization, and its operation must be evaluated to ensure that it fulfills its design
specification. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
Evaluation gives users another chance to provide constructive feedback.
This phase includes several activities that are necessary to make the new system successfully and fully
functional.

Questions
1. What is System Development Life Cycle (SDLC)?
2. What are the phases of SDLC?
3. Discuss the various types of feasibility.
4. What is a feasibility report?
5. What is prototyping

31
 CHAPTER FOUR
SYSTEMS DESIGN
The purpose of systems design is to document exactly how a new system should work. In essence, this means
preparing a detailed set of specifications for the new system. The design must address the following aspects of
the proposed system, usually in this order:

4.1 Input requirements

This comes after specification of the output requirement. The analysts must determine what inputs are necessary
for the system to produce them.
System design takes the following inputs-
• Statement of work
• Requirement determination plan
• Current situation analysis
• Proposed system requirements including a conceptual data model, modified DFDs, Metadata (data about
data).

4.2 Output requirements

Specifies what must be produced, i.e. what mainly interests the users and mangers
System design gives the following outputs-
• Infrastructure and organizational changes for the proposed system
• A data schema, often a relational schema
• Metadata to define the tables/files and columns/data-items
• A function hierarchy diagram or web page map that graphically describes the program structure
• Actual or pseudocode for each module in the program
• A prototype for proposed system
File and storage requirements: this include the sizes, contents, organization, media, devices formats, access
restrictions, and locations for all files the system will use. It's the duty of the system analyst to describe the data
storage needs of the new system in detail.
Processing: it involves the use of data flow diagrams and the program design aids to document fully the
operation of the new system. Consideration of any special software to aid process should also be done by the
analyst.
Control and backups: system controls are instituted to make sure that data are input, processed and output
correctly and to prevent data destruction, unauthorized program modifications; fraud, or any other tampering
that might occur.
Personnel and procedures: What personnel, (operators, programmers, specialists etc.) will be needed to run
the system? What procedures will these people have to follow?
32
4.3 Types of System Design
i. Logical Design: Logical design pertains to an abstract representation of the data flow, inputs, and
outputs of the system. It describes the inputs (sources), outputs (destinations), databases (data stores),
procedures (data flows) all in a format that meets the user requirements.
While preparing the logical design of a system, the system analyst specifies the user needs at level of
detail that virtually determines the information flow into and out of the system and the required data
sources. Data flow diagram, E-R diagram modelling are used.

ii. Physical Design: Physical design relates to the actual input and output processes of the system.
It focuses on how data is entered into a system, verified, processed, and displayed as output. It produces
the working system by defining the design specification that specifies exactly what the candidate system
does. It is concerned with user interface design, process design and data design.
Physical design consists of the following steps-
Specifying the input/output media, designing the database and specifying backup procedures.
Planning system implementation
Devising a test and implementation plan, and specifying any new hardware and software, updating costs,
benefits, conversion dates, and system constraints
iii. Architectural Design: It is also known as high level design that focuses on the design of system
architecture. It describes the structure and behavior of the system. It defines the structure and
relationship between various modules of system development process.
iv. Detailed Design: It follows Architectural design and focuses on development of each module

4.4 Conceptual Data Modeling

It is a representation of organizational data which includes all the major entities and relationship. System
analysts develop a conceptual data model for the current system that supports the scope and requirements for
the proposed system.
The main aim of conceptual data modeling is to capture as much meaning of data as possible. Most organization
today use conceptual data modeling using E-R model which uses special notation to represent as much meaning
about data as possible.

4.4.1 Entity Relationship Model

It is a technique used in database design that helps describe the relationship between various entities of an
organization.
Terms used in E-R model
i. Entity: It specifies distinct real world items in an application. For example: vendor, item, student,
course, teachers, etc.
ii. Relationship: They are the meaningful dependencies between entities. For example, vendor supplies
items, teacher teaches courses, then supplies and course are relationship.
iii. Attributes: It specifies the properties of relationships. For example, vendor code, student name.

Table 4.1 shows the symbols used in E-R model and their significance

33
Table 4.1 E-R model and its significance

Symbol Meaning

Entity

Weak Entity

Relationship

Identity Relationship

Attributes

Key Attributes

34
 Multivalued

Composite Attribute

Derived Attributes

E1 R E2 Total Participation of
E2 in R

Cardinality Ratio 1:N

R
E1 E2 For E1:E2 IN R

4.4.2 Connectivity and cardinalities

The connectivity of a relationship describes the mapping of associated entity instances in the relationship. The
values of connectivity are "one" or "many". Three types of relationship exist between two sets of data: one-to-
one, one-to-many, and many-to-many.
i. One to one: a one-to-one relationship is when at most one stance of an entity A is associated with one
instance of entity B. For example, "employees in the company are each assigned their own office. For
each employee there exists a unique office and for each office there exists a unique employee.
ii. One to many: a one-to-many relationships is when for one instance of entity A, there are zero, one, or
many instances of entity B, but for one instance of entity B, there is only one instance of entity A. An
example of a one-to-many relationship is
- a department has many employees
- each employee is assigned to one department
iii. Many to many: a many-to-many relationship, sometimes called non-specific, is when for cne instance
of entity A, there are zero, one, or many instances of entity B and for one instance c entity B there are zero, one,
or many instances of entity A. An example is:
- employees can be assigned to no more than two projects at the same time;
35
 - projects must have assigned at least three employees

4.5 File Organization

File organization describes how records are stored within a file. There are four file organization methods-
i. Serial: In serial organization, records are stored in chronological order (in order as they are input or
occur). Examples are: Recording of telephone charges, ATM transactions, Telephone queues.
ii. Sequential: Here, records are stored in order based on a key field which contains a value that
uniquely identifies a record. An example is the Phone directory.
iii. Direct (relative): Each record is stored based on a physical address or location on the device.
Address is calculated from the value stored in the record's key field. Randomizing routine or hashing
algorithm does the conversion.
iv. Indexed: Records can be processed both sequentially and non-sequentially using indexes.

Table 4.2: Methods of File organization

Serial Sequential Direct Index
Type of Access Batch Batch Online Batch or Online
Data Serial Sequentially or No particular Sequentially and
Organization Key value Order by index
Flexibility in No No Yes Yes
handling
inquiries
Availability of No No Yes Yes
up to date Data
Speed Retrieval Slow Slow Very Fast Fast
Activity High High Low High
Volatility Low Low High High
Example ATM Payroll process Online Customer
Transaction script billing Reservation and ordering and
Queue operation Banking billing
system

4.5.1 File Access

A file can be accessed using either Sequential Access or Random Access. File Access methods allow computer
programs read or write records in a file.

36
i. Sequential Access: Every record on the file is processed starting with the first record until End of File
(EOF) is reached. It is efficient when a large number of the records on the file need to be accessed at any
given time. Data stored on a tape (sequential access) can be assessed only sequentially.
ii. Direct (Random) Access: Records are located by knowing their physical locations or addresses on the
device rather than their positions relative to other records. Data stored on a CD device (direct-access)
can be accessed either sequentially or randomly.

4.5.2 Types of Files used in an Organization System

Master file: It contains the current information for a system. For example, customer file, student file telephone
directory.
Table file: This is a type of master file that changes infrequently and it is stored in a tabular format.
For example, storing Zipcode.
Transaction file: It contains the day-to-day information generated from business activities. It is used to update
or process the master file. For example, Addresses of the employees.
Temporary file: It is created and used whenever needed by a system.
Mirror file: They are the exact duplicates of other files. Help minimize the risk of downtime in cases when the
original becomes unusable. They must be modified each time the original file is changed.
Log files: They contain copies of master and transaction records in order to chronicle any changes that are made
to the master file. It facilitates auditing and provides mechanism for recovery in case of system failure.
Archive files: Backup files that contain historical versions of other files.

Questions
1. What are the input/output requirements for a new system?
2. What is file organization
3. Discuss the various methods for file organization

37
 CHAPTER FIVE
SYSTEMS IMPLEMENTATION
5.1 System Conversion and Implementation
During system conversion and implementation phase of the system development process, the following
results are realized:
System and acceptance test
System conversion
Each of this result defines an activity that is to take place.

5.1.1 System and acceptance test

This testing has to do with everything that makes up the information system — the hardware, the software, the
end users. the procedure (e.g. user manuals), and the data. If need be, the interfaces between the system and
other systems are tested as well.
Testing with Test Data
Typing with Life Data
User-Acceptance Testing

5.1.2 File conversion

Computerized systems will usually require input data to be in some machine-readable form. This means that
data previously handled manually must be entered into the computer system and stored in files. Data entry
personnel may be temporarily employed if a large quantity of data must be keyed into the system initially. If the
previous system was computerized, a new system may still require that files be modified to accommodate
changes in the way in which data are stored or retrieved. Before a new system can be operational, the files it
will use must be in formats that will be compatible with its programs.

Steps in file conversion

1. encode and verify data;
2. validate data with computer software;
3. investigate, correct and re-code all errors;
4. produce listing of all accepted data and check this on a one-for-one basis with inputs
5. produce reconciliations to reconcile data totals to existing system.

Train users

38
Users must be trained and provided with users manuals (documentation) before converting to a new system, this
manuals will guide them in using the new system.
5.1.3 Approaches to System Conversion
Conversion means switch on to a new system from an existing system. An organization's approach to system
conversion depends on its willingness to accept risk and the amount of time available for the conversion. The
way in which the changeover to the new system is planned and accomplished can have a major effect upon the
system performance and acceptance by its users.
There are four methods of handling a systems conversion. Each method should be considered in light of the
opportunities that it offers and problems that it may cause. However, some situations dictate the use of one
method over others, even though other methods may be more beneficial. In general, systems conversion should
be accomplished as quickly as possible.
Long conversion periods increase the possible frustration and difficulty of the task for all persons involved,
including both analysts and users.

Conversion strategies are as follows;

1. direct conversion
2. parallel conversion
3. phased conversion
4. pilot conversion
Direct Conversion
The direct cutover method converts from the old to the new system abruptly, sometimes over a weekend or even
overnight. The old system is used until a planned conversion day, when it is replaced by the new system. There
are no parallel activities. If the analyst must make the change and wants to ensure that the new system fully
replaces the old one so that users do not rely on the previous methods, direct cutover will accomplish this goal.
Psychologically, it forces all users to make the new system work; they do not have any other method to fall back
on. The advantage of not having a fallback system can turn into a disadvantage if serious problems arise with
the new system. In some instances, organizations even stop operations when problems arise so that difficulties
can be corrected.
Direct cutover require careful planning. Training sessions must be scheduled and maintained. The installation
of all equipment must be on time, with ample days allowed in the schedule to correct an difficulties that occur.
Any site preparation must be completed before the conversion can be done.
Table 5.1: Methods of Systems Conversion
Method Description Advantages Disadvantages
Direct The old system Forces users to make the There is no other
conversion replaced by the new new system work. There system to fall back on
one. The organization are immediate benefits if difficulties arise
relies fully on the from new methods and with the new system.
new system. controls. Requires the most
careful planning.
Parallel The old system is operated Offers greatest security. Doubles operating
Conversion along with the new system The old system can take cost.
over if errors are found The new system may
in the new system or if not get fair trial.
usage problems occur.
Phase-in Gradually implement Allows some users to A long phase – in
Conversion system across all users. take advantage of the causes user problems

39
 system early. whether the project
Allows training and goes well (over
installation without enthusiasm) or not
unnecessary use of (resistance and lack of
resources fair trial).
Pilot Working version of system
conversion implemented in one part of the
organization. Based on
feedback, changes are made
and the system is installed in
rest of the organization by one
of the other methods
Parallel systems
The most secure method of converting from an old to new system is to run both systems in parallel.
Under this approach, users continue to operate the old system in the accustomed manner but they also begin
using the new system. This method is the safest conversion approach, since it guarantees that, should problems
such as errors in processing or inability to handle certain types of transactions arise in using the new system, the
organization can still fall back to the old system without loss of time, revenue, or service.

The disadvantages of the parallel systems approach are significant. First of all, the system costs double. since
there are two sets of systems costs. In some instances it is necessary to hire temporary personnel to assist in
operating both systems in parallel. Second, the fact that users know they can fall back to the old ways may be a
disadvantage if there is potential resistance to the change or if users prefer the old system. In other words, the
new system may not get a fair trial. All in all, the parallel method of systems conversion offers the most secure
implementation plan if things go wrong, but the costs and risks to a fair trail cannot be overlooked.

Phase - In Method
The phase-in method is used when it is not possible to install a new system throughout an organization all at
once. The conversion of files, training of personnel, or arrival of equipment may force the staging of the
implementation over a period of time. Ranging from weeks to months. Some users will begin to take advantage
of the new system before others.
For example, a medical system aimed at linking 10 or 15 different clinics to hospital may phase in over a year.
The work required to convert patient and insurance records on paper to files stored on magnetic disks requires 2
to 3 weeks for each clinic. A week of user training is also required for each clinic.
Therefore, the analysts may phase this system in one clinic at a time, allowing 3 to 4 weeks for each conversion.
It is conceivable in this system that the full conversion will be phased over one year.

Pilot Approach
When new systems also involved new techniques or drastic changes in organization performance, the pilot
approach is often preferred. In this method, a working version of the system is implemented in one part of the
organization, such as a single work area or department. The users in this area typically know that they are
piloting a new system and that changes can be made to improve the system.

When the system is deemed complete, it is installed throughout the organization, either all at once (direct
cutover method) or gradually (phase - in method). This approach has the advantage of providing a sound
proving ground before full implementation. However, if the implementation is not properly handled, users may
develop the impression that the system continues to have problems and that it cannot be relied on. For example,

40
they may feel that the difficulties they experienced for two or three weeks may in fact not be gone just because
the analysts claim they are.

5.1.4 Conversion Plan

The conversion plan includes a description of all the activities that must occur to implement the new system and
put it into operation. It identifies the persons responsible for each activity and includes a timetable indicating
when each activity will occur.
During the pre-implementation stages, when the conversion is being planned, analysts should assemble a list of
all tasks, including the following:

1. list all files for conversion.

2. identify all data required to build new files during conversion.
3. list all new documents and procedures that go into use during conversion.
4. identify all controls to be used during conversion.
5. establish procedures for crosschecking the old and new systems.
6. determine how team members will know if something has not been completed properly.
7. assign responsibility for each activity.
8. verify conversion schedules.

The conversion plan should anticipate possible problems and ways to deal with them. Among the most
frequently occurring problems are missing documents, mixed data formats between current and new files, errors
in data translation, missing data or lost files, and situations that were overlooked during systems development.
The conversion manager must guard against the omission of steps in the conversion. A checklist will prevent
missed steps. Personnel absences must also be expected and adequate fallback plans specified.

Conversion timing is challenging, since there are so many aspects of the conversion, ranging from the
installation of equipment to the ordering of forms and supplies.

5.2 Operating Plan

The operating plan is checking of all arrangements. It includes reviewing conversion plans, verifying the
delivery of equipment, software, forms, preparing the site and preparing the data and files.
1. Site Preparation: Analysts often work with vendor personnel to outline site - preparation guidelines.
Due importance should be paid to electrical using, air conditioning needs, humidity controls, space
requirements, etc.
2. Data and File Preparation: For a new system to begin master files and system files need to be entered
into the system before the normal functioning of the system. Master files are generally created manually.
The number of records in older system master file should tally with the number of records in new master
file.

In case of financial software the balance brought forward should be checked for validation before
implementation of the new system.

41
5.3 Evaluation
System evaluation is usually carried out during and after system conversion to determine the performance of the
new system i.e. whether it fulfils all of the system requirements which were developed in the system design
phase. It is the duty of the systems analyst to ensure that the system is working as intended, if otherwise he must
discover the source of the deficiency and fix it as best as possible.
Post - Implementation
During the production stage of the system life cycle, the system will be modified many times to meet the
changing needs of the company. The following results are realized during the post-implementation phase of the
systems development process:
Post-implementation review
System maintenance

Each of this result defines an activity that is to take place.

Post - implementation Review

This is a critical examination of the system three to six months after it has been put into operation. This waiting
period allows several factors to stabilize the resistance to change, the anxieties associated with change, and the
learning curve. It also allows time for unanticipated problems to surface.

5.4 System Maintenance

Once an information system is implemented and "goes on-line", the emphasis switches from development to
operations. In a payroll system, supervisors begin to enter hours worked on their terminals and the computer
centre produces and issues payroll checks. The process of modifying an information system to meet changing
needs is known as system maintenance.
It involves;
1. updating the system, to adapt it to developments in the user's methods of operations or to
environmental changes as and when they occur;
2. correcting errors as and when they occur;
3. documentation of the system updates and corrections
An information system cannot live forever, systems must continue to be modified for enhancement and over a
period of time these modifications can make the information system cumbersome and inefficient.
This type of minor modification is known as patches. A time will come when the system will outlive its useful
life i.e. if there is a high number of patches, it will be more troublesome to continue patching the system than to
redesign a new system completely. If the system can no longer function as it ought to, it signals the death of the
information cycle. A new system is then "born" out of necessity, and the system development process is
repeated.

Reasons why system maintenance is necessary

1. Early detection of issues: Computers can be temperamental, small issues can become huge problems before
we know it. When there is regular maintenance check, it can eradicate small issues before they become big
problems.
2. Prevention against viruses and malware: Computers are vulnerable to malware and harmful viruses waiting
that infect our systems. Some slow down the processing of the computer or make pop-up messages appear, but
others can infect entire operating systems. When this occurs at home or in business, it may be expensive to fix
or it can cost a company money in other ways such as loss of productivity. But, keeping computers well

42
maintained can keep both viruses and malware away and keep your computer running in tip-top shape. Regular
maintenance can also ensure your antivirus software is up-to-date and working properly.
3. Speed up your computer: When our system gets clogged up with files and everything gets disorganized and
fragmented, the result is slow processing times. Computer maintenance technicians are experts at running speed
and optimization checks that can pinpoint issues and keep your computer running at an optimal speed.
4. Maximize your software efficiency: When your software package gets old, it can slow down your computer.
Due to the fact that this change happens gradually, your computer may get used to it and think that it is normal.
But, having regular scheduled maintenance on your computer will clean out any issues and have your software
running perfectly again.

5. Prevent data loss: When computer start running slowly or begins having occasion hiccups, it can require a
system reboot that can ultimately result in lost data. Keeping your computer maintained will lessen the
likelihood of these instances and keep your data safe and secure when you need to access it.

Questions
1. Compare the different conversion methods with each other.
2. Explain the operating plan.
3. To what extent training is important.
4. "Conversion is simple". Do you agree. Justify

43
 CHAPTER SIX
PROTOTYPING APPROACH TO SYSTEM DEVELOPMENT
A prototype is a model of all or parts of a system, built to show users early in the design process how it will
appear. It is one way of ensuring full involvement in, and commitment to design by users. A simple example is a
prototype of a formatted screen output prepared using a graphic package, or a spreadsheet mode. This will
describe how the screen output would appear to the user. The user could make suggestions, which would be
incorporated into the next model.
A prototype empowers you to test the concept before you jump in to write even a single line of code.
That would save you thousands of naira, countless hours, and all the extra effort. Furthermore. using a prototype
software, the programmer can write an application program quickly, check with user's data to see whether the
prototype program design appears to meet the users' needs, otherwise, it can be amended. As many prototype
program as possible can be made for users to sample in order to obtain the one that satisfies the users needs. It is
at this point that the final version of the program is ready.

In an information system, most managers knows what they want but do not know exactly what they want. This
is a problem when it comes to information system. Prototyping enables users to be familiar with the new system
even before it is produced. This in turn will save cost and time. Before the 1980s prototype systems were very
expensive to build, it could cost as much as building a full scale information system, but today with the use of
fourth generation languages and application it is now cheaper to build prototype systems.
6.1 Objectives of Prototyping
1. To analyse the current situation
2. To identify information needs
3. To develop a scaled-down model of the proposed system, often called the target system.

Prototype systems enables users to work with the functional aspect of the proposed system long before the
system is implemented. Prototype systems are merely models which are tested and refined until the users are
confident that what they see is what they want. Incomplete or inaccurate user specifications can cause problem
when the system is fully implemented. Most users are inexperienced in system design to understand what a
proposed system will look like and how it will work. Project team build prototype system to enable users
understand what the system will look like when it is fully implemented. Just like prototype of manufactured
goods, software prototypes are also be created in varying degrees of sophistication.

44
1. Non-functional prototype systems
2. Partially functional prototype systems
3. Fully functional prototype systems

1. Non-functional prototype systems: It enables users the opportunity to experiment with a non-working
model of the system. This approach is called rapid prototyping, and it focuses on three aspects of the design
a. The user interface
b. Data entry display
c. System output

2. Partially functional prototype systems: A prototype system which is partially functional is developed.
Here, users, especially those at the operational level, can work with most of the basic features of the proposed
system during iterative practice session. Most partially functional prototype systems are created under the
premise that they will eventually be enhanced to the level of fully functional systems.
3. Fully functional prototype systems: These prototype systems are created so that users can experiment with
them. The focus here is functionality, therefore performance characteristics are ignored. This means that
efficiency of the system and the volume of work of the system can do is ignored. i.e. 10 transactions per minute
whereas the eventual system may need to handle up to 100 transactions per minute.

The users can provide meaningful feedback if they are familiar with the proposed system. Unlike the partially
functional approach, the fully functional approach is not intended to result in an operational system.

Successful Prototype Systems

There are two keys to create successfully prototype systems;
1. users must be willing and committed to providing on-going and meaningful feedback. Prototyping is an
iterative process, therefore users should be available to comment on the system design after each addition or
revision to the prototype system.
2. a prototyping system should be designed and created in a manner that makes it easy to modify If it is difficult
to modify a prototype system, the needed changes will not be effected and the finished system will fall short of
user expectations.

6.2 A Model of Prototyping Process

Prototyping system can be discussed in a four-step process;
Step 1: Identify the user's basic information requirements. Here users articulate their basic needs terms of
output from the system. Based on this, the system designer establish a realistic us? expectations and estimates
the cost of developing an operational prototype.
Step 2: Develop the Initial Prototype System: In this step a functional iterative application is developed, this
system meets user's basic stated information requirements, The system designer is saddled witn building the
system using very high development language or other application tools.

45
Step 3: Use of the prototype system to refine the user's requirements. In this stage, users have the opportunity of
using the prototype system where they can attest if the system meets their information needs or not. If problems
are found by the users in the first version, they are effected by the system designer. The users decides when
changes are necessary and thus controls the overall development time.
Step 4: Revise and Enhance the Prototype System: Based on the changes made by the users, the designer
implements these changes using the same principles in step 2. Speed in modifying the system and returning it to
the user is emphasized.

Identify Users
needs

Develop a
Prototype

Is it
Accepted?

Use the
Prototype

Figure 6.1: Development of a Prototype

The number of iterations varies, the user may decide that he prototype is not useful and discarded or he is
satisfied with the system and it becomes an "Operational Prototype".
Advantages of Prototyping
Reduced time and costs: The information specialist and the users spend less time and effort in developing the
system. The cost of developing the system is reduced while users satisfaction increases.
1. Ability to "try out" ideas without Incurring large costs
2. The user plays a more active role in the system development
3. Communications between the systems analyst and users are improved.
4. Implementation is much easier because the user knows what to do.
5. Effective utilization of Human Resources

46
Disadvantages of Prototyping
Some of the potential pitfalls of proto typing are:
1. Insufficient analysis: The haste to deliver the prototype may produce shortcuts in problem definition,
alternative evaluation and documentation.
2. The users may get excited about the prototype that they have unrealistic expectations of the operational
system.
3. Excessive development time of the prototype: A key property of Prototyping is the fact that it is
supposed to be done quickly. If developers lose sight of this fact, they very well may try to develop a
prototype that is too complex.
4. Expense of implementing prototyping: the start up cost for building a development team focused on
prototyping is high.
5. The computer-human interface provided by certain prototyping tools may not reflect good design
techniques.
6.3 Applications that are Good Prospect for Prototyping
Prototyping works best for applications characterized by:
1. High risk: The problem is not well structured, there is a high rate of change over time and the data
requirements are uncertain.
2. Considerable user interaction: The system features online dialogue between the user and microcomputer
or terminal.
3. Large number of users: Agreement on design details is difficult to achieve without hands-on experience.
4. A need for quick delivery
3. An expected short use phase of the system
6. An innovative system: The system is on the cutting-edge, either in the way that it solves the problem or
in its use of hardware.
7. Unpredictable users behavior: The user does not have previous experience with such a system
8. Application that do not reflect these characteristics can be developed by following the traditional
SDLC.

Questions
1. What is prototyping?
2. What are the advantages and disadvantages of prototyping?

47
 CHAPTER SEVEN
SYSTEMS DEVELOPMENT METHODS
There are various methods for developing computer-based information systems. Structured analysis is the most
popular method, but a newer strategy called object-oriented analysis and design also is used widely. Each
method offers many variations. Some organizations develop their own approaches or adopt methods offered by
software suppliers, CASE tool vendors, or consultants. Most IT experts agree that no single, best system
development strategy exists. Instead, a systems analyst should understand the alternative methodologies and
their strengths and weaknesses. Some System development methods are discussed below:

7.1 Structured Analysis and Design

Structured analysis is a traditional systems development technique that is time-tested and easy to understand.
Structured analysis uses a series of phases, called the systems development cycle (SDLC), to plan, analyze,
design, implement and support an information system. Although structured analysis evolved when most systems
were based on mainframe processing, it remains a dominant systems development method.
Structured design is a conceptualization of problem into several well-organized elements of solution. It is
basically concerned with the solution design. Benefit of structured design is, it gives better understanding of
how the problem is being solved. Structured design also makes it simpler for the designer to concentrate on the
problem more accurately.
Structured design is mostly based on 'divide and conquer' strategy where a problem is broken into several small
problems and each small problem is individually solved until the whole problem is solved. The small pieces of
problem are solved by means of solution modules. Structured design emphasizes that these modules be well
organized in order to achieve precise solution. These modules are arranged in hierarchy. They communicate
with each other. A good structured design always follows some rules for communication among multiple
modules, namely:
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.

7.2 Object - Oriented Analysis and Design

Whereas structured analysis treats processes and data as separate components, object-oriented analysis

48
(0-0) components data and the process that act on the data into things called objects. System's analyst use 0-0 to
model real-world business process and operation. The result is a set of software objects that represent actual
people, things, transaction, and events. Using an O-O programming language, a programmer then writes the
code that creates the objects.
An object is a member of a class, which is a collection of similar objects. Objects possess characteristic called
properties, which the objects inherits from its class or possess on its own. Object oriented design works around
the entities and their characteristics instead of functions involved in the software system. This design strategies
focuses on entities and its characteristics. The whole concept of software solution revolves around the engaged
entities.

7.2.1 Important concepts of Object Oriented Design

Objects: All entities involved in the solution design are Known as objects. For example, person, bank, company
and customers are treated as objects. Every entity has some attributes associated to it and has some methods to
perform on the attributes.
Classes: A class is a generalized description of an object. An object is an instance of a class. Class defines all
the attributes, which an object can have and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by means of methods or
procedures.
Encapsulation: In OOD, the attributes (data variables) and methods (operation on the data) are bundled
together is called encapsulation. Encapsulation not only bundles important information of an object together,
but also restricts access of the data and methods from the outside world. This is called information hiding.
Inheritance: OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can
import, implement and re-use allowed variables and methods from their immediate super classes. This property
of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes
from specific ones.
Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in
arguments, can be assigned same name. This is called polymorphism, which allows a single interface
performing tasks for different types. Depending upon how the function is invoked, respective portion of the
code gets executed.

7.2.2 Design Process

Software design process can be perceived as series of well-defined steps. Though it varies according to design
approach (function oriented or object oriented, yet it may have the following steps involved:
 A solution design is created from requirement or previous used system and/or system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in attribute characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.

7.3 Function Oriented Design

49
In function-oriented design, the system is comprised of many smaller sub-systems known as functions.
These functions are capable of performing significant task in the system. The system is considered as top view
of all functions. Function oriented design inherits some properties of structured design where divide and
conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which provides means of
abstraction by concealing the information and their operation. These functional modules can share information
among themselves by means of information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the function changes the
state of the program, which sometimes is not acceptable by other modules. Function oriented design works well
where the system state does not matter and program/functions work on input rather than on a state.

Design Process
The whole system is seen as how data flows in the system by means of data flow diagram.
DFD depicts how functions changes data and state of entire system.
The entire system is logically broken down into smaller units known as functions on the basis of their operation
in the system, each function is then described at large.
7.3.1 Software Design Strategies
There are two generic strategies for software designing:
Top Down Strategy and Bottom up Strategy
i. Top Down Strategy
The top-down strategy uses the modular approach to develop the design of a system. It is called so because it
starts from the top or the highest-level module and moves towards the lowest level modules.
In this technique, the highest-level module or main module for developing the software is identified The main
module is divided into several smaller and simpler submodules or segments based on the task performed by
each module. Then, each submodule is further subdivided into several submodules of next lower level. This
process of dividing each module into several submodules continues until the lowest level modules, which
cannot be further be subdivided, are not identified.
Top-down design is more suitable when the software solution needs to be designed from scratch and specific
details are unknown.

Level 0 Main Module

Level 1

Sub Module 1 Sub Module 2 Sub Module 3

Level 2

Sub Module Sub Module Sub Sub Sub Module Sub Module
11 12 Module 21 Module 22 31 32
50
 Figure 7.1: Top Down Strategy

ii. Bottom-up Strategy

Bottom-up strategy follows the modular approach to develop the design of the system. It is called so because it
starts from the bottom or the most basic level modules and moves towards the highest level modules. In this
technique,
 the modules at the most basic or the lowest level are identified
 these modules are then grouped together based on the function performed by each module to form the
next higher-level modules.
 then, these modules are further combined to form the next higher modules.
 this process of grouping several simpler modules to form higher level modules continues until the main
module of system development process is achieved.
Level 2
Sub Module Sub Module Sub Module Sub Module Sub Module Sub Module
11 12 21 22 31 32

Level 1

Sub Module 1 Sub Module 2 Sub Module 3

Level 0

Main Module

Figure 7.2: Bottom-up strategy

Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the
basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is
used.

7.4 Structured Design

Structured design is a data-flow based methodology that helps in identifying the input and output of the
developing system. The main objective of structured design is to minimize the complexity and increase the
modularity of a program. Structured design also helps in describing the functional aspects of the system.
In structured designing, the system specifications act as a basis for graphically representing the flow of data and
sequence of processes involved in a software development with the help of DFDs.
After developing the DFDs for the software system, the next step is to develop the structure chart.
51
 Structured
English

System
DFD Data Dictionary Decision Tree
Identification

Decision Table

7.4.1 Modularization
Structured design partitions the program into small and independent modules. These are organized in top down
manner with the details shown in bottom. Thus, structured design uses an approach called Modularization or
decomposition to minimize the complexity and to manage the problem by subdividing it into smaller segments.
Advantages
• Critical interfaces are tested first.
• It provide abstraction.
• It allows multiple programmers to work simultaneously.
• It allows code reuse.
• It provides control and improves morale.
• It makes identifying structure easier.

7.4.2 Structured Charts

Structured charts are a recommended tool for designing a modular, top down systems which define the various
modules of system development and the relationship between each module. It shows the system module and
their relationship between them.
It consists of diagram consisting of rectangular boxes that represent the modules, connecting arrows, or
lies.
 Control Module - It is a higher-level module that directs lower-level modules. called subordinate
modules.
 Library Module - It is a reusable module and can be invoked from more than one point in the chart.

Module 1

Module 1 1 Module 1 2 Module 1 3

52
 Library Module
Subordinate Module

We have two different approaches to design a structured chart -

 Transform-Centered Structured Charts - They are used when all the transactions follow same path.
 Transaction-Centered Structured Charts - They are used when all the transactions do not follow the
same path.
Objectives of Using Structure Flowcharts
 To encourage a top-down design.
 To support the concept of modules and identify the appropriate modules.
 To show the size and complexity of the system.
 To identify the number of readily identifiable functions and modules within each function.
 To depict whether each identifiable function is a manageable entity or should be broken down into
smaller components.
7.5 Software User Interface Design
User interface is the front-end application view to which user interacts in order to use the software. User can
manipulate and control the software as well as hardware by means of user interface. Today, user interface is
found at almost every place where digital technology exists, right from computers, mobile phones, cars, music
players, airplanes, ships etc.
User interface is part of software and is designed such a way that it is expected to provide the user
insight of the software. Ul provides fundamental platform for human-computer interaction. User Interface can
be graphical, text-based, audio-video based, depending upon the underlying hardware and software
combination. UI can be hardware or software or a combination of both.
The software becomes more popular if its user interface is:
 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interfacing screens
 User Interface is broadly divided into two categories:
 Command Line Interface
 Graphical User Interface
7.5.1 Command Line Interface (CLI)
CLI has been a great tool of interaction with computers until the video display monitors came into existence.
CLI is first choice of many technical users and programmers. CLI is minimum interface a software can provide
to its users.
CLI provides a command prompt, the place where the user types the command and feeds to the system.
The user needs to remember the syntax of command and its use. Earlier CLI were not programmed to handle the
user errors effectively. A command is a text-based reference to set of instructions, which are expected to be
executed by the system. There are methods like macros, scripts that make it easy for the user to operate. CLI
uses less amount of computer resource as compared to GUI.
CLI Elements

53
A text-based command line interface can have the following elements:
Command Prompt: It is text-based notifier that is mostly shows the context in which the user is working. It is
generated by the software system.
Cursor: It is a small horizontal line or a vertical bar of the height of line, to represent position of character
while typing. Cursor is mostly found in blinking state. It moves as the user writes or deletes something
Command: A command is an executable instruction. It may have one or more parameters. Output on command
execution is shown inline on the screen. When output is produced, command prompt is displayed on the next
line.

7.5.2 Graphical User Interface (GUI)

Graphical User Interface provides the user graphical means to interact with the system. GUI can be combination
of both hardware and software. Using GUI, user interprets the software. Typically, GUI is more resource

54
consuming than that of CLI. With advancing technology, the programmers and designers create complex GUI
designs that work with more efficiency, accuracy and speed.
Graphical user interfaces are a method of user communication with an operating system.
Through the interface, the user gives the operating system commands. With a graphical user interface, rather
than typing commands, the user will select icons, buttons, bars or boxes to perform a task. Usually a mouse is
used to make the selection. Many people believe that graphical user interfaces are quick and easy to learn,
promote standardization of application program interfaces and reduce errors.
Graphical user interfaces (GUIs) were popularized by the success of Apple's Macintosh and Microsoft's
Windows. While the commercial success has been driven by applications such as word processing and
spreadsheets, the popularity of the interface is driving all applications to the interface.
Technology exists to create GUI-like applications for dumb terminals. Technology also exists to create true PC-
based GUls that work with host applications via cooperative processing. And most importantly, GUI technology
has become the user interface of choice for client/server applications. GUIs do not automatically make an
application better. Poorly designed GUls can negate the alleged advantages of consistent user interfaces.
Fortunately, GUI standards are evolving to guide system designers to create consistent interfaces. For example,
DOS/Windows and OS/2 Presentation Manager are based on a standard called Common User Access (CUA),
Properly designed GUIs simplify input, reduce keystrokes required, and provide interesting and useful
formatting options for outputs. Many businesses are mandating their use for all new systems.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system has following elements such
as:

Window: An area where contents of application are displayed. Contents in a window can be displayed in the
form of icons or lists, if the window represents file structure. It is easier for a user to navigate in the file system
in an exploring window. Windows can be minimized, resized or maximized to the size of screen. They can be
moved anywhere on the screen. A window may contain another window of the same application, called child
window.
55
Tabs: If an application allows executing multiple instances of itself, they appear on the screen as separate
windows. Tabbed Document Interface has come up to open multiple documents in the same window. This
interface also helps in viewing preference panel in application. All modern web-browsers use this feature.
Menu: Menu is an array of standard commands, grouped together and placed at a visible place (usually top)
inside the application window. The menu can be programmed to appear or hide on mouse clicks.
Icon: An icon is small picture representing an associated application. When these icons are clicked or double
clicked, the application window is opened. Icon displays application and programs installed on a system in the
form of small pictures.
Cursor: Interacting devices such as mouse, touch pads, digital pen are represented in GUI as cursors. On screen
cursor follows the instructions from hardware in almost real-time. Cursors are also named pointers in GUI
systems. They are used to select menus, windows and other application features.
7.53 Application specific GUI components
A GUI of an application contains one or more of the listed GUI elements:
Application Window: Most application windows uses the constructs supplied by operating systems but many
use their own customer created windows to contain the contents of application.
Dialogue Box: It is a child window that contains message for the user and request for some action to be taken.
For Example: Application generate a dialogue to get confirmation from user to delete a file.

Text-Box: Provides an area for user to type and enter text-based data.
Buttons: They imitate real life buttons and are used to submit inputs to the software.

Radio-button: Displays available options for selection. Only one can be selected among all offered.
Check-box: Functions similar to list-box. When an option is selected, the box is marked as checked.
Multiple options represented by check boxes can be selected.

56
List-box: Provides list of available items for selection. More than one item can be selected.

Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
 Drop-down list
7.5.4 User Interface Design Activities
There are a number of activities performed for designing user interface. The process of GUI design and
implementation is alike SDLC. Any model can be used for GUI implementation among Waterfall, Iterative or
Spiral Model.
A model used for GUI design and development should fulfill these GUI specific steps.

GUI
Requirement GUI
Specification User Analysis

GUI GIU
Testing Task Analysis

GUI
Design &
Implementation

GUI Requirement Gathering: The designers may like to have list of all functional and non-functional
requirements of GUI. This can be taken from user and their existing software solution.

57
User Analysis: The designer studies who is going to use the software GUI. The target audience matters as the
design details change according to the knowledge and competency level of the user. If a user is technical and
well informed, advanced and complex GUI can be incorporated. For a novice user, more information is included
on how-to of software.
Task Analysis: Designers have to analyze what task is to be done by the software solution. Here in GUI, it does
not matter how it will be done. Tasks can be represented in hierarchical manner taking one major task and
dividing it further into smaller sub-tasks. Tasks provide goals for GUI presentation. Flow of information among
sub-tasks determines the flow of GUI contents in the software.
GUI Design & implementation: Designers after having information about requirements, tasks and user
environment, design the GUI and implements into code and embed the GUI with working or dummy software
in the background. It is then self-tested by the developers.
Testing: GUI testing can be done in various ways. Organization can have in-house inspection, direct
involvement of users and release of beta version are few of them. Testing may include usability, compatibility,
user acceptance etc.

7.5.5 GUI Implementation Tools

There are several tools available using which the designers can create entire GUI on a mouse click.
Some tools can be embedded into the software environment (IDE).
GUI implementation tools provide powerful array of GUI controls. For software customization,
designers can change the code accordingly.
There are different segments of GUI tools according to their different use and platform.

Examples are; Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come
handy to build GUI:
 FLUID
 AppInventor (Android)
 LucidChart
 Wavemaker
 Visual Studio

7.5.6 User Interface Golden rules

The following rules are mentioned to be the golden rules for GUI design, described by Shneiderman and
Plaisant in their book (Designing the User Interface).
Strive for consistency: Consistent sequences of actions should be required in similar situations.
Identical terminology should be used in prompts, menus, and help screens. Consistent commands should be
employed throughout.
Enable frequent users to use short-cuts: The user's desire to reduce the number of interactions increases with
the frequency of use. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to
an expert user.
Offer informative feedback: For every operator action, there should be some system feedback. For frequent
and minor actions, the response must be modest, while for infrequent and major actions, the response must be
more substantial.
Design dialog to yield closure: Sequences of actions should be organized into groups with a beginning, middle,
and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of
accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and this
indicates that the way ahead is clear to prepare for the next group of actions.
Offer simple error handling: As much as possible, design the system so the user will not make a serious error.
If an error is made, the system should be able to detect it and offer simple, comprehensible mechanisms for
handling the error.
58
Permit easy reversal of actions: This feature relieves anxiety, since the user knows that errors can be undone.
Easy reversal of actions encourages exploration of unfamiliar options. The units of reversibility may be a single
action, a data entry, or a complete group of actions.
Support internal locus of control: Experienced operators strongly desire the sense that they are in charge of
the system and that the system responds to their actions. Design the system to make users the initiators of
actions rather than the responders.
Reduce short-term memory load: The limitation of human information processing in short-term memory
requires the displays to be kept simple, multiple page displays be consolidated, window-motion frequency be
reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

7.5.7 Methods of interacting with a system

Command language: A human computer interaction method where users entered explicit statements into a
system to invoke operations.
Menu: A human computer interaction method where a list of system options is provided and a specific
command is invoked by user selection of a menu option

Form: A highly intuitive human-computer interaction method whereby data fields are formatted in manner
similar to paper based forms.
Object: A human computer interaction method where symbols are used to represent command of functions.
Natural language: A human-computer interaction method whereby inputs to and outputs from the computer
base application are in conventional speaking language such as English.
7.5.8 Fourth-generation languages
"Fourth-generation" languages are extremely sophisticated languages which enable end-users to perform
programming tasks with little or no professional programmer assistance or that enhance the productivity of
professional programmers. For example, very high-level programming languages, query languages, or
application generators have features that can be employed by end-users or less skilled programmers and can
dramatically increase application development productivity.

Categories of fourth-generation tools

The seven categories of fourth-generation tools are:
Query languages: high-level languages for retrieving data from databases and files which can support requests
for information that are not predefined. Tend to be on-line and interactive.
Report generators: facilities for extracting data from files or databases to create reports in many formats.
Graphics languages: facilities for displaying data from files or databases in graphic format.
Application generators: preprogrammed modules that can generate code for input, validation, processing,
update, and reporting when users provide specifications for an application.
Very high level programming languages: perform coding with far fewer instructions than conventional
languages.
Application software packages: pre-written application software that is marketed commercially.
Microcomputer tools: general-purpose application packages developed for microcomputers, especially word
processing. data management, graphics, desktop publishing and spreadsheet software.

Questions
1. Discuss the different types of system development methods.
59
2. What are the important concepts of object oriented design?
3. What are the generic strategies for software design?
4. What is GUI, what are the GUI elements and GUI implementation tools?
5. What are the various methods of interacting with a system?

CHAPTER EIGHT
STRUCTURED ANALYSIS & DESIGN TOOLS
Structured analysis is a set of techniques and graphical tools that allow the analyst to develop a new kind of
system specifications that are easily understandable to the user. Analysts work primarily with their wits, pencil,
and paper. Most of them have no tools. The traditional approach focuses on cost/benefit and feasibility analysis,
project management, hardware and software selection and personnel considerations. In contrast, structured
analysis considers new goals and structured tools for analysis. The new goals specify the following:
1. Use graphics wherever possible to help communicate better with the user.
2. Differentiate between logical and physical systems.
3. Build a logical system model to familiarize the user with system characteristics and interrelationships before
implementation.

The structured tools focus on the listed earlier- essentially the date flow diagram data dictionary. structured
English, decision trees, and decision tables. The objective is to build a new document, called system
specifications. This document provides the basis for design and implementation. The system development life
cycle with structured analysis. The primary steps are:
Process 2.1: Study affected user areas, resulting in a physical DFD. The logical equivalent of the present system
results in a logical DFD.
Process 2.2: Remove the physical checkpoints and replace them with a logical equivalent, resulting in the
logical DFD.
Process 2.3: Model new logical system. So far, no consideration is given to modifying methods called for in the
feasibility report. This step incorporates the changes the begins to describe the candidate system. It is essentially
a paper model system to be installed.
Process 2.4: Establish man/ machine interface. This process modifies the logical DFD for the candidate system
and considers the hardware needed to implement the system. The combination results in the physical DFD of
the candidate system.
Process 2.5 and 2.6: Quantify costs and benefits and select hardware. The purpose of this step is to cost-justify
the system, leading to the selection of hardware for the candidate system. All that is left after this step is writing
the structured specification.

60
 The structured specification consists of the DFDs that show the major decomposition of system
functions and their interfaces, the data dictionary documenting all interface flows and data stores on the DDs
and documentation of the intervals of DFDs in a rigorous manner through structured English. decision trees, and
decision tables.

In summary, structured analysis has the following attributes:

1. It is graphic. The DFD for example, presents a picture of what is being specified and is a conceptually
easy-to - understand presentation of the application.
2. The process is partitioned so that we have a clear picture of the progression from general to specific in
the system flow.
3. It is logical rather than physical. The elements of a system do not depend on the vendor or hardware.
They specify in a precise, concise, and highly readable manner the working of the system and how it
hangs together.
4. It calls for a rigorous study of the user area, a commitment that is often taken lightly in the traditional
approach to systems analysis.
5. Certain tasks that are normally carried out late in the system development life cycle are moved to the
analysis phase. For example, user procedures are documented during rather than later in implementation.

8.1 Guidelines for Selecting Appropriate Tools that will suit your requirements
● Use DFD at high or low level analysis for providing good system documentations.
● Use a data dictionary to simplify the structure for meeting the data requirement of the system.
● Use structured English if there are many loops and actions are complex.
● Use decision tables when there are a large number of conditions to check and logic is complex.
● Use decision trees when sequencing of conditions is important and if there are few conditions to be
tested. Decision trees are used to verify logic and in problems that involve a few complex decisions
resulting in a limited number of actions.
● Decision trees and decision tables are best suited for dealing with complex branching routines such as
calculating discounts or sales commissions or inventory control procedures.

Below are some structured analysis and design tools used by software designers:
8.2 Flow Charts
A flowchart is a pictorial/diagrammatic or geometric representation of an algorithm Some basic symbols of flow
charts are:

Output and Decision

Start and stop Box
Input

61
Connector
 Process
Flow of Data

Figure 8.1: Flow chart tools

A flowchart consists of a set of 'flowchart symbols' connected by arrows. Each symbol contains information
about what must be done at that point and the arrow shows the 'flow of execution' of the algorithm i.e. they
show the order in which the instruction must be executed. The purpose of using flowcharts is to graphically
present the logical flow of data in the system and define major phases of processing along with the various
media to be used. There are three types of flow chart namely: System flowchart, Run flowchart and Program
flowchart

8.1.1 Types of Flowcharts

i. System flowchart: The system flowchart describes the data flow for a data processing system.
It provides a logical diagram of how the system operates. It represents the flow of documents, the
operations performed in data processing and outputs. The following are features of system flowcharts:
 The sources from which data is generated and device used for this purpose
 Various processing steps involved
 The intermediate and final output prepared and the devices used for their storage
ii. Run Flowcharts: Run flowcharts are used to represent the logical relationship of computer routines along
with inputs, master files, transaction files and outputs.
iii. Program Flowcharts: A program flowchart represents, in detail, the various steps to be performed within
the system for transforming the input into output. The various steps are logical/arithmetic operations,
algorithms, etc. it serves as the basis for discussions and communication between the system analysts and
the programmers. Program flowcharts are quite helpful to programmers in organizing their programming
efforts.
These flowcharts constitute an important component of documentation for applications.

8.2 Data Flow Diagram

Data flow diagram is a graphical representation of the flow of data in an information system. It is capable of
depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about
how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in program
modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control or branch
elements.

8.2.1 Types of DFD

Data Flow Diagrams are either Logical or Physical.
62
Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system.
For example in a Banking software system, how data is moved between different entities.
Physical DED - This type of DFD shows how the data flow is actually implemented in the system. It is more
specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components

Process
Data Flow
Entity
Data Store

Figure 8.2: DFD Components

i. Entities: Entities are source and destination of information data. Entities are represented by rectangles with
their respective names.
ii. Process: Activities and action taken on the data are represented by Circle or Round-edged rectangles.
iii. Data Storage: There are two variants of data storage - it can either be represented as a rectangle with
absence of both smaller sides or as an open-sided rectangle with only one side missing.
iv. Data Flow: Movement of data is shown by pointed arrows. Data movement is shown from the base of
the arrow as its source towards the head of the arrow as the destination.
Advantage of the DFD
The primary strength of the DFD is its ability to represent data flows. It may be used at a high or low level of
analysis and provides good system documentation.
Disadvantage of the DFD
However, the tool only weakly shows input and output detail. The user often finds it confusing initially
8.3 HIPO Diagram
HIPO (HierarchicalInputProcessOutput) diagram is a combination of two organized methods to analyze the
system and provide the means of documentation. The HIPO model was developed by IBM in 1976.
HIPO diagram represents the hierarchy of modules in the software system. Analyst uses HIPO diagrams in
order to obtain a high-level view of system functions. It decomposes functions into sub-functions in a
hierarchical manner. It depicts the functions performed by system. HIPO diagrams are good for documentation
purpose. Their graphical representation makes it easier for designers and managers to get the pictorial idea of
the system structure.

Online
sales

Inventory Payment
Authentication Dispatch Item
Check 63 Process
 Generate
Issue_Item Item_Missing
Invoice

Deduct
Inventory

Figure 8.3: HIPO Diagram

8.4 InputProcessOutput (IPO)

In contrast to IPO InputProcessOutput diagram, which depicts the flow of control and data in a module, HIPO
does not provide any information about data flow or control flow.

Authentication

Input Process Output

Take authentication credentials

from user-screen

User Screen User Screen

Check validity of credentials

Call appropriate module

Figure 8.4: IPO Diagram

Example
Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used for structure design of software
program as well as documentation of the same.
8.5 Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise manner which is easily
understandable. A Decision table represents conditions and the respective actions to be taken to address them, in
a structured tabular format. It is a powerful tool to debug and prevent errors. It helps group similar information
into a single table and then by combining tables it delivers easy and convenient decision-making.
64
 Decision Tables should be verified by end-users and can lately be simplified by eliminating duplicate
rules and actions. It is useful in situations where the resulting actions depend on the occurrence of one or several
combinations of independent conditions. Decision table is a matrix containing rows or columns for defining a
problem and the actions.
8.5.1 Components of a Decision Table
Condition Stub: It is in the upper left quadrant which lists all the conditions to be checked.
Action Stub: It is in the lower left quadrant which outlines all the action to be carried out to meet such
condition.
Condition Entry: It is in upper right quadrant which provides answers to questions asked in condition
stub quadrant.
Action Entry: It is in the lower right quadrant which indicates the appropriate action resulting from the answers
to the conditions in the condition entry quadrant.
The entries in the decision table are given by Decision Rules which define the relationships between
combinations of conditions and courses of action. In rules section,
Y shows the existence of a condition.
N represents the condition, which is not satisfied.
A blank - against action states it is to be ignored.
X (or a check mark will do) against action states it is to be carried out.
Table 8.1 is an example of a Decision Table
Table 8.1: Decision Table
CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance Payment method Y N N N

Purchase amount = Rs 10,000/- - Y Y N

Regular Costumer - Y N -

ACTIONS

Give 5% Discount X X - -

Give no Discount - - X X

8.6 Structured English

Structured English uses plain English words in structured programming paradigm. It is not the ultimate code but
a kind of description of what is required to code and how to code it. Structure English is derived from structured
programming language which gives more understandable and precise description of process. It is based on
procedural logic that uses construction and imperative sentences designed to perform operation for action.

65
 Structured English is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions. It does not have strict syntax rules. It expresses all logic in
terms of sequential decision structures and iterations.
The following are some tokens of structured programming.
IF- THEN-ELSE,
DO-WHILE-UNTIL
The code written in Structured English is more like day-to-day spoken English. It cannot be implemented
directly as a code of software. Structured English is independent of programming language. For example, see
the following sequence of actions -

if customer pays advance

then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if
Advantage of Structured English
Structured English is best used when the problem requires sequences of actions with decisions.
8.7 Pseudo-Code
Pseudo code is written more close to programming language. It may be considered as augmented programming
language, full of comments and descriptions. It is used in conjunction with structured programming. It does not
conform to any programming language and expresses logic in plain English.
Pseudo code avoids variable declaration but they are written using some actual programming language's
constructs, like C, Fortran, Pascal etc. Pseudo code contains more programming details than Structured English.
It provides a method to perform the task, as if a computer is executing the code.
Example:
Program to print Fibonacci up to n numbers.
void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to l;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b:
}
else if b greater than a

66
 {
increase a by b;
print a;
}
}

8.8 Data Dictionary

Data dictionary is the centralized collection of information about data. It stores meaning and origin of data, its
relationship with other data, data format for usage etc. Data dictionary has rigorous definitions of all names in
order to facilitate user and software designers. Data dictionary is often referenced as meta-data dataaboutdata
repository. It is created along with DFD DataFlowDiagram model of software program and is expected to be
updated whenever DFD is changed or updated.

Examples of Data dictionary

StudentRecord = Enrolment Number +
Name +
Address +
Sex +
Date of Birth +
Subject +

Levels of Data Dictionary

Data dictionary can be defined into three different levels:
(i) Data Elements: A data element is a unit of data that cannot be broken down into a smaller but still
meaningful unit. Data elements can describe files, data flows, or processes. Data element is self defining
such as Student name, enrollment no, patient No, Street name.
(ii) Data Structure: A data structure is a group of related data elements and/or other data structures. Data
structure comprises data elements. It is defined as a collection of data elements. For example let us consider
the following "Student Information Record"

Student Information
Enrolment Number
Student name
First name
Second name
Last name
Sex
Student Address
Address 1
Address2
Etc.

67
(iii) Data Flows and Data Stores: Data flows are paths along which data travels and data stores are places
where data is stored until need. We can say that Data flows are Data structures in motion and Data stores
are Data structures at rest.

Data Flow Data Store

Data Structure

Data Element

Figure 8.5: Data Description Hierarchy

Advantage and disadvantage of the Data Dictionary

The data dictionary helps the analyst simplify the structure for meeting the data requirements of the system. It
may be used at high or low levels of analysis, but it does not provide functional details, and it is not acceptable
to many nontechnical users.
8.9. Computer Assistant Software Engineering (CASE)
CASE tools are a set of automated tools that help the developer, they are tools that automate many of the tasks
required in a system development effect and enforces adherence to the SDLC. CASE Technology is intended to
speed up the process of developing systems and to improve the quality of the resulting system. You can think of
the CASE technology as a software that is used to design and implement other software(s) (similar to the CAD
technology for engineers).
Examples of such programs are Excelerator, Iconix, System Architect and Powerbuilder. CASE tools
can handle components like diagramming, data dictionaries, report or screen generators and project
management. CASE tools may be used at almost any stage of the systems development life cycle, not just
design. Some types of CASE tools are; Upper CASE or font-end CASE, and Lower CASE or backend CASE
and Integrated-CASE (I-CASE) Tools.
Upper CASE (front-end CASE): These are tools that focus on activities associated with the early stages
of systems development. The tools support the analysis and design stages, providing graphics and text facilities
to create and maintain structured design techniques. They help document system requirements, develop and
maintain data and process models.
Lower CASE (back-end CASE): They are tools that focus on later implementation stage of systems
development. These tools support the design and construction stages and are used to help in coding and texting.
Automatic code generators convert the results of the physical design into codes that are suitable.
Integrated-CASE (I-CASE) Tools: These are tools that provide links between upper and lower:

68
CASE packages, allowing lower-CASE packages to generate program code from upper-CASE package
generated designs

Figure 8.6: Case Tools

Advantages of CASE tools
Better systems, better documentation
Disadvantages of CASE tools
Hard to use

8.10 Project Management tools and Techniques

PERT CHART (Project Evaluation and Review Technique): is a graphical network model used to depict the
interdependencies between project tasks.

Table 8.2: A PERT Chart table for the Analysis phase of a system project
LABEL ACTIVITY PREDECESSOR DURATION
A Conducts Interviews None 3
B Administers Questionnaires A 4
C Collect Company Reports None 4
D Analyze Data Flow B, C 8
E Introduce Prototype B, C 5
F Observe Reactions of Prototype E 3
G Perform Cost/Benefit Analysis D 2
H Prepare Proposal G 2
I Present Proposal H 2

Activities of the Analysis phase

20
A,3 B,4

10 30 50 60 70 80
69
 C,4 D,8 G,3 H,2 I,2

E,5 40 F,3

Figure 8.7: PERT Chart for the analysis phase

8.11 Gantt Chart
A simple time-charting tool used for project scheduling and progress evaluation. A bar chart to depict project
tasks against a calendar. Example:
Figure 8.8: Gantt Chart for the System Development
Questions
1. What is Structured Analysis and Design
2. What are the attributes of Structured analysis and design
3. What are the various structured analysis and design tools?
4. What is CASE, give examples of CASE
5. What are the differences between PERT and Gantt chart?

70