Systems Analysis and Design: A Simplified Approach | ii

____________________________________________________________________

SYSTEMS ANALYSIS AND DESIGN

A Simplified Approach
 Systems Analysis and Design: A Simplified Approach | iii
____________________________________________________________________
 Systems Analysis and Design: A Simplified Approach | iv
____________________________________________________________________

SYSTEMS ANALYSIS AND DESIGN

A Simplified Approach

By

Dumnamene J.S. Sako

Department of Mathematics and Computer Science
Rivers State University of Science and Technology
Nkpolu-Oroworukwo, Port Harcourt
 Systems Analysis and Design: A Simplified Approach | v
____________________________________________________________________

Harey Publications Coy

No. 2 Nnewi Street, Mile 1, Diobu, Port Harcourt, Nigeria
e-mail: hareypub@[Link]
tel: +234(0)84-741963, +234(0)8036760217

Systems Analysis and Design: A Simplified Approach

Dumnamene J.S. Sako

 2015 Harey Publications Coy. All rights reserved. No part of this publication
may be reproduced or distributed in any form or by any means, or stored in a
database or retrieval system, without the prior written consent of the publisher,
including, but not limited to, in any network or other electronic storage or
transmission, or broadcast for distance learning.

ISBN: 978-978-53272-2-2

Cover Design: +234(0)7030553404

Typeset, printed and bound in Nigeria by:

Sondanet Systems
9, Polytechnic Road, Bori, Port Harcourt.
e-mail: info@[Link]
[Link]
 Systems Analysis and Design: A Simplified Approach | vi
____________________________________________________________________

Live in fragments no longer. Only connect.

Edward Morgan Forster

Systems Analysis and Design (SAD) is an exciting, active field in which analysts
continually learn new techniques and approaches to develop systems more
effectively and efficiently. However, there is a core set of skills that all analysts
need to know no matter what approach or methodology is used. All information
systems projects move through the four phases of planning, analysis, design, and
implementation; all projects require analysts to gather requirements, model the
business needs, and create blueprints for how the system should be built; and all
projects require an understanding of organizational behavior concepts like
change management and team building.

This book captures the dynamic aspects of the field by keeping students focused
on doing SAD while presenting the core set of skills that we feel every systems
analyst needs to know today and in the future.

Each chapter describes one part of the process, provides clear explanations on
how to do it, gives a detailed example, and then has exercises for the students to
practice. In this way, students can leave the course with experience that will form
a rich foundation for further work as a systems analyst.

I wish to thank all those who helped in one way or the other during the
preparation and production of this book. Let me specially acknowledge the staff
of sondanet systems for the diligence exhibited in the production of this book. I
also wish to acknowledge all the authors listed in the bibliography for the
materials I use in preparing this book.

Special thanks to my wife, Goodness, for her support and encouragement and my
son, Noble, for his understanding and companionship. Above all, I thank the
Almighty God for life, guidance and the gift of knowledge.

DUMNAMENE J.S. SAKO

 Systems Analysis and Design: A Simplified Approach | vii
____________________________________________________________________

Preface vi

1 | Introduction to Systems 1
1.0 Introduction 1
1.1 Defining a System 1
1.2 Characteristics of a System 2
1.3 Elements/Components of a System 5
1.4 Classification of a System 8
1.5 Systems Models 12
1.6 Examples of Systems 14
1.7 Summary 14
1.8 Review Questions 14

2 | Overview of Systems Analysis and Design 15

2.0 Introduction 15
2.1 What is Systems Analysis and Design? 15
2.2 Role of System Analyst 16
2.3 Critical Success Factors of a System Analyst 16
2.4 Users of System (System End Users) 17
2.5 Case Study: Noble Library System 18
2.6 Applying the concepts studied so far to the Case Study 20
2.7 Summary 21
2.8 Review Questions 21
3 | System Development Life Cycle 16
3.0 Introduction 16
3.1 The Systems Development Life Cycle 23
3.2 Phases of Systems Development Life Cycle 4
3.3 Systems Development Methodologies 30
3.4 Summary 38
3.5 Review Questions 38

4 | Preliminary Investigation and Feasibility Study 39

4.0 Introduction 39
 Systems Analysis and Design: A Simplified Approach | viii
____________________________________________________________________

4.1 Sources of Project Requests 39

4.2 Determining the User‘s Information Requirements 40
4.3 Strategies for Determining Information Requirements 40
4.4 Preliminary Investigation 42
4.5 Conducting the Investigation 43
4.6 Testing Project Feasibility 44
4.6.1 What Is a Feasibility Study? 44
4.6.2 Content of a Feasibility Study 45
4.6.3 The System Proposal and Feasibility Study Report 45
4.6.4 Factors/Types/Areas of Feasibility Study 47
4.6 Data Analysis 51
4.7 Cost Benefit Analysis 51
4.8 Procedure for Cost/ Benefit Determination 52
4.8.1 Costs and Benefits Identification 52
4.8.2 Cost and Benefit Categories 53
4.8.3 Select Evaluation Method 56
4.8.4 Interpret Results of the Analysis and Final Action 59
4.9 Performing Cost Benefit Analysis (CBA 60
4.10 Handling Infeasible Projects 60
4.11 Summary 61
4.12 Review Questions: 61

5 | System Requirement Specifications and Analysis 62

5.0 Introduction 62
5.1 Detailed Analysis 62
5.2 Requirements Determination 65
5.2.1 Activities in Requirement Determination 65
5.3 Basic Requirements 66
5.3.1 Understand the Process 67
5.3.2 Identify data used and information produced 68
5.3.3 Determine process timing and volume 69
5.3.4 Identity controls 70
5.4 User Transaction Requirements 70
5.5 User Decision Requirements 70
5.6 Fact Finding Techniques 71
5.7 Requirements Structuring/ Decision Making Documentation 77
5.8 Process modelling 78
5.8.1 Data Flow Diagram 78
 Systems Analysis and Design: A Simplified Approach | ix
____________________________________________________________________

5.8.2 Data Dictionary 87

5.9 Logic Modelling 91
5.9.1 Structured English 91
5.9.2 Decision Tree 92
5.9.3 Decision Table 94
5.10 When to use what? 99
5.11 Evolution of Systems Analysis Techniques 99
5.12 Fact Finding Techniques - Case Study: Library Management 100
System
5.13 Case Study 2: Payroll System- Analyzing the Present System 102
5.14 Summary 106
5.15 Review Questions 107

6 | System Design 108

6.0 Introduction 108
6.1 What vs How 108
6.2 System Design 108
6.3 General Guidelines for Systems Design 109
6.4 Physical Modeling Phase 110
6.5 Summary 111
6.6 Review Questions 111

7 | Interface, Input and Output Design 112

7.0 Introduction 112
7.1 Interface Design 112
7.1.1 Significant Types of User-computer Interface Design:- 113
7.1.2 Essential Instructions in Dialogue Design 114
7.2 Screen Design 114
7.3 Input Design 115
7.3.1 Input Design Objectives 115
7.3.2 Key Tasks in Input Design 115
7.3.3 Designing the System Inputs 116
7.3.4. Choosing the Best Data Capture and Data Input Methods for 117
the System
7.3.5. Designing On-Screen Forms for Data Input 118
7.3.6. Form Controls 118
7.3.7. Data Validation Techniques 120
7.3.8. Data Verification Techniques 121
 Systems Analysis and Design: A Simplified Approach | x
____________________________________________________________________

7.4 Output Design 122

7.4.1. Output Design Principles 123
7.4.2. Designing the System Outputs 123
7.5 Summary 126
7.6 Review Questions 126

8 | File and Database Design 127

8.0 Introduction 127
8.1 Overview of Database and File 128
8.2 Basic File Related Keywords 129
8.3 File Design 130
8.4 Database Design 132
8.5 What is good database design? 132
8.6 Conventional Files Versus the Database 133
8.7 Database Design in Perspective 134
8.8 Database Concepts for the Systems Analyst 134
8.9 Sample Database 136
8.10 Practical Approach to Database Design 137
8.11 Process Modeling vs Data Modeling 155
8.12 Summary 156
8.13 Review Questions 156

9 | System Control, Quality Assurance and Testing 157

9.0 Introduction 157
9.2 Design Objectives 157
9.2.1 Reliable Systems 157
9.2.2 Maintenance of Systems 161
9.3 Software Design 162
9.4 Coupling 163
9.5 Software Design and Documentation Tools 165
9.5.1 Structured Flowcharts 166
9.5.2 HIPO 167
9.5.3 Warnier/Orr Diagrams 168
9.5.4 Structure Chart 169
9.5.5 Pseudo-code 171
9.6 Managing Quality Assurance 173
9.7 Testing the New System 175
9.7.1 Testing guidelines 176
 Systems Analysis and Design: A Simplified Approach | xi
____________________________________________________________________

9.7.2 Test Plan 176

9.7.3 Selecting Test Data 177
9.7.4 Phases of System Testing 178
9.7.5 What Happens if the System Fails Some Tests? 179
9.8 System Controls 179
9.9.1 Processing controls 179
9.10 Audit Trails 180
9.11 Summary 181
9.12 Review Questions 181

10 | Implementation and Deployment 182

10.0 Introduction 182
10.1 Documentation 182
10.2 Installation 184
10.3 Training 184
10.3.1 Training guidelines 185
10.3.2 Training topics 185
10.4 Conversion 185
10.4.1 Conversion Strategies 185
10.4 Conversion Plan 189
10.5 Summary 190
10.6 Review Questions 190

11| System Evaluation and Maintenance 191

11.0 Introduction 191
11.1 Evaluating the New System 191
11.1.1 What Does an Evaluation Look For? 191
12.1.2 How is a System Evaluated? 192
11.1.3 What Happens Next? 192
11.2 System Maintenance 193
11.2.1 Definitions 193
11.2.2 Categories of System Maintenance 193
11.3 Summary 194
11.4 Review Questions/Hand-on Exercises. 195
Bibliography 200
Web Resources 202
Index 203
 Systems Analysis and Design: A Simplified Approach | xii
____________________________________________________________________
 CHAPTER ONE

Introduction to Systems

1.0 Introduction

Systems are created to solve problems. One can think of the systems approach as
an organized way of dealing with a problem. A system exists because it is
designed to achieve one or more objectives. We come into daily contacts with the
transportation system, the telephone system, the accounting system, the
production system, and for over three decades, the computer system. Similarly,
we talk of the business system and of the organization as a system consisting of
interrelated departments (subsystems) such as production, sales, personnel, and
an information system. None of these subsystems is of much use as a single,
independent unit. When they are properly coordinated, however, the firm can
function effectively and profitably.

1.1 Defining a System

The term system is derived from the Greek word systema, which means
an organized relationship among functioning units or components.

A system is a set of interrelated (interoperable) elements that collectively work

together to achieve some common purpose or goal.

There are more than a hundred definitions of the word system, but most seem to
have a common thread that suggests that a system is an orderly grouping of
interdependent components linked together according to a plan to achieve a
specific objective. The word component may refer to physical parts (engines,
wings of aircraft, car), managerial steps (planning, organizing and controlling),
or a system in a multi-level structure. The component may be simple or complex,
basic or advanced. They may be single computer with a keyboard, memory, and
printer or a series of intelligent terminals linked to a mainframe. In either case,
each component is part of the total system and has to do its share of work for the
system to achieve the intended goal. This orientation requires an orderly
grouping of the components for the design of a successful system.
 Systems Analysis and Design: A Simplified Approach | 2
____________________________________________________________________

Basically there are three major components in every system, namely input,
processing and output. As an abstraction we symbolically represent a system as a
simple entity by using a rectangular box as shown in Figure 1.1. In general,
inputs such as stimuli and cues are fed into a system that processes the inputs and
produces an output.

Figure 1.1: Basic System Entity Construct

In a system the different components are connected with each other and they are
interdependent. For example, Human body represents a complete natural system.
We are also bound by many national systems such as political system, economic
system, educational system and so forth. The objective of the system demands
that some output is produced as a result of processing the suitable inputs.

The study of system concepts has three basic implications

 A system must be designed to achieve a predetermined objective.

 Interrelationship and interdependence must exist among the components.
 The objectives of the organization as a whole have a higher priority than
the objectives of its subsystems. The whole is greater than the sum of its
parts; 2+2 = 5. For example, computerizing personnel applications must
conform to the organization‘s policy on privacy, confidentiality and
security, as well as making selected data (e.g. payroll) available to the
accounting division on request.

1.2 Characteristics of a System:

Our definition of a system suggests some characteristics that are present in all
systems: organization (order), interaction, interdependence, integration and a
central objective.
 Systems Analysis and Design: A Simplified Approach | 3
____________________________________________________________________

a. Organization:
Organization implies structure and order. It is the arrangement of components
that help to achieve objectives. In the design of a business system, for example,
the hierarchical relationships starting with the president on top and leading
downward to the blue – collar workers represents the organization structure.
Such an arrangement portrays a system – subsystem relationship, defines the
authority structure, specifies the formal flow of communication and formalizes
the chain of command. Like – wise, a computer system is designed around an
input device, a central processing unit, an output device and one or more storage
units. When linked together they work as a whole system for producing
information.

Figure 1.2: Organization Structure – An example

b. Interaction:
Interaction refers to the manner in which each component functions with other
component of the system. In a computer system, for example, the central
processing unit must interact with the input device to solve a problem. In turn,
the main memory holds the program and data that the arithmetic unit uses for
 Systems Analysis and Design: A Simplified Approach | 4
____________________________________________________________________

computation. The interrelationship between these components enables the

computer to perform smooth functions. In an organization, purchasing must
interact with production, advertising with sales and payroll with personnel.

c. Interdependence:
Interdependence means that parts of the organization or computer system depend
on one another. They are coordinated and linked together according to a plan.
One subsystem depends on the input of another subsystem for proper
functioning: that is, the output of one subsystem is the required input for another
subsystem. This interdependence is crucial in systems work. An integrated
information system is designed to serve the needs of authorized users
(department heads, managers, etc.) for quick access and retrieval via remote
terminals. The interdependence between the personnel subsystem and the
organization‘s users is obvious. In summary, no subsystem can function in
isolation because it is dependent on the data (inputs) it receives from other
subsystems to perform its required tasks. Interdependence is further illustrated by
the activities and support of systems analysts, programmers, and the operations
staff in a computer center. A decision to computerize an application is initiated
by the user, analyzed and designed by the analyst, programmed and tested by the
programmer, and run by the computer operator. None of these persons can
perform properly without the required input from others in the computer center
subsystem.

d. Integration:
Integration is concerned with how a system is tied together. It is more than
sharing a physical part or location. 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 synergistic effect and greater total
impact than if each component works separately.

e. Central Objective:
The last quality is central objective. Objectives may be real or stated. It is very
common for an organization to state one objective and operates to achieve
another. This important point is that users must know the central objective of a
computer application early in the analysis for a successful design and conversion.
 Systems Analysis and Design: A Simplified Approach | 5
____________________________________________________________________

1.3 Elements/Components of a System:

To reconstruct a system, key elements must be considered. As discussed above,

a system is a set of components working together to achieve some goal. The
basic elements of the system may be listed as:

a. Inputs & Outputs

b. Processing
c. Control
d. Feedback
e. Environment
f. Boundaries and Interface

a. Inputs & Outputs (data and Information):

A major objective of a system is to produce an output that has value to its user.
Whatever the nature of the output (goods, services, or information), it must be in
line with the expectations of the intended user. Inputs are the elements (material,
human resources, or data) that enter the system for processing. Output is the
outcome of processing. A system feeds on input to produce output in the same
way that a business brings in human, financial, and material resources to produce
goods and services. Determining the output is the 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 i.e. specification of the output that
the computer is expected to provide.

b. Processing:
The processing is the element of a system that involves the actual transformation
of input into output. It is operational component of a system. Processing may
modify the input totally or partially, depending on the specifications of the
output. This means that as the output specifications change, so does the
processing.

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 and outflow of activities that affect the welfare of the business. In
 Systems Analysis and Design: A Simplified Approach | 6
____________________________________________________________________

computer system, the operating system and accompanying software influence the
behavior of the system.

In system analysis, knowing the attitude of the individual who controls the area
for which a computer is being considered can make a difference between the
success and failure of the installation.

Management support is required for securing control and supporting the

objective of the proposed change.

Open Loop Systems: In these systems control is carried out by monitoring

output and by receiving environmental input. Some control is therefore exercised
from outside the system, by intervention administered externally.

Closed Loop Systems: In these systems output is fed back to input and there is
no input from the environment. The output thus initiates the control activity to
alter the system's input or its activities.

d. Feedback:
Feedback is an important element of systems. The output of a system needs to be
observed and feedback from the output taken so as to improve the system and
make it achieve the laid standards. Control in a dynamic system is achieved by
feedback. Feedback measures output against a standard in some form of
cybernetic (automatic, electronic, streamlined) procedures that includes
communication and controls. Output information is fed back into the input and/or
to management (controller) for consideration, calculation, or reflection. After the
output is compared against performance standards, change can result in the input
or processing and, consequently, the output.

Another form of feedback comes after the system is implemented. The user
informs the analyst about the performance of the new installation. This feedback
often results in enhancements to meet the user's requirements.

Types of Feedback:

Positive Feedback: Very generally, this result in successively greater deviations

from the results actually sought. In fact, positive feedback results in some control
activity which causes performance or output to continue deviating (or even
 Systems Analysis and Design: A Simplified Approach | 7
____________________________________________________________________

increases the deviation) from what is required to happen. Positive feedback is

necessary for organizational growth.

Negative Feedback: Negative feedback shows that the system is deviating from
the intended path and that some change is therefore required to correct this
situation. The control action to be taken generally reverses the trend.

e. Environment:

The environment is the system within which an organization operates. It is the

source of external elements that disturb the system. In fact, it often determines
how a system must function. The environment is the collection of elements; these
elements surround the system and often interact with it.

f. Boundaries and Interfaces:

A system should be defined by its boundaries, the limits that identify its
components, processes, and interrelationships when it interfaces with another
system. Systems are normally delimited by boundaries, which separates them
from its environment. Anything within the boundary is part of system; anything
outside is part of the environment. What is included in the system and what is
included in the environment depend on the particular problem being studied.

Every system has defined boundaries within which it operates. Beyond these
limits the system has to interact with the other systems. For instance, Personnel
system in an organization has its work domain with defined procedures. If the
financial details of an employee are required, the system has to interact with the
Accounting system to get the required details.

Interfaces are another important element through which the system interacts with
the outside world. System interacts with other systems through its interfaces.
Users of the systems also interact with it through interfaces. Therefore, these
should be customized to the user needs. These should be as user friendly as
possible.
 Systems Analysis and Design: A Simplified Approach | 8
____________________________________________________________________

1.4 Classifications of System

From previous section we have a firm knowledge of various system components

and its characteristics. The frame of reference within which one views a system
is related to the use of the systems approach for analysis. Systems have been
classified in different ways. Common classifications are:

1. Physical Systems or Abstract Systems

2. Open Systems or Closed Systems
3. Automated Manual and Manual Systems
4. Deterministic Systems or Probabilistic Systems
5. 'Man-made' Information Systems
6. Formal Information Systems
7. Informal Information Systems
8. Computer Based Information Systems

1. Physical or Abstract Systems:

Physical Systems are tangible entities that we can feel and touch. These may be
static or dynamic in nature. For example, take a computer center. Desks and
chairs are the static parts, which assist in the working of the center. Static parts
don't change; they can be seen and counted. The dynamic systems are constantly
changing. Computer systems are dynamic system. Programs, data, output and
applications can change according to the user's needs or the priority of the
information requested changes.

Abstract systems are conceptual or non-physical entities. They may be as

straightforward as formulas of relationships among sets of variables or models–
the abstract conceptualization of physical situations. A model is a representation
of a real or a planned system. The use of models makes it easier for the analyst to
visualize relationships in the system under study. The objective is to point out the
significant elements and the key interrelationships of a complex system.

2. Open or Closed System:

Systems interact with their environment to achieve their targets. Things that are
not part of the system are environmental elements for the system. Depending
upon the interaction with the environment, systems can be divided into two
categories, open and closed.
 Systems Analysis and Design: A Simplified Approach | 9
____________________________________________________________________

Open Systems: These are systems that interact with their environment.
Practically most of the systems are open systems. An open system has many
interfaces with its environment. It can also adapt to changing environmental
conditions. It permits interaction across its boundary; it receives inputs from and
delivers outputs to the outside of system. An information system is an example
of this category, since it must adapt to the changing demands of the users.

Closed Systems: They are systems that don't interact with their environment. It
is independent of its environment; changes in the environment and adaptability
are not issues for closed systems. The system is neither influenced by, nor
influences, its environment. It does not take in from, or give to it. It does not
exchange information, energy or material. In reality, a completely closed system
is rare. In systems analysis, organizations, applications and computers are
invariably open, dynamic systems influenced by their environment. In the
business world closed systems do not exist. Closed systems exist in concept only.

Figure 1.3: A schematic representation of a closed system and its boundary.

Semi-closed Systems relate to its environment in a prescribed controlled and in

well-defined way. A thermostat, circulatory system or heating system would be
good examples of semi-closed system.

3. Manual or Automated System

A manual system is operated directly by the user, and an automated system
occurs without user intervention. A manual system is one that you have to
control, configure, change, or drive yourself. Think of a manual transmission on
a car; in order to change gears, the driver has to push the clutch and then change
the gear by himself.
 Systems Analysis and Design: A Simplified Approach | 10
____________________________________________________________________

An automated system is one that changes by itself when a certain condition is

met. Again, in car transmissions, an automatic transmission will change the gears
when the engine reaches a certain number of revolutions per minute (RPMs).

4. Deterministic/Mechanistic or Probabilistic Systems:

Depending on the system input and the output, the open systems can be further
categorized as deterministic or mechanistic.

Deterministic/Mechanistic Systems are those where end results (outputs) can

be predicted with certainty, provided that they are operating correctly and are
under control. A system may be classified as deterministic if it is possible to
predetermine the stages or states through which it will pass.

The workings of a motor car, a steam engine or a mechanical lift are reasonably
easy to predict and control as long as they are operating efficiently. Unexpected
modes of working may develop as a result of excessive wear, in which case the
system becomes probabilistic rather than deterministic. Whether a system is
regarded as falling into the deterministic or probabilistic category depends upon
how closely the system can be examined.

All computer base information systems (CBIS) like financial accounting system,
inventory control system, payroll system etc. may be described as deterministic,
and they are consequently much easier to control than systems involving people,
whose behavior may be unpredictable.

Probabilistic Systems: Probabilistic systems (also called stochastic systems) are

those whose state can be predicted only within certain limits, even when they are
under control. Business and economic systems are usually in this category,
because they are subjected to so many varying internal and external forces.
Although some of the states in these systems may be predicted from previous
states, they can be described only in terms of probable behavior. There is always
some degree of error associated with the predictions.

For example, budgets or targets and sale are subject to a number of variables in
the environment, including availability of stock, price of the product, market
trends etc. In such instances, where the information is of a probabilistic nature, a
 Systems Analysis and Design: A Simplified Approach | 11
____________________________________________________________________

range of possible outcomes and their associated probabilities will be given. A

major consideration in the design of management information systems (MIS) is
the utilization of probabilistic as well as deterministic information for decision-
making purposes.

5. Man-made Information System

The main purpose of information systems is to manage data for a particular

organization. Maintaining files, producing information and reports are few
functions. An information system produces customized information depending
upon the needs of the organization. These are usually formal, informal, and
computer based.

Formal Information Systems: It deals with the flow of information from top
management to lower management. Information flows in the form of memos,
instructions, etc. But feedback can be given from lower authorities to top
management.

Informal Information Systems: The formal information system is a power

structure designed to achieve company goals. An organization‘s emphasis on
control to ensure performance tends to restrict the communication flow among
employees. As a result, an informal information system develops. It is an
employee based system designed to meet personnel and vocational needs and to
help solve the day to day work related problems. It also funnels information
upward through indirect channels. In this respect, it is a useful system because it
works within the framework of the business and its stated policies.

Computer-Based Information Systems: This class of systems depends on the

use of computer for managing business applications. The computer is now a
required source of information. Systems analysis relies heavily on computers for
problem solving. This suggests that the analyst must be familiar with computer
technology and have experience in handling people in an organizational context.
They include Management Information Systems (MIS) and Decision Support
Systems (DSS).

Management Information Systems (MIS): is a person–machine system and a

highly integrated grouping of information – processing functions designed to
 Systems Analysis and Design: A Simplified Approach | 12
____________________________________________________________________

provide management with a comprehensive picture of specific operations. It is

actually a combination of information systems.

Decision Support Systems (DSS): One reason cited in the literature of

management‘s frustration with MIS is the limited support it provides top
management for decision making. DSS advances the capabilities of MIS. It
assists management in making decisions. It is actually a continually evolving
model that relies heavily on operations research.

The origin of the term ‗decision support system (DSS)‘ is simple:

 Decision – emphasizes decision making in problem situations, not
information processing, retrieval, or reporting.
 Support – requires computer-aided decision situations with enough
―structure‖ to permit computer support.
 System – accentuates the integrated nature of problem solving, suggesting
a combined ―man‖, machine, and decision environment.

1.5 Systems Models

In no field are models used more widely and with greater variety than in systems
analysis. The analyst begins by creating a model of the reality (facts,
relationships, procedures, etc.) with which the system is concerned. Every
computer system deals with the real world, a problem area, or a reality outside
itself. For examples, a telephone switching system is made up of subscribers,
telephone handsets, dialing, conference calls, and the like. The analyst models
this reality before considering the functions that the system is to perform.
Various business system models are used to show the benefits of abstracting
complex system to model form.

The major models are schematic, flow, static and dynamic system models.

Schematic Models. A schematic model is a two – dimensional chart depicting

system elements and their linkages. Different arrows are used to depict
information flow, material flow and information feedback. Various elements of
the system are depicted in boxes.

Flow System Models. A flow system model shows the flow of the material,
energy and information that hold the system together. There is an orderly flow of
 Systems Analysis and Design: A Simplified Approach | 13
____________________________________________________________________

logic in such models. A widely known example is PERT (Program Evaluation

and Review Technique). It is used to abstract a real world system in model form,
manipulate specific values to determine the critical path, interpret the
relationships and relay them back as a control. The probability of completion
within a time period is considered in connection with time, resources and
performance specifications.

Static System Models. This type of model exhibits one pair of relationships such
as activity – time or cost – quantity. The Gantt chart, for example, gives a static
picture of an activity- time relationship. Planned activities (stamping, sanding
etc.) are plotted in relation to time are shown in figure 1.4. The date column has
light lines that indicate the amount of time it takes to complete a given activity.
The heavy line represents the cumulative time schedule for each activity. The
stamping department, for example, is scheduled to start working on order number
25 Wednesday morning and complete the job by the same evening. One day is
also scheduled for order number 28, two days for order number 28, two days for
order number 22 and two days (May 10-11) for order number 29. The heavy line
opposite the stamping department represents the total of six days. The broken
line indicates that the department is two days behind schedule. The arrowhead
indicates the date when the chart is to be in effect.

Figure 1-4: The Gantt Chart.

 Systems Analysis and Design: A Simplified Approach | 14
____________________________________________________________________

Dynamic System Models. Business organizations are dynamic systems. A

dynamic model approximates the type of organization or application that analysts
deal with. It depicts an ongoing, constantly changing system. It consists of
inputs that enter the system, the processor through which transformation takes
place, the program(s) required for processing and the output(s) that result from
processing.

1.6 Examples of System:

Some examples of systems include: A closed economy of a country (closed), a

circulatory system or heating system (semi-closed), business system (open), a
computerized accounting system (deterministic), a football playing system
(probabilistic), etc

1.7 Summary

 A system is a set of interdependent components, organized in a planned

manner to achieve certain objectives.
 System interacts with their environment through receiving inputs and
producing outputs.
 Systems can be decomposed into smaller units called subsystems.
 Its main characteristic are organization, interaction, interdependence,
integration and a central objective.
 To construct a system, system analyst must consider its elements- input
and output, processors, control, feedback, and environment.
 Systems are classified as physical or abstract, open or closed, and man-
made information systems, etc.
 A system may be schematic, static or dynamic.
 An information system is an open system that allows inputs and facilitates
interaction with the user.

1.8 Review Questions

1. Define the term ‗System‘. What are the various elements of system?
2. Differentiate between a) Open and closed systems b) Physical
and Abstract systems
3. A system leads to a lot of planning and less of implementation. Do you
agree, justify your answer.
 Systems Analysis and Design: A Simplified Approach | 15
____________________________________________________________________

CHAPTER TWO

Overview of Systems Analysis and Design

2.0 Introduction
Till now we have studied what systems are, their components, classification of
systems. Now we will look into the different aspects of how these systems are
built.

Any change in the existing policies of an organization may require the existing
information system to be restructured or complete development of a new
information system. In case of an organization functioning manually and
planning to computerize its functioning, the development of a new information
system would be required.

The development of any information system can be put into two major phases:
Analysis and Design. During analysis phase the complete functioning of the
system is understood and requirements are defined which lead to designing of a
new system. Hence the development process of a system is also known as
System Analysis and Design process.

2.1 What is Systems Analysis and Design?

System development can generally be thought of having two major components:

systems analysis and systems design. In System Analysis more emphasis is given
to understanding the details of an existing system or a proposed one and then
deciding whether the proposed system is desirable or not and whether the
existing system needs improvements. Thus, system analysis is the process of
investigating a system, identifying problems, and using the information to
recommend improvements to the system.
 Systems Analysis and Design: A Simplified Approach | 16
____________________________________________________________________

System design is the process of planning a new business system or one to replace
or complement an existing system.

Analysis specifies what the system should do. Design states how to accomplish
the objective.

After the proposed system is analyzed and designed, the actual implementation
of the system occurs. After implementation, working system is available and it
requires timely maintenance.

2.2 Role of System Analyst

The system analyst is the person who guides through the development of an
information system. In performing these tasks the analyst must always match the
information system objectives with the goals of the organization.

Role of System Analyst differs from organization to organization. Most common

responsibilities of System Analyst are follows:

1) System analysis: It includes system's study in order to get facts about

business activity. It is about getting information and determining requirements.
Here the responsibility includes only requirement determination, not the design
of the system.

2) System analysis and design: Here apart from the analysis work, Analyst is
also responsible for the designing of the new system/application.

3) Systems analysis, design, and programming: Here Analyst is also required

to perform as a programmer, where he actually writes the code to implement the
design of the proposed application.

2.3 Critical Success Factors of a System Analyst

Due to the various responsibilities that a system analyst requires to handle, he has
to be multifaceted person with varied skills required at various stages of the life
cycle. In addition to the technical know-how of the information system
development a system analyst should also have the following knowledge.
 Systems Analysis and Design: A Simplified Approach | 17
____________________________________________________________________

1. Interpersonal skills (communication, work alone and with a team, facilitating

groups, managing expectations)
2. Analytical skills (systems thinking, organizational knowledge, problem
identification, problem analysing and solving)
3. Management skills (resource management, project management, risk
management, change management)
4. Technical skills (understand how technologies work, their potential and
limitations; stay versatile and up-to-date; understand technical concepts rather
than specific tools)
1. Integrating technologies: Web, Enterprise Resource Planning (ERP),
m-commerce
2. CASE tools

Types of CASE tools Users Example

Upper CASE Analysts DFD, ER
Lower CASE Programmers Code generator

Benefits of using CASE

1. Increase productivity
2. Improve communication
3. Integrate activities
4. Assess maintenance changes

2.4 Users of System (System End Users)

The system end users of the system refer to the people who use computers to
perform their jobs, like desktop operators. Further, end users can be divided into
various categories.

Very first users are the hands-on users. They actually interact with the system.
They are the people who feed in the input data and get output data. Like person
at the booking counter of a gas authority. This person actually sees the records
and registers requests from various customers for gas cylinders.

Other users are the indirect end users who do not interact with the systems
hardware and software. However, these users benefit from the results of these
systems. These types of users can be managers of organization using that system.
 Systems Analysis and Design: A Simplified Approach | 18
____________________________________________________________________

There are third types of users who have management responsibilities for
application systems. These oversee investment in the development or use of the
system.

Fourth types of users are senior managers. They are responsible for evaluating
organization's exposure to risk from the systems failure.

Now we know what systems are and what is systems analysis and design. So let
us take a case in which we‘ll apply the concepts we have learned in the chapter.
The case would be referred to where necessary throughout the book and in this
process we will be developing the system required.

2.5 Case Study: Noble Library System

Noble Public Library is the biggest library in Port Harcourt! Currently it has
about 500 members. A person who is 18 years or above can become a member.
There is a membership fee of N500 for a year. There is a form to be filled in
which person fills personal details. These forms are kept in store for maintaining
members‘ records and knowing the membership period.

A member can issue a maximum of three books. He/she has three cards to issue
books. Against each card a member can issue one book from library. Whenever a
member wishes to issue a book and there are spare cards, then the book is issued.
Otherwise that request is not entertained. Each book is to be returned on the
specified due date. If a member fails to return a book on the specified date, a fine
of N10 per day after the due return date is charged. If in case a card gets lost then
a duplicate card is issued. Accounts are maintained for the membership fees and
money collected from the fines. There are two librarians for books return and
issue transaction. Approximately 100 members come to library daily to issue and
return books.

There are 5000 books available out of which 1000 books are for reference and
cannot be issued. Records for the books in the library are maintained. These
records contain details about the publisher, author, subject, language, etc. There
are suppliers that supply books to the library. Library maintains records of these
suppliers.
 Systems Analysis and Design: A Simplified Approach | 19
____________________________________________________________________

Many reports are also produced. These reports are for details of the books
available in the library, financial details, members‘ details, and supplier‘s details.

Currently all functions of the library are done manually. Even the records are
maintained on papers. Now day by day members are increasing. Maintaining
manual records is becoming difficult task. There are other problems also that the
library staff is facing; like in case of issue of duplicate cards to a member when
member or library staff loses the card. It is very difficult to check the genuity of
the problem.

Sometimes the library staff needs to know about the status of a book as to
whether it is issued or not. So to perform this kind of search is very difficult in a
manual system.

Also management requires reports for books issued, books in the library,
members, and accounts. Manually producing the reports is a cumbersome job
when there are hundreds and thousands of records.

Management plans to expand the library, in terms of books, number of members

and finally the revenue generated. It is observed that every month there are at
least 50-100 requests for membership. For the last two months the library has not
entertained requests for the new membership as it was difficult to manage the
existing 250 members manually. With the expansion plans, the management of
the library aims to increase its members at the rate of 75 per month. It also plans
to increase the membership fees from 400 to 1000 for yearly and 500 for half
year, in order to provide its members better services, which includes increase in
number of books from 3 to 4.

Due to the problems faced by the library staff and its expansion plans, the
management is planning to have a system that would first eradicate the needs of
cards. The system will automate the functions of record keeping and report
generation, which could help in executing the different searches in a faster
manner. The system will also handle the financial details.
 Systems Analysis and Design: A Simplified Approach | 20
____________________________________________________________________

Figure 2.1: Case Study: Noble Library System

2.6 Applying the concepts studied so far to the Case Study:

The first thing we studied is system. In our case study Noble Public Library is
our system. Every system is a set of some functional units that work together to
achieve some objective. The main objective of library system is to provide books
to its members without difficulty. Figure 2.1 depicts our library system
pictorially.

Our system has many functional units. Books issue and return section, books
record unit, members‘ record unit, accounts, and report generation units are the
different functional units of the library. Each functional unit has its own task.
However, each of these works independently to achieve the overall objective of
the library.

Later in the session, we talked about different components and characteristics of

the systems. Data is an important component of any system. Here, data is
pertaining to the details of members, books, accounts, and suppliers. Since
people can interact with the system this system is an open system. The system is
mainly concerned with the management of data it is an information system.
 Systems Analysis and Design: A Simplified Approach | 21
____________________________________________________________________

If this system was to be automated as conceived by the management, then role of

the system analyst would be to study the system, its workings, and its existing
problems. Also the analyst needs to provide a solution to the existing problem.

Now that the management has decided for an automated system the analyst
would perform the above tasks. As the analyst did the study of the system, the
following problems were identified

 Maintaining membership cards

 Producing reports due to large amount of data
 Maintaining accounts
 Keeping records for books in library and its members
 Performing searches

Now that the analyst has studied the system and identified the problems, it is the
responsibility of the analyst to provide a solution system to the management of
the library.

2.7 Summary

 Systems Analysis and Design refers to the application of systems

approach to problem solving.
 The system analyst is the person (or persons) who guides through the
development of an information system.
 In performing these tasks the analyst must always match the information
system objectives with the goals of the organization.
 Role of System Analyst differs from organization to organization.

2.8 Review Questions

1. What is system analysis and design?

2. What are the roles of system analyst?
3. Make a list of traits that a system analyst should have.
4. Will the responsibility of a system analyst vary according to:
(a) Organization size( for example small or large business)?
(b) Type of organization (business, government agency, non-profit
organization)?
 Systems Analysis and Design: A Simplified Approach | 22
____________________________________________________________________

CHAPTER THREE

System Development Life Cycle

3.0 Introduction
The Systems Development Life Cycle (SDLC) is the process of understanding
how an Information System (IS) can support business needs, designing the
system, building it, and delivering it to users.

The key person in the SDLC is the systems analyst who analyzes the business
situation, identifies opportunities for improvements, and designs an information
system to implement them. Being a systems analyst is one of the most
interesting, exciting, and challenging jobs around. As a systems analyst, you will
work with a variety of people and learn how they conduct business. Specifically,
you will work with a team of systems analysts, programmers, and others on a
common mission. You will feel the satisfaction of seeing systems that you
designed and developed make a significant business impact, while knowing that
your unique skills helped make that happen.

It is important to remember that the primary objective of the systems analyst is

not to create a wonderful system. The primary goal is to create value for the
organization, which for most companies means increasing profits (government
agencies and not-for-profit organizations measure value differently). Many failed
systems were abandoned because the analysts tried to build a wonderful system
without clearly understanding how the system would support the organization‘s
goals, current business processes, and other information systems to provide
value. An investment in an information system is like any other investment, such
as a new machine tool. The goal is not to acquire the tool, because the tool is
simply a means to an end; the goal is to enable the organization to perform work
better so it can earn greater profits or serve its constituents more effectively.
 Systems Analysis and Design: A Simplified Approach | 23
____________________________________________________________________

3.1 The Systems Development Life Cycle

System life cycle is an organizational process of developing and maintaining
systems. It is a step by step approach to solving business problems. It helps in
establishing a system project plan, because it gives overall list of processes and
sub-processes required for developing a system. System development life cycle
means combination of various activities. In other words we can say that various
activities put together are referred as system development life cycle.

In many ways, building an information system is similar to building a house.

First, the house (or the information system) starts with a basic idea. Second, this
idea is transformed into a simple drawing that is shown to the customer and
refined (often through several drawings, each improving on the other) until the
customer agrees that the picture depicts what he or she wants. Third, a set of
blueprints is designed that presents much more detailed information about the
house (e.g., the type of water faucets, where the telephone jacks will be placed).
Finally, the house is built following the blueprints—and often with some changes
and decisions made by the customer as the house is erected.

The SDLC has a similar set of four fundamental phases: planning, analysis,
design, and implementation. Different projects may emphasize different parts
of the SDLC or approach the SDLC phases in different ways, but all projects
have elements of these four phases. Each phase is itself composed of a series of
steps, which rely on techniques that produce deliverables (specific documents
and files that provide understanding about the project).

For example, when you apply for admission to a university/polytechnic, there are
several phases that all students go through: information gathering, applying, and
accepting. Each of these phases has steps: information gathering includes steps
like searching for schools, requesting information, and reading brochures.
Students then use techniques (e.g., Internet searching) that can be applied to steps
(e.g., requesting information) to create deliverables (e.g., evaluations of different
aspects of universities). Figure 3.1 suggests that the SDLC phases and steps
proceed in a logical path from start to finish. In some projects, this is true, but in
many projects, the project teams move through the steps consecutively,
incrementally, iteratively, or in other patterns. In this section, we describe the
phases, steps, and some of the techniques that are used to accomplish the steps.

Following are the different phases of system development life cycle:

 Systems Analysis and Design: A Simplified Approach | 24
____________________________________________________________________

1. Planning:
o Preliminary/System Study
o Feasibility Study
2. Analysis
3. Design
4. Implementation
o Coding
o Testing/Integration
o Implementation/Installation/Deployment
o Maintenance/Evaluation

The different phases of system development life cycle are shown in this diagram

Figure 3.1 Different Phases of Phases of System Development Life Cycle

3.2 Phases of Systems Development Life Cycle

Let us now describe the different phases and related activities of systems
development life cycle.

(a) Preliminary System Study

Preliminary system study is the first stage of system development life cycle. This
is a brief investigation of the system under consideration and gives a clear
picture of what actually the physical system is. It initiates with a project request
 Systems Analysis and Design: A Simplified Approach | 25
____________________________________________________________________

and attempts to answer the question Why build this system? The main aim of
preliminary analysis is to identify the problem. First, need for the new or the
enhanced system is established. Only after the recognition of need, for the
proposed system is done then further analysis is possible.

In practice, the initial system study involves the preparation of a ‘System

Proposal’ which lists the Problem Definition, Objectives of the Study, Terms of
reference for Study, Constraints, and Expected benefits of the new system, etc. in
the light of the user requirements.

In the first step, the preliminary survey of the system is done which helps in
identifying the scope of the system. The second step of the system study is more
detailed and in-depth study in which the identification of user‘s requirement and
the limitations and problems of the present system are studied. After completing
the system study, a system proposal is prepared by the System Analyst (who
studies the system) and placed before the user management. The proposed
system contains 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 management may accept the proposal and the cycle proceeds to the next
stage. The management may also reject the proposal or request some
modifications in the proposal. In summary, we would say that system study
phase passes through the following steps:

 Problem identification and project initiation

 Background analysis
 Inference or findings (system proposal)

Once the initial investigation is done and the need for new or improved system is
established, all possible alternate solutions are chalked out. All these systems are
known as "candidate systems". All the candidate systems are then weighed and
the best alternative of all these is selected as the solution system, which is termed
as the "proposed system". The proposed system is evaluated for its feasibility.
Feasibility for a system means whether it is practical and beneficial to build that
system.
 Systems Analysis and Design: A Simplified Approach | 26
____________________________________________________________________

(b) Feasibility Study

Incase the system proposal is acceptable to the management, the next phase is to
examine the feasibility of the system. 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. In the process of feasibility study, the cost and benefits are estimated with
greater accuracy to find the Return on Investment (ROI). This also defines the
resources needed to complete the detailed investigation. The result is a feasibility
report submitted to the management. This may be accepted or accepted with
modifications or rejected. The system cycle proceeds only if the management
accepts it.

Feasibility is evaluated from developer and customer's point of view. Developer

sees whether they have the required technology or manpower to build the new
system. Is building the new system really going to benefit the customer? Does
the customer have the required money to build that type of a system? All these
issues are covered in the feasibility study of the system. The feasibility of the
system is evaluated on the three main issues: technical, economical, and
operational. Another issue in this regard is the legal feasibility of the project.

1. Technical feasibility: Can the development of the proposed system be

done with current equipment, existing software technology, and available
personnel? Does it require new technology?
2. Economic feasibility: Are there sufficient benefits in creating the system
to make the costs acceptable? An important outcome of the economic
feasibility study is the cost benefit analysis.
3. Legal feasibility: It checks if there are any legal hassle in developing the
system.
4. Operational feasibility: Will the system be used if it is developed and
implemented? Will there be resistance from users that will undermine the
possible application benefits?

The result of the feasibility study is a formal document, a report detailing the
nature and scope of the proposed solution.
 Systems Analysis and Design: A Simplified Approach | 27
____________________________________________________________________

Once the feasibility study is done then the project is approved or disapproved
according to the results of the study. If the project seems feasible and desirable
then the project is finally approved otherwise no further work is done on it.

(c) System Analysis

Systems Analysis involves detailed study of the current system, leading to
specifications of a new system. Systems analysis is a process of collecting factual
data, understanding the processes involved, identifying problems and
recommending feasible suggestions for improving the system functioning. This
involves studying the business processes, gathering operational data, understand
the information flow, finding out bottlenecks and evolving solutions for
overcoming the weaknesses of the system so as to achieve the organizational
goals. System Analysis also includes subdividing of complex process involving
the entire system, identification of data store and manual processes.

The major objectives of systems analysis are to find answers for each business
process: What is being done, How is it being done, Who is doing it, When is he
doing it, Why is it being done and How can it be improved, Who will use the
system, What the system will do, Where and When it will be used? It is more
of a thinking process and involves the creative skills of the System Analyst. It
attempts to give birth to a new efficient system that satisfies the current needs of
the user and has scope for future growth within the organizational constraints.
The result of this process is a logical system design. Systems analysis is an
iterative process that continues until a preferred and acceptable solution emerges.

(d) System Design

Based on the user requirements and the detailed analysis of the existing system,
the new system must be designed. The design phase attempts to answer the
question: How will this system work? It is the most crucial phase in the
developments of a system. The logical system design arrived at as a result of
systems analysis is converted into physical system design.

In the design stage, the programming language and the hardware and software
platform in which the new system will run are also decided. The system design
involves.

i. Defining precisely the required system output

ii. Determining the data requirement for producing the output
 Systems Analysis and Design: A Simplified Approach | 28
____________________________________________________________________

iii. Determining the medium and format of files and databases

iv. Devising processing methods and use of software to produce output
v. Determine the methods of data capture and data input
vi. Designing Input forms
vii. Designing Codification Schemes
viii. Detailed manual procedures
ix. Documenting the Design

(e) Coding
The system design needs to be implemented to make it a workable system. This
demands the coding of design into computer understandable language, i.e.,
programming language. This is also called the programming phase in which the
programmer converts the program specifications into computer instructions,
which we refer to as programs. It is an important stage where the defined
procedures are transformed into control specifications by the help of a computer
language. The programs coordinate the data movements and control the entire
process in a system. It is generally felt that the programs must be modular in
nature. This helps in fast development, maintenance and future changes, if
required.

(f) Testing
Before actually implementing the new system into operation, a test run of the
system is done to remove bugs, if any. It is an important phase of a successful
system. After codifying the whole programs of the system, a test plan should be
developed and run on a given set of test data. The output of the test run should
match the expected results. Sometimes, system testing is considered a part of
implementation process. Using the test data following test run are carried out:

 Unit/Program test
 System test

When it is ensured that the system is running error-free, the users are called with
their own actual data so that the system could be shown running as per their
requirements.
 Systems Analysis and Design: A Simplified Approach | 29
____________________________________________________________________

(g) Implementation
After having the user acceptance of the new system developed, the
implementation phase begins. Implementation is the stage of a project during
which theory is turned into practice. The major steps involved in this phase are:

 Acquisition and Installation of Hardware and Software

 Conversion
 User Training
 Documentation

(i) Maintenance
Maintenance is necessary to eliminate errors in the system during its working life
and to tune the system to any variations in its working environments. It has been
seen that there are always some errors found in the systems that must be noted
and corrected. It also means the review of the system from time to time. The
review of the system is done for:

 knowing the full capabilities of the system

 knowing the required changes or the additional requirements
 studying the performance.

If a major change to a system is needed, a new project may have to be set up to

carry out the change. The new project will then proceed through all the above life
cycle phases.

The table below summarizes the different phases of System Development Life
Cycle, their purposes, tool used and deliverables.
 Systems Analysis and Design: A Simplified Approach | 30
____________________________________________________________________

Phases Purposes Tools used Deliverables

Project Identify business Feasibility Feasibility

identification problems, opportunities impact grid report
and objectives
Systems planning Study the current systems Interview Current
and requirements and understand user needs Data sampling system
analysis Questionnaire description
Observation
Systems analysis Study system needs and DFD System
propose alternative Data dictionary proposal
solutions Structured
English
Decision
tree/table
Systems logical Describe the functional DFD System
design features (independent of ERD specifications
any computer platform) of System
the system flowchart
Systems physical Transform the logical Structure chart
design design into technology- N-S chart manuals
specific details Pseudocode
Systems Test and install the system TQM
implementation manuals

plan
Systems Repair and improve the IS utility New and
evaluation/Maint system improved
enance systems

3.3 Systems Development Methodologies

This section discusses the most popular methods for developing computer-based
information systems. A software development methodology (also known as
a system development methodology, software development life cycle, software
development process, and software process) is a division of software
 Systems Analysis and Design: A Simplified Approach | 31
____________________________________________________________________

development work into distinct phases (or stages) containing activities with the
intent of better planning and management. It is often considered a subset of
the systems development life cycle. The methodology may include the pre-
definition of specific deliverables and artifacts that are created and completed by
a project team to develop or maintain an application.
A popular, traditional method is called structured analysis, 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 vendors or consultants. Most IT experts agree
that no single, best system development strategy exists. Instead, a systems
analyst should understand the alternative methods and their strengths and
weaknesses.

Figure 3.2: The three basic approaches applied to software development

methodology frameworks.
 Systems Analysis and Design: A Simplified Approach | 32
____________________________________________________________________

Other common methodologies include waterfall, prototyping, iterative and

incremental development, spiral development, rapid application development,,
extreme programming and agile methodology. Some people consider a life-cycle
"model" a more general term for a category of methodologies and a software
development "process" a more specific term to refer to a specific process chosen
by a specific organization. For example, there are many specific software
development processes that fit the spiral life-cycle model.

Waterfall Model
The waterfall model is a sequential design process, used in software development
process, in which progress is seen as flowing steadily downwards (like
a waterfall), through several phases, typically:
 Requirement Analysis; resulting in a software requirements specification
and models, schema, and business rules.
 Design: resulting in the software architecture
 Implementation: the development, proving and integration of software
 Testing: the systematic discovery and debugging of defects
 Integration, if there are multiple subsystems
 Deployment (or Installation): the installation, migration, support.
 Maintenance; maintenance of complete systems

The waterfall model is a traditional engineering approach applied to software

engineering. A strict waterfall approach discourages revisiting and revising any
prior phase once it is complete. This "inflexibility" in a pure waterfall model has
been a source of criticism by supporters of other more "flexible" models. It has
been widely blamed for several large-scale government projects running over
budget, over time and sometimes failing to deliver on requirements due to
the Big Design Up Front approach. Except when contractually required, the
waterfall model has been largely superseded by more flexible and versatile
methodologies developed specifically for software development.
 Systems Analysis and Design: A Simplified Approach | 33
____________________________________________________________________

Figure 3.3: The activities of the software development process represented in the
waterfall model. Progress flows from the top to the bottom, like a cascading
waterfall.

Rapid Application Development (RAD) Methodology

Rapid Application Development (RAD) is a software development methodology,
which favors iterative development and the rapid construction of prototypes
instead of large amounts of up-front planning. The "planning" of software
developed using RAD is interleaved with writing the software itself. The lack of
extensive pre-planning generally allows software to be written much faster, and
makes it easier to change requirements.
The rapid development process starts with the development of preliminary data
models and business process models using structured techniques. In the next
stage, requirements are verified using prototyping, eventually to refine the data
and process models. These stages are repeated iteratively; further development
results in "a combined business requirements and technical design statement to
be used for constructing new systems".
 Systems Analysis and Design: A Simplified Approach | 34
____________________________________________________________________

Figure 3.4: Rapid Application Development (RAD) Model

The basic principles of rapid application development are:

 Key objective is for fast development and delivery of a high quality

system at a relatively low investment cost.
 Attempts to reduce inherent project risk by breaking a project into smaller
segments and providing more ease-of-change during the development
process.
 Aims to produce high quality systems quickly, primarily via iterative
Prototyping (at any stage of development), active user involvement, and
computerized development tools. These tools may include Graphical User
Interface(GUI) builders, Computer Aided Software Engineering (CASE)
tools, Database Management Systems (DBMS),fourth-generation
programming languages, code generators, and object-oriented techniques.
 Key emphasis is on fulfilling the business need, while technological or
engineering excellence is of lesser importance.
 Project control involves prioritizing development and defining delivery
deadlines or ―timeboxes‖. If the project starts to slip, emphasis is on
reducing requirements to fit the timebox, not in increasing the deadline.
 Generally includes joint application design (JAD), where users are
intensely involved in system design, via consensus building in either
structured workshops, or electronically facilitated interaction.
 Active user involvement is imperative.
 Systems Analysis and Design: A Simplified Approach | 35
____________________________________________________________________

 Iteratively produces production software, as opposed to a throwaway

prototype.
 Produces documentation necessary to facilitate future development and
maintenance.
 Standard systems analysis and design methods can be fitted into this
framework.

Prototyping
Software prototyping is the activity of creating prototypes of software
applications, i.e., incomplete versions of the software program being developed.
A prototype typically simulates only a few aspects of, and may be completely
different from, the final product.
The process of prototyping involves the following steps
1. Identify basic requirements
Determine basic requirements including the input and output information
desired. Details, such as security, can typically be ignored.
2. Develop Initial Prototype
The initial prototype is developed that includes only user interfaces.
3. Review
The customers, including end-users, examine the prototype and provide
feedback on additions or changes.
4. Revise and Enhance the Prototype
Using the feedback both the specifications and the prototype can be
improved. Negotiation about what is within the scope of the
contract/product may be necessary. If changes are introduced then a
repeat of steps #3 and #4 may be needed
 Systems Analysis and Design: A Simplified Approach | 36
____________________________________________________________________

Spiral Model
The spiral model is a risk-driven process model generator for software projects.
Based on the unique risk patterns of a given project, the spiral model guides a
team to adopt elements of one or more process models, such as incremental,
waterfall, or evolutionary prototyping.

Figure 3.5: Spiral model

The spiral methodology extends the waterfall model by introducing prototyping.
It is generally chosen over the waterfall approach for large, expensive, and
complicated projects.

At a high-level, the steps in the spiral model are as follows:

1. The new system requirements are defined in as much detail as possible.
This usually involves interviewing a number of users representing all the
external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. Evaluate the first prototype and identify its strengths, weaknesses, and
risks.
 Define the requirements of the second prototype.
 Plan and design the second prototype.
 Systems Analysis and Design: A Simplified Approach | 37
____________________________________________________________________

 Construct and test the second prototype.

4. At the project sponsor's option, the entire project can be aborted if the risk
is deemed too great. Risk factors might involve development cost
overruns, operating-cost miscalculation, or any other factor that could
result in a less-than-satisfactory final product.
5. The existing prototype is evaluated in the same manner as was the
previous prototype, and, if necessary, another prototype is developed from
it according to the fourfold procedure outlined above.
6. The preceding steps are iterated until the customer is satisfied that the
refined prototype represents the final product desired.
7. The final system is constructed, based on the refined prototype.
8. The final system is thoroughly evaluated and tested. Routine maintenance
is carried out on a continuing basis to prevent large-scale failures and to
minimize downtime.
Incremental Methodology
Various methods are acceptable for combining linear and iterative systems
development methodologies, with the primary objective of each being to reduce
inherent project risk by breaking a project into smaller segments and providing
more ease-of-change during the development process.
The basic principles are:

 A series of mini-Waterfalls are performed, where all phases of the

Waterfall are completed for a small part of a system, before proceeding to
the next increment, or
 Overall requirements are defined before proceeding to evolutionary, mini-
Waterfall development of individual increments of a system, or
 The initial software concept, requirements analysis, and design of
architecture and system core are defined via Waterfall, followed by
iterative Prototyping, which culminates in installing the final prototype, a
working system.
 Systems Analysis and Design: A Simplified Approach | 38
____________________________________________________________________

Code and fix

"Code and fix" development is not so much a deliberate strategy as a result of
schedule pressure on software developers. Without much of a design in the
way, programmers immediately begin producing code. At some
point, testing begins (often late in the development cycle), and the
unavoidable bugs must then be fixed before the product can be shipped.
Programming without a planned-out design is also known as cowboy coding.

3.4 Summary

 System life cycle is an organizational process of developing and

maintaining systems. It is a step by step approach to solving business
problems.
 The SDLC has four fundamental phases: planning, analysis, design, and
implementation which can further be broken down into smaller phases.
 Each phase is itself composed of a series of steps, which rely on
techniques that produce deliverables.
 Common software development methodologies
include waterfall, prototyping, iterative and incremental
development, spiral development, rapid application development, etc.

3.5 Review Questions

1. What do you understand by system development life cycle?

2. Discuss the importance of system analysis and design in the development
of a system.
3. What are deliverables? State the main deliverables from each phase of
Systems Development Life Cycle.
4. Why is a system proposal so crucial for system design?
5. How would an analysis determine the users‘ needs for a system? Explain.
6. Distinguish between initial investigation and feasibility study. In what
way are they related?
7. There are several considerations in deciding on a candidate system. What
are they? Why are they important?
 Systems Analysis and Design: A Simplified Approach | 39
____________________________________________________________________

CHAPTER FOUR

Preliminary Investigation and Feasibility Study

4.0 Introduction
The first step in the system development life cycle is the identification of a need.
This is a user‘s request to change, improve or enhance an existing system.
Because there is likely to be a stream of such requests, standard procedures must
be established to deal with them. The objective of project selection is to
determine whether the request is valid and feasible before a recommendation is
reached to do nothing, improve or modify the existing system or build a new one.

The user request identifies the need for change and authorizes the initial
investigation. It may undergo several modifications before it becomes final. The
success of a system depends largely on how accurately a problem is defined. The
user‘s request must be communicated if the organization‘s personnel and other
resources are to be successfully mobilized to build and maintain a viable
information system plan.

Each problem has generally more than one solution. Each such approach has
costs and benefits that are compared with those of other approaches before a final
recommendation is made. The result is a project proposal. The findings of the
analysis are summarized and the design is recommended.

4.1 Sources of Project Requests

There are four primary sources of project requests. The requesters inside the
organization are department managers, senior executives, and systems analysts.
In addition, government agencies outside the organization may request
information systems projects. Depending on the origin of the request and the
reason for it, requesters may seek either completely new applications or changes
in existing ones.
 Systems Analysis and Design: A Simplified Approach | 40
____________________________________________________________________

4.2 Determining the User’s Information Requirements

Shared, complete and accurate information requirements are essential in building
computer–based information systems. Unfortunately, determining the
information each user needs is particularly difficult task. In fact, it is recognized
as one of the most difficult tasks in system development.

There are several reasons why it is difficult to determine user requirements:

1. Systems requirements change and user requirements must be modified to
account for those these changes.
2. The articulation of requirements is difficult, except for experienced users.
Functions and processes are not easily described.
3. Heavy user involvement and motivation are difficult. Reinforcement for
their work is usually not realized until the implementation phase – too
long to wait.
4. The pattern of interaction between users and analysts in designing
information requirements is complex.

Users and analysts traditionally do not share a common orientation toward

problem definition. For example, in the analyst‘s view the problem definition
must be translatable into a system design expressed quantitatively in terms of
outputs, inputs, processes and data structures. This is the best of situations, and
within time constraints. In contrast, the user seems to be satisfied with a
qualitative definition that specifies the system in generalities. Flexibility is a key
consideration. System specifications must change with their needs, as must the
system after implementation.

4.3 Strategies for Determining Information Requirements

There are three key strategies or general approaches for eliciting information
regarding the user‘s requirements:
(1) asking,
(2) getting information form the existing information system, and
(3) prototyping.

 Asking:
This strategy obtains information from users by simply asking them about the
requirements. It assumes a stable system where users are well informed and can
overcome biases in defining their problems. There are three key asking methods:
 Systems Analysis and Design: A Simplified Approach | 41
____________________________________________________________________

1. Questions may be open-ended or closed. An open-ended question allows

the respondent to formulate a response. It is used when feeling or
opinions are important. For example, ―How do you evaluate the latest
addition to your hardware?‖ In contrast, a closed question requests one
answer from a specific set or responses. It is used when factual responses
are known. For example, ―How long have you been manager of the
computer center?‖
2. Brainstorming is a technique used for generating new ideas and obtaining
general information requirements. During brainstorming each participant
is asked to define ideal solutions and then select the best feasible one. It
works well for users who have system knowledge but have difficulty
accepting new ideas.
3. Group consensus asks participants for their expectations regarding
specific variables. Each participant may be required to fill out a
questionnaire. The results are summarized and given to participants along
with a follow-up questionnaire. Participants are invited to change their
responses. The results are again summarized and fed back to the
participants. This debate by questionnaire continues until participants‘
responses have converged enough. This method is an advantage over
brainstorming in that participants are not subjected to psychological
pressure from others with presumed authority or influence.

 Getting Information from the Existing Information System.

Determining information from an existing application has been called the data
analysis approach. It simply asks the user what information is currently received
and what other information is required. It relies heavily on the user to articulate
information needs. The analyst examines all reports, discusses with the user each
piece of information examined, and determines unfulfilled information needs by
interviewing the user. The analyst is primarily involved in improving the existing
flow of data to the user. In contrast to this method is decision analysis. This
breaks down a problem into parts, which allows the user to focus separately on
the critical issues. It also determines policy and organizational objectives
relevant to the decision areas identified and the specific steps required to
complete each major decision. Then the analyst and the user refine the decision
process and the information requirements for a final statement of information
requirements. The data analysis method is ideal for making structured decisions,
although it requires that users articulate their information requirements. A major
drawback is a lack of established rules for obtaining and validating information
 Systems Analysis and Design: A Simplified Approach | 42
____________________________________________________________________

needs that are not linked to organizational objectives. In the decision analysis
method, information needs are clearly linked to decision and organizational
objectives. It is useful for unstructured decisions and information tailored to the
user‘s decision-making style. The major drawback, though, is that information
requirements may change when the user is promoted or replaced.

4.3.3 Prototyping
The third strategy for determining user information requirements is used when
the user cannot establish information needs accurately before the information
system is built. The reason could be the lack of an existing model n which to
base requirements or a difficulty in visualizing candidate systems. In this case,
the user needs to anchor on real life systems from which adjustments can be
made. Therefore, the iterative discovery approach captures an initial set of
information requirements and builds a system to meet these requirements. As
user gain experience in its use, they request additional requirements or
modifications (iterations), in the system in essence, information requirements are
discovered by using the system.

Prototyping is suitable in environments where it is difficult to formulate a

concrete model for defining information requirements and where the information
needs of the user are evolving, such as in DSS. Which of the three strategies is
selected depends on uncertainties in the process of determining information
requirements – that is, uncertainly with respect to the stability of information
requirements, the user‘s ability to articulate information requirements, and the
ability of the analyst to elicit requirements and evaluate their accuracy. Thus, the
asking strategy is appropriate for low- uncertainty information requirements
determinations, whereas the prototyping strategy is appropriate for high
uncertainty information requirements determination

4.4 Preliminary Investigation

Whether a system will be developed by means of the systems development life
cycle method (SDLC) prototyping strategy, or the structured analysis method, or
a combination of these methods, a project request should first be reviewed. The
choice of development strategy is secondary to whether a request merits the
investment of organization‘s resources in an information system project. It is
advisable for all proposals to be submitted to the selection committee for
evaluation to identify those projects that are most beneficial to the organization.
 Systems Analysis and Design: A Simplified Approach | 43
____________________________________________________________________

The preliminary investigation is then carried out by systems analysts, working

under the direction of the selection committee.

The purpose of the preliminary investigation is to evaluate project requests. It is

not a design study, nor does it include the collection of details to completely
describe the business system. Rather, it is the collecting of information that
permits committee members to evaluate the merits of the project request and
make an informed judgment about the feasibility of the proposed project.
Analysts working on the preliminary investigation should accomplish the
following objectives:

1. Clarify and understand the project request. What is being done? What is
required?
2. Determine the size of the project.
3. Assess costs and benefits of alternative approaches.
4. Determine the technical and operational feasibility of alternative
approaches.
5. Report the findings to management, with recommendations outlining the
acceptance or rejection of the proposal.

4.5 Conducting the Investigation

The data that the analysts collect during preliminary investigations are gathered
through two primary methods: reviewing documents and interviewing selected
company personnel.

Reviewing Organization Documents: The analysts conducting the investigation

first learn about the organization involved in, or affected by, the project.

Conducting Interviews: Interviews allow analysts to learn more about the

nature of the project request and the reason for submitting it. To accomplish the
purpose of the interviews, analysts must be sure to emphasize the request and the
problem it addresses. In other words, interviews should provide details that
further explain the project and show whether assistance is merited economically,
operationally, and technically. Working out a solution to the situation comes
later, during the detailed investigation. Usually, preliminary investigation
interviews involve only management and supervisory personnel.
 Systems Analysis and Design: A Simplified Approach | 44
____________________________________________________________________

4.6 Testing Project Feasibility

Preliminary investigations examine project feasibility; the likelihood the system
will be useful to the organization. Three tests of feasibility-all equally important-
are studied: operational, technical and economic (financial).

A feasibility study is a preliminary study undertaken before the real work of a

project starts to ascertain the likelihood of the project's success. It is an analysis
of possible solutions to a problem and a recommendation on the best solution to
use. It involves evaluating how the solution will fit into the corporation. It, for
example, can decide whether an order processing be carried out by a new system
more efficiently than the previous one.

4.6.1 What Is a Feasibility Study?

A feasibility study is defined as an evaluation or analysis of the potential impact

of a proposed project or program. A feasibility study is conducted to assist
decision-makers in determining whether or not to implement a particular project
or program. The feasibility study is based on extensive research on both the
current practices and the proposed project/program and its impact on the selected
organization operation. The feasibility study will contain extensive data related
to financial and operational impact and will include advantages and
disadvantages of both the current situation and the proposed plan.

This analytical tool used during the project planning process shows how a
business would operate under a set of assumptions - the technology used (the
facilities, equipment, production process, etc.) and the financial aspects (capital
needs, volume, cost of goods, wages etc.). The study is the first time in a project
development process that the pieces are assembled to see if they perform together
to create a technical and economically feasible concept. The study also shows the
sensitivity of the business to changes in these basic assumptions.

The feasibility study evaluates the project‘s potential for success. The perceived
objectivity of the evaluation is an important factor in the credibility placed on the
study by potential investors and financiers. Also, the creation of the study
requires a strong background both in the financial and technical aspects of the
project. For these reasons, outside consultants conduct most studies.
 Systems Analysis and Design: A Simplified Approach | 45
____________________________________________________________________

A feasibility study could be used to test a new working system, which could be
used because:

 The current system may no longer suit its purpose,

 Technological advancement may have rendered the current system
redundant,
 The business is expanding, allowing it to cope with extra work load,
 Customers are complaining about the speed and quality of work the
business provides,
 Competitors are not winning a big enough market share due to an
effective integration of a computerized system.

4.6.2 Content of a Feasibility Study

Things to be studied in the feasibility study:
a. The present organizational system
Stakeholders, users, policies, functions, objectives...
b. Description of the existing System (including Problems with the present
system
inconsistencies, inadequacies in functionality, performance…
c. Goals and other requirements for the new system
Which problem(s) need to be solved?
What would the stakeholders like to achieve?
d. Description Criteria
essential requirements and desirable features of the proposed system
e. Constraints
including nonfunctional requirements on the system (preliminary pass)
f. Possible alternatives
―Sticking with the current system‖ is always an alternative
Different business processes for solving the problems
Different levels/types of computerization for the solutions
g. Advantages and disadvantages of the alternatives

4.6.3 The System Proposal and Feasibility Study Report

The final decision following cost/benefit analysis is to select the most cost-
effective and beneficial system for the user. At this time, the analyst prepares a
feasibility report on the major findings and recommendations. It outlines the
options and recommendations. It is presented to management for determining
whether a candidate system should be designed.
 Systems Analysis and Design: A Simplified Approach | 46
____________________________________________________________________

TITLE PAGE Defines the name of the project and who it is for

I. TABLE OF CONTENTS
a. List various parts, features and exhibits, showing page numbers
II. SCOPE/TERMS OF REFERENCE
a. Present a brief explanation of the system boundaries, objectives and
constraints.
III. STATEMENT OF PROBLEM
a. Describe current system (including any problems and the projected
costs), Describe proposed system
b. Describe the criteria (essential requirements and desirable features of
the proposed system)
c. Indicate how proposed system will solve the problem(s)
IV. SUMMARY/ ABSTRACT
a. (optional) Give executive a summary of project, high-lighting
benefits
V. THE PREFERED ALTERNATIVE - COST/BENEFIT STATEMENT
a. List benefits and savings in quantitative terms
b. Present figures of savings versus costs
c. Summarize cost of new equipment, one – time charges, etc.
d. Quantify net savings and expected returns.
VI. IMPLEMENTATION SCHEDULE
a. Submit implementation plan
b. Specify human resources requirements, systems and procedures, etc.
Include PERT-CPM or Gantt Chart.
VII. HARDWARE CONFIGURATION (optional)
a. Lay out computer configuration.
b. Describe terminal network and equipment (CRTs, printers, etc.).
c. List communication equipment (data sets, lines, etc.)
VIII. CREDITS Give credit to those who contributed to the project study.

APPENDIX Include exhibits, correspondence on project, and other

miscellaneous documentation.

Effective reports follow carefully these planned formats that management can
understand and evaluate without having to read the entire document. There is no
standard format for preparing feasibility reports. Analysts usually decide on a
format that suits the particular user and system. Most reports, however, contain
the following contents and format:
 Systems Analysis and Design: A Simplified Approach | 47
____________________________________________________________________

The outcome of the feasibility study should be very clear, yet detailed enough to
provide the basis for system design. It should answer the following issues.

 Is there an alternate way to do the job in a better way?

 What is recommended?

If the feasibility study is accepted then the systems analyst moves to the next
stage which is a full analysis of the system

4.6.4 Factors/Types/Areas of Feasibility Study

Although few businesses would not benefit from a computerized system at all,
the process of carrying out this feasibility study makes the purchaser/client think
carefully about how it is going to be used.

After request clarification, analyst proposes some solutions. After that for each
solution it is checked whether it is practical to implement that solution.

This is done through feasibility study. In this, various aspects like whether it is
technically or economically feasible or not are evaluated. So depending upon the
aspect on which feasibility is being done it can be categorized into five classes.
The acronym TELOS refers to the five areas of feasibility - Technical,
Economic, Legal, Operational, and Scheduling.

 Technical Feasibility
 Economic Feasibility
 Legal Feasibility
 Operational (Organizational) Feasibility
 Scheduling Feasibility

1. Technical Feasibility

In technical feasibility the following issues are taken into consideration.

 Is the proposed technology or solution practical?

 Do we currently possess the necessary technology?
 Do we possess the necessary technical expertise
o and is the schedule reasonable for this team?
 Systems Analysis and Design: A Simplified Approach | 48
____________________________________________________________________

 Is relevant technology mature enough to be easily applied to our

problem?
 What kinds of technology will we need?
 Some organizations like to use state-of-the-art technology
o but most prefer to use mature and proven technology.
 A mature technology has a larger customer base for obtaining
advice concerning problems and improvements.
 Does the necessary technology exist to do what is suggested (and can it be
acquired)? Is the required technology available ―in house‖?
 If the technology is available:
o does it have the capacity to handle the solution?
 If the technology is not available:
o can it be acquired?
o will it be compatible with other systems?
 Whether the required resources are available –
 Manpower- programmers, testers & debuggers
 Software and hardware
 Does the proposed equipment have the technical capacity to hold the data
required to use the new system?
 Will the proposed system provide adequate responses to inquiries,
regardless of the number or location of users?
 Can the system be expanded if developed?
 Are there technical guarantees of accuracy, reliability, ease of access, and
data security?
 What technical risk is there?

For example, if the proposal includes a printer that prints at the rate of 15,000
lines per minute, a brief search shows that this specification is technically
feasible. (Whether it should be included in the configuration is an economic
decision). On the other hand, if a user is requesting voice input to write, read, and
change stored data, the proposal may not be technically feasible.

Once the technical feasibility is established, it is important to consider the

monetary factors also. Since it might happen that developing a particular system
may be technically possible but it may require huge investments and benefits
may be less. For evaluating this, economic feasibility of the proposed system is
carried out.
 Systems Analysis and Design: A Simplified Approach | 49
____________________________________________________________________

2. Economic Feasibility

A system that can be developed technically and that will be used installed must
still be a good investment for the organization. For any system if the expected
benefits equal or exceed the expected costs, the system can be judged to be
economically feasible. In economic feasibility, cost benefit analysis is done in
which expected costs and benefits are evaluated. Economic analysis is used for
evaluating the effectiveness of the proposed system.

In economic feasibility, the most important is cost-benefit analysis (CBA). As

the name suggests, it is an analysis of the costs to be incurred in the system and
benefits derivable out of the system.

Thus in economic feasibility the following issues are taken into consideration
and an estimation done.

 Is the project possible, given resource constraints?

 What are the development and operational costs?
o The cost of hardware and software for the class of application
being considered.
o The cost to conduct a full systems investigation
 What are the benefits?
o Both tangible and intangible
o Quantify them!
 Are the benefits worth the costs?
 The cost if nothing changes (i.e., the proposed system is not developed).

To be judged feasible, a project proposal must passed all these tests. Otherwise, it
is not a feasible project. For example, a personnel record feasible if the necessary
technology does not exit. A medical system that can be developed at reasonable
costs but that nurses will avoid using cannot be judged operationally feasible.

3. Operational Feasibility

Proposed projects are beneficial only if they can be turned into information
systems that will meet the organization‘s operating requirements. Simply stated,
this test of feasibility asks if the system will work when it is developed and
installed. Are there major barriers to implementation?
 Systems Analysis and Design: A Simplified Approach | 50
____________________________________________________________________

Operational feasibility is mainly concerned with issues like whether the system
will be used if it is developed and implemented. Whether there will be resistance
from users that will affect the possible application benefits? The essential
questions that help in testing the operational feasibility of a system are following.

 Is there sufficient support for the project from management? From users?
 If the system is developed, will it be used? If the current system is well
liked and used to the extent that persons will not be able to see reasons for
a change, there may be resistance.
 Are the users not happy with current business practices? Will it reduce the
time (operation) considerably? If yes, then they will welcome the change
that will bring about a more operational and useful system.
 Have the users been involved in the planning and development of the
project? Early involvement reduces the probability of resistance towards
the new system. change in general and increases the likelihood of
successful projects.
 Will the proposed system really benefit the organization? Does the overall
response increase? Will the proposed system cause harm? Will it produce
poorer result in any respect or area? Will loss of control result in any
area? Will accessibility of information be lost? Will individual
performance be poorer after implementation than before? Will customers
be affected in an undesirable way? Will the system slow performance in
any areas?

Issues that appear to be relatively minor in the beginning have ways of growing
into major problems after implementation. Therefore, all operational aspects
must be considered carefully.

4. Legal Feasibility

This determines whether the proposed system conflicts with legal requirements,
e.g. a data processing system must comply with the local Data Protection Acts. It
includes study concerning contracts, liability, violations, and other traps
frequently unknown to the technical staff.

5. Schedule Feasibility
A project will fail if it takes too long to be completed before it is useful.
Typically this means estimating how long the system will take to develop, and if
 Systems Analysis and Design: A Simplified Approach | 51
____________________________________________________________________

it can be completed in a given time period using some methods like payback
period. Schedule feasibility is a measure of how reasonable the project timetable
is.
 Given our technical expertise, are the project deadlines reasonable? Some
projects are initiated with specific deadlines. You need to determine
whether the deadlines are mandatory or desirable.
 Is it possible to build a solution in time to be useful?
o What are the consequences of delay?
o Any constraints on the schedule?
o Can these constraints be met?

4.6 Data Analysis

Data analysis is a prerequisite to cost/ benefit analysis. System investigation and

data gathering lead to an assessment of current findings. From the analysis, the
system design requirements are identified, which could be:

1. Better customer service.

2. Faster information retrieval
3. Quicker reports.
4. Less time consuming.
5. Accuracy.
6. Reduce data redundancy.
7. Improved staff efficiency.
8. Lower processing & operating costs.

To achieve these design objectives, several alternatives, must be evaluated, there

is seldom just one alternative. The analyst selects those that are feasible
economically, technically and operationally. Each approach has its benefits and
drawbacks. An analysis of the costs and benefits of each alternative guides the
selection process.

4.7 Cost Benefit Analysis

Developing an IT application is an investment, since after developing that

application it provides the organization with profits. Profits can be monetary or
in the form of an improved working environment. However, it carries risks,
 Systems Analysis and Design: A Simplified Approach | 52
____________________________________________________________________

because in some cases an estimate can be wrong. And the project might not
actually turn out to be beneficial.

Cost benefit analysis helps to give management a picture of the costs, benefits
and risks. It usually involves comparing alternate investments. It determines the
benefits and savings that are expected from the system and compares them with
the expected costs.

4.8 Procedure for Cost/ Benefit Determination

There is a difference between expenditure and investment. We spend to get what

we need, but we invest to realize a return on the investment. Building a computer
– based system is an investment. Costs are incurred throughout its life cycle.
Benefits are realized in the form of reduced operating costs, improved corporate
image, staff efficiency, or revenues. To what extent benefits outweigh costs is the
function of cost /benefit analysis. Cost/ benefit analysis is a procedure that gives
a picture of the various costs, benefits and rules associated with a system. The
determination of costs and benefits entails the following steps:

1. Identify the costs and benefits pertaining to given project.

2. Categorize the various costs and benefits for analysis.
3. Select a method of evaluation.
4. Interpret the results of the analysis.
5. Take action.

4.8.1 Costs and Benefits Identification

Certain costs and benefits are more easily identifiable than others. For example,
direct costs, such as the price of a hard disk, are easily identified form company
invoice payments or canceled checks. Direct benefits often relate one-to-one to
direct costs, especially savings from reducing costs in the activity in question.
Other direct costs and benefits, however, may not be well defined, since they
represent estimated costs or benefits that have some uncertainty. An example of
such costs is reserve for bad debt. It is a discerned real cost, although its exact
amount is not so immediate. A category of costs or benefits that is not easily
discernible is opportunity costs and opportunity benefits. These are the costs or
benefits forgone by selecting one alternative over another. They do not show in
the organization‘s accounts and therefore are not easy to identify.
 Systems Analysis and Design: A Simplified Approach | 53
____________________________________________________________________

4.8.2 Cost and Benefit Categories

In performing Cost benefit analysis (CBA) it is important to identify cost and

benefit factors. Cost and benefits can be categorized into the following
categories. There are several cost factors/elements. These are
hardware/equipment, software, personnel, facility, overhead, consultants‘ fees,
operating, and supplies costs.

In a broad sense the cost of an information system can be divided into two types:
development cost and operating cost. The development costs are one time
investment whereas operating costs are recurring.

1. Development costs- The development cost is basically the costs incurred

during the various stages of the system development. It includes: Wages,
hardware/software, Equipment costs.

2. Operating costs: Operating costs are the expenses required for the day to day
running of the system. This includes the maintenance of the system. That can be
in the form of maintaining the hardware or application programs or money paid
to professionals responsible for running or maintaining the system.

Benefits:
We can define benefit as:
Profit or Benefit = Income – Costs
Benefits can be accrued by increasing income, or decreasing costs, or both.
The system will provide some benefits also. Benefits can be tangible or
intangible, direct or indirect. In cost benefit analysis, the first task is to identify
each benefit and assign a monetary value to it.

The two main benefits are improved performance and minimized processing
costs.

Further costs and benefits can be categorized as

 Tangible or Intangible Costs and Benefits

Tangible cost and benefits can be measured. Hardware costs, salaries for
professionals, software cost are all tangible costs. They are identified and
 Systems Analysis and Design: A Simplified Approach | 54
____________________________________________________________________

measured. The purchase of hardware or software, personnel training, and

employee salaries are example of tangible costs. Costs whose value cannot be
measured are referred as intangible costs. The cost of breakdown of an online
system during banking hours will cause the bank lose deposits.

Benefits are also tangible or intangible. For example, more customer satisfaction,
improved company status, etc are all intangible benefits. Whereas improved
response time, producing error free output such as producing reports are all
tangible benefits. Both tangible and intangible costs and benefits should be
considered in the evaluation process.

 Direct or Indirect Costs and Benefits

From the cost accounting point of view, the costs are treated as either direct or
indirect. Direct costs are having naira value associated with it. Direct benefits are
also attributable to a given project. For example, if the proposed system can
handle more transactions say 25% more than the present system then it is direct
benefit.

Indirect costs result from the operations that are not directly associated with the
system. Insurance, maintenance, heat, light, air conditioning are all indirect costs.

 Fixed or Variable Costs and Benefits

Some costs and benefits are fixed. Fixed costs don't change. Depreciation of
hardware, Insurance, etc are all fixed costs. Variable costs are incurred on regular
basis. Recurring period may be weekly or monthly depending upon the system.
They are proportional to the work volume and continue as long as system is in
operation.

Fixed benefits don't change. Variable benefits are realized on a regular basis.
 Systems Analysis and Design: A Simplified Approach | 55
____________________________________________________________________

Benefits Costs
1. Tangible Benefits 1. Development costs (OTO)
Readily quantified as naira values i. Development and purchasing
Examples: costs:
o increased sales o Cost of development team
o cost/error reductions o Consultant fees
o increased throughput/efficiency o software used (buy or build)?
o increased margin on sales o Hardware (what to buy,
o more effective use of staff time buy/lease)?
o facilities (site, communication,
2. Intangible benefits power,...)
Difficult to quantify ii. Installation and conversion
o But maybe more important! costs:
o business analysts help estimate o installing the system,
$ values o training personnel,
Examples: o file conversion,....
o increased flexibility of
operation 2. Operational costs (on-going)
o higher quality products/services i. System Maintenance:
o better customer relations o hardware (repairs, lease,
o improved staff morale supplies,...),
o software (licenses and
3. How will the benefits accrue? contracts),
o When - over what timescale? o facilities
o Where in the organization? ii. Personnel:
o For operation (data entry,
backups,…)
o For support (user support,
hardware and software
maintenance,
supplies,…)
o On-going training costs
 Systems Analysis and Design: A Simplified Approach | 56
____________________________________________________________________

4.8.3 Select Evaluation Method

When all financial data have been identified and broken down into cost
categories, the analyst must select a method of evaluation. Several evaluation
methods are available, each with pros and cons. The common methods are:

1. Net benefit analysis.

2. Present value analysis.
3. Net Present value.
4. Payback analysis.
5. Break- even analysis.
6. Cash-flow analysis

1. Net Benefit Analysis:- Net benefit analysis simply involves subtracting total
costs from total benefits. It is easy to calculate easy to interpret, and easy to
present. The main drawback is that it does not account for the time value of
money and does not discount future cash flow. Period 0 is used to represent the
present period. The negative numbers represent cash outlays. The time value of
money is extremely important in evaluation processes. What is suggested here is
that money has a time value. Today‘s dollar and tomorrow‘s dollar are not the
same. The time lag accounts for the time value of money. The time value of
money is usually expressed in the form of interest on the funds invested to realize
the future value. Assuming compounded interest, the formula is:

F = P (1 + i)n

Where :

F= Future value of an investment

P= Present value of the investment.
I= Interest rate per compounding period.
N= Number of years.

2. Present Value Analysis:- In developing long-term projects, it is often difficult

to compare today‘s costs with the full value of tomorrow‘s benefits. As we have
seen, the time value of money allows for interest rates, inflation and other factors
that alter the value of the investment. Furthermore certain investments offer
benefit periods that varies with different projects. Presents value analysis
 Systems Analysis and Design: A Simplified Approach | 57
____________________________________________________________________

controls for these problems by calculating the costs and benefits of the system in
terms of today‘s value of the investment and then comparing across alternatives.

A critical factor to consider in computing present value is a discount rate

equivalent to the forgone amount that the money could earn if it were invested in
a different project. It is similar to the opportunity cost of the funds being
considered for the project. Suppose that N3,000 is to be invested in a
microcomputer for our safe deposit tracking system and the average annual
benefit is N1,500 for the four-year life of the system. The investment has to be
made today, whereas the benefits are in the future. We compare present values to
future values by considering the time value of money to be invested. The amount
that we are willing to invest today is determined by the value of the benefits at
the end of a given period (year). The amount is called the present value of the
benefit.

To compute the present value, we take the formula for future value:

F = P * (1 + i)n

and solve for the present value (P) as follows:

P = F / (1 + i)n

So the present value of N1,500 invested at 10 percent interest at the end of the
fourth year is:

P= 1,500/(1+0.10)4 = N1,027.39

That is, if we invest N1,027.39 today at 10 percent interest, we can expect to

have N1,500 in four years. This calculation can be represented for each year
where a benefit is expected.

3. Net Present Value:- The net present value is equal to discounted benefits
minus discounted costs. Our N3,000 microcomputer investment yields a
cumulative benefit of N4,758.51 or a net present gain of N1,758.51. This value is
relatively easy to calculate and accounts for the time value of money.
 Systems Analysis and Design: A Simplified Approach | 58
____________________________________________________________________

The net present value is expressed as a percentage of the investment- in our

example: 1,758.51/3,000 = 0.55 percent

4. Payback Analysis:- The payback method is a common measure of the relative

time value of a project. It determines the time it takes for the accumulated
benefits to equal the initial investment. Obviously the shorter the payback period,
the sooner a profit is realized and the more attractive is the investment. The
payback method is easy to calculate and allows two or more activities to be
ranked. Like the net profit, though, it does not allow for the time value of money.
The payback period may be computed by the following formula:

Overall cost outlay/Annual cash return = (A*B)+ (C*D)/ (5+2)= Years +

Installation time (G) / Years to recover

5. Break –even Analysis:- Break–even is the point where the cost of the
candidate system and that of the current one are equal. Unlike the payback
method that compares costs and benefits of the candidate system, break-even
compares the costs of the current and candidate systems. When a candidate
system is developed, initial costs usually exceed those of the current system. This
is an investment period. When both costs are equal, it is break-even. Beyond that
point, the candidate system provides greater benefit (profit) than the old one--a
return period.

A break–even chart compares the costs of the current and candidate systems. The
attributes are processing cost and processing volume. Straight lines are used to
show the model‘s relationships in terms of the variable, fixed and total costs of
the two processing methods and their economic benefits. Intersection indicates
the point where the total cost of processing transactions by the current system is
equal to the total cost of using the candidate system. Beyond that point is the
return period. Before the intersection is the investment period. According to the
chart, then, it would be more economical to process manually when volume is
below the number of break-even point transactions. Higher processing volume
favors the candidate system.

6. Cash – Flow Analysis:- Some projects, such as those carried out by computer
and word processing services, produce revenues from an investment in computer
systems. Cash–flow analysis keeps track of accumulated costs and revenues on a
 Systems Analysis and Design: A Simplified Approach | 59
____________________________________________________________________

regular basis. The ―spread sheet‖ format also provides break – even and payback
information. It is revenue minus expense on a period by period basis.

Drawbacks of the Cash flow analysis are: It ignores time value of money. For a
limited period, it does not take into account the profitability of the project. It
ignores behavioral implications of the numbers in the financial statement.
However the major advantage of the cash flow analysis is that it combines
benefits of break even and payback methods.

4.8.4 Interpret Results of the Analysis and Final Action

When the evaluation of the project is complete, the results have to be interpreted.
This entails comparing actual results against a standard or the result of an
alternative investment. The interpretation phase as well as the subsequent
decision phase is subjective, requiring judgment and intuition. Depending on the
level of uncertainty, the analyst may be confronted with a single known value or
a range of values. In either case, simpler measures such as net benefit analysis
are easier to calculate and present than other measures, although they do not
discount future cash flows. If it can be modified to include the time value of
money, the net benefit method would be comparable to the net present value
method. More complex measures such as net present value account for the time
value of money but are more difficult to evaluate and present. The decision to
adopt an alternative candidate system can be highly subjective, depending on the
analyst‘s or end user‘s confidence in the estimated costs and benefits and the
magnitude of the investment. In summary, cost/ benefit analysis is a tool for
evaluating projects rather than a replacement of the decision-maker. In real-life
business situations, whenever a choice among alternatives is considered, cost /
benefit analysis is an important tool. Like any tool, however, it has problems:

1. Valuation problems:- Intangible costs and benefits are difficult to quantify

and tangible costs are generally more pronounced than tangible benefits. In most
cases, then, a project must have substantial intangible benefits to be accepted.

2. Distortion problems:- There are two ways of distorting the results of

cost/benefit analysis. One is the intentional favoritism of an alternative for
political reasons. The second is when data are incomplete or missing from the
analysis.
 Systems Analysis and Design: A Simplified Approach | 60
____________________________________________________________________

3. Completeness problems:- Occasionally an alternative is overlooked that

compromises the quality of the final choice. Furthermore, the costs related to
cost/ benefit analysis may be on the high side or not enough costs may be
considered to do a complete analysis. In either case, the reliability of the final
choice is in doubt.

4.9 Performing Cost Benefit Analysis (CBA)

Example: Cost for the proposed system (figures in Thousands)

Benefit for the proposed system

Profit = Benefits – Costs = 300, 000 -154, 000 = N146, 000.00

Since we are gaining, this system is feasible.

4.10 Handling Infeasible Projects

Not all projects submitted for evaluation and review are judged acceptable.
Requests that fail to pass feasibility tests are not pursued further, unless they are
reworked and resubmitted as new proposals. In some cases, only part of a project
is actually unworkable, and the selection committee may decide to combine the
workable part of the project with another feasible proposal. In still other cases,
 Systems Analysis and Design: A Simplified Approach | 61
____________________________________________________________________

preliminary investigations produce enough new information to suggest that

improvements in management and supervision, not the development of
information systems, are the actual solutions to reported problems.

4.11 Summary
 The first step in the system development life cycle is the identification of
a need. This is a user‘s request to change, improve or enhance an existing
system.
 Preliminary investigations examine project feasibility, the likelihood the
system will be useful to the organization
 Not all projects submitted for evaluation and review are judged
acceptable.
 Data analysis is a prerequisite to cost/ benefit analysis. System
investigation and data gathering lead to an assessment of current findings.
From the analysis, the system design requirements are identified, and
alternative system evaluated.
 In developing cost estimates for a system, we need to consider several
cost elements. Among them are hardware, personnel, facility, operating
and supply costs. Cost/ benefit analysis is a procedure that gives a picture
of the various costs, benefits and rules associated with a system.
 Cost/ benefit analysis is a tool for evaluating projects rather than a
replacement of the decision-maker. In real-life business situations,
whenever a choice among alternatives is considered, cost/ benefit analysis
is an important tool. The final decision following cost/benefit analysis is
to select the most cost-effective and beneficial system for the user.

4.12 Review Questions:

1. Explain closed questions and open-ended questions with examples.
2. What planning dimensions determine information system development?
Elaborate.
3. Why is it difficult to determine user requirements?
4. What is the purpose of preliminary investigation?
5. What is an infeasible project and how are they handled?
6. How are tangible costs different from direct costs?
7. What are the various cost benefit categories?
8. Why is it necessary to conduct cost/benefit analysis?
 Systems Analysis and Design: A Simplified Approach | 62
____________________________________________________________________

CHAPTER FIVE

System Requirement
Specifications and Analysis

5.0 Introduction

Analysis is the heart of the system development process. It is the key component
of the first two phases of the cycle. Systems Analysis involves detailed study of
the current system, leading to specifications of a new system. Systems analysis is
a process of collecting factual data, understanding the processes involved,
identifying problems and recommending feasible suggestions for improving the
system functioning. This involves studying the business processes, gathering
operational data, understand the information flow, finding out bottlenecks and
evolving solutions for overcoming the weaknesses of the system so as to achieve
the organizational goals.

5.1 Detailed Analysis

In analysis the present system, the analyst collects a great deal of relatively
unstructured data through interviews, questionnaires, on–site observations,
procedure manuals, and the like. The traditional approach is to organize and
convert the data through system flowcharts, which support future developments
of the system and simplify communication with the user. But the system
flowchart represents a physical rather than a logical system. It makes it difficult
to distinguish between what happens and how it happens in the system.

There are other problems with the traditional approach.

1. The system life cycle provides very little quality control to ensure accurate
communication from user to analyst. They have no language in common.
 Systems Analysis and Design: A Simplified Approach | 63
____________________________________________________________________

2. The analyst is quickly overwhelmed with the business and technical details of
the system. Much of the time is spent gathering information. The details are
needed and must be available, but the analyst does not have the tools to
structure and control the details.
3. Present analytical tools have limitations.
a. English narrative descriptions of a system are often too vague and
make it difficult for the user to grasp how the parts fit together.
Furthermore, English is inherently difficult to use where precision is
needed.
b. System and program flowcharts commit to a physical implementation
of the system before on has complete understanding of its logical
requirements.
4. Problems also relate to system specifications:-
a. System specifications are difficult to maintain or modify. A simple
change in the user‘s requirements necessitates changes in several parts
of the document.
b. They describe user requirements inn terms of physical hardware that
will implement the system rather than what the user wants the system
to do.
c. They are monolithic and redundant; that is, to find out information
about a particular part of the system, the user has to search the entire
document. Furthermore, the same information is found in numerous
locations with no cross-reference.
Because of these drawbacks, the analyst needs something analogous to the
architect‘s blueprint as a starting point for system design. It is a way to focus on
functions rather than physical implementation.

System analysis is about understanding situations, not solving problems.

Effective analysts therefore emphasize investigation and questioning to learn
how a system currently operates and to identify the requirements users have for a
new or modified one. Only after analysts fully understand the systems are they
able to analyze it and assemble recommendations for systems design. The
manner in which a systems investigation is conducted will determine whether the
appropriate information is gathered. In turn, having the right information
influences the quality of the application that follows. In other words, good
system design, whether developed through the SDLC method, prototyping, or
structured methods, begins by documenting the current system and properly
diagnosing systems requirements.
 Systems Analysis and Design: A Simplified Approach | 64
____________________________________________________________________

The major objectives of systems analysis are to find answers for each business
process: What is being done, How is it being done, Who is doing it, When is he
doing it, Why is it being done and How can it be improved, Who will use the
system, What the system will do, Where and When it will be used? It is more
of a thinking process and involves the creative skills of the System Analyst. It
attempts to give birth to a new efficient system that satisfies the current needs of
the user and has scope for future growth within the organizational constraints.
The result of this process is a logical system design. Systems analysis is an
iterative process that continues until a preferred and acceptable solution emerges.

The detailed investigation of the system is carried out in accordance with the
objectives of the proposed system. This involves detailed study of various
operations performed by a system and their relationships within and outside the
system. During this process, data are collected on the available files, decision
points and transactions handled by the present system. Interviews, on-site
observation and questionnaire are the tools used for detailed system study.

In a nutshell, the analysis involves some or all of the following stages:

 Identify the user requirements
 Fact finding – this is usually done in four ways (see next session)
 Understanding the current system
 Produce data flow diagrams
 Interpret the user requirements
 Agree the objectives with the user
 Collect data from the current system

Using the following steps it becomes easy to draw the exact boundary of the new
system under consideration:

 Keeping in view the problems and new requirements

 Workout the pros and cons including new areas of the system

All the data and the findings must be documented in the form of detailed data
flow diagrams (DFDs), data dictionary, logical data structures and miniature
specification. The main points to be discussed in this stage are:

 Specification of what the new system is to accomplish based on the user

requirements.
 Systems Analysis and Design: A Simplified Approach | 65
____________________________________________________________________

 Functional hierarchy showing the functions to be performed by the new

system and their relationship with each other.
 Functional network, which are similar to function hierarchy but they
highlight the functions which are common to more than one procedure.
 List of attributes of the entities – these are the data items which need to be
held about each entity (record)

5.2 Requirements Determination

Requirements determination involves studying the current business system to
find out how it works and where improvements should be made. Systems studies
result in an evaluation of how current methods are working and whether
adjustments are necessary or possible. These studies consider both manual and
computer methods, they are not merely computer studies. A requirement is a
feature that must be included in a new system. It may include a way of capturing
or processing data, producing information, controlling a business activity, or
supporting management. The determination of requirements thus entails studying
the existing system and collecting details about it to find out what these
requirements are. Certain types of requirements are so fundamental as to be
common in most all situations. Developing answers to a specific group of
questions (to be discussed in this section) will help you understand these basic
depending on whether the system is transaction – or decision – oriented and
whether the system cuts across several departments. For example, the need to
inform the inventory manager of an unusually large order that is forthcoming
underscores the importance of linking the sales, purchasing, and warehouse
departments.

5.2.1 Activities in Requirement Determination

It is helpful to view requirements determination through the three major activities
of requirements anticipation, requirements investigation, and requirements
specification.

Requirements Anticipation
Having had experience in a particular business area or having encountered
systems in an environment similar to the one currently under investigation will
influence systems analysts study. They may foresee the likelihood of certain
problems or features and requirements for a new system. As a result, the features
they investigate for the current system, questions they raise, or methods
 Systems Analysis and Design: A Simplified Approach | 66
____________________________________________________________________

employed may be based on this familiarity. Requirements anticipation can be a

mixed blessing. On the one hand, experience form previous studies can lead to
investigation of areas that would otherwise go unnoticed by an inexperienced
analyst. Having the background to know what to ask or which aspect to
investigate can be a substantial benefit to the organization. On the other hand, if a
bias is introduced or shortcuts are taken in conducting the investigation,
requirements anticipation is a problem. We will point out guidelines for
structuring an investigation around basic questions to avoid the undesirable
consequences of requirements anticipation.

Requirements Investigation
This activity is at the heart of systems analysis. Using a variety of tools and
skills, analysts study the current system and document its features for further
analysis. Requirements investigation relies on the fact-finding techniques and
includes methods for documenting and describing system features.

Requirements Specifications
The data produced during the fact-finding investigation are analyzed to
determine requirements specifications, the description of features for a new
system. This activity has three interrelated parts: ™
 Analysis of Factual Data: The data collected during the fact – finding
study and included in data flow and decision analysis documentation are
examined to determine how well the system is performing and whether it
will meet the organization‘s demands. ™
 Identification of Essential Requirements: Features that must be
included in a new system, ranging from operational details to
performance criteria, are specified. ™
 Selection of Requirements Fulfillment Strategies: The methods that
will be used to achieve the stated requirements are selected.

These form the basis for system design, which follows requirements
specification. All three activities are important and must be performed correctly.
5.3 Basic Requirements
Analysts structure their investigation by seeking answers to these four major
questions:

What is the basic business process?

What data are used or produced during that process?
 Systems Analysis and Design: A Simplified Approach | 67
____________________________________________________________________

What are the limits imposed by time and the volume of work?
What performance controls are used?

5.3.1 Understand the Process

Begin with the basics. Analysts must raise questions that, when answered, will
provide a background of fundamental details about the system and describe it.
Asking the following questions will help acquire the necessary understanding.

What is the purpose of this business activity?

What steps are performed?
Where are they performed?
Who performs them?
How long does this take?
How often is it done?
Who uses the resulting information?

Suppose you are reinvestigating an inventory reordering system, something about

which you know very little. Where should you begin? Listed below are brief
answers to basic questions about the inventory reordering system. These are the
kinds of answers you would need to seek for any system you were studying.

What is the purpose of inventory reordering?

To ensure that adequate quantities of stock and materials are on hand and
available for use without carrying an excessive and therefore costly
quantity.

What steps are performed?

Verifying stock on hand. Determining future requirements and optimum
times to place orders. Determining quantities to order.

Where are they performed?

The purchasing department, using information provided by
manufacturing, sales, and inventory staff members, as well as by its own
records, handles ordering and lead – time. Projection.
 Systems Analysis and Design: A Simplified Approach | 68
____________________________________________________________________

Who perform them?

Purchasing manages approve all orders. Stock managers assemble buying
instructions and write orders.

How long does this take?

The process may take a few minutes for simple and routine high – prices
item or other special circumstance.

How often is it done?

This is a continuous process. Different items are always being ordered.

Who uses the resulting information?

Information produced as a by – product of this process is used to manage
inventory, schedule service and manufacturing monitor purchasing, and
pay suppliers, as well as meet unexpected requirements for purchasing
and inventory reorder information.

Notice how quickly answers to these questions provide a broad understanding of

what inventory reordering is all about and show that the objective of inventory
reordering is more than just buying stock. But analysts cannot stop here. There is
not yet enough information to fully understand inventory reordering. Instead, the
background acquired enables to raise more detailed questions.

5.3.2 Identify data used and information produced

Analysts next need to find out what data are used to perform each activity for
example, to reorder inventory, the buyer might require data describing the
quantity of an item of hand, expected demand for the item, supplier name, and
item cost. To know when to place an order, the buyer would also consider the
necessary lead-time (how for in advance the item should be ordered to be on
hand when needed).

Most business transactions also produce information that is useful to managers

when they evaluate employee, business, and systems performance and that may
be useful in another context to both manager and analyst. Inquiring analysts will
find out, for example that data about inventory reordering and stocking also
provide information about warehouse demands, purchasing practices, sales, and
cash flow.
 Systems Analysis and Design: A Simplified Approach | 69
____________________________________________________________________

5.3.3 Determine process timing and volume

The frequency of business activities varies greatly. For example, some activities,
such as paying taxes, occur only a few times a year, whereas paying employees is
a weekly activity. Therefore, analysts should learn how often the activity is
repeated. Knowing whether an activity occurs frequently may lead the analyst to
raise many additional and important questions to determine the reason for the
frequency and its effect on business activities.

Many times the easiest way to get this information is to identify the reason for
the activity: what causes the activity to be performed? Analysts sometimes refer
to the direct cause as the trigger function (it triggers the activity). Activities can
be triggered by customers of an application to open a new bank, charge, or credit
account), and by the passage of time (the ending of the day, week, or month).
Unless analysts know what triggers an activity, they may misunderstand the
reason for the activity and give it more or less importance in the system than it
merits.

Some activities, such as completing a purchase requisition, take only a few

seconds. Others, such as deciding whether to accept a merger offer, occur
infrequently but require a great deal of time when they do take place. Timing
alone does not determine the importance of an activity, but it does affect the way
analysts evaluate certain steps in carrying out the performance. For example,
making a telephone call to obtain stock price information during a merger
decision is quite acceptable, since a merge is an infrequent occurrence. But
making a telephone call to obtain information every time a purchase requisition
is processed is another matter.

The volume of items to be handled may increase the amount of time needed to
complete the activity. Savings banks prepare consumer account statements
(summaries of deposits, withdrawals, interest accumulations, and balances) only
four times a year. Although the frequency of this activity is very low, when the
calendar triggers this activity at the end of each quarter, the volume of work is
very high, sometimes running into tens of thousands of statements to be
prepared. The sheer quantity of item making up an activity can produce special
problems for the analyst to study, even though the activity occurs infrequently.
 Systems Analysis and Design: A Simplified Approach | 70
____________________________________________________________________

5.3.4 Identity controls

In business situations that are well controlled either by management or process
monitoring, determining whether an activity has been performed properly may be
no problem. But during the analysis stage, the analysts must examine control
methods: are there specific performance standards? Who compares performance
against standards? How are mistakes caught? How are error handled? Are the
errors excessive?

5.4 User Transaction Requirements

Transaction – level systems captures, process, and store data for a reason. In an
order system, for example, sale order form customers are processed so that
specified item can be shipped. This simple procedure applies to every order that
is received. Analyst assigned to work on an order entry system would want to
know more about how these transactions are processed. To under – stand these
transaction requirements they would undoubtedly ask questions such as the
following:
What makes up the transaction being processed?
What initiates the transaction?
Who actually initiates the order?
For what purpose?
How often do order occur?
What volume is associated with each?
Are there different conditions that can affect how orders are processed?
What details are needed to process the transaction?
What information is generated?
What data is stored?

5.5 User Decision Requirements

Decision, unlike transaction activities, may not follow a specific procedure.
Routines are not as clear – cut, and controls may be very vague. Decisions are
made by integrating information in such a way that managers can know what
actions to take. Decision systems may focus on the past, the present, or the
future. Some may support recurring decisions (such as merchandise pricing,
while other are unique and do not recur (such as the merger example used
earlier). They may use data that originate inside the firm, such as through
transaction processing, or outside, for example form trade associations or
commercial sources (such as marketing research firms who sell information to
organizations). In some cases, transaction data are processed to provide new
 Systems Analysis and Design: A Simplified Approach | 71
____________________________________________________________________

information for decision making. For instance, summarized sales transaction data
tell managers which products sell and which do not.

Analysts investigating decision support systems should raise the same questions
about timing and frequency discussed previously. But other questions should also
be posed to determine decision requirements:

1. What information is used to make the Decision?

2. What is the source of the information? Which transaction system produce
the data used in the decision process? Which data are required but do not
result from processing transactions? Which data originate from sources
outside the organization?
3. How would data be processed to produce the necessary information?
4. How should the information be presented?

These questions also point out the relationship between transaction and decision
systems. Inventory systems capture details about ongoing ordering, receipt, sale,
and shipment of items, the data they store are further processed to produce
information periodically to analyze sales, determine pricing policy, or decide on
marketing plan for product lines. This means
(1) that analysts investigating decision systems must be aware of supporting
transaction systems and
(2) that effective decision systems require suitable transaction processing
procedures to be place first.

5.6 Fact Finding

The specific methods analysts use for collecting data about requirements are
called fact – finding techniques. Various kinds of techniques are used and the
most popular among them are:

 Personal observation – made by the Analyst himself

 Interviews
 Questionnaires
 Record reviews/inspection – on-site looking at existing paperwork.
Analysts usually employ more than one of these techniques to help ensure an
accurate and comprehensive investigation. Each of these techniques is further
dealt with:
 Systems Analysis and Design: A Simplified Approach | 72
____________________________________________________________________

1. On-Site Observation:

Observation allows analysts to gain information they cannot obtain by any other
fact – finding method. On-site observation involves observing the existing
system first hand. Through observation, analysts can obtain firsthand information
about how activities are carried out. This method is most useful when analysts
need to actually observe how documents are handled, how processes are carried
out, observers know what to look for and how to assess the significance of what
they observe. The analyst watches the personnel using the existing system to find
out exactly how it works. On-site observations are one of the most effective tools
with the analyst where the analyst personally goes to the site and discovers the
functioning of the system. As an observer, the analyst can gain first hand
knowledge of the activities, operations, processes of the system on-site, hence
here the role of an analyst is of an information seeker.

This information is very meaningful as it is unbiased and has been directly taken
by the analyst. This exposure also sheds some light on the actual happenings of
the system as compared to what has already been documented, thus the analyst
gets closer to the system. This technique is also time-consuming and the analyst
should not jump to conclusions or draw inferences from small samples of
observation rather the analyst should be more patient in gathering the
information. This method is however less effective for learning about people's
perceptions, feelings and motivations.

There are a number of advantages and disadvantages of using this method to

gather information about the existing system:

Advantages
 the analyst obtains reliable data.
 it is possible to see exactly what is being done.
 this is an inexpensive method compared to other techniques.
Disadvantages
 people are generally uncomfortable being watched and may work in a
different way.
 what they are watching may not be representative of a typical day‘s work.
 if workers perform tasks that violate standard procedures, they may not do
this when being watched!!
 Systems Analysis and Design: A Simplified Approach | 73
____________________________________________________________________

2. Interviews

Interview is a very important data gathering technique. Analysts use interviews

to collect information from individuals or from groups. The respondents are
generally current users of the existing system or potential users of the proposed
system. In some instances, the respondents may be managers or employees who
provide data for the proposed system or who will be affected by it.

Interview involves a one to one question and answer session (Q&R session)
between the analyst and employee/customer. A good method if the analyst wants
to probe deeply into one specific aspect of the existing system.

One very essential aspect of conducting the interview is that the interviewer
should first establish a rapport with the interviewee. It should also be taken into
account that the interviewee may or may not be a technician and the analyst
should prefer to use day to day language instead of jargon and technical terms.

For the interview to be a success the analyst should be appropriately prepared, as

he needs to be beforehand aware of what exactly needs to be asked and to what
depth. Also he should try to gather maximum relevant information and data. As
the number and type of respondents vary, the analyst should be sensitive to their
needs and nature.

This may also help the analyst to verify and validate the information gained.
Interviewing should be approached, as logically as possible and from a general
point of view the following guides can be very beneficial for a successful
interview.

1. Set the stage for the interview.

2. Establish rapport; put the interviewee at ease.
3. Phrase questions clearly and succinctly.
4. Be a good listener; avoid arguments.
5. Evaluate the outcome of the interview.

Although some analysts prefer the interview to other fact – finding techniques, it
is not always the best source of application data. Because of the time required for
interviewing, other methods must also be used to gather the information needed
to conduct an investigation. It is important to remember that respondents and
 Systems Analysis and Design: A Simplified Approach | 74
____________________________________________________________________

analysts converse during an interview – the respondents are not being

interrogated. Interviews provide analysts with opportunities for gathering
information form respondents who have been chosen for their knowledge of the
system under study. This method is frequently the best source of qualitative
information (opinions, policies, and subjective descriptions of activities and
problems). Other fact finding methods are likely to be more useful for collecting
quantitative data (numbers, frequencies, and quantities). This method of fact –
finding can be especially helpful for gathering information from individuals who
do not communicate effectively in writing or who may not have the time to
complete questionnaires. Interviews allow analysts to discover areas of
misunderstanding, unrealistic expectations, and even indications of resistance to
the proposed system. Interviews can be either structured or unstructured.
Unstructured interviews, using a question – and – answer format, are appropriate
when analysts want to acquire general information about a system. This format
encourages respondents to share their feelings, ideas, and beliefs. Structured
interviews use standardized questions in either an open – response or closed –
response format. The former allows respondents to answer in their own words;
the latter uses a set of prescribed answers. Each approach has advantages and
disadvantages. The success of an interview depends on the skill or the
interviewer and on his or her preparation for the interview. It is important to have
adequate verification of data through other data collection methods.

As with the previous method, there are a number of advantages and

disadvantages:

Advantages
 analyst has a free hand and he can extract almost all the information from
the concerned people
 opportunity to motivate the interviewee to give open and free answers to
the analyst‘s questions
 allows the analyst to probe for more feedback from the interviewee
(easier to extend a topic than it is when using questionnaires)
 can ask modified questions or questions specific to the interviewee based
on previous responses .
Disadvantages
 can be a very time consuming exercise
 can be expensive to carry out
 unable to remain anonymous
 Systems Analysis and Design: A Simplified Approach | 75
____________________________________________________________________

3. Questionnaires

Questionnaires are another way of information gathering where the potential

users of the system are given questionnaires to be filled up and returned to the
analyst.

This involves sending out questionnaires to the work force and/or to customers to
find out their views of the existing system and to find out how some of the key
tasks are carried out.

The use of questionnaires allows analysts to collect information about various

aspects of a system from a large number of persons. It is not possible to interview
each individual. Also if the time is very short, in that case also questionnaires are
useful. If the anonymity of the respondent is guaranteed by the analyst then the
respondent answers the questionnaires very honestly and critically.

The use of standardized question formats can yield more reliable data than other
fact – finding techniques, and the wide distribution ensures greater anonymity for
respondents, which can lead to more honest responses. However, this method
does not allow analysts to observe the expressions or reactions or respondents.
The questionnaire may not yield the results from those respondents who are busy
or who may not give it a reasonable priority.

In addition, response may be limited, since completing questionnaires may not

have high priority among the respondents. Analysts often use open – ended
questionnaires to learn about feeling, opinions, and general experiences or to
explore a process or problem. Closed questionnaires control the frame of
reference by presenting respondents with specific responses form which to
choose. This format is appropriate for electing factual information. The high cost
of developing and distributing questionnaires demands that analysts carefully
consider the objective of the questionnaire and determine what structure will be
most useful to the study and most easily understood by the respondents.
Questionnaires should also be tested and, if necessary, modified before being
printed and distributed. As with interviewees, recipients, of questionnaires would
be selected for the information they can provide. The analysts should ensure that
the respondents, background and experiences qualify them to answer the
questions.
 Systems Analysis and Design: A Simplified Approach | 76
____________________________________________________________________

Advantages
 questions can be answered quickly
 an inexpensive way of gathering data from a large number of people
 allows individuals to remain anonymous
 it is quick to analyze data

Disadvantages
 number of people returning questionnaires is often quite low
 questions asked tend to be rather inflexible
 no immediate way to clarify a vague/incomplete answer to a question
 it is difficult to prepare a good questionnaire

4. Record Reviews

This involves Looking at existing paperwork. This allows the analyst to see how
paper files are kept, look at operating instructions and training manuals, check
accounts, etc. In record reviews, analysts examine information that has been
recorded about the system and user.

Records and reports are the collection of information and data accumulated over
the time by the users about the system and its operations. This can also put light
on the requirements of the system and the modifications it has undergone.
Records include written policy manuals, regulations and standard operating
procedures used by most organizations and a guide for managers and employees.
They do not show what activities are actually occurring, where the decision –
making power lies, or how tasks are performed. However, they can help analysts
understand the system by familiarizing them with what operations must be
supported and with formal relations within the organization.

Many kinds of records and reports can provide analysts with valuable
information about organizations and operations. The analyst may scrutinize the
records either at the beginning of his study which may give him a fair
introduction about the system and will make him familiar with it or in the end
which will provide the analyst with a comparison between what exactly is/was
desired from the system and its current working.
 Systems Analysis and Design: A Simplified Approach | 77
____________________________________________________________________

Advantages
 It gives the analyst some idea of the scale of the problem, memory size
requirements, type of input/output devices needed, and so on.
 They will often gain information not obtained by any of the other methods
described above.

Disadvantages

 One drawback of using this method for gathering information is that

practically the functioning of the systems is generally different from the
procedure shown in records.
 It can be a very time consuming exercise.
 Records and reports may have a limitation if they are not up-to-date or if
some essential links are missing. All the changes, which the system
suffers, may not be recorded.

5.7 Requirements Structuring/ Decision Making Documentation

Decision-making is an integral part of any business no matter how small, simple

or big and complex it may be. Thus decisions have to be made and set procedures
are to be followed as the subsequent actions. Thus while analyzing and designing
a business system, analyst also needs to identify and document any decision
policies or business rules of the system being designed.

There are various tools and techniques available to the analyst for this. Tools,
which are usually used, are decision trees, decision tables, Structured English and
the various CASE tools. The basic role of these tools is to depict the various
conditions, their possible combinations and the subsequent decisions.

This has to be done without harming the logical structure involved. Once all of
the parameters are objectively represented the decision process becomes much
simpler, straightforward and almost error free.

Requirements structuring involves organizing information gathered during

requirements determination into a meaningful representation of process, data,
and logic views of the information systems. This can be achieved using process
modelling and logic modelling.
 Systems Analysis and Design: A Simplified Approach | 78
____________________________________________________________________

5.8 Process modelling

Process modelling is used to represent the functions/processes which capture,
manipulate, store, and distribute data between a system and its environment and
between components within a system, i.e., what are involved in converting data
into information?
They include
 Data Flow Diagram (DFD)
 Data Dictionary.
5.8.1 Data Flow Diagram
Data Flow Diagrams - DFD (also called data flow graphs) are commonly used
during problem analysis. Data Flow Diagrams (DFDs) are quite general and are
not limited to problem analysis for software requirements specification. DFDs
are very useful in understanding a system and can be effectively used during
analysis. This is a technique for graphically depicting, at levels of increasing
detail, the transformation of data into information by processes.

A DFD shows the flow of data through a system. It views a system as a function
that transforms the inputs into desired outputs. Any complex system will not
perform this transformation in a "single step", and a data will typically undergo a
series of transformations before it becomes the output. The DFD aims to capture
the transformations that take place within a system to the input data so that
eventually the output data is produced. The agent that performs the
transformation of data from one state to another is called a process (or a bubble).
So a DFD shows the movement of data through the different transformation or
process in the system.

DFDs are basically of 2 types: Physical and logical DFDs. Physical DFDs are
used in the analysis phase to study the functioning of the current system. Logical
DFDs are used in the design phase for depicting the flow of data in proposed
system.

Elements of Data Flow Diagrams

Data Flow Diagrams are composed of the four basic symbols shown below.

The External Entity symbol represents sources of data to the system or

destinations of data from the system.
 Systems Analysis and Design: A Simplified Approach | 79
____________________________________________________________________

The Data Flow symbol represents movement of data (data moves from one place
of the system to another)

The Data Store symbol represents data that is not moving (delayed data at rest).

The Process symbol represents an activity that transforms or manipulates the data
(combines, reorders, converts, etc.).

Any system can be represented at any level of detail by these four symbol.

1. External Entities

External entities determine the system boundary. They are

external to the system being studied. They are often beyond the
area of influence of the developer.

These can represent another system or subsystem. These go on margins/edges of

data flow diagram. External entities are named with appropriate name.

2. Processes

Processes are work or actions performed on incoming data flows

to produce outgoing data flows. These show data transformation
or change. Data coming into a process must be "worked on" or
transformed in some way. Thus, all processes must have inputs
and outputs. In some (rare) cases, data inputs or outputs will
only be shown at more detailed levels of the diagrams. Each process in always
"running" and ready to accept data.

Major functions of processes are computations and making decisions. Each

process may have dramatically different timing: yearly, weekly, daily.

3. Data Flow

Data flow represents the input (or output) of data to (or

from) a process ("data in motion"). Data flows only data, not control. Represent
 Systems Analysis and Design: A Simplified Approach | 80
____________________________________________________________________

the minimum essential data the process needs. Using only the minimum essential
data reduces the dependence between processes. Data flows must begin and/or
end at a process.

Data flows are always named. Name is not to include the word "data". Should be
given unique names. Names should be some identifying noun. For example,
order, payment, complaint.

4. Data Stores

or

Data Stores are repository for data that are temporarily or permanently recorded
within the system. It is an "inventory" of data. These are common link between
data and process models. Only processes may connect with data stores.

There can be two or more systems that share a data store. This can occur in the
case of one system updating the data store, while the other system only accesses
the data.

Data stores are named with an appropriate name, not to include the word "file",
Names should consist of plural nouns describing the collection of data. Like
customers, orders, and products. These may be duplicated. These are detailed in
the data dictionary or with data description diagrams.

The procedure for producing a data flow diagram

 Identify and list external entities providing inputs/receiving outputs from

system;
 Identify and list inputs from/outputs to external entities;
 Draw a context DFD
 Define the scope and boundary for the system and project
1. Think of the system as a container (black box)
2. Ignore the inner workings of the container
3. Ask end-users for the events the system must respond to
4. For each event, ask end-users what responses must be produced by the
system
 Systems Analysis and Design: A Simplified Approach | 81
____________________________________________________________________

5. Identify any external data stores

6. Draw the context diagram
i. Use only one process
ii. Only show those data flows that represent the main objective or most
common inputs/outputs
 identify the business functions included within the system boundary;
 identify the data connections between business functions;
 confirm through personal contact sent data is received and vice-versa;
 trace and record what happens to each of the data flows entering the
system (data movement, data storage, data transformation/processing)
 Draw an overview DFD
- Shows the major subsystems and how they interact with one another
- Exploding processes should add detail while retaining the essence of the
details from the more general diagram
- Consolidate all data stores into a composite data store
 Draw middle-level DFDs
- Explode the composite processes
 Draw primitive-level DFDs
- Detail the primitive processes
- Must show all appropriate primitive data stores and data flows
 verify all data flows have a source and destination;
 verify data coming out of a data store goes in;
 review with "informed";
 explode and repeat above steps as needed.

Balancing DFDs

 Balancing: child diagrams must maintain a balance in data content with

their parent processes
 Can be achieved by either:
 exactly the same data flows of the parent process enter and leave the child
diagram, or
 the same net contents from the parent process serve as the initial inputs
and final outputs for the child diagram or
 the data in the parent diagram is split in the child diagram
 Systems Analysis and Design: A Simplified Approach | 82
____________________________________________________________________

Rules for Drawing DFDs

 A process must have at least one input and one output data flow
 A process begins to perform its tasks as soon as it receives the necessary
input data flows
 A primitive process performs a single well-defined function
 Never label a process with an IF-THEN statement
 Never show time dependency directly on a DFD
 Be sure that data stores, data flows, data processes have descriptive titles.
Processes should use imperative verbs to project action.
 All processes receive and generate at least one data flow.
 Begin/end data flows with a bubble.

Rules for Data Flows

 A data store must always be connected to a process

 Data flows must be named
 Data flows are named using nouns - Customer ID, Student information
 Data that travel together should be one data flow
 Data should be sent only to the processes that need the data

Use the following additional guidelines when drawing DFDs

 Identify the key processing steps in a system. A processing step is an

activity that transforms one piece of data into another form.
 Process bubbles should be arranged from top left to bottom right of page.
 Number each process (1.0, 2.0, etc). Also name the process with a verb
that describes the information processing activity.
 Name each data flow with a noun that describes the information going
into and out of a process. What goes in should be different from what
comes out.
 Data stores, sources and destinations are also named with nouns.
 Realize that the highest level DFD is the context diagram. It summarizes
the entire system as one bubble and shows the inputs and outputs to a
system
 Each lower level DFD must balance with its higher level DFD. This
means that no inputs and outputs are changed.
 Systems Analysis and Design: A Simplified Approach | 83
____________________________________________________________________

Steps in developing DFDs

1. List business activities to identify processes, external entities, data flows,
and data stores
2. Create a context diagram
3. Create the next level diagram
4. Create child diagrams
5. Check for errors
6. Develop a physical DFD

An example: Bookstore cap and gown order processing

Step 1: A list of business activities
1. Students place orders by filling out a form.
2. Order department receives orders by mail, fax, or personal delivery.
3. Order department processes orders by verifying that all order information
is accurate and that the item ordered is currently available in stock.
4. Information from valid orders is used to update the student and item
master records.
5. Valid orders are forwarded to the shipping department to be filled.
6. A receipt is produced notifying the student the status of his/her order.

Step 2: Context diagram

Figure 5.1: Context diagram for ‗Students place orders‘

 Systems Analysis and Design: A Simplified Approach | 84
____________________________________________________________________

Step 3: Level-0 diagram

Figure 5.2: Level-0 diagram for the cap and gown order processing

Step 4: Level-1 diagram

Figure 5.3: Level-1 diagram for cap and gown order processing
 Systems Analysis and Design: A Simplified Approach | 85
____________________________________________________________________

Step 5: Check for error

DFD rules

 Internal consistency rules

Elements Rules
DFD At least one process
No more than 9 processes
Context Contains only one process numbered 0
diagram At least one input from an external entity and one output to
an external entity
External Appears only on the context diagram
entity Connected to a process
Labeled with noun phrase
Process At least one input data flow and one output data flow
Inputs to process are different from outputs of that process
Labeled with verb phrase
Data flow Has only one flow direction
No split
No loop
Labeled with noun phrase
Data store An interface between two processes
Labeled with noun phrase

 Hierarchical consistency rules

Elements Rules
DFD A parent diagram must exist unless it is a context diagram
Process Decompose to either another diagram or a primitive process
specification
Numbered with respect to its parent
Data flow An input (output) data flow on a parent diagram must appear
on a child diagram as input (output)
An input (output) data flow on a child diagram must appear
on a parent diagram as input (output)
Data store Decompose to either a file definition or a record definition
 Systems Analysis and Design: A Simplified Approach | 86
____________________________________________________________________

Step 6: Develop a physical DFD

Logical vs Physical DFDs

Features Logical Physical
Model How the business How the system will be implemented
operates
Process Business activities Programs, program modules, manual
procedures
Data store Collections of data Physical files and databases, manual
files
Type of data Permanent data Master files, transaction files
store collections
System controls Business controls Controls for data validation, record
status, system security

Figure 5.4: DFD for the cap and gown order processing
 Systems Analysis and Design: A Simplified Approach | 87
____________________________________________________________________

DFD Example -Enrolling in the university.

Figure 5.5: DFD for Enrolling in the university

5.8.2 Data Dictionary

A data dictionary is a structured repository of data about data. It is a set of

rigorous definitions of all DFD data elements and data structures. Data dictionary
is a documentation and reference of the metadata: data on

1. Data flow
2. Data structure
3. Data elements
4. Data stores
 Systems Analysis and Design: A Simplified Approach | 88
____________________________________________________________________

Data dictionary promotes understanding of the data of the system by collecting,

coordinating, and confirming what a specific data term means to different people
in the organization.

Data types Specific description

Data flow  Source
 Destination
 Type (File, Screen, Report, Form, Internal)
 Data structure
 Volume
Data structure  =  is composed of
 +  and
 {  repetitive elements
}  either/or
 [  optional
]
 (
)
Data element  Alias
 Length
 Type (alphabetic, alphanumeric, date, numeric)
 Input/Output format
 Default
 Base/Derived
 Continuous/Discrete
 Validation criteria
Data store  File type
 File format
 Record size
 Number of records
 Growth rate
 Primary key
 Secondary keys

In our data flow diagrams, we have given names to data flows, processes and
data stores. Although the names are descriptive of the data, thy do not give
 Systems Analysis and Design: A Simplified Approach | 89
____________________________________________________________________

details. So following the DFD, our interest is to build some structures place to
keep details of the contents of data flows, processes and data stores.

To define the data structure, different notations are used. These are similar to the
notations for regular expression. Essentially, besides sequence or composition
(represented by +) selection and iteration are included. Selection (represented by
vertical bar "|‖) means one or the other, and repetition (represented by "*‖)
means one or more occurrences.

The data dictionary for this DFD is shown below:

Weekly timesheet = Emplyee_Name + Employee_ID + {Regular_hours +

overtime_hours}

Pay_rate = {Horly | Daily | Weekly} + Naira_amount

Employee_Name = Last + First + Middle_Initial

Employee_ID = digit + digit + digit + digit

Most of the data flow in the DFD are specified here. Some of the most obvious
ones are not shown here. The data dictionary entry for weekly timesheet specifies
that this data flow is composed of three basic data entities - the employee name,
employee ID and many occurrences of the two-tuple consisting of regular hours
and overtime hours. The last entity represents the daily working hours of the
worker. The data dictionary also contains entries for specifying the different
elements of a data flow.

Once we have constructed a DFD and its associated data dictionary, we have to
somehow verify that they are "correct". There can be no formal verification of a
DFD, because what the DFD is modeling is not formally specify anywhere
against which verification can be done. Human processes and rule of thumb must
be used for verification. In addition to the walkthrough with the client, the
analyst should look for common errors. Some common errors are

1. Unlabeled data flows.

2. Missing data flows: Information required by a process is not available.
3. Extraneous data flows: Some information is not bein used in the process
 Systems Analysis and Design: A Simplified Approach | 90
____________________________________________________________________

4. Consistency not maintained during refinement

5. Missing processes
6. Contains some control information

Data flow description example:

Figure 5.6: Data flow description example

 Systems Analysis and Design: A Simplified Approach | 91
____________________________________________________________________

5.9 Logic Modelling

Data flow diagrams do not show the computation logic inside the processes.
Logic modeling involves representing internal structure and functionality of
processes depicted on a DFD. i.e., how data can be converted to information.
Logic modeling can also be used to show when processes on a DFD occur.

Logic Modelling Deliverables and Outcomes includes

 Structured English
 Decision Tables
 Decision Trees
 State-transition diagrams
 Sequence diagrams
 Activity diagrams

5.9.1 Structured English

It relies on action verbs and noun phrases without adjectives or adverbs to
specify three typical logic in structured programming: sequence, selection, and
repetition
sequence: sequential order of the statements
selection: IF_THEN_ELSE; SELECT_CASE
repetition: DO_UNTIL; DO_WHILE

Cap & gown ordering systems example

Process 3.1 Validate Student Status
MATCH Student_Information with Student_Record using student‘s
Last_Name and First_Name
BEGIN IF
IF Student_Not_Found
THEN RETURN Student_Not_Found
ELSE
IF graduation_date is not equal to May, 2001
THEN RETURN Student_Invalid_Status
END_IF
RETURN Valid_Student
 Systems Analysis and Design: A Simplified Approach | 92
____________________________________________________________________

Process 3.2 Validate Order Item

MATCH Order_Item_Information with Available_Item_Record based on
Item_Description
BEGIN IF
IF the Order_Item_Quantity is grater than the Available_Item_Quantity
THEN RETURN Insufficient_Quantity
END_IF
RETURN Valid_Order

5.9.2 Decision Tree

A decision tree is a decision support tool that uses a tree-like graph or model of
decisions and their possible consequences, including chance event outcomes,
resource costs, and utility. A decision tree is a flowchart-like structure in which
each internal node represents a "test" on an attribute (e.g. whether a coin flip
comes up heads or tails), each branch represents the outcome of the test and each
leaf node represents a class label (decision taken after computing all attributes).
The path from root to leaf represents classification rules.
In decision analysis a decision tree and the closely related influence diagram are
used as a visual and analytical decision support tool, where the expected
value (or expected utility) of competing alternatives are calculated.
A decision or choice situation is depicted as a connected series of nodes
(decision points) and branches (decision alternatives)
A decision tree consists of 3 types of nodes:
 Decision nodes - commonly represented by squares
 Chance nodes - represented by circles
 End nodes - represented by triangles
 Systems Analysis and Design: A Simplified Approach | 93
____________________________________________________________________

Figure 5.7: A decision tree structure

Figure 5.8: Cap & gown ordering system example

 Systems Analysis and Design: A Simplified Approach | 94
____________________________________________________________________

5.9.3 Decision Table

A decision table (DT) is a table of contingencies for defining a problem and the
actions to be taken. It is single representation of the relationships between
conditions and actions. A decision table presents a set of conditions and their
corresponding actions. It displays the possible actions that a decision-maker can
follow according to the outcome of a number of relevant conditions.

Each decision rule of a DT is composed of a premise (condition) and a

conclusion (action). In its tree-like representation, the premises and conclusions
are shown as nodes, and the branches of the tree connect the premises and the
conclusions. The logical operators ―AND‖ and ―OR‖ are used to reflect the
structure of the if-then rules. As such, decision tables (DTs) do not seem to differ
much from a decision tree. Instead of specifying a table, the choice maker
constructs a graph of the decision alternatives emanating as branches from a root
node over a number leafs. There are, however, some important differences
between both approaches. The advantage of the DT is that it provides a more
compact visual presentation and, thus, contributes to a better comprehension of
the choice problem. But probably the most important advantage is that using a
DT the completeness, correctness and consistency of the information input is
easier to check. Thus, in a way, a DT may be regarded as a special case of a
decision tree because it fulfils certain logical constraints.

In summary, Decision tables

 Decision tables are an excellent tool
- To capture certain kinds of system requirements.
- To document internal system design
 They are used to record complex business rules that a system must
implement
 In addition, they can serve as a guide to creating test cases
 Decision tables are a vital tool in the tester's personal toolbox
 Unfortunately, many analysts, designers, programmers, and testers are not
familiar with this technique

Technique:
 Decision tables represent complex business rules based on a set of
conditions.
 Systems Analysis and Design: A Simplified Approach | 95
____________________________________________________________________

 all possible choices and conditions the choices depend on are represented
in tabular form: condition, actions, and rules
 The general form/structure is shown in Figure 5.1

Problem area
Conditions and Actions Rules
CONDITION SET CONDITION
SPACE/ALTERNATIVE
ACTION SET ACTION SPACE/ENTRIES

Figure 5.9: The general structure of a decision table

Maximum number of rules in the table =

n: number of conditions
Ci: number of alternatives for condition i

Condition Stubs - Condition stubs describe the conditions or factors that will
affect the decision or policy. They are listed in the upper section of the decision
table.

Action Stubs -Action stubs describe, in the form of statements, the possible
policy actions or decisions. They are listed in the lower section of the decision
table.

Rules - Rules describe which actions are to be taken under a specific

combination of conditions. They are specified by first inserting different
combinations of condition attribute values and then putting X's in the appropriate
columns of the action section of the table.
 Systems Analysis and Design: A Simplified Approach | 96
____________________________________________________________________

Decision Table Methodology

Find the data attribute each condition tests and

1. Identify Conditions & Values
all of the attribute's values.
2. Compute Max Number of Multiply the number of values for each
Rules condition data attribute by each other.
Determine each independent action to be
3. Identify Possible Actions
taken for the decision or policy.
Fill in the values of the condition data
4. Enter All Possible Rules
attributes in each numbered rule column.
For each rule, mark the appropriate actions
5. Define Actions for each Rule
with an X in the decision table.
Review completed decision table with end-
6. Verify the Policy
users.
Eliminate and/or consolidate rules to reduce
7. Simplify the Table
the number of columns.

Example 1: Before making a plan/design, experts are asked to establish the

(functional or technical) requirements the design must meet, considering the
needs and constraints imposed by users, policies, the environment, etc.

The limited-entry decision table is the simplest to describe. The condition

alternatives are simple Boolean values, and the action entries are check-marks,
representing which of the actions in a given column are to be performed.
 Systems Analysis and Design: A Simplified Approach | 97
____________________________________________________________________

Rules
Conditions and Actions 1 2 3 4
Under N50 Y Y N N
Pays by check with 2 forms of ID Y N Y N
Uses credit card N Y N Y
Ring up sales X
Decline sales X
Call supervisor for approval X
Call bank for credit authorization X

Example 2: A technical support company writes a decision table to diagnose

printer problems based upon symptoms described to them over the phone from
their clients. The following is a balanced decision table.
Printer troubleshooter
Rules
Printer does not print Y Y Y Y N N N N
Conditions A red light is flashing Y Y N N Y Y N N
Printer is unrecognized Y N Y N Y N Y N
Check the power cable X
Check the printer-computer cable X X
Actions Ensure printer software is installed X X X X
Check/replace ink X X X X
Check for paper jam X X
Of course, this is just a simple example (and it does not necessarily correspond to
the reality of printer troubleshooting), but even so, it demonstrates how decision
tables can scale to several conditions with many possibilities.
Example 3: Company X sells merchandise to wholesale and retail
outlets. Wholesale customers receive a two percent discount on all orders. The
company also encourages both wholesale and retail customers to pay cash on
 Systems Analysis and Design: A Simplified Approach | 98
____________________________________________________________________

delivery by offering a two percent discount for this method of payment. Another
two percent discount is given on orders of 50 or more units. Each column
represents a certain type of order.

Process 3. Validate Order - Cap & gown ordering system example.

Conditions/Actions Rules
Student found Y - N -
Graduate in May Y N - -
Item in stock Y - - N
Accept order X
Reject order X X X

The Decision Table records the conditions for discounts in the top left quadrant
along with the ranges for the conditions in the top right quadrant. The bottom
half of the table lists the actions taken, i.e., the discount rates that apply, based on
the conditions. Each column represents a certain type of order. For example,
column two represents cash on delivery orders of less than 50 units from
retailers.
 Systems Analysis and Design: A Simplified Approach | 99
____________________________________________________________________

5.10 When to use what?

Condition Recommendation
Many repetitious actions Structured English
Communication to end users is important Structured English
Complex combinations of conditions, actions and rules Decision tables
Checking for redundancies, contradictions, possibilities Decision tables
The sequence of conditions and actions is critical Decision tree
Not every condition is relevant to every action Decision tree

5.11 Evolution of Systems Analysis Techniques

Era Orientation Techniques Evaluation
Pre-computer Flow- Process flow charts Little
oriented, Forms flow charts clarification of
i.e., no system structure
logical Weak on the
details treatment of
procedure
1stGeneration Flow- System flow charts Reduce
(1950's) oriented Flowcharts readability to non-
Message technical people
specification sheets Human is
considered external
to the system
2nd & Package- Decision tables Multiple system
3rdGeneration approach Gridcharts representations
(1970's) Analysis packages, require multiple
e.g., IBM's SOP tools
(Study Organization
Plan)
4thGeneration Structured Functional Improved
(1980's) decomposition consideration of
IBM's HIPO system structure
DFD issues
Data dictionary
Structured process
specification
 Systems Analysis and Design: A Simplified Approach | 100
____________________________________________________________________

5.12 Fact Finding Techniques - Case Study: Library Management System

In the previous chapter, we discussed how the analyst performed the preliminary
analysis. But we didn't look into the actual methods that the analyst employed to
gather the information about the system. In our case the analyst used on-site
observations, interviewed the staff members and used questionnaires for both
staff and members of the library.

Now we'll look at the techniques that the analyst employed to document the
various business rules of the library. Analyst identified the following business
rules.

1) Procedure for becoming a member of library.

Anyone whose age is 18 or more than that can become a member of library.
There are two types of memberships depending upon the duration of
membership. First is for 6 months and other is for 1 year. 6 months membership
fee is N500 and 1 year membership fee is N1000.

The decision tree and decision table illustrating the business rule are given
below.

Figure 5.10: Decision Tree for Membership Rule

 Systems Analysis and Design: A Simplified Approach | 101
____________________________________________________________________

Is Age < 18 Y . .
Age > = 18 . Y Y
Is Membership for 6 months? . Y .
Is Membership for 12 months? . . Y
Grant Membership . X X
Deny Membership X . .
Charge Membership N500 . X .
Charge Membership N1000 . . X
Figure 5.11: Decision table for membership rule
2) Rule for Issuing Books
If the number of books already issued is equal to 4 then no more books is issued
to that member. If it is less than 4 then that book is issued.

Figure 5.12: Decision Tree for the issue of Books.

Figure 5.13: Decision table for Book Issue rule

Now the analyst has a good understanding of the requirements for the new
system, we can move to the designing. Design of the system will be discussed in
the later chapters.
 Systems Analysis and Design: A Simplified Approach | 102
____________________________________________________________________

5.13 Case Study 2: Payroll System- Analyzing the Present System

Having collected as much information about the present system as possible, the
systems analyst now looks though it all to understand how the system works, and
to try and identify problems that need to be fixed.

Identifying the Inputs, Outputs and Processes

Every system has inputs and outputs and the systems analyst needs to identify the
data input to the present system, and the data output. This is because any new
system that is designed will have to deal with similar inputs and outputs as the
present system.

For example, the payroll system in a business might have the following inputs
and outputs.

Figure 5.14: Inputs and Outputs from a Payroll System

Identifying the inputs, outputs and processes helps the Systems Analyst really
understand how a system works:

 What goes in?

 What happens inside?
 What comes out?

Any new system that is created will need to take in the same input data (the
number of hours worked by employees), and will have to produce the same three
outputs.
 Systems Analysis and Design: A Simplified Approach | 103
____________________________________________________________________

For similar reasons, the systems analyst also has to understand how the present
system works (the processes – who does what and when).

Figure 5.15: Payroll System processes

It is important to know exactly how the system works because some parts of the
present system may work very well, and it would be a waste of time and effort to
replace them.
Most large systems are actually made up of many sub-systems. We call these
sub-systems processes.

Each process takes data from the inputs or from other processes, processes the
data, and produces an output. The output is passed to other processes, and so on.

Identifying Problems

No system is perfect and it is the job of the systems analyst to try and identify
where the problems in a system are.

If these problems can be fixed, the system will work more smoothly, be more
efficient and, in the case of a business, be more profitable.
 Systems Analysis and Design: A Simplified Approach | 104
____________________________________________________________________

In the above payroll example, the following problems might be identified...

 The payroll often takes over three days to process, resulting in many
employees being paid late
 Timesheets sometimes get lost before being processed. This means that
sometimes pay has to be estimated
 The reports sent to management do not show enough information.

Figure 5.16: Identifying problems

Hopefully you have realized why all of the research and analysis is necessary.
Unless we really understand how a system works, we can't begin to identify the
parts that are broken and need fixing / replacing
 Systems Analysis and Design: A Simplified Approach | 105
____________________________________________________________________

New System Requirements Specification

Now the problems with present system are understood, the system analyst can
begin to plan how the new system will fix those problems. The systems analyst
specifies a list of requirements for the new system (‗requirements‘ simply means
targets or aims).

This list is usually called the Requirements Specification.

For the payroll example the requirements might be...

1. Payroll processing should be completed within 24 hours

2. The recording of hours worked should use a system that means the data
cannot be lost
3. Management reports should contain detailed information about pay for
each department, overtime payments and average hours worked by each
employee
4. Management reports should be electronic so that managers can analyse
the data more easily

Any new system that is designed must meet these requirements.

The whole point of any system analysis is to end up with a better system than
presently exists. The Requirements Specification is the document that lists all of
the improvements that we hope the new system will bring.

What Hardware and Software Will Be Required?

The systems analysts will now need to decide what hardware and software will
be required for the new system.

Hardware

 How many computers?

 What type of network?
 How many servers?
 Any special input devices? (e.g. barcode readers)
 Any special output devices?
 Systems Analysis and Design: A Simplified Approach | 106
____________________________________________________________________

Software

 Is ready-made, off-the-shelf software available?

 Is custom-written software required?

Off-the-shelf software is software that is created for use by a large range of

customers - it tends to be quite general-purpose.

Custom-written software is designed and written specifically for one customer.

Off-the-shelf software:

 Cheaper
 More reliable (because most problems will have been found by one of the
many users)
 Has lots of support and help available (because lots of other people are
using it)
Custom-written software:
 Very expensive
 Provides exactly what the customer needs (a „perfect fit‟)
 Only has one user, so little help is available

5.14 Summary
 In the analysis of the present system, the analyst collects a great deal of
relatively unstructured data through interviews, questionnaires, on–site
observations, procedures manuals, and the like.
 Requirements determination involves studying the current business
system to find out how it works and where improvements should be
made.
 The specific methods analysts use for collecting data about requirements
are called fact – finding techniques. These include the interview,
questionnaire, record inspections (on – site review) and observation.
 Analysts usually employ more that one of these techniques to help ensure
an accurate and comprehensive investigation.
 The traditional approach focuses on cost/benefit and feasibility analysis,
project management, hardware and software selection and personnel
considerations.
 Systems Analysis and Design: A Simplified Approach | 107
____________________________________________________________________

 In contrast, structured analysis considers new goals and structured tools

for analysis. The first step is to draw a data flow diagram (DFD). The
DFD was first developed by Larry Constantine as a way of expressing
system requirements in a graphical from; this led to a modular design.
 A decision tree is a diagram that presents conditions and actions
sequentially and thus shows which conditions to consider first, which
second, and so on. It is also a method of showing the relationship of each
condition and its permissible actions.
 A decision table is a table of contingencies for defining a problem and the
actions to be taken. It is single representation of the relationships between
conditions and actions.
 The primary strength of the DFD is its ability to represent data flows. It
may be used at high or low level of analysis and provides good system
documentation.
 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.
 Structured English is best used when the problem requires sequences of
actions with decisions.
 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.

5.15 Review Questions

1. What type of information is best obtained through interview.
2. What is systems requirement?
3. What advantages do decision trees present?
4. Discuss the pros and cons of the various tools of doing analysis.
 Systems Analysis and Design: A Simplified Approach | 108
____________________________________________________________________

CHAPTER SIX

System Design

6.0 Introduction
Once the analysis has taken place and the systems analyst has some idea of the
scale of the problem and what needs to be done, the next stage is to design the
key parts of the recommended system. The analyst designs all aspects of the
system from the data collected. System design allows you to define the ―look and
feel‖ of all system outputs, inputs, interfaces, dialogues, and data requirements.

This chapter introduces techniques for the design of interfaces, menus, and
databases, based on the requirement specification worked out during the analysis
phase (functioning diagram, relationship diagram, data flow diagram...). At the
end of this phase, you need to identify the borderline between the computer
system and human being and find the answer to the question of how to attain the
system's objectives.

6.1 What vs How

 The logical model is completed during the Systems Analysis Phase

o What are the needs?
o DFD, DD, ERD, Process Descriptions
 The physical model is completed during the Systems Design Phase
o How are the needs delivered?
o Output, Input, file design, processing, and architecture

6.2 System Design

Based on the user requirements and the detailed analysis of the existing system,
the new system must be designed. The design phase attempts to answer the
question: How will this system work? It is the most crucial phase in the
 Systems Analysis and Design: A Simplified Approach | 109
____________________________________________________________________

developments of a system. The logical system design arrived at as a result of

systems analysis is converted into physical system design.

The design translates the system requirements into ways of operationalizing

them. The design is a solution, a ―how to― approach, compared to analysis, a
―what is‖ orientation. The design phase focuses on the detailed implementation
of the system recommended in the feasibility study. Emphasis is on translating
performance specifications into design specifications. The design phase is a
transition from a user-oriented document to a programmer-oriented document.

Normally, the design proceeds in two stages:

 Preliminary or General 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. If the project is
still considered to be feasible, we move to the detailed design stage.
 Structured or Detailed Design: In the detailed design stage, computer
oriented work begins in earnest. At this stage, the design of the system
becomes more structured. Structure design is a blue print of a computer
system solution to a given problem having the same components and
inter-relationships among the same components as the original problem.
Input, output, databases, forms, codification schemes and processing
specifications are drawn up in detail.

In the design stage, the programming language and the hardware and software
platform in which the new system will run are also decided. There are several
tools and techniques used for describing the system design of the system. These
tools and techniques, also used in analysis, include: Flowchart , Data flow
diagram (DFD), Data dictionary, Structured English, Decision table and Decision
tree.

6.3 General Guidelines for Systems Design

Goal of Systems Design
Build a system that is effective, reliable and maintainable
Effective – satisfy defined requirements
Reliable – handles errors
Maintainable – well designed, flexible, considers future
modifications
 Systems Analysis and Design: A Simplified Approach | 110
____________________________________________________________________

Design Approach
Consider Users, Data and Processing – in that order

6.4 Physical Modeling Phase

 Review the system requirements (analysis)

 Model the system

i) Interface/Input and data entry /Output Design (user design)

 Use scenario/interface
 design the data capture forms/input forms
 validation to be applied to input data
 determining the data requirement for producing the output
 design the screen and print layouts
 design output forms and reports
 Defining precisely the required system output

ii) File and Database Design (Data modelling)

 Data format specification -Determining the medium and
format of files and databases
 physical layout of data files, DB normalization
 File design including access method and file organization
to be used. Each data item will be defined by name and
size, type and use recorded.
 File structures/tables need to be designed/agreed
 Select the most appropriate data verification method(s)
 Select/design any validation rules that need to be used

iii) Program Design

 Data flow programming
 Program structure chart (produce any algorithms or
program flowcharts)
 Program specification
 produce systems flowcharts and/or pseudocode
 Modularization – the analyst identifies how the logical
design will break down into smaller modules/programs
 Systems Analysis and Design: A Simplified Approach | 111
____________________________________________________________________

iv) Process design

 system flowcharts, data flow diagrams, decision tables

v) Architectural Design:
 select/design the hardware requirements for the new system
 select/design the software requirements
 select/design the network infrastructure

vi) Other aspects of design include:

 Design a testing strategy/plan -Plan for testing and setting
target dates. Method of conversion from old to the new
system
 Designing Codification Schemes
 Detailed manual procedures
 Documenting the Design
 Data structures
 Security of data (and privacy) to be built in
 Training identified

 Present the system design

A system specification is produced and from this, individual program
specifications for each program process. System design specification
report which also includes costs and benefits is presented to
Management.

6.5 Summary

 The design translates the system requirements into ways of

operationalizing them.
 The design is a solution, a ― how to ― approach, compared to analysis, a
―what is‖ orientation.
 The design phase focuses on the detailed implementation of the system
recommended in the feasibility study.

6.6 Review Questions

1. What is system design?
2. How does system design simplify implementation?
 Systems Analysis and Design: A Simplified Approach | 112
____________________________________________________________________

CHAPTER SEVEN

Interface, Input and Output Design

7.0 Introduction

As discussed earlier, inputs and outputs are an important part of any system, so
while designing a system inputs and outputs of the system as a whole need to be
identified and the inputs and outputs for the various processes of the system need
to be listed down. We need to define the manner (method and sequence) in which
humans and computers exchange information.

7.1 Interface Design

Systems are designed for human beings to make their work simpler and faster.
Hence interaction of any system with the human being should be an important
area of concern for any system analyst. The analyst should be careful enough to
design the human element of the system in such a manner that the end user finds
the system friendly to work with. Interface design implies deciding upon the
human computer interfaces.

There are various types of user-computer interface designs, each of which has a
typical character and ability. The design type is required to be suitable to the
system‘s duties and to its users who will interact directly with the computers.

Significant criteria for the evaluation of dialogue type:-

Easy to use: easy even with inexperienced users-
Easy to learn: easy for users to remember -
Processing and responding speed-
Easy to develop-
 Systems Analysis and Design: A Simplified Approach | 113
____________________________________________________________________

The following factors should be considered while working on interfaces.

 Use of a consistent format for menu, command input, and data display.
 Provide the user with visual and auditory feedback to ensure that two-way
communication is established.
 Provide undo or reversal functions.
 Reduce the amount of information that must be memorized between
actions.
 Provide help facilities that are context sensitive.
 Use simple action verbs or short verb phrases to name commands.
 Display only that information that is relevant to the current context.
 Produce meaningful error messages.
 Use upper and lower case, indentation, and text grouping to aid in
understanding.
 Produce meaningful error messages.
 Maintain consistency between information display and data input. The
visual characteristics of the display (e.g., text size, color, and placement)
should be carried over to the input domain.
 Interaction should be flexible but also tuned to user's preferred mode of
input.
 Deactivate commands that are inappropriate in the context of current
actions.
 Provide help to assist with all input actions

7.1.1 Significant Types of User-computer Interface Design:-

Q&A: Questions or pop-up reminders on computer are by turn answered by

users. This type of design is simple and suitable with inexperienced users-
Menu table: Options are classified and displayed on the screen. Menu table is
frequently used as a mechanism for connecting to the system. It is a good
approach if the screen displays a full menu. This type of design is suitable with
inexperienced users but boring with more experienced users-
Symbols: Symbols are displayed on the screen to stand for various functions.
They are easy to learn and they enable fast access. In fact, graphics occupy more
space on the screen and they are not as economic as menu table. The main
disadvantage of symbols is their inability to describe the options lively, clearly
and meaningfully. In order to develop symbol-dialogue, professional software
are necessary.-
 Systems Analysis and Design: A Simplified Approach | 114
____________________________________________________________________

Form: Filling in the form is a popular type of dialogue on data and data
processing. Forms are displayed on the screen similarly to the way tables are
arranged. The screen also displays form name, field name and instruction
information. The pointer controlled by a software moves automatically among
fields or by using TAR or carriage return – enter keys. The advantage of form is
its close contact with users. This type of design is suitable to all users.-
Language command: This is a wide but simple area consisting of both simple
commands and grammatically complicated commands. A command will result in
a move of the system when it is entered by the user. The most significant
advantage of language command is that its flexibility is limited by the language‘s
grammar only. However, it takes time for users to learn by heart the commands
and users are required to have background knowledge of the system in case there
are no information displayed on the screen. Language command asks for great
efforts while developing it. It is suitable for users who are professionals.

7.1.2 Essential Instructions in Dialogue Design

Feedback information: provide users with the information on what are being
done Status: keep users informed of the system‘s parts they are using
Escape: allow users to exit from one manipulation
Minimum tasks: Avoid users from making too many manipulations
Default: Set the frequently used parameter
Support: Provide users with necessary supporting information
Cancel: Users can cancel and resume
Consistence: The implementation of commands must be consistent via interface

7.2 Screen Design

In this process, the most important thing is that the displayed information,
command, notice of the systems status go in line with each other and are
arranged in priority order in particular cases and comfortable to users. There are
3 main types of display:
• Menu display: which helps users in fast connecting and easy access to
system‘s functions
• Dialogue display: that consists of notices/dialogues between users and the
system
• Data entry display: which organizes data in groups of information classified
by changeability, frequency of use, importance. Depending on the situations,
designers will decide whether to design simple or master-detail data entry display
 Systems Analysis and Design: A Simplified Approach | 115
____________________________________________________________________

7.3 Input Design

The design decisions for handling input specify how data are accepted for
computer processing. During design of input, the analyst should decide on the
following details:

 What data to input

 Define the methods used for data capture, entry and input
Data Capture – record the source data
Data Entry – convert Captured data into computer readable form
Data Input – process Entered data into the Information System

 What medium to use

 How data should be arranged
 How data should be coded i.e. data representation conventions
 The dialogue to guide users in providing input i.e. informative messages
that should be provided when the user is entering data. Like saying, "It is
required. Don't leave it blank."
 Data items and transactions needing validation to detect errors
 Methods for performing input validation and steps to follow when errors
occur

7.3.1 Input Design Objectives

 Develop efficient input procedures:
o Make it easy to do the right things and hard to do the wrong
things.
o Don‘t penalize good users.
 Reduce input volume
 Reduce input errors

7.3.2 Key Tasks in Input Design

 List system inputs with data content
o examine the output requirements
 Design and prototype input methods
 Input controls & security
 Identify devices and mechanisms
 Systems Analysis and Design: A Simplified Approach | 116
____________________________________________________________________

7.3.3 Designing the System Inputs

To get data into a system is a two-part process:

1. Data must first be ‗captured‘ (collected in a way that then makes it easy
to input)
2. Data must be input into the computer

The systems analyst will select a data capture method and data input method that
best suit the requirements of the new system.

Sometimes the two steps of data capture and data input are performed at the
same time. For example a barcode reader captures the data (the numeric code
on the barcode) and inputs it to a computer in one go.

Figure 7.1: Data capture and input

 Systems Analysis and Design: A Simplified Approach | 117
____________________________________________________________________

7.3.4. Choosing the Best Data Capture and Data Input Methods for the
System

Collecting data into a form that is ready for input to a computer system can be
done in many ways:

Paper Forms
Form can be a simple one with spaces for numbers and text to be written in.
The data form this form would then be typed into the computer

Forms can also be machine-readable, such as OMR forms

Barcode Reader
Barcode readers capture the numeric code that
the barcode represents.
Typically used with POS systems and also
stock-control systems.
Card Reader
Many cards contain data stored on a magnetic
strip or in a small bit of memory (smart cards)
which can be captured with a card reader
Used in systems such as EFTPOS

Camera
Capture still or moving images which can then
be input to a computer for processing

In the payroll example, the hours worked by the employees could be captured
using...
 A paper form (a timesheet) - simple and
cheap, but the needs to be manually input
(slow) and the form can be lost
 Barcode reader - employees could have ID
cards and swipe them at the start and end of
work (can cheat easily)
 Fingerprint reader - employees could put a
finger on the reader at the start and end of work
(hard to cheat)
 Systems Analysis and Design: A Simplified Approach | 118
____________________________________________________________________

7.3.5. Designing On-Screen Forms for Data Input

Much of the data that enters computer systems needs to typed in. A well-
designed on-screen form can make this task easier and quicker.

On-screen forms should:

 Have all of the necessary fields

 Have obvious places for user input (boxes, use of colour, etc.)
 Use appropriate controls (see below) for each field
 Have text box controls that are the right size for the data
 Have easy-to-understand instructions (if needed)
 Make good use of the screen area available

7.3.6. Form Controls

On-screen forms can have a variety of controls (the little buttons / boxes that you
click or type in):

Textbox Option / Radio Buttons

Buttons
Used for normal text Used to Used to select an option
perform an
input (only one can be picked)
action

Tick / Check Boxes

Used to select options
(more than one can be Drop-Down Menus
ticked) Used to select options
from a list

Figure 7.2: Form controls

 Systems Analysis and Design: A Simplified Approach | 119
____________________________________________________________________

As data is entered into the form, it needs to be checked for accuracy. Two
techniques help us do this: validation and verification...

Figure 7.3: An on-screen form

Above is an example of a well-designed on-screen form. Note the clear

instructions, labels and layout.
Note that appropriate controls have been used for each field
 Systems Analysis and Design: A Simplified Approach | 120
____________________________________________________________________

7.3.7. Data Validation Techniques

When data is input to a computer, it is a good idea for the computer to check that
the data is sensible (no dates of birth in the future, etc.)

Checks like this are called validation checks (is the data valid?)

Different validation checks can be used on different fields, depending on the

type of data being entered

 Presence Check
o Is data actually present in a field, or has it been missed out?
 Range Check
o Is the data value within a set range?
(E.g. an exam mark should be between 0% and 100%, a month
should be between 1 and 12)
 Length Check
o Is an item of text too short or too long?
 Type Check
o Is the data the correct type?
(E.g. the letter ‗A‘ should not be allowed in a numeric field)
 Format Check
o Is the data in the correct format?
(E.g. a date of birth should be entered as dd/mm/yyyy)

Figure 7.4: A validation check

 Systems Analysis and Design: A Simplified Approach | 121
____________________________________________________________________

If one of the validation checks fails (because the data entered is invalid) the
computer should show a nice, friendly error message such as...
“You have forgotten to enter a name”

7.3.8. Data Verification Techniques

Data validation only checks whether the data entered is sensible - it does not
mean that the data is the right data.

For example, if you are entering a date of birth and you mis-type it…

 Correct date of birth: 12/11/1982

 Date of birth entered: 12/11/1928

You would not see an error, since 12/11/1928 is a valid date of birth.

To check that data is the correct value, we use a system called data verification.

There are two methods of data verification:

1. Proof Reading
After the data has been entered a person compares the original data with the data
in the computer (either on the screen or using a print-out). If mistakes are spotted
they can be corrected by the person. Proof-reading is quick and simple, but
doesn‘t catch every mistake.

2. Double-Entry
The data is entered into the computer twice (preferably by two different people).
The computer compares the two sets of data to see if they match. If not it
generates an error and a person will need to correct the mistake. Double-entry
takes more time and effort, but it catches almost every mistake.
 Systems Analysis and Design: A Simplified Approach | 122
____________________________________________________________________

Figure 7.5: Data verification using double-entry

A common example of double-entry verification is when you are asked to choose

a new password - you are usually asked to type it in twice to make sure you've
typed it correctly (since the actual letters are hidden)

7.4 Output Design

Output refers to the results and information that are generated by the system. In
many cases, output is the main reason for developing the system and the basis on
which the usefulness of the system is evaluated. Most end-users will not actually
operate the information system or enter data through workstations, but they will
use the output from the system.

While designing the output of system, the following factors should be

considered:

 Determine what information to present

 Decide on the mode of output, i.e. whether to display, print, or "speak"
the information and select the output medium
 Arrange the presentation of information in an acceptable format
 Decide how to distribute the output to intended recipients
 Exact format of reports

These activities require specific decisions, such as whether to use preprinted

forms when preparing reports and documents, how many lines to plan on a
printed page, or whether to use graphics and color. The output design is specified
 Systems Analysis and Design: A Simplified Approach | 123
____________________________________________________________________

on layout forms, sheets that describe the location characteristics (such as length
and type), and format of the column heading, etc.

7.4.1. Output Design Principles

A number of basic design principles ensure that the output is presented in a way
that is easy to understand and interpret. They are as follows:
Notes, headings, and output formats should be standardized whenever
possible. Format consistency is an attribute of ‗user-friendly‘ output.
Users feel comfortable. With familiar layouts.
The arrangement of information should be logical. Information should be
presented in ‗chunks‘ or quantities that can be easily absorbed in language
that is easy to understand
Acronyms and abbreviations in output should be avoided especially when the
output will serve novice users. Define words that may be unfamiliar to the
user.
Algorithms and assumptions on which calculations are based should be
available to users of the output. This assures correct interpretation of
output.
The user should be able to locate needed data quickly without having to
search through all of the data.

7.4.2. Designing the System Outputs

There are usually two types of output from a system that need to be designed:

 On-screen reports (information displayed on the monitor)

 Printed reports (hard-copy to be mailed, filed, etc.)

Designing On-Screen Reports

Designing an on-screen report is similar to designing an on-screen form (see

above). There are a number of things that the designer should consider.

On-screen reports should...

 Show all of the necessary fields

 Have fields that are the right size for the data
 Have easy-to-understand instructions (if needed)
 Make good use of the screen area available
 Systems Analysis and Design: A Simplified Approach | 124
____________________________________________________________________

 Make good use of colours and fonts to make the data clear

This is an example of a well-designed on-screen report used to show details of an

employee.

Figure 7.5: On-screen Report

On-screen reports can include more than just text...

Reports can include:

 Text
 Images
 Bar charts
 Pie charts
 Animations
 Video
 Systems Analysis and Design: A Simplified Approach | 125
____________________________________________________________________

Designing Printed Reports

Designing a printed report is just like designing an on-screen report (see above),
except that the report needs to fit a piece of printer paper, rather than the
screen. The report might also include page numbers, a header / footer, etc. This
is an example of a well-designed printed report used to show details of an
employee.

Figure 7.6: A printed report

 Systems Analysis and Design: A Simplified Approach | 126
____________________________________________________________________

7.5 Summary
 Inputs and outputs are an important part of any system, so while
designing a system inputs and outputs of the system as a whole need to be
identified and the inputs and outputs for the various processes of the
system need to be listed down.
 We need to define the manner (method and sequence) in which humans
and computers exchange information.
 Systems are designed for human beings to make their work simpler and
faster. Hence interaction of any system with the human being should be
an important area of concern for any system analyst.
 The analyst should be careful enough to design the human element of the
system in such a manner that the end user finds the system friendly to
work with.
 Interface design implies deciding upon the human computer interfaces.
 The design decisions for handling input specify how data are accepted for
computer processing. During design of input, the analyst should decide on
what data to input, methods for capture, entry and input, medium to use,
etc
 As data is entered into the form, it needs to be checked for accuracy. Two
techniques help us do this: validation and verification.

7.6 Review Questions

1. What are the key tasks in input design?

2. How are data got into a computer system?
3. On-screen forms can have a variety of controls. Name and briefly discuss
any four of them.
4. Name and explain any two data verification and two data validation
techniques.
5. What factors should be considered while designing the output of system?
 Systems Analysis and Design: A Simplified Approach | 127
____________________________________________________________________

CHAPTER EIGHT

File and Database Design

8.0 Introduction

Once the analyst has decided onto the basic processes and inputs and outputs of
the system, he also has to decide upon the data to be maintained by the system
and for the system. The data is maintained in the form of data stores, which
actually comprise of databases.

Each database may further be composed of several files where the data is
actually stored. The analyst, during the design of the system, decides onto the
various file-relating issues before the actual development of the system starts.

The design of files includes decisions about the nature and content of the file
itself such as whether it is to be used for storing transaction details, historical
data, or reference information.

When designing a database, the system designer needs to consider:

 The type of data being stored (numbers, text, dates, etc.)

 The size of the data (how long is a typical name, etc.)
 The field names to use
 How many records will need to be stored
 Which data items to include in a record format within the file?
 Length of each record, based on the characteristics of the data items
 The sequencing or arrangement of records within the file (the storage
structure, such as sequential, indexed, or relative)
 Systems Analysis and Design: A Simplified Approach | 128
____________________________________________________________________

The designer also needs to consider which backing storage device and media
will be suitable to store the data:

 How often will the data need to be accessed

 How quickly the data needs to be accessed
 How large will the data files be

So, for example, if there is a large amount of data that needs to be accessed
quickly, and regularly, then a hard drive would be the best storage device to use.

Figure 8.1: A table consisting of rows and columns in a relational database model

In database design, the analyst decides upon the database model to be

implemented. Database model can be traditional file based, relational, network,
hierarchical, or object oriented database model.

8.1 Overview of Database and File

 All information systems create, read, update and delete data. This data is
stored in files and databases.
 Files are collections of similar records.
 Databases are collections of interrelated files.
 The key word is interrelated.
 The records in each file must allow for relationships (think of them as
‗pointers‘) to the records in other files.
 In the file environment, data storage is built around the applications that
will use the files.
 In the database environment, applications will be built around the
integrated database.
 Systems Analysis and Design: A Simplified Approach | 129
____________________________________________________________________

8.2 Basic File Related Keywords:

Byte:- It is the smallest addressable unit in computer. A byte is a set of 8 bits and
represents a character.

Field/Element:- It is a combination of one or more bytes. A field is actually a

physical space on tape or disk. A roll number, age, name of employee etc. are
examples of it.

Record: - The elements related to are combined into a record. An employee has
a record with his name, designation, basic pay, allowances, deductions etc. as its
fields. A record may have a unique key to identify a record e.g. employee
number. Records are represented as logical & physical records. A logical record
maintains a logical relationship among all the data items in the record. It is the
way the program or user sees the data. In contrast a physical record is the way
data are recorded on a storage medium.

File: - It is a collection of similar records. The records will have the same fields
but different values in each record. The size of a file is limited by the size of
memory available.

Database: - It is a set of interrelated files. The files in combination tend to link

to a common solution. For example, a student attendance file, a student result
file, a student admission file, etc. are related to academic software pertaining to
students.

Attributes - detailed data about an entity, such as price, length, name

Cardinality - the relationship between two entities, in figures. For example, a

person can place multiple orders.

Entities - abstract data that you save in a database. For example: customers,
products.

Key - a key is used to point out records. The most well-known key is the Primary
Key (see Primary Key).
 Systems Analysis and Design: A Simplified Approach | 130
____________________________________________________________________

Foreign key (FK) - a referral to the Primary Key of another table. Foreign Key-
columns can only contain values that exist in the Primary Key column that they
refer to.

Primary key - one or more columns within a table that together form a unique
combination of values by which each record can be pointed out separately. For
example: customer numbers, or the serial number of a product.

Normalization - A flexible data model needs to follow certain rules. Applying

these rules is called normalizing.

8.3 File Design

A file is organized to ensure that records are available for processing. It should
be designed in the line with the activity and volatility of the information and the
nature of the storage media and devices.

There are four methods of organizing files: sequential, indexed – sequential,

inverted list and direct access.

• Sequential organization simply means storing and sorting in physical,

contiguous blocks within files on tape or disk according to key.

• Indexed sequential organization stores records sequentially but uses an index

to locate record. Records are related through chaining using pointers.

• Inverted list organization uses an index for each key type. Records are not
necessarily in a particular sequences.

• Direct access organization has records placed randomly throughout the file.
Records are updated directly and independently of the other records.

Most fundamental entities from the data model would be designed as master or
transaction records. The master files a typically fixed length records. Associative
entities from the data model are typically joined into the transaction records to
form variable length records (based on the one-to-many relationships). Other
types of files (not represented in the data model) are added as necessary.
 Systems Analysis and Design: A Simplified Approach | 131
____________________________________________________________________

Two important considerations of file design are file access and organization.
Other considerations are
(1) cost of file media (highest for disk, lowest for tape)
(2) inquiry requirements (real – time versus batch processing) and
(3) file privacy, integrity, security, and confidentiality.

The systems analyst usually studies how each program will access the records in
the file (‗sequentially‘ or ‗randomly‘), and then select an appropriate file
organization.

Method Advantages Disadvantages

Sequential Simple to design Record cannot be added
Easy to program to middle file
Variable length and
blocked records available
Best use of software
space

Indexed Sequential Records can be inserted Unique keys required

or updated in middle of
file Processing occasionally
Processing may be slow
carried out sequentially
or randomly Periodic re-organization
of file required
Random Record can be inserted or Calculating address
middle of file required updated in processing
for better control over
record allocation Variable-length nearly
impossible to process.
 Systems Analysis and Design: A Simplified Approach | 132
____________________________________________________________________

8.4 Database Design

Introduction
The design of any database will usually involve the DBA and database staff.
They will handle the technical details and cross-application issues.
It is useful for the systems analyst to understand the basic design principles
for relational databases.

Goals and Prerequisites to Database Design

The goals of database design are as follows:

 A database should provide for the efficient storage, update, and retrieval
of data.
 A database should be reliable – the stored data should have high integrity
to promote user trust in that data.
 A database should be adaptable and scaleable to new and unforeseen
requirements and applications.
 The data model may have to be divided into multiple data models to
reflect database distribution and database replication decisions.
 Data distribution refers to the distribution of either specific tables,
records, and/or fields to different physical databases.
 Data replication refers to the duplication of specific tables, records, and/or
fields to multiple physical databases.
 Each sub-model or view should reflect the data to be stored on a single
server.

8.5 What is good database design?

 Certain principles guide the database design process. The first principle is
that duplicate information (also called redundant data) is bad, because it
wastes space and increases the likelihood of errors and inconsistencies.
 The second principle is that the correctness and completeness of
information is important. If your database contains incorrect information,
any reports that pull information from the database will also contain
incorrect information. As a result, any decisions you make that are based
on those reports will then be misinformed.
 Systems Analysis and Design: A Simplified Approach | 133
____________________________________________________________________

A good database design is, therefore, one that:

 Divides your information into subject-based tables to reduce redundant

data.
 Provides Access with the information it requires to join the information in
the tables together as needed.
 Helps support and ensure the accuracy and integrity of your information.
 Accommodates your data processing and reporting needs.

8.6 Conventional Files Versus the Database

The Pros and Cons of Conventional Files

Pros:
 Conventional files are relatively easy to design and implement because
they are normally based on a single application or information system.
 Historically, another advantage of conventional files has been processing
speed.
Cons:
 Duplication of data items in multiple files is normally cited as the
principal disadvantage of file-based systems.
 A significant disadvantage of files is their inflexibility and non-
scaleability.
 As legacy file-based systems and applications become candidates for
reengineering, the trend is overwhelmingly in favor of replacing file-
based systems and applications with database systems and applications.

The Pros and Cons of Database

Pros:
 The principal advantage of a database is the ability to share the same data
across multiple applications and systems.
 Database technology offers the advantage of storing data in flexible
formats.
 Databases allow the use of the data in ways not originally specified by the
end-users - data independence.
 The database scope can even be extended without impacting existing
programs that use it.
 New fields and record types can be added to the database without
affecting current programs.
 Systems Analysis and Design: A Simplified Approach | 134
____________________________________________________________________

Cons:
 Database technology is more complex than file technology.
 Special software, called a database management system (DBMS), is
required.
 A DBMS is still somewhat slower than file technology.
 Database technology requires a significant investment.
 The cost of developing databases is higher because analysts and
programmers must learn how to use the DBMS.
 In order to achieve the benefits of database technology, analysts and
database specialists must adhere to rigorous design principles.
 Another potential problem with the database approach is the increased
vulnerability inherent in the use of shared data.

8.7 Database Design in Perspective

 To fully exploit the advantages of database technology, a database must

be carefully designed.
 The end product is called a database schema, a technical blueprint of the
database.
 Database design translates the data models that were developed for the
system users during the definition phase, into data structures supported by
the chosen database technology.
 Subsequent to database design, system builders will construct those data
structures using the language and tools of the chosen database technology.

8.8 Database Concepts for the Systems Analyst

Fields
 Fields are common to both files and databases.
 A field is the implementation of a data attribute.
 Fields are the smallest unit of meaningful data to be stored in a file or
database.
 There are four types of fields that can be stored: primary keys, secondary
keys, foreign keys, and descriptive fields.
o Primary keys are fields whose values identify one and only one
record in a file. Secondary keys are alternate identifiers for a
database.
 Systems Analysis and Design: A Simplified Approach | 135
____________________________________________________________________

o A single file in a database may only have one primary key, but it
may have several secondary keys.
o Foreign keys are pointers to the records of a different file in a
database.
o Foreign keys are how the database ‗links‘ the records of one type
to those of another type.
o Descriptive fields are any other fields that store business data.

Records
 When a computer program ‗reads‘ a record from a database, it actually
retrieves a group or block of records at a time.
 This approach minimizes the number of actual disk accesses.
 A blocking factor is the number of logical records included in a single
read or write operation (from the computer‘s perspective). A block is
sometimes called a physical record.
 Today, the blocking factor is usually determined and optimized by the
chosen database technology, but a qualified database expert may be
allowed to fine tune that blocking factor for performance.

Files and Tables

 Similar records are organized into groups called files.
 A file is the set of all occurrences of a given record structure.
 In database systems, a file corresponds to a set of similar records; usually
called a table.
 A table is the relational database equivalent of a file.
 Some of the types of files and tables include:
 Master files or tables contain records that are relatively permanent.
 Once a record has been added to a master file, it remains in the system
indefinitely.
 The values of fields for the record will change over its lifetime, but the
individual records are retained indefinitely.

Databases
 Databases provide for the technical implementation of entities and
relationships.
 The history of information systems has led to one inescapable conclusion:
o Data is a resource that must be controlled and managed!
 Systems Analysis and Design: A Simplified Approach | 136
____________________________________________________________________

 Out of necessity, database technology was created so an organization

could maintain and use its data as an integrated whole instead of as
separate data files.

8.9 Sample Database

Microsoft Office Access 2007 organizes your information into tables: lists of
rows and columns reminiscent of an accountant‘s pad or a Microsoft Office
Excel 2007 worksheet. In a simple database, you might have only one table. For
most databases you will need more than one. For example, you might have a
table that stores information about products, another table that stores information
about orders, and another table with information about customers.

Figure 8.2: Table names and field names.

 Systems Analysis and Design: A Simplified Approach | 137
____________________________________________________________________

Figure 8.3: The tables and fields

Each row is also called a record, and each column, is also called a field. A
record is a meaningful and consistent way to combine information about
something. A field is a single item of information — an item type that appears in
every record. In the Products table, for instance, each row or record would hold
information about one product. Each column or field holds some type of
information about that product, such as its name or price.

8.10 Practical Approach to Database Design

Designing a database is in fact fairly easy, but there are a few rules to stick to. It
is important to know what these rules are, but more importantly is to know why
these rules exist, otherwise you will tend to make mistakes!

Standardization makes your data model flexible and that makes working with
your data much easier. Please, take the time to learn these rules and apply them

A good database design starts with a list of the data that you want to include in
your database and what you want to be able to do with the database later on. This
 Systems Analysis and Design: A Simplified Approach | 138
____________________________________________________________________

can all be written in your own language, without any SQL. In this stage you must
try not to think in tables or columns, but just think: "What do I need to know?"
Don't take this too lightly, because if you find out later that you forgot
something, usually you need to start all over. Adding things to your database is
mostly a lot of work.

Identifying Entities
The types of information that are saved in the database are called 'entities'. These
entities exist in four kinds: people, things, events, and locations. Everything you
could want to put in a database fits into one of these categories. If the
information you want to include doesn't fit into these categories, than it is
probably not an entity but a property of an entity, an attribute.

To clarify the information given in this article we'll use an example. Imagine that
you are creating a website for a shop, what kind of information do you have to
deal with? In a shop you sell your products to customers. The "Shop" is a
location; "Sale" is an event; "Products" are things; and "Customers" are people.
These are all entities that need to be included in your database.

But what other things are happening when selling a product? A customer comes
into the shop, approaches the vendor, asks a question and gets an answer.
"Vendors" also participate, and because vendors are people, we need a vendors
entity.

Figure 8.4: Entities: types of information.

Identifying Relationships
The next step is to determine the relationships between the entities and to
determine the cardinality of each relationship. The relationship is the connection
between the entities, just like in the real world: what does one entity do with the
 Systems Analysis and Design: A Simplified Approach | 139
____________________________________________________________________

other, how do they relate to each other? For example, customers buy products,
products are sold to customers, a sale comprises products, a sale happens in a
shop.

The cardinality shows how much of one side of the relationship belongs to how
much of the other side of the relationship. First, you need to state for each
relationship, how much of one side belongs to exactly 1 of the other side. For
example: How many customers belong to 1 sale?; How many sales belong to 1
customer?; How many sales take place in 1 shop?

You'll get a list like this: (please note that 'product' represents a type of product,
not an occurrence of a product)

 Customers --> Sales; 1 customer can buy something several times

 Sales --> Customers; 1 sale is always made by 1 customer at the time
 Customers --> Products; 1 customer can buy multiple products
 Products --> Customers; 1 product can be purchased by multiple
customers
 Customers --> Shops; 1 customer can purchase in multiple shops
 Shops --> Customers, 1 shop can receive multiple customers
 Shops --> Products; in 1 shop there are multiple products
 Products --> Shops; 1 product (type) can be sold in multiple shops
 Shops --> Sales; in 1 shop multiple sales can me made
 Sales --> Shops; 1 sale can only be made in 1 shop at the time
 Products --> Sales; 1 product (type) can be purchased in multiple sales
 Sales --> Products; 1 sale can exist out of multiple products

Did we mention all relationships? There are four entities and each entity has a
relationship with every other entity, so each entity must have three relationships,
and also appear on the left end of the relationship three times. Above, 12
relationships were mentioned, which is 4*3, so we can conclude that all
relationships were mentioned.
 Systems Analysis and Design: A Simplified Approach | 140
____________________________________________________________________

Now we'll put the data together to find the cardinality of the whole relationship.
In order to do this, we'll draft the cardinalities per relationship. To make this easy
to do, we'll adjust the notation a bit, by noting the 'backward'-relationship the
other way around:

 Customers --> Sales; 1 customer can buy something several times

 Sales --> Customers; 1 sale is always made by 1 customer at the time

The second relationship we will turn around so it has the same entity order as the
first. Please notice the arrow that is now faced the other way!

 Customers <-- Sales; 1 sale is always made by 1 customer at the time

Cardinality exists in four types: one-to-one, one-to-many, many-to-one, and

many-to-many. In a database design this is indicated as: 1:1, 1:N, M:1, and M:N.
To find the right indication just leave the '1'. If there is a 'many' on the left side,
this will be indicated with 'M', if there is a 'many' on the right side it is indicated
with 'N'.

 Customers --> Sales; 1 customer can buy something several times; 1:N.
 Customers <-- Sales; 1 sale is always made by 1 customer at the time; 1:1.

The true cardinality can be calculated through assigning the biggest values for
left and right, for which 'N' or 'M' are greater than '1'. In thisexample, in both
cases there is a '1' on the left side. On the right side, there is a 'N' and a '1', the 'N'
is the biggest value. The total cardinality is therefore '1:N'. A customer can make
multiple 'sales', but each 'sale' has just one customer.

If we do this for the other relationships too, we'll get:

 Customers --> Sales; --> 1:N

 Customers --> Products; --> M:N
 Customers --> Shops; --> M:N
 Sales --> Products; --> M:N
 Systems Analysis and Design: A Simplified Approach | 141
____________________________________________________________________

 Shops --> Sales; --> 1:N

 Shops --> Products; --> M:N

So, we have two '1-to-many' relationships, and four 'many-to-many'

relationships.

Figure 8.4: Relationships between the entities.

Between the entities there may be a mutual dependency. This means that the one
item cannot exist if the other item does not exist. For example, there cannot be a
sale if there are no customers, and there cannot be a sale if there are no products.

The relationships Sales --> Customers, and Sales --> Products are mandatory, but
the other way around this is not the case. A customer can exist without sale, and
also a product can exist without sale. This is of importance for the next step.

Recursive Relationships

Sometimes an entity refers back to itself. For example, think of a work hierarchy:
an employee has a boss; and the bosschef is an employee too. The attribute 'boss'
of the entity 'employees' refers back to the entity 'employees'.
 Systems Analysis and Design: A Simplified Approach | 142
____________________________________________________________________

In an ERD (see next chapter) this type of relationship is a line that goes out of the
entity and returns with a nice loop to the same entity.

Redundant Relationships

Sometimes in your model you will get a 'redundant relationship'. These are
relationships that are already indicated by other relationships, although not
directly.

In the case of our example there is a direct relationship between customers and
products. But there are also relationships from customers to sales and from sales
to products, so indirectly there already is a relationship between customers and
products through sales. The relationship 'Customers <----> Products' is made
twice, and one of them is therefore redundant. In this case, products are only
purchased through a sale, so the relationships 'Customers <----> Products' can be
deleted. The model will then look like this:

Figure 8.6: Relationships between the entities.

Solving Many-to-Many Relationships

 Systems Analysis and Design: A Simplified Approach | 143
____________________________________________________________________

Many-to-many relationships (M:N) are not directly possible in a database. What

a M:N relationship says is that a number of records from one table belongs to a
number of records from another table. Somewhere you need to save which
records these are and the solution is to split the relationship up in two one-to-
many relationships.

This can be done by creating a new entity that is in between the related entities.
In our example, there is a many-to-many relationship between sales and
products. This can be solved by creating a new entity: sales-products. This entity
has a many-to-one relationship with Sales, and a many-to-one relationship with
Products. In logical models this is called an associative entity and in physical
database terms this is called a link table or junction table.

Figure 8.7: Many to many relationship implementation via associative entity.

In the example there are two many-to-many relationships that need to be solved:
'Products <----> Sales', and 'Products <----> Shops'. For both situations there
needs to be created a new entity, but what is that entity?

For the Products <----> Sales relationship, every sale includes more products.
The relationship shows the content of the sale. In other words, it gives details
about the sale. So the entity is called 'Sales details'. You could also name it 'sold
products'.

The Products <----> Shops relationship shows which products are available in
which the shops, also known as 'stock'. Our model would now look like this:
 Systems Analysis and Design: A Simplified Approach | 144
____________________________________________________________________

Figure 8.8: Model with link tables Stock and Sales_details.

Identifying Attributes
The data elements that you want to save for each entity are called 'attributes'.

About the products that you sell, you want to know, for example, what the price
is, what the name of the manufacturer is, and what the type number is. About the
customers you know their customer number, their name, and address. About the
shops you know the location code, the name, the address. Of the sales you know
when they happened, in which shop, what products were sold, and the sum total
of the sale. Of the vendor you know his staff number, name, and address. What
will be included precisely is not of importance yet; it is still only about what you
want to save.
 Systems Analysis and Design: A Simplified Approach | 145
____________________________________________________________________

Figure 8.9: Entities with attributes.

Derived Data

Derived data is data that is derived from the other data that you have already
saved. In this case the 'sum total' is a classical case of derived data. You know
exactly what has been sold and what each product costs, so you can always
calculate how much the sum total of the sales is. So really it is not necessary to
save the sum total.

So why is it saved here? Well, because it is a sale, and the price of the product
can vary over time. A product can be priced at 10 euros today and at 8 euros next
month, and for your administration you need to know what it cost at the time of
the sale, and the easiest way to do this is to save it here. There are a lot of more
elegant ways, but they are too profound for this article.

Presenting Entities and Relationships: Entity Relationship Diagram (ERD)

The Entity Relationship Diagram (ERD) gives a graphical overview of the
database. There are several styles and types of ER Diagrams. A much-used
notation is the 'crowfeet' notation, where entities are represented as rectangles
and the relationships between the entities are represented as lines between the
entities. The signs at the end of the lines indicate the type of relationship. The
side of the relationship that is mandatory for the other to exist will be indicated
through a dash on the line. Not mandatory entities are indicated through a circle.
 Systems Analysis and Design: A Simplified Approach | 146
____________________________________________________________________

"Many" is indicated through a 'crowfeet'; the relationship-line splits up in three

lines.

A 1:1 mandatory relationship is represented as follows:

Figure 8.10: Mandatory one to one relationship.

A 1:N mandatory relationship:

Figure 8.11: Mandatory one to many relationship.

A M:N relationship is:

Figure 8.12: Mandatory many to many relationship.

The model of our example will look like this:

 Systems Analysis and Design: A Simplified Approach | 147
____________________________________________________________________

Figure 8.13: Model with relationships.

Assigning Keys

 Primary Keys

A primary key (PK) is one or more data attributes that uniquely identify an
entity. A key that consists of two or more attributes is called a composite key. All
attributes part of a primary key must have a value in every record (which cannot
be left empty) and the combination of the values within these attributes must be
unique in the table.

In the example there are a few obvious candidates for the primary key.
Customers all have a customer number, products all have a unique product
number and the sales have a sales number. Each of these data is unique and each
record will contain a value, so these attributes can be a primary key. Often an
integer column is used for the primary key so a record can be easily found
through its number.

Link-entities usually refer to the primary key attributes of the entities that they
link. The primary key of a link-entity is usually a collection of these reference-
 Systems Analysis and Design: A Simplified Approach | 148
____________________________________________________________________

attributes. For example in the Sales_details entity we could use the combination
of the PK's of the sales and products entities as the PK of Sales_details. In this
way we enforce that the same product (type) can only be used once in the same
sale. Multiple items of the same product type in a sale must be indicated by the
quantity.

In the ERD the primary key attributes are indicated by the text 'PK' behind the
name of the attribute. In the example only the entity 'shop' does not have an
obvious candidate for the PK, so we will introduce a new attribute for that entity:
shopnr.

 Foreign Keys

The Foreign Key (FK) in an entity is the reference to the primary key of another
entity. In the ERD that attribute will be indicated with 'FK' behind its name. The
foreign key of an entity can also be part of the primary key, in that case the
attribute will be indicated with 'PF' behind its name. This is usually the case with
the link-entities, because you usually link two instances only once together (with
1 sale only 1 product type is sold 1 time).

If we put all link-entities, PK's and FK's into the ERD, we get the model as
shown below. Please note that the attribute 'products' is no longer necessary in
'Sales', because 'sold products' is now included in the link-table. In the link-table
another field was added, 'quantity', that indicates how many products were sold.
The quantity field was also added in the stock-table, to indicate how many
products are still in store.
 Systems Analysis and Design: A Simplified Approach | 149
____________________________________________________________________

Figure 8.14: Primary keys and foreign keys.

Defining the Attribute's Data Type

Now it is time to figure out which data types need to be used for the attributes.
There are a lot of different data types. A few are standardized, but many
databases have their own data types that all have their own advantages. Some
databases offerthe possibility to define your own data types, in case the standard
types cannot do the things you need.

The standard data types that every database knows, and are most-used, are:
CHAR, VARCHAR, TEXT, FLOAT, DOUBLE, and INT.
 Systems Analysis and Design: A Simplified Approach | 150
____________________________________________________________________

Text:

 CHAR(length) - includes text (characters, numbers, punctuations...).

CHAR has as characteristic that it always saves a fixed amount of
positions. If you define a CHAR(10) you can save up to ten positions
maximum, but if you only use two positions the database will still save 10
positions. The remaining eight positions will be filled by spaces.
 VARCHAR(length) - includes text (characters, numbers, punctuation...).
VARCHAR is the same as CHAR, the difference is that VARCHAR only
takes as much space as necessary.
 TEXT - can contain large amounts of text. Depending on the type of
database this can add up to gigabytes.

Numbers:

 INT - contains a positive or negative whole number. A lot of databases

have variations of the INT, such as TINYINT, SMALLINT,
MEDIUMINT, BIGINT, INT2, INT4, INT8. These variations differ from
the INT only in the size of the figure that fits into it. A regular INT is 4
bytes (INT4) and fits figures from -2147483647 to +2147483646, or if
you define it as UNSIGNED from 0 to 4294967296. The INT8, or
BIGINT, can get even bigger in size, from 0 to 18446744073709551616,
but takes up to 8 bytes of diskspace, even if there is just a small number in
it.
 FLOAT, DOUBLE - The same idea as INT, but can also store floating
point numbers. . Do note that this does not always work perfectly. For
instance in MySQL calculating with these floating point numbers is not
perfect, (1/3)*3 will result with MySQL's floats in 0.9999999, not 1.

Other types:

 BLOB - for binary data such as [Link] - for IP addresses. Also

useable for netmasks.
 Systems Analysis and Design: A Simplified Approach | 151
____________________________________________________________________

For our example the data types are as follows:

Figure 8.15: Data model displaying data types.

Normalization
Normalization makes your data model flexible and reliable. It does generate
some overhead because you usually get more tables, but it enables you to do
many things with your data model without having to adjust it.

Normalization, the First Form: The first form of normalization states that there
may be no repeating groups of columns in an entity. We could have created an
entity 'sales' with attributes for each of the products that were bought. This would
look like this:
 Systems Analysis and Design: A Simplified Approach | 152
____________________________________________________________________

Figure 8.16: Not in 1st normal form.

What is wrong about this is that now only 3 products can be sold. If you would
have to sell 4 products, than you would have to start a second sale or adjust your
data model by adding 'product4' attributes. Both solutions are unwanted. In these
cases you should always create a new entity that you link to the old one via a
one-to-many relationship.

Figure 8.17: In accordance with 1st normal form.

Normalization, the Second Form: The second form of normalization states that
all attributes of an entity should be fully dependent on the whole primary key.
This means that each attribute of an entity can only be identified through the
whole primary key. Suppose we had the date in the Sales_details entity:

Figure 8.17: Not in 2nd normal form.

 Systems Analysis and Design: A Simplified Approach | 153
____________________________________________________________________

This entity is not according the second normalization form, because in order to
be able to look up the date of a sale, I do not have to know what is sold
(productnr), the only thing I need to know is the sales number. This was solved
by splitting up the tables into the sales and the Sales_details table:

Figure 8.18: In accordance with 2nd normal form.

Now each attribute of the entities is dependent on the whole PK of the entity. The
date is dependent on the sales number, and the quantity is dependent on the sales
number and the sold product.

Normalization, the Third Form: The third form of normalization states that all
attributes need to be directly dependent on the primary key, and not on other
attributes. This seems to be what the second form of normalization states, but in
the second form is actually stated the opposite. In the second form of
normalization you point out attributes through the PK, in the third form of
normalization every attribute needs to be dependent on the PK, and nothing else.

Figure 8.19: Not in 3rd normal form.

 Systems Analysis and Design: A Simplified Approach | 154
____________________________________________________________________

In this case the price of a loose product is dependent on the ordering number, and
the ordering number is dependent on the product number and the sales number.
This is not according to the third form of normalization. Again, splitting up the
tables solves this.

Figure 8.20: In accordance with 3rd normal form.

Normalization, More Forms: There are more normalization forms than the
three forms mentioned above, but those are not of great interest for the average
user. These other forms are highly specialized for certain applications. If you
stick to the design rules and the normalization mentioned in this article, you will
create a design that works great for most applications.

Normalized Data Model: If you apply the normalization rules, you will find that
the 'manufacturer' in de product table should also be a separate table:
 Systems Analysis and Design: A Simplified Approach | 155
____________________________________________________________________

Figure 8.21: Data model in accordance with 1st, 2nd and 3d normal form.

8.11 Process Modeling vs Data Modeling

Process modeling
 Views a system from an input-process-output perspective
 DFD is the technique used to represent the hierarchical decomposition of
the real-world system under investigation.
 DFD achieves top-down partitioning by decomposing the system first into
subsystems, then into processes performed within a subsystem.

Data modeling
 Views a system from a reality-metadata-date modeling perspective. ERD
is used to capture the meaning of data from the users‘ point of view
(reality level)
 Systems Analysis and Design: A Simplified Approach | 156
____________________________________________________________________

 Relational data model is used to represent data in the form of table

(metadata level)

Finding:
Process modeling is easier to learn and apply than data modeling

8.12 Summary

 A file is organized to ensure that records are available for processing.

 It should be designed in the line with the activity and volatility of the
information and the nature of the storage media and devices.
 A database is a collection of interrelated data stored with minimum
redundancy to serve many users quickly and efficiently.
 The general objective is to make information access easy, quick,
inexpensive and flexible for the user.
 Data base design minimizes the artificially embedded in using separate
files. The primary objectives are fast response time to inquiries, more
information at low cost, control of redundancy, clarity and ease of use,
data and program independence, accuracy and integrity of the system, fast
recovery, privacy and security of information, and availability of
powerful end user languages. The heart of the data base is DBMS. It
manages and controls the data base file and handle request from the
application program.

8.13 Review Questions

1. How is modularization a better approach than the traditional approach.

2. Give examples of various types of relationships.
3. Explain all the file organizations.
4. What is normalization?
5. Briefly explain the need of detailed design.
 Systems Analysis and Design: A Simplified Approach | 157
____________________________________________________________________

CHAPTER NINE

System Control, Quality Assurance and Testing

9.0 Introduction
No program or system design is perfect. Communication between the user and
the designer is not always complete or clear and time is usually short. The result
is errors. The number and nature of errors in a new design depend on several
factors:
1. Communication between the user and the designer.
2. The programmer‘s ability to generate a code that reflects exactly the
system specifications.
These factors put an increasing burden on systems analysts to ensure the success
of the system developed. The quality of a system depends on its design,
development, testing and implementation.

9.2 Design Objectives

The two operational design objectives continually sought by developers are
systems reliability and maintainability.

9.2.1 Reliable Systems

A system is said to have reliability if it does not produce dangerous or costly
failures when it is used in a reasonable manner, that is, in a manner that a typical
user expects is normal. This definition recognizes that systems may not always
be used in the ways that designers expect. There are changes in the ways users
use a system and also in business operations. However, there are steps analysts
can take to ensure that the system is reliable when it is installed and that the
reliability can be maintained after implementation.
 Systems Analysis and Design: A Simplified Approach | 158
____________________________________________________________________

Approaches to Reliability
There are two levels of reliability. The first is that the system is meeting the right
requirements. For instance, a system might be expected to have specific security
features or controls built into it by the users. But if the design fails to specify
them and permits the loss of funds or merchandise for a lengthy time before
someone detects the problem, the system is not reliable. Reliability at the design
level is possible only if the analyst performed a thorough and effective
determination of systems requirements. A careful and thorough systems study is
needed to satisfy this aspect of reliability.

The second level of systems reliability involves the actual workings of the
system delivered to the user. At this level, systems reliability is interwoven with
software engineering and development.

An error occurs whenever the system does not produce the expected output.
While it is true that no program is ever fully debugged or fully tested, nor proven
correct – a fact that startles many users and aspiring programmers – errors are not
limited to the correct use of programming syntax alone.
The computing industry, has come to distinguish between error and failures. A
failure is the occurrence of a software error, weighted by its seriousness. For
example, if an inventory program is developed to truncate rather than round half
– the amount when calculating the value of materials on handed, it is an error if
specifications call for rounding. But it may be of no consequence to the user,
who in fact does not consider this a failure. However, if the program regularly
skips certain items or indicates they are out of stock when in fact the records
show they are in stock, there is a serious failure.

 Error Avoidance
There are three approaches to reliability namely, error avoidance, error detection
and error tolerance. Under error avoidance, developers and programmers make
every attempt to prevent errors from occurring at all. The emphasis on early and
careful identification of user requirements in another way this objective is
pursued.
Analysts must assume that it is impossible to fully achieve this objective. Errors
will occur despite the best efforts of very competent people.
 Systems Analysis and Design: A Simplified Approach | 159
____________________________________________________________________

 Error Detection and Correction

This method uses design features that detect errors and make necessary changes
to correct either the error while the program is in use or the effect on the user, so
that a failure does not occur. Correcting user errors, such as misspelling
keywords or entering invalid commands, is one remedy. Error detection in
programs is handled in a similar manner. For example, a program that calculates
the productivity of a waiter or waitress in a restaurant by dividing the total
revenue from meals served into the hours worked should not fail when
employees do not serve anything. When a blinding snowstorm prevents
customers from coming to a restaurant, employees will accumulate working time
but will not have sales. The program should detect the divide – by – zero error
and correct for it in order to keep the system running properly. Unfortunately,
many programs fail when a situation like this one occurs. Even though it may not
happen for several years after the system is installed, the error is there from the
day of development. The failure occurs later.

 Error Tolerance
Error tolerance strategies keep the system running even in the presence of errors.
The United States National Aeronautics and Space Administration (NASA), for
example, designs its systems to be error – tolerant through the use of redundant
hardware. In one space program, redundant on – board computers and computer
voting are used to process data in parallel, so results can be compared. Two
computers process the data on location, course correction and compare the results
with those produced by two other computers processing the same data. A fifth
computer is available to break a tie should one occur. If needed, a sixth computer
stored away in an accessible storage compartment can quickly replace one of the
other computers that has been damaged or failed.

Another manner of error tolerance is the use of degraded processing. With this
strategy, the user receives less service than the system was designed to provide,
but that is considered a better alternative in some cases than having no service at
all. For example, many electric power generation and distribution facilities in
North America are computer – controlled. Suppose that on a record – breaking
hot day the system becomes overloaded and the computer control centre is
unable to correctly process allocation data and keep up with the power demands.
Rather than risk damaging the power distribution network, the computer
automatically shuts down part of the network. By providing degraded service, the
computer tolerates a software error without failing.
 Systems Analysis and Design: A Simplified Approach | 160
____________________________________________________________________

Causes of Errors
The software aspects of systems design are different from concerns about
hardware reliability. In hardware, for example, any design errors are reproduced
in every copy of the item manufactured. However, application systems are often
unique and design errors are not widely distributed. Of course, if you are
working on a system that will be sold commercially, there is considerable
concern over development and marketing of software packages that is rampant
with design errors.

Manufacturing errors are introduced during the actual production process. They
are not a property of the design and, in fact, may not be in every item produced.
Manufacturing errors may exist only in items made during a specific time period,
either because of unknown problems with material quality or mistakes made by
people newly assigned to a step in the process. In software systems, the
equivalent of manufacturing errors is the small chance that, when disk or tape
copies of programs are made for distribution, errors will be introduced. This
problem seldom occurs, however, and should not be a major concern to the
analyst.

Hardware failures occur as equipment is used and begins to wear out. There is no
equivalent in software; that is, we do not find software unusable because it is
worn out. The medium on which it is carried (such as magnetic tape or disk) may
become worn or damaged, but the software will not. Therefore, the primary
software problem is designing and developing software that will not fail. It is
impossible to prove that there are no errors in a particular system. The causes of
errors that interest the analyst are:
(1) not obtaining the right requirements,
(2) not getting the requirements right, and
(3) not translating the requirements in a clear and understandable manner
so that programmers implement them properly.
The transition from systems design to software development is an additional
opportunity for introducing translation errors. These are the result of the
programmer‘s not properly understanding or interpreting the design
specifications produced by analysts. Conversely, they also occur when analysts
force programmers to translate specifications that are incomplete. In the latter
case, the programmer is forced to make design decision while coding the
software. When such misunderstanding exists and implementation occurs before
they are detected, the result is a need for maintenance.
 Systems Analysis and Design: A Simplified Approach | 161
____________________________________________________________________

9.2.2 Maintenance of Systems

When systems are installed, they generally are used for long periods. The
average life of a system is 4 to 6 years, with the oldest application often in use
for over 10 years. However, this period of use brings with it the need to
continually maintain the system. Because of the use a system receives after it is
fully implemented, analysts must take precautions to ensure that the need for
maintenance is controlled through design and testing and the ability to perform it
is provided through proper design practices.

Maintenance Issues
Many private, university and government studies have been conducted to learn
about maintenance requirements for information systems. The studies have
generally concluded the following:
1. From 60 to 90 percent of the overall cost of software during the life of a
system is spent on maintenance.
2. Often maintenance is not done very efficiently. In documented cases, the cost
of maintenance, when measured on the basis of the cost of writing each
instruction in code form, is more than 50 times the cost of developing a system in
the first place.
3. Software demand is growing at a faster rate than supply. Many programmers
are spending more time on systems maintenance than on new development.
Studies have documented that in some sites, two – thirds of the programmes are
spending their time on the maintenance of software. There is a backlog of new
development work..

Several studies of maintenance have examined the type of tasks performed under
maintenance. The broad classes maintenance found in information systems
environments are corrective, adaptive and perfective. Once systems are installed,
the need for debugging and correcting errors or failures on an emergency basis is
comparatively low: less than 20 percent of the tasks are for correction.
Information systems and the organizations they serve are in a constant state flux.
Therefore, the maintenance of systems also involves adaptations of earlier
versions of the software. Approximately 20 percent of all maintenance is
performed to accommodate changes in reports, files and data. This also includes
adaptations required when new hardware or software is installed in a particular
processing center.
 Systems Analysis and Design: A Simplified Approach | 162
____________________________________________________________________

The greatest amount of maintenance work is for user enhancement, improved

documentation, or recoding systems components for greater efficiency. Sixty
percent of all maintenance is for this purpose. Yet, many of the tasks in this
category can be avoided if systems engineering is carried out properly.

Maintainable Designs
The keys to reducing the need for maintenance, while making it possible to do
essential tasks more efficiently, are these:

1. More accurately defining the user‘s requirements during systems

development.
2. Assembling better system documentation.
3. Using more effective methods for designing processing logic and
communicating it to project team members.
4. Making better use of existing tools and techniques.
5. Managing the systems engineering process effectively.

As indicated by the preceding comments, design is both a process and a product.

The design practices followed for software dramatically affect the
maintainability of a system: good design practices produce a product that can be
maintained.

9.3 Software Design

These principles should guide software design:

Modularity and Partitioning.

Each system should consist of a hierarchy of modules. Lower level modules are
generally smaller in scope and size compared to higher – level modules and serve
to partition processes into separate functions. Top – down methods are used
throughout the analysis and design process. The value of using a top-down
approach starts at the general levels to gain an understanding of the system and
gradually moves down to levels of greater detail. In the process of moving from
top downward, each component is ―exploded‖ into greater detail. One data flow
diagram became several at the next lower level. During the discussion of input
and menu design, a top-down approach was emphasized. The main menu
contains several choices. Making one choice produces another menu in, which
more detailed options are presented to the user.
 Systems Analysis and Design: A Simplified Approach | 163
____________________________________________________________________

Coupling
Modules should have little dependence on other modules in a system.

Cohesion
Modules should carry out a single processing function.

Span of Control
Modules should interact with and manage the functions of a limited number of
lower-level modules.

Size
The number of instructions (called line of code – LOC) contained in a module
should be limited to that module size is generally small.

Shared Use
Functions should not be duplicated in separate modules, but established in a
single module that can be invoked by any other module when needed.

9.4 Coupling
Coupling refers to the strength of the relationship between modules in a system.
In general, good designers seek to develop the structure of a system so that one
module has little dependence on any other module. Loose coupling minimizes
the interdependence between modules. We can achieve this in the following
ways.

�Control the number of parameters passed between modules

�Avoid passing unnecessary data to called modules
�Pass data (whether upward or downward) only when needed
�Maintain superior/subordinate relationship between calling and called modules.
�Pass data, not control information

Consider the manner in which data are passed in an accounting system. In editing
a vendor record (for the accounts payable portion), two alternative designs for
editing a vendor record (for the accounts payable portion) are available. In the
first, typified by tight coupling, which is undesirable, the calling module passes
the vendor name, vendor identification number, address, tax status and date. The
called module returns the customer record, along with an end – of – file flag.
 Systems Analysis and Design: A Simplified Approach | 164
____________________________________________________________________

Figure: 9.1: Coupling & Cohesion in software design

Compare this with the preferred loosely coupled version in which only the
vendor ID is passed to retrieve the same record of information. Not only does
this design move less data (only non-superfluous data), but also there is far less
dependence between modules. Only the vendor identification is needed to
distinguish one vendor‘s record from another. Since it is likely to be the record
key, it is also unlikely to change. Other items in the record may change. Hence,
the loosely coupled alternative is better suited to achieving the stated design and
maintenance objectives.

Several poor design features should be avoided. Passing too little data can make
it impossible to perform the task. For example, if the calling module does not
pass the vendor ID, how does the subordinate module know which record to
locate?
 Systems Analysis and Design: A Simplified Approach | 165
____________________________________________________________________

(a) Poor – Tight Coupling (b) Good: Lose Coupling

Figure 9.2 Coupling and strength of relations between modules

Designs that create floating data should also be avoided. This occurs when one
module produces data that are not needed by the calling module but by another
elsewhere in the system. The details are passed through the system (hence the
term ―floating‖), until they finally reach the function that requires them.
Redesigning, to establish loose coupling, along with the creation of more
cohesive modules, will avoid this difficulty.

9.5 Software Design and Documentation Tools

Well – designed, modular software is more likely to meet the maintenance,
reliability, and testing requirements. Some specific tools include: Structured
flowcharts, HIPO diagrams, and Warnier / Orr diagrams, structure chart
(organization of programs and program modules) and pseudocode (processing
logic specification in each module).
 Systems Analysis and Design: A Simplified Approach | 166
____________________________________________________________________

9.5.1 Structured Flowcharts

Structured flowcharts, also called Nassi-Schneiderman Charts, are graphic tools
that force the designer to structure software that is both modular and top- down.
They provide a structure that can be retained by programmers who develop the
application software. Organization responsibilities vary. In some organizations,
analysts are responsible for developing module logic, while in others that
responsibility is delegated to the programmer. In either case, the programmer
should be well versed in the use of structured flowcharts.

Basic Elements of Structured Flowcharts

There are three basic elements used in developing structured flowcharts:
process, decision, and iteration. (There are many similarities between these
elements and the components used in structured English.)

 Process:
A rectangular box, the process symbol, represents Simple processes or steps in a
program. This symbol represents initialization of values, input and output
activities, and calls to execute other procedures.

A name of brief description written in the box states the purpose of the process.
The succession of steps is shown using several process boxes.

 Decision
The decision symbol represents alternative conditions that can occur and that the
program must have a manner of handling. They show the equivalent of the IF-
THEN-ELSE structures common in many programming languages. As examples
will show, the decision symbol may show actions for more than two alternatives
at the same time.

 Iteration
The iteration symbol represents looping and repetition of operations while a
certain condition exists or until a condition exists. The form of the iteration
symbol clearly shows the scope of the iteration, including all processes and
decisions that are contained within the loop. The left – hand portion of the
symbol shows the path of repetition to follow until the conditions controlling the
iteration are satisfied.
 Systems Analysis and Design: A Simplified Approach | 167
____________________________________________________________________

9.5.2 HIPO
HIPO is another commonly used method for developing systems software. IBM
developed this method of Hierarchical Input Process Output (HIPO), for large,
complex operating systems.

Purpose of HIPO
The assumption on which HIPO is based is that is easy to lose track of the
intended function of a system or component in a large system. This is one reason
why it is difficult to compare existing systems against their original
specifications (and therefore why failures can occur even in systems that are
technically well formulated). From the user‘s view, single functions can often
extend across several modules. The concern of the analyst then is understanding,
describing, and documenting the modules and their interaction in a way that
provides sufficient detail but that does not lose sight of the larger picture. HIPO
diagrams are graphic, rather than prose or narrative, descriptions of the system.
They assist the analyst in answering three guiding questions:

1. What does the system or module do? (Asked when designing the system).
2. How does it do it? (Asked when reviewing the code for testing or
maintenance).
3. What are the inputs and outputs? (Asked when reviewing the code for
testing or maintenance.)

A HIPO description for a system consists of the visual table of contents and the
functional diagrams.

 Visual Table of contents

The visual table of contents (VTOC) shows the relation between each of the
documents making up a HIPO package. It consists of a hierarchy chart that
identifies the modules in a system by number and in relation to each other and
gives a brief description of each module. The numbers in the contents section
correspond to those in the organization section. The modules are in increasing
detail. Depending on the complexity of the system, three to five levels of
modules are typical.

 Functional Diagrams
There is one diagram for each box in the VTOC. Each diagram shows input and
output (right to left or top to bottom), major processes, movement of data, and
 Systems Analysis and Design: A Simplified Approach | 168
____________________________________________________________________

control points. Traditional flowchart symbols represent media, such a magnetic

tape, magnetic disk, and printed output.

A solid arrow shows control paths, and open arrow identifies data flow. Some
functional diagrams contain other intermediate diagrams. But they also show
external data, as well as internally developed data (such as tables in the invoice
example) and the step in the procedure where the data are used. A data dictionary
description can be attached to further explain the data elements used in a process.
HIPO diagrams are effective for documenting a system.

9.5.3 Warnier/Orr Diagrams

Warnier/Orr diagrams (also known as logic construction of programs/logical
construction of system) were initially developed in France by Jean – Dominique
Warnier and in the United States by Kenneth Orr. This method aids the design of
program structures by identifying the output and processing results and then
working backwards to determine the steps and combinations of input needed to
produce them. The simple graphic methods used in Warnier/Orr diagrams make
the levels in the system evident and the movement of the data between them
vivid.

The following is an example of a simple hierarchy.

Figure 9.3: A simple hierarchy in Warnier/Orr diagram

 Systems Analysis and Design: A Simplified Approach | 169
____________________________________________________________________

Figure 9.4: Using a Warnier/Orr diagram to show a data structure:

9.5.4 Structure Chart

The structure chart is used to show graphically
1. how the various program parts/modules of an information system are
physically organized hierarchically
2. exchange) and flag (control/message)
3. how the modules are related to each other in terms of sequence, selection,
and repetition

Structured Chart Symbols

Components Symbol
Module Rectangle
Data couple Clear circle without arrow
Control flag Filled circle without arrow
Conditional Diamond
processing/selection
Repetition A curved line intersecting the connection to the modules
Predefined module Rectangle with a vertical bar on each side

Converting DFDs to structure charts

1. Locate the central transform/transaction center
2. Find a coordinating module for the top of the chart
3. Identify the primary input and output data flows
4. Draw a top-level chart (consists of two hierarchical level)
5. Refine the chart until the data origin, system function, and output
dispositions are defined
 Systems Analysis and Design: A Simplified Approach | 170
____________________________________________________________________

Cap and gown ordering system example

Step Example
Center Process #3: Validate Order
Root module Process Order
Primary inputs Student ID, cap size, gown size
Primary Receipt, Order detail, Inventory update
outputs
Top-level Get student, Get order, Process invalid order, Process valid
order
Refinement Get student, Get order, Process valid order

Figure 9.5 – The structured chart for the Cap and gown ordering system example
 Systems Analysis and Design: A Simplified Approach | 171
____________________________________________________________________

9.5.5 Pseudo-code
It shows processing logic specification in each module of a program.
Pseudocode provides the programmers with a text description of the contents of
each module.

Cap and gown ordering system example

MODULE: Process_Order()
Set EOF = no, VALID = 0
Get_Student
DO WHILE EOF = no
IF VALID = 0
Get_Order
ENDIF
IF VALID = 0
Process_Valid_Order
ELSE Process_Invalid_Order(VALID)
ENDIF
Get_Student
ENDDO

MODULE: Get_Student()
SET EOF = no, VALID = 0, TYPE="student"
READ student_ID
IF student_ID = null
THEN EOF = yes
ELSE Verify_Data(TYPE)
ENDIF
RETURN student_ID, EOF, VALID

MODULE: Get_Order()
SET TYPE = "order"
READ cap_size, gown_size
Verify_Data(TYPE)
RETURN cap_size, gown_size, VALID
 Systems Analysis and Design: A Simplified Approach | 172
____________________________________________________________________

MODULE: Process_Invalid_Order(valid)
IF VALID = 1
error = "Student not found"
ELSE IF VALID = 2
error = "Student is not graduating in spring"
ELSE IF VALID = 3
error = "Cap size out of stock"
ELSE IF VALID = 4
error = "Gown size out of stock"
ENDIF
ENDIF
ENDIF
ENDIF
DISPLAY error

MODULE: Verify_Data (type)

IF TYPE = "student"
THEN OPEN Student_File
FIND Student_Record USING student_ID
IF Student_Record NOT_FOUND
THEN VALID = 1
ELSE IF Student.graduate_date <> "Spring 1999"
THEN VALID = 2
ENDIF
ENDIF
ELSE IF TYPE = "order"
THEN OPEN Inventory_File
GET Inventory.cap_on_hand USING cap_size
GET Inventory.gown_on_hand USING gown_size
IF Inventory.cap_on_hand = 0
THEN VALID = 3
ELSE IF Inventory.gown_on_hand = 0
THEN VALID = 4
ENDIF
ENDIF
ENDIF
ENDIF
RETURN VALID
 Systems Analysis and Design: A Simplified Approach | 173
____________________________________________________________________

MODULE: Process_Valid_Order(student_ID, cap_size, gown_size)

Update_Inventory(cap_size, gown_size)
Generate_Receipt(student_ID, cap_size, gown_size)
Record_order(student_ID, cap_size, gown_size)

MODULE: Update_Inventory(cap_size, gown_size)

OPEN Inventory_file
GET Inventory.cap_on_hand USING cap_size
REDUCE Inventory.cap_on_hand BY 1
FIND Inventory.gown_on_hand USING gown_size
REDUCE Inventory.gown_on_hand BY 1
CLOSE Inventory_File

MODULE: Record_Order(student_ID, cap_size, gown_size)

OPEN Order_File
Order.student_ID = student_ID
Order.cap_size = cap_size
Order.gown_size = gown_size
WRITE Order_Record
PRINT Order_Record AS Receipt_Report
CLOSE Order_File

9.6 Managing Quality Assurance

Quality assurance is the review of software products and related documentation
for completeness, correctness, reliability, and maintainability. And, of course, it
includes assurance that the system meets the specifications and the requirements
for its intended use and performance. The indicators of a quality system therefore
include:
1. Structured: top-down in design; modular in programming
2. Documented
3. Tested
4. Maintained, and
5. Audited
Structured system = structured analysis + structured design + structured
programming
Structured analysis: input-process-output
Structured design: modular
Structured programming: sequence-selection-repetition
 Systems Analysis and Design: A Simplified Approach | 174
____________________________________________________________________

Levels of Assurance
Analysts use four levels of quality assurance: testing, verification, validation, and
certification.

 Testing
System testing is an expensive but critical process that can take as much as 50
percent of the budget for program development. The common view of testing
held by users is that it is performed to prove that there are no errors in a program.
However, this is virtually impossible, since analysts cannot prove that software is
free and clear of errors. Therefore, the most useful and practical approach is with
the understanding that testing is the process of executing a program with explicit
intention of finding errors that is, making the program fail. The tester, who may
be an analyst, programmer, or specialist trained in software testing, is actually
trying to make the program fail. A successful test, then, is one that finds an error.
Analysts know that an effective testing program does not guarantee systems
reliability. Reliability is a design issue. Therefore, reliability must be designed
into the system. Developers cannot test for it.

 Verification and Validation

Like testing, verification is also intended to find errors. Executing a program in a
simulated environment performs it. Validation refers to the process of using
software in a live environment on order to find errors. When commercial systems
are developed with the explicit intention of distributing them to dealers for sale
or marketing them through company – owned field offices, they first go through
verification, some-times called alpha testing. The feedback from the validation
phase generally produces changes in the software to deal with errors and failures
that are uncovered. Then a set of user sites is selected that puts the system into
use on a live basis. These beta test sites use the system in day- to - day activities;
they process live transactions and produce normal system output. The system in
live in very sense of the word, except that the users are aware they are using a
system that can fail. But the transactions that are entered and the persons using
the system are real. Validation many continue for several months. During the
course of validating the system, failure may occur and the software will be
changed. Continued use may produce additional failures and the need for still
more change.
 Systems Analysis and Design: A Simplified Approach | 175
____________________________________________________________________

 Certification

Software certification is an endorsement of the correctness of the program, an

issue that is rising in importance for information systems applications. There is
an increasing dependence on the purchase or lease of commercial software rather
than on its in-house development. However, before analysts are willing to
approve the acquisition of a package, they often require certification of the
software by the developer or an unbiased third party. For example, selected
accounting firms are now certifying that a software package in fact does what the
vendor claims it does and in a proper manner. To so certify the software, the
agency appoints a team of specialists who of specialists who carefully examine
the documentation for the system to determine what the vendor claims the system
does and how it is accomplished. Then they test the software against those
claims. If no serious discrepancies or failures are encountered, they will certify
that the software does what the documentation claims. They do not, however,
certify that the software is the right package for a certain organization. That
responsibility remains with the organization and its team of analysts.

9.7 Testing the New System

Once the system has been created, it needs to be thoroughly tested. Before
actually implementing the new system into operation, a test run of the system is
done to remove bugs, if any. It is an important phase of a successful system.
After codifying the whole programs of the system, a test plan should be
developed and run on a given set of test data. The output of the test run should
match the expected results. Sometimes, system testing is considered a part of
implementation process. Using the test data following test run are carried out:

 Unit/Program test
 System test

Program test: When the programs have been coded, compiled and brought to
working conditions, they must be individually tested with the prepared test data.
Any undesirable happening must be noted and debugged (error corrections)

System Test: After carrying out the program/unit test for each of the programs
of the system and errors removed, then system test is done. At this stage the test
is done on actual data. The complete system is executed on the actual data. At
each stage of the execution, the results or output of the system is analyzed.
 Systems Analysis and Design: A Simplified Approach | 176
____________________________________________________________________

During the result analysis, it may be found that the outputs are not matching the
expected output of the system. In such case, the errors in the particular programs
are identified and are fixed and further tested for the expected output.

When it is ensured that the system is running error-free, the users are called with
their own actual data so that the system could be shown running as per their
requirements.

9.7.1 Testing guidelines

 Test different aspects of the system, e.g., response time, response to
boundary data, response to no input, response to heavy volumes of input
 Test anything that could go wrong or be wrong about a system
 Test the most frequently used parts of the system at a minimum
 The people who create the test cases should not be the same people as
those who coded and tested the system
 Use debugging tools, e.g., symbolic debugger

9.7.2 Test Plan

A test plan is usually written whilst the system is being developed. The test plan
will contain details of every single thing that needs to be tested. For example:

 Does the system open and close properly?

 Can data be entered?
 Can data be saved?
 Can reports be printed?
 When you do something wrong, does an error message appear?
 Is invalid data rejected? E.g. if you are not allowed to enter an amount
above N1000 on the system then a value of 1,001 should not be accepted
(i.e. does the validation work?)

Test plans are very detailed, and contain many tests. Each test is specified very
precisely. A typical test would contain:
 Details of what is being tested
 The test data to use
 What is expected to happen when the test is performed
 Systems Analysis and Design: A Simplified Approach | 177
____________________________________________________________________

9.7.3 Selecting Test Data

When choosing what data to use to test a system, you need to think about why
we are testing the system: to see if it works and to check it doesn't break. It is
necessary to develop a proper testing strategy to ensure all possible scenarios are
covered and that all error trapping techniques are fully tested; for example if
inputting data to represent somebody‘s age, the test plan may include: 0, 5, -2,
fred, 3.5, 215, 85 etc. to see whether each piece of data is correctly dealt with;
test data often falls into 3 types:

1. Normal Data Values

This is data that would normally be entered into the system. The system should
accept it, process it, and we can then check the results that are output to make
sure they are correct.

E.g. In a system that was designed to accept and process test marks
(percentages), then normal test values would include:

 10
 25
 63
 89

2. Extreme Data Values

Extreme values are still normal data. However, the values are chosen to be at the
absolute limits of the normal range. Extreme values are used in testing to make
sure that all normal values will be accepted and processed correctly.

E.g. In a system that was designed to accept and process test marks
(percentages), then extreme test values would be:
 Systems Analysis and Design: A Simplified Approach | 178
____________________________________________________________________

 0 (lowest possible value)

 100 (highest possible value)

In systems that deal with text, the extreme values are defined by how long the
text can be. The limits would be:

 "" (nothing entered)

 "ABCDEF..." (max. length)

3. Abnormal/Erroneous Data Values

This is data that should not normally be accepted by the system - the values are
invalid. The system should reject any abnormal values. Abnormal values are
used in testing to make sure that invalid data does not break the system.

E.g. In a system that was designed to accept and process test marks
(percentages), then abnormal test values would include:

 -1
 101
 200
 -55

9.7.4 Phases of System Testing

There are two major phases of system testing. These two phases of testing are
often referred to as Alpha Testing (testing by the designers/engineers) and Beta
Testing (testing by real users, with real data).

The first phase of testing is done by the designers and engineers who created the
system, usually before the system is delivered to the customer.
 Systems Analysis and Design: A Simplified Approach | 179
____________________________________________________________________

The test data that is used in this first phase is similar to data that would be used
by the actual customer.

The second phase of testing is done after the system has been delivered and
installed with the customer.

The data used in the second phase is usually 'live' data - data that is actually part
of the customer's business /organization.

9.7.5 What Happens if the System Fails Some Tests?

The whole point of testing is to try and find areas that don't work as they
should, or areas that can be improved.

If any failures are found, the systems analyst goes back and does some further
research, analysis and design to fix these areas.

9.8 System Controls

A well-designed system should have controls to ensure proper operation and
routine auditing. A candidate systems failure often results from lack of emphasis
on data control. Therefore, standards of accuracy, consistency and
maintainability must be specified to eliminate errors and control for fraud. A
system design introduces new control elements and changes the control
procedures. New controls in the form of relational comparisons are designed to
detect and check errors that rise form the use of the system. In a manual system,
internal control depends on human judgment, personal care and division of labor.
In a computer based system the number of persons involved is considerably
reduced. In designing a new system the designer should specify the location of
error control points and evaluate them on the basis of error frequency, cost and
timing of error detection. By identifying points where potential errors may occur,
designers can create control procedures for handling errors immediately.

9.9.1 Processing Controls

Several methods have been devised to control processing activities:

 Systems Analysis and Design: A Simplified Approach | 180
____________________________________________________________________

1. Data record may be combined into small groups to control totals. If in batch
processing, error is encountered, the batch may be held and reviewed to
correct the error.
2. Completeness check ensures that all fields in a record are present and are read
in the proper sequence. In a multiple record check, the program verifies the
self-checking number of the records that make up the transaction. If an error
is detected, the entire group of records is rejected.
3. Consistency check refers to the relevance of one type of data to another. Data
being accepted through various means need to be checked for its uniformity.
All critical paths need to be checked for its proper path selection.
4. Reasonableness check evaluates a transaction against a standard or maximum
/ minimum value to determine its validity. For example an employee may not
have age less than 21 and not more than 60 years.
5. Sequence check verifies that data records are in sequence prior to processing.
Duplicate records need to be checked.

9.10 Audit Trails

An important function of system controls is providing for an audit trail. An audit
trail is a routine designed to allow the analyst, user or auditor to verify a process
or an area in the new system.

It is a feature of data processing systems that allows for the study of data as
processed from step to step, an auditor may then trace all transactions that affect
an account. In a manual system, the audit trail includes journals, ledgers and
other documents used by auditor to trace transactions. In a computerized system,
record content and format frequently make it difficult to trace a transaction
completely. Some reasons are the following:

1. Files stored on the tape or disk can be read only by a computer, which
limits the auditing function. A data dump is possible, though, to compare
the data against a data map.
2. Direct data entry eliminates the physical documentation for an audit
program.
3. Data processing activities are difficult to observe, since they take place
within the computer system.

For the audit trail to show its impact a detailed file of the transactions need to be
maintained. During evaluation of a system following steps should be considered.
 Systems Analysis and Design: A Simplified Approach | 181
____________________________________________________________________

1. Define the control objectives as separate design and test requirements. Input
preparation and transmission by the user are important control areas that are
viewed with an emphasis on audit trails and adequate documentation during
testing.
2. Examine budget costs to see whether system testing is within the limits.
3. Review specifications. The auditor should evaluate program acceptance test
specifications and assist the programmer in developing test standards, levels
of testing and actual test conditions.

9.11 Summary
 The number and nature of errors in a new design depend on several
factors. The two operational design objectives continually sought by
developers are systems reliability and maintainability.
 There are three approaches to reliability namely, error avoidance, error
detection and error tolerance.
 Software design should be guided by modularity and partitioning ,
coupling, cohesion, span of control , size and shared use.
 Well – designed, modular software is more likely to meet the
maintenance, reliability, and testing requirements.
 Quality assurance is the review of software products and related
documentation for completeness, correctness, reliability, and
maintainability.
 The philosophy behind testing is to find errors. The analyst must perform
both unit and integration testing.
 A well-designed system should have controls to ensure proper operation
and routine auditing.

9.12 Review Questions

1. Differentiate between error tolerance & Error avoidance.
2. What are the causes of errors?.
3. Explain Coupling & Cohesion.
4. Conduct a comparative study between the various documentation tools.
5. What are the levels of assurance?.
 Systems Analysis and Design: A Simplified Approach | 182
____________________________________________________________________

CHAPTER TEN

Implementation and Deployment

10.0 Introduction

After having the user acceptance of the new system developed, the
implementation phase begins. Implementation is the stage of a project during
which theory is turned into practice. The major steps involved in this phase are:

 Acquisition and Installation of Hardware and Software

 Conversion
 User Training
 Documentation

The hardware and the relevant software required for running the system must be
made fully operational before implementation. The conversion is also one of the
most critical and expensive activities in the system development life cycle. The
data from the old system needs to be converted to operate in the new format of
the new system. The database needs to be setup with security and recovery
procedures fully defined.

During this phase, all the programs of the system are loaded onto the user‘s
computer. After loading the system, training of the user starts.

10.1 Documentation

The documentation of the system is also one of the most important activities in
the system development life cycle. This ensures the continuity of the system.
There are generally two types of documentation prepared for any system. These
are:
 Systems Analysis and Design: A Simplified Approach | 183
____________________________________________________________________

 User or Operator Documentation

 System ( or Technical) Documentation

 User Documentation
The user documentation is a complete description of the system from the end-
users‘ point of view detailing how to use or operate the system. The users are
usually non-technical people, who don't need to know how the system works.
They just need to know how to use it. It also includes the major error messages
likely to be encountered by the users and their meanings. In summary, the user
documentation usually consists of:

 How to install the system

 How to start / stop the system
 How to use the features of the system
 How to save files
 How to do a search
 How to sort data
 How to do print outs
 How to add, delete or amend records
 The purpose of the system/program/software package
 Screen layouts (input)
 Print layouts (output)
 Hardware & Software requirements
 Screenshots showing the system in typical use
 Example inputs and outputs
 Sample runs (with results and actual test data used)
 Error handling/meaning of errors
 Troubleshooting guide/help lines/faqs
 How to log in/log out

 System or Technical Documentation

The technical documentation is intended to help the maintainers of the system
(the people who need to keep the system running smoothly, fix problems, etc.)
The maintainers are usually technical people, who need to know exactly how
the system works. The system documentation contains the details of system
design, programs, their coding, system flow, data dictionary, process description,
etc. This helps to understand the system and permit changes to be made in the
 Systems Analysis and Design: A Simplified Approach | 184
____________________________________________________________________

existing system to satisfy new user needs. In summary, the system or technical
documentation consists of:
 Program listing/coding
 Programming language(s) used
 Diagrams showing how data moves through the system
 Flowchart/Pseudocode/algorithm
 Purpose of the system/program/software
 Input formats and expected inputs
 Details of Hardware/Software requirements
 Minimum memory requirements
 Known ―bugs‖ in the system
 List of variables used (and their meaning/description)
 File structures
 Sample runs (with results and actual test data used)
 Output formats
 Validation rules/checks
 Details of data structures (data types, field names, etc.)
 Details of how data is processed

10.2 Installation
 Install the hardware and, if necessary, the new software
 Fully test the new system once installed

10.3 Training
Even well designed and technically elegant systems can succeed or fail because
of the way they are operated and used. Therefore, the quality of training received
by the personnel involved with the system in various capacities helps or hinders,
and may even prevent, the successful implementation of an information system.
Those whose will be associated with or affected by the system must know in
detail what their roles will be, how they can use the system, and what the system
will or will not do. Both systems operators and users need training (User
Training).

The training of operators and users can be achieved in several different ways.
Training activities may take place at vendor locations; at rented facilities, for
example, in hotels or on university campuses (Vendor and In-Service Training);
or in-house at the employee‘s organizations (in-house training). The methods and
 Systems Analysis and Design: A Simplified Approach | 185
____________________________________________________________________

content of the training often vary, depending on the source and location of the
training.

10.3.1 Training guidelines

1. Consider who will be the trainer and trainee
2. Establish measurable objectives
3. Use appropriate training methods
4. Select suitable training site
5. Use understandable training materials

10.3.2 Training topics

1. Use of the system
2. Computer concepts
3. IS concepts
4. Organizational concepts
5. System management
6. System installation

10.4 Conversion
After the users are trained about the computerized system, working has to shift
from manual or old system to computerized working or new one. The process is
called conversion or ‗Changeover‘.

10.4.1 Conversion Strategies

The following strategies are followed for changeover of the system: Direct
(abrupt/cold-turkey), parallel, Phased (gradual/staged) and pilot (modular/single
location) run.
(i) Direct Changeover: This is the complete replacement of the old system by
the new system. All of the data that used to be input into the old system now
goes into the new one. It is a risky approach and requires comprehensive system
testing and training.

This is has its advantages...

 Systems Analysis and Design: A Simplified Approach | 186
____________________________________________________________________

 Takes the minimal time and effort

 New system is up and running immediately
 The benefits are immediate.
 costs are reduced (only one system in use so save on staff costs)
 less likelihood of a malfunction since the new system will have been fully
tested

But there are also disadvantages...

If the new system fails, there is no back-up system, so data can be lost.
This method can be disastrous if the new system fails at any point.

Sometimes a direct changeover is the only way to implement a new system.

E.g. an aircraft's auto-pilot system can't have a new and old version running
side-by-side, arguing about what to do!

(ii) Parallel run: In parallel, we run both systems (old and new systems) side-
by-side for a period of time, i.e., computerized and manual, are executed
simultaneously for certain defined period. The same data is processed by both the
systems. All of the data that is input into the old system is also input into the new
one.

Eventually, the old system will be stopped, but only when the new system has
been proven to work.

This has its advantages...

 If anything goes wrong with the new system, the old system will act as a
back-up.
 The outputs from the old and new systems can be compared to check
that the new system is running correctly
 It gives you time to gradually train staff/time to get used to the new
system
 Systems Analysis and Design: A Simplified Approach | 187
____________________________________________________________________

But there are also disadvantages...

 Entering data into two systems, and running two systems together, takes a
lot of extra time and effort
o The operational work is doubled.
o Extra staff are needed to run both systems.
o More time consuming since both systems need to be run and
evaluated

(iii) Pilot run: with this technique, the new system is introduced into one part of
the company (e.g. in just one office, or in just one department) and its
performance assessed. The new system is first of all piloted (trialed) in one part
of the business / organisation. It is then run with the data from one or more of the
previous periods for the whole or part of the system. The results are compared
with the old system results. Once the pilot system is running successfully, the
new system is introduced to the all of the business / organization.

This has its advantages...

 All features of the new system can be fully trialled

 If something goes wrong with the new system, only a small part of the
organisation is affected; the rest is still functional
 The staff who were part of the pilot scheme can help train other staff.
 It is less expensive and risky than parallel run approach.
 This strategy builds the confidence and the errors are traced easily
without affecting the operations.
 The costs are also less than parallel since only one system is being used
in the pilot warehouse

But there are also disadvantages...

 For the office / department doing the pilot, there is no back-up system if
things go wrong
 Systems Analysis and Design: A Simplified Approach | 188
____________________________________________________________________

A 'pilot' is someone who guides others - someone who leads the way.
On an airplane, the pilot guides all of the passengers safely to their destination.
In a port, the pilot is a person on a small boat who guides large ships safely into
the harbour.

(iv) Phased run. The new system is introduced in phases (stages, or steps),
gradually replacing parts of the old system until eventually, the new system has
taken over. That is only part of the new system is introduced and only when it
proves to work satisfactorily is the next part introduced, and so on, until the old
system is fully replaced

This has its advantages...

 Allows users to gradually get used to the new system

 can ensure the system works properly before expanding
 Staff training can be done in stages

But there are also disadvantages...

 If a part of the new system fails, there is no back-up system, so data can
be lost. However, failure isn‘t disastrous, compared to direct changeover,
because if the latest part fails, only need to go back in the system to the
point of failure.
 More expensive than direct since it is necessary to evaluate each phase
before moving to the next stage

The following table summarizes the risks involved in all four methods:
 Systems Analysis and Design: A Simplified Approach | 189
____________________________________________________________________

Method Relative Input Input needed by Impact of

costs needed by Systems team failure of
the user method
Parallel High High Low Low
Pilot Medium Low Medium Low
Phased Medium Medium Medium Medium
Direct Low Medium Low (if High
successful;
otherwise VERY
High)

10.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 lit 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. Establish procedures for
crosschecking the old and new systems. Determine how team members will
know if something has not been completed properly.
5. Assign responsibility for each activity.
6. 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.
 Systems Analysis and Design: A Simplified Approach | 190
____________________________________________________________________

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.

10.5 Summary

 Implementation is the stage of a project during which theory is turned into

practice.
 The major steps involved in this phase are Acquisition and Installation of
Hardware and Software, Conversion, User Training and documentation.
 The hardware and the relevant software required for running the system
must be made fully operational before implementation.
 The conversion is also one of the most critical and expensive activities in
the system development life cycle.
 The data from the old system are converted to operate in the new format
of the new system.
 Documentation ensures the continuity of the system.

10.6 Review Questions

1. Name any items contained in user documentation
2. Discuss the different conversion strategies that are followed for
changeover of the systems.
 Systems Analysis and Design: A Simplified Approach | 191
____________________________________________________________________

CHAPTER ELEVEN

System Evaluation and Maintenance

11.0 Introduction
Once the new system has been implemented and is in full use, the system should
be evaluated (this means that we take a long, critical look at it) and maintained.

11.1 Evaluating the New System

The purpose of an evaluation is to assess the system to see if it does what it was
supposed to do, that it is working well, and that everyone is happy with it.
Evaluation provides feedback for system improvement and measures the success
of a developed system.

This is summarized below:

• compare final solution with the original requirement
• identify any limitations in the system
• identify any necessary improvements that need to be made
• evaluate the user‘s responses to using the new system
• compare test results from new system with results from the old system
• compare performance of new system with performance of old system

11.1.1 What Does an Evaluation Look For?

When the systems analyst evaluates the new system, the following questions will
be asked:
 Is the system efficient?
 Does it operate quickly, smoothly and with minimal waste?
 Systems Analysis and Design: A Simplified Approach | 192
____________________________________________________________________

 Is the system saving time, and resources?

 ...easy to use?
 Are all of the system's users able to use the system easily and effectively?
 Can new staff understand and use the system with minimal training?
 ...appropriate?
 Is the system suitable for the particular business / organisation?
 Does the system actually meet the needs of the business / organisation?

12.1.2 How is a System Evaluated?

The systems analyst will use a number of techniques to evaluate the system:
 Check against the Requirements Specification
If you remember, earlier on in the Systems Analysis, the old system was
analysed, and a checklist of targets was drawn up for the new system. This list
was called the Requirement Specification.

The systems analyst will use this document to check the new system. Going
through the requirements one-by-one the analyst will check if they have been
met.
 Check the Users' Responses
It is essential to get feedback from the users of the system...
 Do they like it?
 Does it make their work easier?
 What, if anything, could be improved?
The systems analyst can get this feedback in the same way they collected
information about the original system:
 Questionnaires
 Interviews
 Observations

11.1.3 What Happens Next?

The outcome of the evaluation will be to identify any limitations or problems
with the new system. The system analyst will then need to begin the task of
system analysis from the beginning, but this time analyzing the new system, and
then designing, testing and implementing improvements.

Thus the whole process repeats.

 Systems Analysis and Design: A Simplified Approach | 193
____________________________________________________________________

The fact that the process of Systems Analysis is often repeated over and over
(constantly building upon and improving systems) means that it is often referred
to as a cyclic (repeating) process.

11.2 System Maintenance

The results obtained from the evaluation process help the organization to
determine whether its information systems are effective and efficient or
otherwise. The process of monitoring, evaluating, and modifying of existing
information systems to make required or desirable improvements may be termed
as System Maintenance.

System maintenance is an ongoing activity, which covers a wide variety of

activities, including removing program and design errors, updating
documentation and test data and updating user support.

11.2.1 Definitions
Software maintenance is a very broad activity often defined as including all
works made on a system after it becomes operational. This covers the correction
of errors, the enhancement, deletion and addition of capabilities, the adaptation to
changes in data requirements and operation environments, the improvement of
performance, usability, or any other quality attribute. It is defined as follows:

―System maintenance is the process of modifying a system or component after

delivery to correct faults, improve performances or other attributes, or adapt to
a changed environment.‖

This definition reflects the common view that software maintenance is a post-
delivery activity: it starts when a system is released to the customer or user and
encompasses all activities that keep the system operational and meet the user‘s
needs.

11.2.2 Categories of System Maintenance

Maintenance falls into three major components: corrective, adaptive, and
perfective maintenance.
 Systems Analysis and Design: A Simplified Approach | 194
____________________________________________________________________

Corrective maintenance: reactive modification of a system performed after

delivery to correct discovered faults. It includes all the changes made to remove
actual faults in the system. - This type of maintenance implies removing errors in
a program, which might have crept in the system due to faulty design or wrong
assumptions. Thus, in corrective maintenance, processing or performance
failures are repaired.
.
Adaptive maintenance: modification of a system performed after delivery to
keep the system usable in a changed or changing environment. In adaptive
maintenance, program functions are changed to enable the information system to
satisfy the information needs of the user. It encompasses the changes needed as a
consequence of some mutation in the environment in which the system must
operate, for instance, altering a system to make it running on a new hardware
platform, operating system, DBMS, TP monitor, or network.

Perfective maintenance: Perfective maintenance means adding new programs or

modifying the existing programs to enhance the performance and maintainability
of the information system. This type of maintenance undertaken to respond to
user‘s additional needs which may be due to the changes within or outside of the
organization.

It refers to changes that originate from user requests; examples include inserting,
deleting, extending, and modifying functions, rewriting documentation,
improving performances, or improving ease of use.

Outside changes are primarily environmental changes, which may in the absence
of system maintenance, render the information system ineffective and inefficient.
These environmental changes include:

a. Changes in governmental policies, laws, etc.,

b. Economic and competitive conditions, and
c. New technology.

11.3 Summary

 Once the new system has been implemented and is in full use, the system
will be evaluated and maintained.
 Systems Analysis and Design: A Simplified Approach | 195
____________________________________________________________________

 Evaluation provides feedback for system improvement and measures the

success of a developed system.
 The results obtained from the evaluation process help the organization to
determine whether its information systems are effective and efficient or
otherwise.
 System Maintenance is the process of monitoring, evaluating, and
modifying of existing information systems to make required or desirable
improvements
 System maintenance is an ongoing activity, which covers a wide variety
of activities, including removing program and design errors, updating
documentation and test data and updating user support.

11.4 Review Questions/Hand-on Exercise.

A. The purpose of these exercises is to provide practice using the tools of

structured systems analysis and design by applying them to problem sets which
are realistically vague, ambiguous, amorphous, complex, and contradictory.
These characteristics pertain to most real-world problems you have, probably,
encountered or will encounter later.

All practice exercises (1-12) refer to the following scenario: Assume you have
graduated! In addition to a full-time job in information systems, you have started
a part-time business as an independent computer consultant working out of your
home office. You need a system to keep track of the time you spend working on
various projects for various clients, and of the hardware, software, supplies, and
other materials you purchase for a client during a given project. Currently, you
are keeping these records on scraps of paper which are scattered all over your
desk (and which are mostly inaccurate). You know you are either cheating
yourself or your clients (you suspect the former). Something has to change!
 Systems Analysis and Design: A Simplified Approach | 196
____________________________________________________________________

The Practice Exercises are as follows:

I. GETTING STARTED: Problem/Opportunity Recognition and Initial Request

(1) Design an initial request form that might be used by anyone from within or
without an organization to convey the existence of a problem or opportunity to
the systems analysis group. The form should be general and should request the
information needed to start work on any problem/opportunity.

Now use the form you designed to describe a real-world problem based on the
scenario given above. DO NOT DESIGN YOUR FORM AROUND THE
PROBLEM. Design a general-purpose form then USE it for your chosen
problem.

(2) Conduct a problem definition (i.e., preliminary investigation) for your

consulting records problem. Present your results in a brief English narrative
report which should include:

(1) A definition of whether or not there is a problem, and if so, what you think
the problem really is

(2) A recommendation as to whether a detailed investigation of this problem

should be conducted

(3) An estimate of the resources (time, money, personnel, materials etc.) required
to conduct a detailed investigation of this problem

II. TOOLS OF SYSTEMS ANALYSIS:

(3) Draw a systems flowchart graphically depicting the consulting records

system.

(4) Draw a data flow diagram graphically depicting the consulting records
system. You must level the highest DFD at least twice, producing a total of three
sets of DFD‘s representing three different levels.
 Systems Analysis and Design: A Simplified Approach | 197
____________________________________________________________________

(5) Draw a data structure diagram with at least three record/file structures which
might be used in the consulting records system. Draw directed arrows to show
possible data access relationships between these record/file structures.

(6) Write structured English specifying procedures used in the consulting records
system. Remember that structured English should focus on what must be done
(not how to do it), and that it should use only vocabulary accessible to typical
users of the system (in this case, the consultant and the clients).

(7) Develop a decision table showing decision procedures used in the consulting
records system.

(8) Develop a decision tree showing the decision procedures you used in Practice
Exercise (7).

(9) Develop some sample Data Dictionary entries for the consulting records
system.

III. TOOLS OF SYSTEMS DESIGN:

(10) Draw a structure chart documenting the processes in the consulting records
system.

(11) Draw a structured flowchart for one of the processes in your structure chart
from Practice Exercise (10).

(12) Write either pseudocode or structured English to describe one of the

processes in your structure chart from Practice Exercise (10). Indicate whether
you have chosen to write pseudocode or structured English.

B. A company selling CDs and DVDs presently uses a manual, paper-based

system to keep track of:
- stock levels
- files containing CD and DVD information
- sales information
The company has shops in five major cities. When a customer comes into the
shop s/he goes to the desk and either asks the assistant to find a particular
 Systems Analysis and Design: A Simplified Approach | 198
____________________________________________________________________

CD/DVD. The shop assistant locates the files for the item the customer has
requested and,
(i) checks if it is stock
(ii) checks the price of the CD/DVD
(iii) finds where the CD/DVD is in the shop
If the customer has already found the CD/DVD in the shop s/he takes it to the
desk and the shop assistant finds the item file to check for its price. The customer
pays for the CD/DVD and the following then happens:
- shop assistant fills out a sales receipt and puts it into a file
- at the end of the day, all the sales are recorded and the number of each
item in stock is updated
- if the number of items are low a request for new stock is filled out
- the value of the day‘s sales are recorded in an accounts book.
The new system
The system is to be computerised. The following will be created:
(i) all CD and DVD data will be stored on a database
(ii) all items for sale will have a bar code on them
(iii) a sales file will be set up
(iv) a database will be created showing supplier and customer details

A customer goes into the shop and finds a CD/DVD s/he wants to buy. The shop
assistant scans the bar code on the item and the CD/DVD details have been found
including its price. The stock files are updated (i.e. 1 is reduced from the number
in stock) and the takings file updated. The stock levels for that item are checked
and an automatic order is sent out after accessing the supplier database.
If the customer has requested the assistant to find a particular CD/DVD the
assistant keys in the name/artist and finds out if the item is in stock, where it can
be found and it‘s price (the next stage is the same as above). If the item isn‘t in
stock, the assistant takes the customer details and updates the database and adds a
request for the item to be ordered and this is added to the customer‘s file.

(a) Draw the systems flow charts to show how the above system will work.
(b) Perform analysis and design of the new system using the concepts in Exercise
A above (practice exercises 1-12).
(b) Discuss the advantages of the new computerized system when compared to
the manual paper-based system.
(c) Why would the new system reduce the shop‘s costs?
(d) Implement your design.
 Systems Analysis and Design: A Simplified Approach | 199
____________________________________________________________________

C. Book Publisher’s Assistant

This system attempts to help a book publisher in maintaining details about his
books, customers, receipts/payments, etc. A book may be published afresh or it
could be a new edition or just reprint. The copyright may belong to either the
author(s) or publisher. The publisher may reprint any number of copies if he
holds the copyright. If the author holds the copyright, he may publish only as
much as is asked by the author. Further, the publisher may have to pay royalty in
such a case for every book sold.

Various book sellers, libraries, institutions, etc., order books. If the required
number of copies is available the publisher sends the books and updates his stock
level. If they are not available, he may send a partial consignment provided it is
acceptable to the customer. Payments may be either cash/credit, subject to
suitable credit limits. The publisher may decide to reprint a popular book if he
holds the copyright. Otherwise he approaches the author for consent. The author
may also revise it and the publisher brings out a new edition.

Assume that the publisher has published roughly 10,000 books of various titles in
various subjects and that roughly 100 new books are published every year and
that 100 new editions are also brought each year. Assume that 200 reprints of
various books are also published. The minimum number of copies published is
1000. On an average about 5000 copies of each book is published.
Your system should provide the following information:
 A list of various customers, libraries, etc., placing orders has to be
maintained, with relevant details.
 For each customer the list of books ordered with details such as cost,
address of customer, date of order, date of delivery, quantity. delivered,
etc.
 Details of reprints, new editions of books.
 Details of current stock, books and their quantity in publication etc.
 Books published by an author.
 List of books in a given subject
 The books that get sold out fast, the authors who are popular, etc.
 The publisher would also like to send a list of new books published every
year to various customers/libraries, etc., with relevant details such as title
and author.
 Systems Analysis and Design: A Simplified Approach | 200
____________________________________________________________________

Bibliography

Alavi, M. (1984). An Assessment of the Prototyping Approach to Information

Systems Development. Communications of the ACM. vol.27, no.6, June,
1984, pp.556-563

Bennett, S. (2005). Object-oriented Systems Analysis and Design Using UM .

Boston. Prentice-Hall.

Boillot, M. H., Gleason, G. & Horn, L. (1985). Essentials of Flowcharting. 4th

Edition. Dubuque, IA: William C. Brown Company.

Colter, M.A. (1984). A comparative Examination of Systems Analysis

Techniques. MIS Quarterly. March, 1984, pp.51-66.

Curtis, G (2004). Business Information Systems: Analysis, Design and

Practice. Wokingham: Addison-Wesley.

Davis, W. S. (1994). Business Systems Analysis and Design. Belmont, CA:

Wadsworth.

Dennis, A. & Wixom, B. (2009).Systems Analysis and Design. 4th Edition.

Chigaco: John Wiley and Sons.

Dennis, A., Wixom. B.H. & ROTH, R.M. (2012). Systems Analysis and Design. 5th
Edition. Hoboken, NJ: John Wiley & Sons, Inc.

Dennis, A, Wixom, B.H & Tegarden, D.P. (2002). Systems Analysis and Design:
An Object-Oriented Approach with UM . Boston: Pearson.

Elliott, G.(2004) Global Business Information Technology: an integrated systems

approach. Danvers, MA: Pearson Education

Fichman, R.G., and Kemerer, C.F.(1992). Object-Oriented and Conventional

Analysis and Design Methodologies: Comparison and Critique. IEEE
Computer. vol.25, no.10, 1992, pp.22-39
 Systems Analysis and Design: A Simplified Approach | 201
____________________________________________________________________

Gane, C. & Sarson, T.(1979). Structured Systems Analysis: Tools and

Techniques. Englewood Cliffs, NJ: Prentice-Hall.

Ginzberg, M.J.(1981). Early Diagnosis of MIS Implementation Failure:

Promising Results and Unanswered Questions. Management
Science. vol.27, no.4, April, 1981, pp.459-478

Gore, M. & Stubbe, L. (1988). Elements of Systems Analysis. 4th Edition.

Dubuque, IA: William C. Brown Company.

Hirschheim, R., and Klein, H. (1989). Four Paradigms of Information Systems

Development. Communications of the ACM, vol.32, no.10, October 1989,
pp.1199-1216.

Kock, N.F.(2006). Systems Analysis & Design Fundamentals: A Business

Process Redesign Approach. Englewood Cliffs: Prentice Hall.

Martin, J., and McClure, C (2009). Diagramming Techniques for Analysis and
Programming. Englewood Cliffs: Prentice Hall.

Patel, N.V. (2005). Critical Systems Analysis and Design: A Personal

Framework Approach. New Jersey: Prentice Hall

Rowley, J.E. (1990). The Basics of Systems Analysis and Design for Information
Managers. Wokingham: Addison-Wesley.

Satzinger, J.W., Jackson,R.B. & Burd, S.D. (2008). Systems Analysis and
Design in a Changing World. 2nd Edition. Boston: Pearson.

Valacich, J., George J. & Hoffer, J.A. (2011). Essentials of Systems Analysis and
Design. 5th Edition. Boston: Pearson.

Weinberg, G. M. & Weinberg, D.(1988). General Principles of System Design.

New York: Dorset House.

Yeates, D. & Wakefield, T. (2003). Systems Analysis and Design. 2nd Edition.
New Jersey: Prentice Hall
 Systems Analysis and Design: A Simplified Approach | 202
____________________________________________________________________

Web Resources
[Link]
[Link]/view/tutorial/Systems-Analysis/31659
[Link]
[Link]
[Link]
[Link]
[Link]/
[Link]/sdlc/documents/sys_design_doc.doc
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]/~lxn/CMPSC_174/systems_analysis_exercises.htm
[Link]
[Link]
[Link]
[Link]
[Link]
 Systems Analysis and Design: A Simplified Approach | 203
____________________________________________________________________

Index

Data flow · 74, 126, 127, 128, 129,

A 131
Data flow diagram ·42, 87, 74, 131,
Abstract systems · 11 126, 127
Accounting system · 1, 15, 17, 168 Data input · 97, 99, 101
Architectural design · 88 Data stores · 130
Automated system · 13 Data verification techniques · 105
Database design · 115, 116, 119
Decision table · 42, 76, 77, 87
B
Decision tree · 76, 77
Background analysis · 37 Deliverables · 33, 46, 47
Barcode reader · 101 Deterministic systems · 11
Boundaries · 9 Documentation · 45, 73, 149, 150,
152
Double-entry · 106
C

Case tools · 74 E
Closed loop systems · 7
Closed systems · 11, 12 Economic feasibility · 53, 55
Coding · 34, 43, 142 Educational system · 2
Computer system · 1, 3, 4, 6, 7, 41, Entity · 2, 67, 141
85, 87, 99, 153 Environment · 9
Computer-based information
systems · 16 F
Control · 5, 6, 8
Conversion · 45, 149 Feasibility study · 34, 37, 48, 50, 51,
Cost-benefit analysis · 55 52
Custom-written · 83 Feedback · 8
Field · 124
File and database design · 89, 112
D
File design · 115
Data capture · 97, 99 Fingerprint reader · 101
Data dictionary · 42, 74, 87, 126, Flowchart · 42, 87, 152, 166
139 Form · 94
Data entry · 97 Formal information systems · 11, 16
 Systems Analysis and Design: A Simplified Approach | 204
____________________________________________________________________

H O

Hands-on users · 23 Off-the-shelf software · 83

OMR forms · 99
I On-screen reports · 109
On-site observation · 67
Indirect end users · 23 Open loop systems · 7
Inference · 37 Open systems · 11, 12
Informal information systems · 11, Operational feasibility · 39, 56
16 Organization · 3
Input design · 96, 97 Output design · 88
Input devices · 83 Output design principles · 108
Integration · 4
Interaction · 4 P
Interdependence · 4
Interface design · 91 Paper form · 101
Interfaces · 9, 10 Payroll system · 77, 79
Interpersonal skills · 23 Physical model · 86
Interviews · 66, 67, 69, 161 Physical systems · 11
Planning · 34
L Preliminary system study · 35
Printed reports · 109
Language command · 95 Probabilistic systems · 14, 15
Legal feasibility · 39 Problem solving skills · 23
Logical model · 86 Process design · 89
Production system · 1
Program test · 44, 143
M
Program test · 44
Maintenance · 34, 45, 63, 159, 162, Proof reading · 106
163
Man made information system · 16 Q
Manual systems · 11
Mechanistic systems · 14 Questionnaires · 71
Menu table · 94
 Systems Analysis and Design: A Simplified Approach | 205
____________________________________________________________________

R T

Record · 27, 28, 67, 97, 113, 119, Table · 75, 94, 114, 122, 123, 124,
121, 122, 124, 131, 132, 136 158
Record reviews · 72 Technical feasibility · 39
Return on investment · 38 Telephone system · 1
Revolutions per minute · 14 TELOS · 53
Testing · 34, 43, 142, 147
S Transportation system · 1

Scheduling feasibility · 53 U
Screen design · 96
Semi-closed systems · 13 User training · 45, 149, 153
Stochastic systems · 15, 18 Users of system · 23
Structured english · 42, 74, 87
Symbols · 94
System analysis · 7, 20, 30, 47, 82,
162
System analyst · 20, 21, 22, 23, 28,
29, 30, 37, 81, 92, 162
System design · 41, 85, 86, 90, 165
System flowcharts · 89
System proposal · 36
System requirements specification ·
81
System specification · 90
System test · 44, 143
Systema · 1
Systems · 1, 9, 11, 12, 18, 20, 21,
41, 47, 86, 90, 92, 120, 158, 161,
162, 164, 165
Systems analysis · 19, 20, 21, 29, 40
Systems development life cycle · 30,
35
 Systems Analysis and Design: A Simplified Approach | 206
____________________________________________________________________