SYSTEM ANALYSIS AND DESIGN

The Systems Concepts

Scholars in various disciplines who are concerned about the tendency toward the
tragmentation of knowledge and the increasing complexity of phenomena have
sought a unifying approach to knowledge. Luduring von Bertalanlfy, a biologist,
developed a general systems thereby that applied to any arrangement of elements
such as cells, people, societies or even planets. Norbert Wiener, a mathematician
observed that information and communications provides connecting links for unifying
fragments or elements, His systems concept of information theory, which shows the
parallel between the functioning of human beings and electronic systems, laid the
foundation for today’s computer systems. Herbert A. Simon, a political scientist,
related the systems concept to the study of organizations by viewing an ongoing
system as a processor of information for making decisions.
Systems analysis and information systems were founded in general systems theory,
which emphasizes a close look at all parts of a system. Too often analysts focus on
only one component and over look other equally important component. General
systems theory is concerned with “developing a systematic, the oretieal framework
upon which to make decisions’. It discourages thinking in a vacuum and encourages
consideration of all the activities of the organization and its external environment.
Pionerring work in general systems theory emphasized that organizations be viewed
as total systems. The idea of systems has become most practical and necessary in
conceptualizing the interrelationships and integration of operations, especially when
using computers. Thus a system is a way of thinking about organizations and their
problems. It also involves a set of techniques that helps in solving problems.

Definition of a System
The term system is derived from the Greek word systema, which means an organized
relationship among functioning units or components. A system exists because it is
designed to achieve one or more objectives. We come into daily contact with the
transportation system, the telephone system etc. Similarly we talk of the business
system and of the organization as a system consisting of interrelated departments
such as production, sales, personnel.
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 or a subsystem in a
multilevel structure. The components may be simple or complex, basic or advanced.
They may be a single computer with a keyboard, memory and printer or a series of
intelligent terminals linked to a mainframe. In either case each component is part of
the total system and has to do its share to work for the system to achieve the
intended goal. This orientation requires an orderly grouping of the components for
design for a successful system.
The study of systems concept, has three basic implications:
1. A system must be designed to achieve a predetermined objective.
2. Interrelationship and interdependence must exist among the components.
3. The objectives of the organization as a whole have higher priority that the
objectives of its subsystems.

Characteristics of a System
Our definition of a system suggests some characteristics that are present in all
systems: organization, interaction, inter dependences, interaction and a central
objective.

Organization
Organization implies structure and order. It is the arrangement of components that
helps to achieve objectives. In the design of a business system, for example, the
hierarchical relationship starting with 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 (see figure
1.1). Likewise a computer system is designed around an input device, a central
processing unit, and output device and one or more storage units.

Interaction
Interaction refers to the manner in which each component functions with other
components of the system. In an organization, for example, purchasing must interact
with production, advertising with sales, and payroll with personnel. In a computer
system the central processing unit must intract with input device to solve a problem.
In turn, the main memory holds programs and data that the arithmetic unit uses for
computation. The interrelationship between these components enables the computer
to perform.

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. Our
subsystem depends on the input of another subsystem for proper functioning i.e. the

Formal
organization
President position

Vice president Vice president

Vice president production accounting
sales

Dept. head Dept. head

assembly painting Lines of Authority

Workers Workers
output of one subsystem is the required input for another subsystem. This
interdependence is crucial in systems work.
Figure 1.1: Organisation Structure

Production
Research &
Development.

Marketing
Major Higher-level
subsystem

Purchasing
Financing &
administration

Distribution system
Personnel

Intermediate (Middle-level
subsystem

Employme
Figure 1.2:
nt section
Major subsystems of Production Firm
Benefits &
services
section Unemployme
nt reports
To illustrate these system characteristics, figure 1.2 shows three Labourlevels of
Labour distribution
subsystems. Each
section of the topHealth
inner
and
safety
circles represent a major subsystem
reports of a
production firm. The personnel subsystem,
section in turn, may be
Voluntary
deduction viewed as a system that
reports

consists of subsystemsTraining
such as a benefits and safety, and employment.
section Health and
Fringe benefits
reports
safety as a key personnel subsystem consists of lower level Insuranceelements that are
benefits reports
considered vital in personnel operation.

Input
data

Payroll Feedback and

Control

Computer
programs Remote
Budget terminals for
data acquisition

Data
base

Skills inventory job

Operatio positions, recruitment,
n personnel budget,
benefits, health,
employment record.

Finance
Feedbac
k and Action
control report
Administrators

Demograph
ic data

Other authorized
Personnel staff
users
 Figure 1.3: A Human Resources Information System

Above figure is an integrated information system designed to serve the needs of

authorized users for quick access and retrieval through 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 it receives from other sub systems to perform its required tasks.
Interdependence is further illustrated by 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. As shown in figure below, none of these persons can perform properly
without the required input from others in the computer based subsystem.

Systems Programming Operations

User
Analysis
area

Figure 1.4: Task Interdependence in a Computer-Based System

Integration
Integration refers to the holism of systems. Synthesis follows analysis to achieve the
central objective of the organization. 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.

Central Objective
The last characteristics of a system is its central objective. Objective may be real or
stated. Although a stated objective may be the real objective, it is not uncommon for
an organization to state one objective and operate to achieve another. The important
point is that users must known the central objective of a computer application early
in the analysis for a successful design and conversion.

Elements of a System
1. Output and Inputs
2. Processor(s)
3. Control
4. Feedback
5. Environment
6. Boundaries and Interface

Outputs and Inputs

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

Compare output
against
performance
standards

Informational
Action feedback
Management
(Control)

Policy decision

Human resources,
material, energy,
information Transformation Goods of services

Standard of
Input Processing performance

Output

Figure 1.5: Inputs and Outputs in a Business Operation

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

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

Feedback
Control in a dynamic system is achieved by feedback. Feedback measures output
against standard in some form. After the output is compared against performance
standards, changes can result in the input or processing and consequently, the
output.
Feedback may be positive or negative, routine or informational. Positive feedback
reinforces the performance provides the controller with information for action. In
system analysis, feedback is important in different ways. During analysis, the user
may specify that the problems in a given application, and justify the need for change.
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.

Environment
The environment is the “suprasystem” within which an organization operates. It is the
source of external elements that unhinge on the system. In fact, it often determines
how a system must function. The organization’s environment, consisting of vendors,
competitions and others, may provide constraints and consequently influence the
actual performance of the business.

Boundaries and Interface

A system should be defined by its boundaries – the limits that identify its
components, processes and interrelationships and interfaces with another system.
For example, a teller system in a commercial bank is restricted to the deposits,
withdrawals and related activities of customers checking and savings accounts. It
may exclude mortgage foreclosures, trust activities and the like.
Each system has boundaries that determine its sphere of influence and control.
Although in an integrated banking computer system design, a customer who has a
mortgage and a checking account with the same bank may write a check through the
“teller system” to pay the premium that is latter processed by the “mortgage loan
system”. Recently system design has been successful in allowing the automatic
transfer of funds from the bank account to pay bills and other obligations to creditors,
regardless of distance or location. This means that in systems analysis, knowledge of
the boundaries of given system is crucial in determining the nature of its interface
with other system for successful design.

Types of Systems
Systems have been classified in different ways. Common classifications are:
(i) Physical or abstract systems
(ii) Open or closed systems
(iii) Deterministic or probabilistic systems
(iv) Man-made information systems
(i) Physical or Abstract Systems: Physical systems are tangible entities that may
be static or dynamic in operation. Abstract systems are conceptual or non-
physical entities which may be as straightforward as formulas of relationships
among sets of variables or models - the abstract conceptualization of physical
situations.
(ii) Open or Closed Systems: An open system continually interacts with its
environments. It receives inputs from and delivers output to the outside. An
information system belongs to this category, since it must adapt to the
changing demands of the user. In contrast, a closed system is isolated from
environmental influences. In reality completely closed systems are rare.
(iii) Deterministic or Probabilistic Systems: A deterministic system is one in which
the occurrence of all events is perfectly predictable. If we get the description of
the system state at a particular time, the next state can be easily predicted. An
example of such a system is a numerically controlled machine tool.
Probabilistic system is one in which the occurrence of events cannot be
perfectly predicted. An example of such a system is a warehouse and its
contents.
(iv) Man-made Information Systems: It is generally believed that information
reduces uncertainty about a state or event. For example, information that the
wind is calm reduces the uncertainty that a trip by boat will be enjoyable. An
information system is the basis for interaction between the user and the
analyst. It determines the nature of relationship among decision makers. In
fact, it may be viewed as a decision centre for personnel at all levels. From this
basis, an information system may be defined as a set of devices, procedures
and operating systems designed around user-based criteria to produce
information and communicate it to the user for planning, control and
performance. Many practitioners fail to recognise that a business has several
information systems; each is designed for a specific purpose. The major
information systems are:
 formal information systems
 informal information systems
 computer based information system
A Formal information system is based on the organisation represented by the
organization chart. The chart is a map of positions and their authority relationships,
indicated by boxes and connected by straight lines. It is concerned with the pattern of
authority, communication and work flow.
An Informal information system is an employee-based system designed to meet
personnel and vocational needs and to help in the solution of work-related problems.
It also funnels information upward through indirect channels. In this way, it is
considered to be a useful system because it works within the framework of the
business and its stated policies.
Third category of information system depends mainly on the computer for handling
business applications. Systems analysts develop several different types of
information systems to meet a variety of business needs. There is a class of systems
known collectively as Computer Based Information Systems. As we have different
types of transportation systems such as highway systems, railway systems and
airline systems, computer based information systems are of too many types. They
are classified as:
 Transaction Processing Systems (TPS)
 Management Information Systems (MIS)
 Decision Support Systems (DSS)
 Office Automation Systems (OAS).
The next figure shows the organisation chart of computer based information system
(CBIS) and figure shows the hierarchical view of CBIS.

Figure 1.6: CBIS in an Organisation Context

Figure 1.7: Hierarchical View of CBIS

Transaction Processing Systems

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

Management Information System

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

Decision Support Systems

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

Office Automation Systems

Office automation systems are among the newest and most rapidly expanding
computer based information systems. They are being developed with the hopes and
expectations that they will increase the efficiency and productivity of office workers-
typists, secretaries, administrative assistants, staff professionals, managers and the
like. Many organisations have taken the First step toward automating their offices.
Often this step involves the use of word processing equipment to facilitate the typing,
storing, revising and printing of textual materials. Another development is a
computer based communications system such as electronic mail which allows people
to communicate in an electronic mode through computer terminals. An office
automation system can be described as a multi-function, integrated computer based
system that allows many office activities to be performed in an electronic mode.
Categories of different information systems with their characteristics have been
described briefly in table below.
Categories of Information Systems

Category of Characteristics
Information System

Transaction Processing System Substitutes computer-based processing for

manual processes. Includes record-keeping
applications.

Management Information System Provides input to be used in the managerial

decision process. Deals with supporting well
structured decision situations. Typical
information requirements can be anticipated

Decision Support System Provides information to managers who make

judgements about particular situations.
Supports decision makes in situations that are
not well structured.

Office Automation System It is a multi-function, integrated computer

based system, that allows many office
activities to be performed in an electronic
mode.

System Development Life Cycle

To understand system development, we need to recognize that a candidate system
has a life cycle, much like a living system or a new product. Systems analysis and
design are based to the system life cycle. The stages are described below. The
analyst must progress from one stage to another methodically, answering key
questions and achieving results in each stage.
A word of caution regarding life cycle activities. We isolate and sequence these
activities for learning purposes, but in real life they overlap and highly interrelated,
for example, when the analyst is evaluating an existing operation he/she is probably
thinking about an alternative way that would improve the system or wondering
whether a given piece of hardware would be a critical cost item to consider for a
candidate system. Therefore, there can easily be overlap during any phase of the
cycle. In fact, it may act as a basis for modifying earlier steps taken. We now describe
each of these steps.

Recognition of Need – What is the Problem?

One must know what the problem is before it can be solved. The basis for a candidate
system is recognition of a need for improving an information system or a procedure.
For example, a supervisor may want to investigate the system flow in purchasing. Or
a bank president has been getting complaints about the long lines in the drive – in.
This need leads to a preliminary survey or an initial investigation to determine
whether an alternative system can solve the problem. It entails looking into the
duplication of effort bottlenecks, inefficient existing procedures, or whether parts of
the existing system would be candidates for computerization. If the problem is
serious enough, management may want to have an analyst look at it, such an
assignment emplies a commitment, especially if the analyst hired from the outside. In
larger environments, where formal procedures are the norm, the analyst’s first task is
to prepare a statement specifying the scope and objective of the problem. He/she
then reviews it with the user for accuracy at this stage, only a rough “ball parle”
estimate of the development cost of the project may be reached. However, an
accurate cost of the next phase – the feasibility study – can be produced.

Stage Key Question Result

1. Recognition of need
Preliminaryy survey/ What is the problem or Statement of scope and
Initial investigation opportunity? Objectives
Performance criteria
2. Feasibility study
Evaluation of existing What are the user’s Technical/behavioral
System and procedures demonstrabel needs? Feasibility
Analysis alternative Is the problem worth Cost/benefit analysis
Candidate system solving? System scope and objectives
Cost estimates How can the problem be Statement of new scope and
Redefined? Objectives
3. Analysis
Detailed evaluation of What must be done to solve Logical model of system—
Present system the problem? e.g., data dictionary, data
Data collection What are the facts? flow diagram
Pertient data
4. Design
General design In general, how must the Design of alternative
specifications problem be solved? solutions
Detailed design Specifically, how must the Final cost/benefit analysis
specifications problem be solved? Hardware specifications
Output What is the system Cost estimates
Input (processing) flow? Implementation specifications
Fiels
Procedures Does the user approve the Implementation schedule
System? Approval of system by user
Programs
Program constrcution
Testing
Unit testing How well do individual Security, audit, and operating
Combined module programs/modules test out? Procedures
Testing How ready are programs for Actual hardware use
User acceptance acceptance test? Formal system test
Testing
5. Implementation
User training What is the actual operation? Training program
File/System conversion Are user manuals ready? User-friendly documentation
Are there delays in lading
 Files?
6. Post-implementation and
Maintenance
Evaluation Is the key system running? User requirements met
Maintenance Should the system be User standards met
Enchancements modified? Satisfied user

Figure 1.9: System Development Life Cycle

Project Selection
The project has to be identified before it can be solved. The basis for an alternative
system is the recognition of a need for improving an information system or a
procedure.
The idea for change originates in the environment or within the firm due to any of the
following reasons :
speed of processing needed to be improved
increased workload
to cut down on cost of processing
requirement of increased accuracy/reliability of output reports generated
security of processing
Environment based ideas originate from customers, vendors, government sources
etc. e.g., new unemployment compensation regulations may make it necessary to
change the reporting procedure, format, and content of various reports, as well as the
file structures. Customer complaints about the delivery of orders may prompt an
investigation of the delivery schedule, the experience of the truck drivers, or the
volume of the orders to be delivered.
Ideas for change may also come from within the organisation's top management or
from the users.
When investigated, each of these ideas may lead to a problem definition which leads
to the first step in the system life cycle process.
The objective of this phase is to answer the following questions :
1. What is the problem (or opportunity) perceived ?
2. What are the goals to be achieved by the solution ?
3. What are the benefits which will result from achieving the solution ?
These details may be recorded in an informal note or in a formal document. This
document would be called the Project Request Form.
A request to receive assistance from an information system can be made for many
reasons, but in each case someone-a manager, an employee, or a systems specialist
- initiates the request.
The project proposal submitted by the users to the project selection committee is a
critical element while launching a systems study.
The form of such a request varies from firm to firm, but there is a general
agreement on the kind of information that should be provided.
A sample of the project request form is shown below.
THE PROJECT REQUEST FORM
Job Title Nature of Request To be completed
Investigation of Job Data not
an on-line safe _____ New 27/07/2001 later than
deposit system. _____ Revision 12/05/2002

Job Objectives: Provide customer service, reduce paper work, better billing
system, and possible reduction in staffing requirements.

Expected Benefits 1. Shorten or eliminate customer lines in lobby

2. Provide quick up-to-date information regarding box availability
3. More accurate billing procedure

Output Specifications Input Specifications

Report Title Document Title

Customer monthly statement Billing notices

Quantity 2-5 No. of pages/report Quantity 100-400

4 No. of copies/report

Frequency _____ daily Frequency _____ daily

______ weekly ______ weekly

Remarks: letter quality printing Remarks: number of notices vary with

the season. In January the range may be
between 200 – 1,000

Report Title Document title

Quantity ____ No. of pages/report Quantity ___

_____ No. of copies/report
Frequency ____ daily Frequency ____ daily
____ weekly ____ weekly
Remarks

As seen from the above table, the user’s request form specifies the following:
1. User-assigned title of work requested.
2. Nature of work requested (problem definition).
3. Date on which the request was submitted.
4. Date by which the job should be completed.
5. Job objective(s) - purpose of job requested.
6. Expected benefits to be derived from the proposed change.
7. Input/output description-quantity (number of copies or pages) and frequency
(daily, weekly, etc.) of inputs and outputs of the proposed change.
8. Requester's signature, title, department, and phone number.
9. Signature, title and department of the person(s) approving the request.

Preliminary Investigation of Project Selection

When a request to change, improve or enhance an existing system is made, the next
systems activity, that is, the preliminary investigation, begins. Because there is a
possibility for a stream of requests, standard procedures must be established to deal
with them.
The 'initial investigation' is one way to handle this. The objective is to determine
whether the request is 'valid' and 'feasible' before a recommendation is made to
either do nothing, or improve or modify the existing system or build a new one.

Scope of Study
The purpose of the preliminary investigation is to evaluate the project requests. It is
not a design study. It is collecting the information that permits the committee
members to

Evaluate the merits of the project request

Make an informal judgement about the feasibility of the proposed project.

The following activities should be accomplished during the preliminary investigation.

1. Clarify and understand the project request.
What is being done? What is required? Why?
Is there an underlying reason different from the one the requester identifies?
E.g. the user justifies a request for developing of an accounts receivable
system based on the requirement of faster processing. However, the
preliminary investigation may reveal that the need for better control of cash
handling outweighs the need for speed. Lost checks and not speed of
processing, are the real problems, but the requester has not described the
specific need clearly.
2. Determine the size of the project.
e.g. Does a request for a course-registration project call for new development
or for modification of the existing system? The investigation conducted for a
solution will also gather the details useful in estimating the amount of time and
number of people required to develop the project. Since many enhancements
of existing system are costly, they are treated in the same way as a new
project by the project selection committee.
3. Assess costs and benefits of alternative approaches
 e.g. What are the estimated costs for developing a patient information system,
as requested by the hospital's chief of staff? What expenses will be incurred to
train the medical and nursing personnel and install the system ? Will the
proposed system reduce the operating costs? Is it likely that the cost of error
will decrease?
4. Determine the technical and operational feasibility of alternative approaches.
e.g. Does the necessary technology to link office word processing systems to
the main computer exist or can it be acquired ? How workable is the request to
enable administrative assistants to retrieve sales information from the main
system and insert it directly into type written reports prepared on a word
processor ?
5. Report the findings to the management, with recommendations outlining the
acceptance or rejection of the proposal.
e.g. A proposal for the installation of an order entry system should be modified
to allow all salespersons to submit their orders through ordinary telephone
connections directly into the computer. The modifications will improve the
usefulness of the system and increase the financial benefits of the
organization.

Feasibility Study
Depending on the results of the initial investigation, the survey is expanded to a
more detailed feasibility study. As we shall learn, a feasibility study is a test of a
system proposal according to its workability impact on the organization, ability to
meet user needs, and effective use of resources. It focuses on there major questions:
i. What are the user’s demonstrable needs and how does a candidate system meet
them?
ii. What resources are available for given candidate systems? Is the problem worth
solving?
iii. What are the likely impact of the candidate system on the organization? How will
it fit within the organization’s master MIS plan?
Each of these questions must be answered carefully. They revolve around
investigation and evaluation of the problem, identification and description of
candidate systems, specification of performance and the cost of each system, and
final selection of the best system.
The objective of a feasibility study is not to solve the problem but to acquire a sense
of its scope. During the study, the problem definition is crystallized and aspects of
the problem to be included in the system are determined. Consequently, costs and
benefits are estimated with greater accuracy at this stage.
The result of the feasibility study is a formal proposal. This is simply a report - a
formal document detailing the nature and scope of the proposed solution. The
proposal summarizes what is known and what is going to be done. It consists of the
following.
1. Statement of the Problem – a carefully worded statement of the problem that
led to analysis.
2. Summary of Findings and Recommendations – a list of the major findings and
recommendations of the study. It is ideal for the user who required quick
access to the results of the analysis of the system under study. Conclusions are
stated, followed by a list of the recommendations and a justification for them.
3. Details of Findings – An outline of the methods and procedures undertaken by
the existing system, followed by coverage of objectives & procedures of the
candidate system. Included are also discussions of output reports, file
structures, and costs and benefits of the candidate system.
4. Recommendations and Conclusions – special recommendations regarding the
candidate system, including the personal assignments costs, project
schedules, and target dates.
In the feasibility study offering system design, we have to consider the following:

Feasibility Considerations
Three key considerations are involved in the feasibility analysis: economic, technical,
behavioural. Let’s briefly review each consideration and how it relates to the systems
effort.

Economic Feasibility

Economic analysis is the most frequently used method for evaluating the
effectiveness of a candidate system. More commonly known as cost/benefit analysis,
the procedure is to determine the benefits and savings that are expected from a
candidate system and compare them with costs. If benefits outweigh costs, then the
decision is made to design and implement the system. Otherwise, further justification
or alterations in the proposed system will have to be made if it is to have a chance of
being approved. This is an ongoing effort that improves in accuracy at each phase of
the system life cycle.

Technical Feasibility

Technical feasibility centers around the existing computer system (hardware,

software etc.) and to what extent it can support the proposed addition. For example,
if the current computer is operating at 80 per cent capacity – an arbitrary ceiling –
then running another application could overload the system or require additional
hardware. This involves financial considerations to accommodate technical
enhancements. If the budget is a serious constraint, then the project is judged not
feasible.

Behavioural Feasibility

People are inherently resistant to change, and computers have been known to
facilitate change. An estimate should be made of how strong a reaction the user staff
is likely to have towards the development of a computerized system. It is common
knowledge that computer installations have something to do with turnover, transfers,
retraining, and changes in employee job status. Therefore, it is understandable that
the introduction of a candidate system requires special effort to educate, sell, and
train the staff on new ways of conducting business.
After the proposal is viewed by management it becomes a formal agreement that
paves the way for actual design and implementation. This is a crucial decision point
in the life cycle. Many projects die here, whereas the more promising ones continue
through implementation. Changes in the proposal are made in writing, depending on
the complexity, size, and cost of the project. It is simply common sense to verify
changes before committing the project to design.

Analysis
It is a detailed study of the various operations performed by the system and their
relationship within and outside of the system. A key question is – what must be done
to solve the problem? One aspect of analysis is defining the boundaries of the system
and determining whether or not a candidate system should consider other related
systems. During analysis, data are collected on available files, decision points, and
transactions handled by the present system. We shall learn about some logical
system models and tools that are used in analysis. It requires special skills and
sensitivity to the subjects being interviewed. Bias in data collection and interpretation
can be problem. Training, experience and common sense are required for collection of
the information needed to do the analysis. Once analysis is completed the analyst
has a firm understanding of what is to be done. The next step is to decide how the
problem might be solved. Thus, in the systems design, we move from the logical to
the physical aspects of the life cycle.

Design
The most creative and challenging phase of the system life cycle is system design.
The term design describes both a final system and a process by which it is
developed. It refers to the technical specifications (analogous to the engineer’s
blueprints) that will be applied in implementing the candidate system. It also includes
the constructions of programs and programme testing. The key question here is –
How should the problem be solved? The major steps in design are shown below.
 Form
1
analysis

Output
design

Detailed system
documentation

Input design Cost justification

and candidate
system design

Design submitted to
management for
approval

File design

No
Processing Design accepted? Abandon project
design Output design

Yes

Test
programs

Go to implementation
Go to
implementation

Figure 1.10: Steps in System Design

The first step is to determine how the output is to be produced and in what
format. Samples of the output (and input) are also available. Second, input
data and master files (data base) have to be designed to meet the
requirements of the proposed output. The operational (processing) phase
are handled through programe construction and testing, including a list of
the programmes needed to meet the system’s objectives and complete
documentation. Finally, details related to justification of the system and an
estimate of the impact of the candidate system on the user and the
organization are documented and evaluated by management as a step
toward implementation.
The final report prior to the implementation phase includes procedural
flowcharts, record layouts, report layouts, and a workable plan for
implementing the candidate system. Information on personnel, money,
hardware, facilities and their estimated cost must also be available. At this
point, projected costs must be close to actual costs of implementation.
In some firms, separate groups of programmer do the programming
whereas other firms employ analyst programmers who do analysis and
design as well as code programmes. For this discussion, we assume that
analysis and programming is carried out by two separate persons. There
are certain functions, though, that the analyst must perform while
programes are being written operating procedures and documentation
must be completed. Security and auditing procedures must also be
developed.

Testing
No system design is ever perfect. Communication problems, programmers
negligence or time constraints create errors that most be eliminated
before the system is ready for user acceptance testing. A system is tested
for online response, volume of transactions, stress, recovery form failure
and usability. Then comes system testing, which verifies that the whole set
of programs hangs together, following system testing is acceptance
testing or running the system with live data by the actual use.
System testing requires a test plan that consists of several key activities
and steps for programs, string, system and user acceptance testing. The
system performance criteria deal with turaround time, backup, file
protection, and the human factor.

Implementation
This phase is less creative than system design. It is primarily concerned
with user training, site preparation, and file conversion. When the
candidate system is linked to terminals and remote sites the
telecommunication network and tests of the network along with the
system are also included under implementation.
During the final testing, user acceptance is tested, followed by user
training. Depending on the nature of the system, extensive user training
may be required, conversion usually takes place at about the same time
the user is being trained or later.
In the extreme, the programmer is falsely viewed as someone who ought
to be isolated from other aspects of system development. Programming is
itself design work, however. The initial parameter of the candidate system
should be modified as a result of programming efforts. Programming
provides a “reality test” for the assumptions made by the analyst. It is
therefore a mistake to exclude programmers from the initial system
design. System testing checks the readiness and accuracy of the system
to access, update and retrieve data from new files. Once the programmes
become available, test data are read into the computer and processed
against the file(s) provided for testing. If successful, the programe(s) is
then run with “live” data. Otherwise, a diagnostic procedure is used to
local and correct errors in the program. In most programes, a parallel run
is conducted where the new system runs simultaneously with the ‘old’
systems. This method, though costly, provides added assurance against
errors in the candidate system and also gives the user-staff an opportunity
to gain experience through operation. In some cases, however, parallel
processing is not practical. For example, it is not plausible to run two
parallel online point-to-sale (POS) systems for a retail chain. In any case,
after the candidate system proves itself, the old system is phased out.

Evaluation
During systems testing, the system is used experimentally to ensure that
the software does not fail. In other words, we can say that it will run
according to its specifications and in the way users expect. Special test
data are input for processing, and the results examined. A limited number
of users may be allowed to use the system so that analyst can see
whether to use it in unforeseen ways. It is desirable to discover any
surprises before the organization implements the system and depends on
it.
Implementation is the process of having systems personnel check out and
put new equipment into use, train users, install the new application and
construct any files of data needed to use it. This phase is less creative
than system design. Depending on the size of the organisation that will be
involved in using the application and the risk involved in its use, systems
developers may choose to test the operation in only one area of the Firm
with only one or two persons. Sometimes, they will run both old and new
system in parallel way to compare the results. In still other situations,
system developers stop using the old system one day and start using the
new one the next.
Evaluation of the system is performed to identify its strengths and
weaknesses. The actual evaluation can occur along any one of the
following dimensions:
(i) Operational Evaluation: Assessment of the manner in which the
system functions, impact.
(ii) Organisational Impact: Identification and measurement of benefits
to the organisation in such areas as financial concerns, operational
efficiency and competitive impact.
(iii) User Manager Assessment: Evaluation of the attitudes of senior and
user manager within the organisation, as well as end-users.
(iv) Development Performance: Evaluation of the development process
in accordance with such yardsticks as overall development time and
effort, conformance to budgets and standards and other project
management criteria.
Maintenance is necessary to eliminate errors in the working system during
its working life and to tune the system to any variations in its working
environment. Often small system deficiencies are found as a system is
brought into operation and changes are made to remove them. System
planners must always plan for resource availability to carry out these
maintenance functions. The importance of maintenance is to continue to
bring the new system to standards.

Post – Implementation and Maintenance

Maintenance is to eliminate errors in the working system during
its working life and to tune the system to any variations in its
working environment.
After the installation phase is completed and the user staff is adjusted to
changes created by the candidate system, evaluation and maintenance
being. Like any system there is an ageing process the requires periodic
maintenance of hardware & software. If the new information is
inconsistent with the design specifications, then changes have to be
made. Hardware also requires periodic maintenance to keep in time with
design specification. The importance of maintenance is to continue to
bring the new system to standards.

User priorities, changes in organizational requirements, or environmental

factor also call for system enhancements. To contrast maintenance with
enhancement, if a bank decided to increase its service charges for
checking accounts from $ 3.00 to $ 450 for a minimum balance of $ 3,000,
it is maintenance. However, if the same bank decided to create a personal
loan on negative balances when customers overdraw their account, it is
enhancement. This change requires evaluation, program modifications,
and future testing.

Role of a Systems Analyst

Who is Systems Analyst?

A systems analyst is a person who conducts a study, identifies activities

and objectives and determines a procedure to achieve the objectives.
Designing and implementing systems to suit organisational needs are the
functions of the systems analyst He plays a major role in seeing business
benefit from computer technology. The analyst is a person with unique
skills. He uses these skills to coordinate the efforts of different type of
persons in an organisation to achieve business goals.

What a Systems Analyst does?

A system analyst carries out the following job:

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

Attributes of an effective Systems Analyst

Systems analyst must have the following attributes:

(a) Knowledge of people: Since a systems analyst works with others so
closely, he or she must understand their needs and what motivates
them to develop systems properly.
(b) Knowledge of Business functions: A systems analyst must know the
environment in which he or she works. He must be aware of the
peculiarities of management and the users at his installation and
realize how they react to systems analyst. A working knowledge of
accounting and marketing principles is a must since so many
systems are built around these two areas. He must be familiar with
his company's product and services and management's policies in
areas concerning him.
(c) Knowledge of Data processing principles: Most systems today are
computer based. The systems analyst must fully aware about the
potential and limitations of computers.
(d) Ability to communicate: As a coordinator, a systems analyst must
communicate properly with people of different levels within an
organisation. Systems analyst must listen carefully to what others
say and integrate the thoughts of others into the systems
development process.
(e) Flexibility: Systems analysts must be flexible in their thinking since
they often do not get-their own way. Different factions in an
organisation have conflicting needs and most systems are the result
of compromise. The analyst's goal is to produce the system that will
be the best for the organisation. This requires an open mind and
flexibility in his ideas.
(f) An analytical mind: It takes an unusual person to see through
problems facing an organisation and develop solutions that will
work. Systems analysts often find themselves with more data than
 they can cope with. It requires an analytical mind to select pertinent
data and concentrate on them in defining problems and forming
solutions.
(g) Well educated with sharp mind: Systems analysts are called upon to
work with people at all levels virtually in every aspect of business.
They must know how to work with all of them and gain their
confidence. Analysts must have sharp mind to learn quickly how
people do their jobs and develop ways for them to do it better.

Objectives of Feasibility Analysis

The main objectives of feasibility analysis are –
 To identify the deficiencies in the current system.
 To determine objectives of the proposed system.
 To acquire a sense of scope of the system.
 To identify the responsible users.
 To determine whether it is feasible to develop the new system.
Consider our case scenario ‘Stock Monitoring System’ for finding the main
objectives of feasibility study. The various objectives of feasibility analysis
for are discussed below.

Deficiencies in the Current System

The major deficiencies in the manual ‘Stock Monitoring System’ are –
 Searching for a particular item or transaction is time consuming.
 There is a possibility of making wrong entries in stock register by
the store clerk.
 The management does not get stock status reports on time.
 The purchase department cannot place orders on time.

Objectives of the Proposed System

The main objectives of the proposed system are –
 To resolve the deficiencies of the current system.
 To help the store clerk in doing his role more efficiently and
correctly.

Scope of the Proposed System

The proposed system can be –

 Developed further to get many inventory management reports; and
 Integrated with other systems, viz. Production, Planning and Control
systems and Invoicing system.

Responsible Users

The responsible users of the proposed system are store clerk and
production manager.

Feasibility of the System

Whether the proposed system is feasible to develop depends on many

factors which we will discuss throughout this unit.

Steps in Feasibility Analysis

Feasibility analysis is carried out in following steps:
1. Form a Project Team and Appoint a Project Leader: First of all project
management group of the organization forms separate teams for
independent projects. Each project team comprises of one or more
systems analysts and programmers with a project leader. The
project leader is responsible for planning and managing the
development activities of the system.
2. Start Preliminary Investigation: The systems analyst of each project
team starts preliminary investigations through different fact
finding techniques.
3. Prepare the Current Systems Flowchart: After preliminary
investigations, the analysts prepare the systems flowchart of the
current system. These charts describe the general working of the
system in a graphical way.
4. Describe the Deficiencies in the Current System: On studying the
systems flowcharts, the analysts identify and describe the
deficiencies in the current system.
5. Determine Objectives of the Proposed System: The major objectives
of the proposed systems are listed by each analyst and are
discussed with the project leader.
6. Prepare the Proposed Systems Flowchart: After determining the
major objectives of the proposed system, the analysts prepare their
systems flowcharts. Systems flowcharts of the proposed system are
compared with those of current system in order to ensure that they
meet the objectives.
7. Determine the Technical Feasibility: The existing computer systems
(hardware and software) of the concerned department are identified
and their technical specifications are noted down. The analysts
decide whether the existing systems are sufficient for the technical
requirements of the proposed system or not.
8. Determine the Economic Feasibility: The analysts determine the
costs and benefits of proposed system in order to ensure that the
project is economically feasible.
9. Determine the Operational Feasibility: After determining the
economic feasibility, the analysts identify the responsible users of
the system and hence determine the operational feasibility of the
project.
10. Presentation of Feasibility Analysis: During the feasibility study, the
analysts also keep on preparing the feasibility study report. At the
end of feasibility analysis, the feasibility analysis report is given to
the management alongwith the oral presentation.

Types of Feasibility
During feasibility analysis, the analyst considers the three main types of
feasibility – technical, economical and operational feasibility, all of which
are interrelated.
(a) Technical Feasibility: During this study, the analyst identifies the
existing computer systems (hardware and software) of the
concerned department and determines whether these technical
resources are sufficient for the proposed system or not. If they are
not sufficient, the analyst suggests the configuration of the
computer systems that are required. The analyst generally pursues
two or three different configurations which satisfy the key technical
requirements but which represent different costs. During technical
feasibility study, financial resources and budget is also considered.
The main objective of technical feasibility is to determine whether
the project is technically feasible, provided it is economically
feasible.
(b) Economic Feasibility: Economic feasibility is the most important
study that determines the cost and benefits of the proposed system
and compares with the budget. The cost of the project should not
outweigh the budget. The cost of the project includes the cost of
hardware, software, development and implementation. Cost/benefit
analysis is the common method to determine the benefits that are
expected from the proposed system and compare them with the
costs expected to spend on development of the system. If benefits
are found to be more than costs, then the analyst decides to
continue the development of the proposed system otherwise
considers it economically not feasible. The feasibility study presents
both tangible (e.g., increased productivity, low operating cost, etc.)
and intangible benefits (e.g., improved organizational planning,
improved asset utilization, etc.) in a formal way. We will discuss the
cost/benefit analysis in a subsequent sub-section.
(c) Operational Feasibility: When it is found that the project is both
economic and technical feasible, the next step is to determine
whether it is operationally feasible or not. During operational
feasibility study, it is determined whether the system will operate in
the way that user wants. Operational feasibility depends upon
human resources for the development and implementation of the
system. It is considered whether the qualified and experienced
manpower is available for development and implementation of the
system. User involvement is more required in determining the
operational feasibility.
d. Social Feasibility: Social feasibility is a determination of whether a
proposed project will be acceptable to the people or not. This
determination typically examines the probability of the project
being accepted by the group directly affected by the proposed
system change.
e. Management feasibility: It is a determination of whether a proposed
project will be acceptable to management. If management does not
accept a project or gives a negligible support to it, the analyst will
tend to view the project as a non-feasible one.
f. Legal feasibility: Legal feasibility is a determination of whether a
proposed project infringes on known Acts, Statutes, as well as any
pending legislation. Although in some instances the project might
appear sound, on closer investigation it may be found to infringe on
several legal areas.
g. Time feasibility: Time feasibility is a determination of whether a
proposed project can be implemented fully within a stipulated time
frame. If a project takes too much time it is likely to be rejected.
After the feasibility study, a document is prepared that is known as
‘Feasibility Study Report’. Besides this report, the analyst also gives the
oral presentation of feasibility study to the management.

Feasibility Analysis Report

Feasibility analysis report is a formal document for management use and
is prepared by systems analyst during or after feasibility study. This report
generally contains the following sections:
(a) Covering letter: It formally presents the report with a brief
description of the project problem alongwith recommendations to
be considered.
(b) Table of Contents: It lists the sections of feasibility study report
alongwith their page numbers.
(c) Overview: It presents the overview of the project problem alongwith
the purpose and scope of the project.
(d) Description of Existing System: A brief description of the existing
system alongwith its deficiencies are presented in this section.
(e) System Requirements: The system requirements, which are either
derived from the existing system or from the discussion with the
users, are presented in this section.
(f) Description of Proposed System: It presents a general description of
the proposed system, highlighting its role in solving the problem. A
description of output reports to be generated by the system is also
presented in the desired formats.
(g) Development Plan: It presents a detailed plan with starting and
completion dates for different phases of SDLC. A complementary
plan is also needed for hardware and software evaluation, purchase
and installation.
(h) Technical Feasibility Findings: It presents the findings of technical
feasibility study alongwith recommendations.
(i) Costs and Benefits: The detailed findings of cost and benefits
analysis are presented in this section. The savings and benefits are
highlighted to justify the economic feasibility of the project.
(j) Operational Feasibility Findings: It presents the findings of
operational feasibility alongwith the human resource requirements
to implement the system.
(k) Alternatives Considered/Rejected: The different alternatives that an
analyst usually considers and rejects during feasibility study, should
also be included in the feasibility study report. These alternatives
are required to be discussed because they show, how the suggested
system is the best alternative to solve the problem.
(l) Recommendations and Conclusions: The benefits and savings are
summarized and it is recommended whether the management
should decide to proceed with the project or abort the project.
(m) Appendixes: In the last section of feasibility study report, all memos,
documents and data compiled during study are enclosed for
reference.

Oral Presentations
Although, feasibility study report is the best written presentation of the
proposed system, it is expected that the analyst gives an oral presentation
to the management and end users. During oral presentation, many issues
can be clarified and new ideas from the users can be picked up by the
analyst.
There is no standard form of the sequence of topics to be discussed during
oral presentation by the analyst but the following general outline is
suggested:
I. Introduction.
A. Self introduction by the analyst.
B. A brief introduction of the problem.
C. A brief description of the current system.
(i) Specify the drawbacks of the current system.
(ii) Specify how the proposed system can solve the
problem.
II. Body of Presentation.
A. Describe Current System.
(i) Highlight drawbacks of the current system.
(ii) Highlight how the current system cannot satisfy the
user.
B. Describe Proposed System.
(i) Highlight System Requirements.
(ii) Highlight scope and objectives of the proposed system.
(iii) Highlight savings and benefits of the proposed system.
C. Describe implementation plan of the proposed system.
D. Describe Operational Feasibility of the system.
III. Conclusion.
A. Summarize the proposal.
B. Summarize the objectives and recommendations.
C. Summarize the benefits and savings.
IV. Discussion period.

Cost/Benefit Analysis
Since cost plays quite an important role in deciding the new system, it
must be identified and estimated properly. Costs vary by type and consist
of various distinct elements. Benefits are also of different type and can be
grouped on the basis of advantages they provide to the management. The
benefits of a project include four types:
(i) Cost-savings benefits
(ii) Cost-avoidance benefits
(iii) Improved-service-level benefits
(iv) Improved-information benefits
Cost-savings benefits lead to reduction in administrative and operational
costs. A reduction in the size of the clerical staff used in the support of an
administrative activity is an example of a cost-saving benefit.
Cost-avoidance benefits are those, which eliminate future administrating
and operational costs. No need to hire additional staff in future to handle
an administrative activity is an example of a cost-avoidance benefit.
Improved-service-level benefits are those where the performance of a
system is improved by a new computer-based method.
Improved-information-benefit is where computer based methods lead to
better information for decision-making. For example, a system that reports
the most-improved fifty customers as measured by an increase in sales is
an improved-information. This information makes it easier to provide
better service to major customers.

Categories of Costs and Benefits

The costs associated with the system are expenses, outlays or losses
arising from development and using a system. But the benefits are the
advantages received from installing and using this system.
Costs and benefits can be classified as follows:
(a) Tangible or intangible
(b) Fixed or variable
(c) Direct or indirect

Tangible or Intangible Costs and Benefits

Tangibility refers to the ease with which costs or benefits can be measure.
An outlay of cash for any specific item or activity is referred to as a
tangible cost. These costs are known and can be estimated quite
accurately.
Costs that are known to exist but their financial value cannot be exactly
measured are referred to as intangible costs. The estimate is only an
approximation. It is difficult to fix exact intangible costs. For example,
employee moral problem because of installing new system is an intangible
cost. How much moral of an employee has been affected cannot be
exactly measured in terms of financial values.
Benefits are often more difficult to specify exactly than costs. For example,
suppliers can easily quote the cost of purchasing a terminal but it is
difficult for them to tell specific benefits or financial advantages for using
it in a system. Tangible benefits such as completing jobs in fewer hours or
producing error free reports are quantifiable. Intangible benefits such as
more satisfied customers or an improved corporate image because of
using new system are not easily quantified. Both tangible and intangible
costs and benefits should be taken into consideration in the evaluation
process. If the project is evaluated on a purely intangible basis, benefits
exceed costs by a substantial margin. We call such projects cost effective.
On the other hand, if intangible costs and benefits are included, the total
costs (tangible-intangible) exceed the benefits making the project an
undesirable investment. Hence it is desirable that systems projects should
not be evaluated on the basis of intangible benefits alone.

Direct or Indirect Costs and Benefits

Direct costs are those which are directly associated with a system. They
are- applied directly to the operator. For example, the purchase of floppy
for Rs.400/- is a direct cost because we can associate the floppy box with
money spent.
Direct benefits also can be specifically attributable to a given project. For
example, a new system that can process 30 per cent more transactions
per day is a direct benefit.
Indirect costs are not directly associated with a specific activity in the
system. They are often referred to as overhead expenses. For example,
cost of space to install a system, maintenance of computer centre, heat,
light and air-conditioning are all tangible costs, but it is difficult to
calculate the proportion of each attributable to a specific activity such as a
report.

Indirect benefits are realized as a by-product of another system. For

example, a system that tracks sales-calls on customers provides an
indirect marketing benefit by giving additional information about
competition. In this case, competition information becomes an indirect
benefit although its work in terms of money cannot be exactly measured.

Fixed or Variable Costs and Benefits

Some costs and benefits remain constant, regardless of how a system is
used. Fixed costs are considered as sunk costs. Once encountered, they
will not recur. For example, the purchase of an equipment for a computer
centre is called as fixed cost as it remains constant whether in equipment
is being used extensively or not. Similarly, the insurance, purchase of
software etc. In contrast, variable costs are incurred on a regular basis.
They are generally proportional to world volume and continue as long as
the system is in operation. For example sample, the cost of computer
forms vary in proportion to the amount of processing or the length of the
reports desired.
Fixed benefits also remain constant by using a new system, if 20 percent
of staff member are reduced, we can call it a fixed benefit. The benefit of
personnel saving may occur month. Variable benefits, on the other hand,
are realized on a regular basis. For example are reduced, we can call it a
fixed benefit. The benefit of personnel saving may occur month. Variable
benefits, on the other hand, are realized on a regular basis. For example
the library information system that saves two minutes in providing
information about a month. Variable benefits, on the other hand, are
realized on a regular basis. For example the library information system
that saves two minutes in providing information about particular book
whether it is issued or not, to the borrower compared with the manual
system. The amount of time saved varies with the information given to the
number of borrowers.

Structured Analysis
Structured analysis is a development method for analysis of an existing
system. It is a set of techniques that allow the analyst to design the
proposed system. The main purpose of structured analysis is to completely
understand the current system.

Tools of Structured Analysis

Data flow diagrams, data dictionary and process descriptions are the main
tools for structured analysis.
(a) Data Flow Diagrams (DFDs): Data flow diagrams are widely used
graphic tools for describing the movement of data within or outside
the system. As a DFD consists of a series of bubbles joined by lines,
it is also known as a ‘bubble chart’. The basic DFD format is shown
in Figure 4.5.
(b) Data Dictionary: Data dictionary is an organised list of terms and
their definitions for all the data elements and data structures that
are pertinent to the system. It stores the names alongwith their
descriptions of all data used in a system.

Figure 4.5: Basic DFD Format for a Generalised Payroll Application

(c) Process Descriptions: Process descriptions are another major tool of

structured analysis, that describe the sequence of different
processes in the system. Structured English (pseudocode), decision
tree and decision table are commonly used process descriptions.

Data Flow Diagrams

During analysis phase of SDLC, the systems analyst or other members of
the project team draw many diagrams to show how data move within an
organisation. These diagrams, popularly called as DFD (Data Flow
Diagram), quickly convey to both the software developers and users how
the current system is working and how the proposed system will work. The
main advantage of DFD is that they are easily understood by the users,
and hence users can suggest modifications in the proposed system. We
will discuss now the different types of DFD and see how these DFD can be
drawn.

Determination of DFD
Armed with interview results, tabulated questionnaires, and experience
through personal observations, the analyst is ready to describe the current
system in narrative form, with a data-flow diagram, or with a system
flowchart. Since all organisations have an accounts payable (AP) system
let us being with such an example using a context DFD. A context DFD
defines the system under study in a general form, showing:
Inputs to AP: Packing slips, invoices, checking account balances, payment
notifications.
Outputs from AP: reports to management, cheque to suppliers.

Figure 4.6: A context data-flow diagram depicts a typical accounts payable system
in its broadest perspective, not showing any of the details or internal processes

A context DFD does not show any detail but is an overview drawing of the
system. It is an excellent diagram to share with management whose
interest is general in nature. Context DFDs place a boundary around the
system under investigation, saying that this is what will be examined -
nothing more and nothing less.
After developing a context DFD, the analyst turns his attention to the
details of accounts able. Management reviews inventory reports and
determines what to order from suppliers orders are placed by the
accounting department using a purchase order/requisition: on delivery
merchandise and packing slips enter the warehouse, and packing slips are
sent to the accounting department, which receives invoices directly from
suppliers, while merchandise stays the warehouse or goes to a distribution
outlet. Accounting clerks compare purchase order requisitions with
invoices and packing slips to make sure all invoiced items have actually
rived, and then post the purchase to the supplier's ledger. At the end of
each month, the accounting department prepares a report of balances due
suppliers-and an inventory report for management evaluation.
These detailed activities by the accounting department, management,
warehouse personnel the bank and suppliers add up lo six major activities
(Figure 4.8):
1. Generation of reports
2. Ordering of stock
3. Printing of cheque
4. Posting of accounts
5. Reconciliation of bank statements
6. Authorisation of payment
During the design phase of the systems process, the analyst will study
each of these activities further, leveling the data-flow diagram of Figure
4.7 into far more details.
To draw the analysis DFD:
1. Look at the system from the inside to the outside
2. Identify the activities
3. Locate the data flows
4. Show the relationships between activities
5. Find the internal inputs or outputs that exist within the system
6. Level complex processes in the DFD into simpler ones
7. Look for duplication of data flows or data stores (Files)

Figure 4.7

While determining the flow of data, the analyst collects samples of all
relevant documents, such as sample cheques, invoices, packing slips, and
other relevant forms. To create a record of all purchases from and
payments to suppliers, a manual system requires that someone prepare a
ledger entry for each supplier.

The assembled documents help an analyst understand what data the new
system must collect and process. For example, the company can easily
obtain the following data from the invoice itself:
1. Supplier name, address, and telephone number
2. Invoice number
3. Invoice dale
4. Invoice
5. Terms of invoice
6. Amount of invoice
From the packing slip, it can obtain
1. Supplier name
2. Shipping date
3. Date goods are received
4. Freight charges
5. Invoice number
Packing slips are carbon copies of invoices omitting certain data, such as
the money value of the shipment. The warehouse clerk checks the
merchandise received against the packing slip to be sure everything is in
the carton and notes any discrepancies. Then the packing slip goes to
accounting for comparison with invoices to be sure that the company
received what it is paying for.
The ledger offers two categories offers supplier data and
purchase/payment history:
1. Supplier name
2 Supplier address
3. Supplier telephone number
4. Date of transaction
5. Description of transaction
6. Amount of invoice or payment
7. Discount
8. Balance due the supplier
Each cheque sent to a supplier contains the following data:
1. Invoice number
2. Cheque number

3. Amount of payment
4. Payment date
In addition to these documents, it is useful to have copies of reports
prepared by the accounting department

Types of DFD
There are two types of DFD - Physical and Logical DFD.
(a) Physical DFD: The data flow diagrams which represent the model of
the current system (manual or computerised), are known as
physical DFD. These diagrams are drawn, when the analyst studies
the current working system in detail.
(b) Logical DFD: The data flow diagrams which represent the model of
the proposed system, are known as logical DFD. These diagrams are
drawn from the physical DFD.
Each of these DFD can be further categorised into different levels like zero
level (context diagram), first level, second level and third level. Each
higher level DFD is drawn by adding more details to each process of lower
level, by a technique called ‘Exploding DFD’. We will learn these
techinques in subsequent sections.

DFD Modelling Notation

The four notations that are widely used in DFD, are shown in Table 4.2. The
description of these notations is explained below –

Table 4.2: DFD Modelling Notation

(a) External Entity: External Entity represents any entity that supplies
data or receives information from the system. For example,
customer, sales department, employee, etc., are external entities.
(b) Data Flow: The data flow indicates the movement of data either
from input to process or from process to output. Data flow is labeled
to show what data is flowing. For example, customer details, sale
reports, etc., are data flows.
(c) Process: Processes are the actions performed on input data to
produce the output data. They are given some meaningful names.
For example, Prepare Bill, Calculate Sales, Compute Pay, etc., are
the processes.
(d) Data Store: Data store indicates the data file or register where data
is accumulated. For example, Customer Master File, Employee
Register, Sales Transaction File, etc., are data stores.

Steps to Draw DFD

The different level physical and logical DFD are generally drawn in the
following steps:
1. Identify external entities and data flows of the current system and
draw physical context diagram.
2. Identify data stores and processes of the system and draw first level
physical DFD.
3. Explore the processes of first level and draw second level DFD.
4. Explore the processes of second level and draw third level DFD.
5. Derive the logical view of each physical DFD by the following ways-
(a) Remove documents and show actual data in data flow.
(b) Remove registers and use files as data stores.
(c) Remove unnecessary processes.
(d) Remove data flow between external entities (if any) and show
data flow through processes.

Data Dictionary
Data dictionary is a catalogue of all data elements, data structures and
processes described in logical DFDs. Before we discuss the importance
and contents of a data dictionary, let us understand the meaning of the
following terminology:
Data Element: Data element is the smallest unit of data that has some
meaning. For example, part code, part name, date of transaction, etc., are
data elements.
Data Structure: Data structure is a group of data elements that describe a
unit in the system. For example, Part Details is a data structure that
contains part code, part name and date of transaction as data elements.
Data Store: Data store is a data structure for collecting data input during
processing. For example, Part Register is a data store.
Data Flow: Data flow is a data structure, that shows a unit of data in
motion. For example, New Part Details is a data flow that moves from an
external entity to a process.
The data elements, data stores, data flows and processes are described in
a data dictionary as illustrated in Figures 4.13, 4.14, 4.15 and 4.16.
Part Code
Data Element

Short Description: This element describes the code of a part or subassembly.

Organisation: B.R. Auto Limited

Date:

Aliases (contents): Part Number

If Discrete If Continuous

Value Meaning Range of

Value: A001 to Z999

Typical Value: A001

Length: 4

Internal Representation: Character

Figure 4.13: An Example of Data Element in a Data Dictionary
Data Dictionary

Transactions file
Data Store
Description: Day’s Transaction

Data Flow in: Data flow out:

Issue, Return, Receipt Consolidated transaction of the day

Contents: Part No., Part Name, Date of Transaction, Issue, Receipt, Name of Concerned Person and
Posting Status

Physical Organisation: Store

Figure 4.14: An Example of Data Store in a Data Dictionary

New Part Details Data Flow

Source Ref. Description:Part
Destn. Ref. Description: Part Register
Expanded Description: Part Details like: Part code, Part name, Date of
Transaction etc. are entered into the Part register.
Included data structure: Volume Information
Part register Volume increases when
new part is entered but
do not decrease when old
part is
discarded.

Figure 4.15: An Example of Data Flow in a Data Dictionary

 Description: Maintain Part Register
Process
Input Logic Summary Output
New part details All part details with Updated
part
a unique part code is
accepted. Duplicate
part code is not accepted
Daily Transaction Details Daily Transactions
Details of those part
codes are accepted that
exist in Part-Registers.

Figure 4.16: An Example of Process in a Data Dictionary

Importance of Data Dictionary

Data dictionary is an important tool for structured analysis as it offers
following advantages-
 It is a valuable reference for designing the system. It is used to build
the database and write programs during design phase.
 It assists in communicating meanings of different elements, terms
and procedures.
 It facilitates analysis in determining additions and changes in the
system.
 It helps the analyst to record the details of each element and data
structure.
 It is used to locate errors in the system descriptions.
 It is also a useful reference document during implementation of the system.
Data Dictionary
Data dictionary is a repository of data about data (metadata). It contains
information about each of the component of DFDS, data stores, processes
and data flowed. DD is a integral part of system specifications, since with
it, DFDS are just pictures with no details e.g.
Emp-master

4
Empho Empted
Get empted
Data flows:
Emp_no: Char (6)
Emp_details: Ep_Empa_add+Emp_det
Data stores:
Emp_record: Emp_no + Emp_no+Emp_add+Emp_doc
Process
do while not of empmaster
open emp_master
gotop
get emp_det

Basic Notations used for DD

= is equivalent of
+ And
[ ] either or
( ) optional entry
Alias Another nature.

Why Data Dictionary?

A data dictionary defines each term (called a data element) encountered
during the analysis and design of a new system. Data elements can
describe files, data flows, or processes. For example, suppose you want to
print the vendor's name and address at the bottom of a cheque. The data
dictionary might define vendor's name and address as follows:
Vendor name and address = Vendor name +
Street +
City+
State +
Pin +
Phone +
Fax+
e: mail
This definition becomes a part of the data dictionary that ultimately will
list all key terms used to describe various data flows and files.

Four Rules
Four rules govern the construction of data dictionary entries:
1. Words should be defined to stand for what they mean and not the
variable names by which they may be described in the program;
use CLIENT_NAME not ABCPQ or CODE06. Capitalization of words
helps them to stand out and may be of assistance.
2. Each word must be unique; we cannot have two definitions of the
same client name.
3. Aliases, or synonyms, are allowed when two or more entries show
the same meaning a vendor number may also be called a customer
number. However, aliases should be used only when absolutely
necessary.
4. Self-defining words should not be decomposed. We can even
decompose a dictionary definition. For instance, we might write
Vendor name = Company name,
Individual's name
which we might further decompose to
Company name = (Contact) +
Business name
Individual's name = Last name +
First name +
(Middle initial)
After defining a term, say VENDOR NUMBER, we list any aliases or
synonyms, describe the term verbally, specify its length and data type,
and list the data stores where the term is found (figure 4.8). Some terms
may have no aliases, may be found in many files, or may be limited to
specific values. Some self-defining or obvious words and terms may not
require inclusion in the data dictionary. For example, we all know what a
PIN code and a middle initial are. Data dictionaries seldom include
information such as the number of records in file, the frequency a process
will run, or security factors such as passwords users must enter to gain
access to sensitive data. Rather, data dictionaries offer definitions of
words and terms relevant to a system, not statistical facts about the
system.
Data dictionaries allow analysts to define precisely what they mean by a
particular file, data flow, or process. Some commercial software packages,
usually called Data Dictionary Systems (or DDS), help analysts maintain
their dictionaries with the help of the computer. These systems keep track
of each term, its definition, which systems or programs use the term,
aliases, the number of times a particular term is used and the size of the
term can be tied to commercial data managers.

DATA ELEMENT NAME: VENDOR_NUMBER

ALIASES: None
DESCRIPTION: Unique identifier for vendors in the
accounts payable system.
FORMAT: Alphanumeric, six characters.
DATAFLOWS: Vendor master
Accounts payable open item
Accounts payable open adjustments
Cheque reconciliation
REPORTS: Alphabetic vendor list
Numeric vendor list
A/P transaction register
Open item
Vendor account inquiry
Cash requirements
Pre-cheque-writing
Cheque register
Vendor analysis

Figure 4.8

There are two kinds of data dictionaries:

(i) integrated and
(ii) stand-alone.
The integrated dictionary is related to one database management system.
To the extent the organisation data is under this DBMS it is global or
organisation wide. However, very few enterprises have all their data eggs
in one basket, so the dictionary documentation (metadata) can be
considered as local and fragmented.
The stand-alone dictionary is not tied to any one DBMS, although it may
have special advantages for one DBMS, such as the IBM DB-DC Data
Dictionary, which has special features related to the IBM IMS DBMS but is
still a stand-alone variety of dictionary.
Data Dictionary Functions
Both these types of dictionaries can be identified by functions as either
passive, active, or inline. Viewed either way, by type or function, the
differences are striking. Passive, active, and in-line dictionaries differ
functionally as follows:

Passive Data Dictionaries

The functionally passive dictionary performs documentation only. This
variety of dictionary could be maintained as a manual rather than an
automated database. For more than limited documentation use, the
automated passive dictionary has clear advantages. From the
organisational view the documentation function is the most important
dictionary service with the most potential benefits, so the passive
dictionary should not be thought of negatively. It has more limited
functionality but may perform its critical function of global documentation
best of all.

Active Data Dictionaries

Besides supporting documentation to one degree or another, the active
data dictionary supports program and operations development by
exporting database definitions and program data storage definitions for
languages such as COBOL and Job Control Language (JCL) for execution-
time performance. The IBM DB/DC Data Dictionary already mentioned is
such a stand-alone, active data dictionary. A dictionary such as this is not
an in-line data dictionary as delivered, which is not to say that it could not
be put in-line by a determined effort of major proportions.

In-line Data Dictionaries

An in-line data dictionary is active during program execution, performing
such feats as transaction validation and editing. Such a dictionary would
always have some documentation value, but documentation across the
organisation about the organisation functions and activities and all the
organisation information data stores is not likely. In-line dictionaries are
associated with DBMS products such as Cullinet Software Corporation's
IDMS-R or Cincom System's TOTAL, to name just two.
The Make-up of Data Dictionaries: Data Dictionary Internals
The minimum data dictionary is shown in figure 4.9
 Figure 4.9: Minimum Data Dictionary

We have a database system consisting of databases or files. These files

consist of data groups or segments or records. These data groups consist
of data items or fields. There is an implicit relationship here, which needs
no additional comment. A certain amount of attribute information is
always present In the case of data items we need to know if it is a primary
or secondary key or an attribute field, if it has aliases, what are the field
type and field size, what is the name in various languages, and what is the
user description of the item. We need to know whether the data item or
data group is in test, system test, or production status need to know the
number of occurrences of this data item on the dictionary.
Addressing these last points, a data item (for instance) on the IBM data
dictionary may lok strange to the uninitiated. It will look like this:
T,C,BALANCE-ON-HAND,0
We recognize balance-on hand as an inventory quantity. The T is the
status code, which will say is T because the data- item balance-on-hand is
on the test-data database. The C is the subject code, which in this case is
the primary programming language: COBOL. The 0 is the occurrence
number where duplication exists in the common information system. So,
terms of this dictionary, the full description of the data-item consists of the
four elements mentioned above. This convention holds for all subjects
defined on the IBM data dictionary.
Before discussing the functions of the full-service extended data dictionary
we need to review data-dictionary elements. Figure 4.10 shows these
elements.
 Figure 4.10: Data-Dictionary Elements

We have already referred to categories, subjects, relationships, attributes,

and descriptions on other occasions. These are the elements that make up
the data dictionary. In figure 4.6, Category A has a forward and reverse
relationship to Category B. We have two-way relationships simply because
we may want to examine these relationships in both directions. Data-Item
is an example of a category. In a full- service dictionary some categories
are predefined regarding attributes and relationships, but the dictionary
has the capacity to handle user-defined categories. This, in IBM parlance,
is an extended use of the dictionary. This "extensibility" feature is the
heart of the full-service dictionary, allowing documentation of the whole
organization and allowing us to use the dictionary as the software support
for strategic and tactical planning.
Category A in figure 4.13 has four subjects. Each subject has the same
attribute set as the others (attributes AA, AB, AC). For instance the
category may be Projects. The four subjects are four different projects,
described by name and description as unique. Perhaps the attributes are
Project Leader, Project Due Date, and Percent Accomplished. All four
subjects would have identical attribute names. Perhaps Category B is
Information Systems, with subjects and attributes defined in a similar
fashion. The forward relationship might be Projects ACCOMPLISH
Information Systems. Reverse might be ACCOMPLISHED-BY.
Figure 4.14 shows another example of the elements that make up a data-
dictionary database. In this case we have the category Business Function
(or department) related to the Processes of the organisation such as
Provide-Materials. Remember that the subject name looks like this:
P„Provide-Materials,0. Remember that the P is the status code, which in
this case stands for Production. The two adjacent commas means the
subject code is not used for this kind of category, and the zero is the
occurrence (only this occurrence exists).

Figure 4.11: Example of Data-Dictionary Elements

The IBM data dictionary, which is actually six linked databases, each with
many segments, consists of standard categories and the infrastructure
needed to "customize" installation categories. The standard categories
have the attributes prebuilt and ready for the user to fill in. These
standard categories are:
 DATA-BASE
 SEGMENT
 ELEMENT
 PROGRAM COMMUNICATION BLOCK
 IMS SYSTEM DEFINITION
 APPLICATION SYSTEM
 JOB
 PROGRAM
 MODULE
 TRANSACTION
 PSB
These categories are all related to servicing the data processing function
and are not sufficiently broad in scope to support a dictionary for the
entire organisation. The strategic plan cannot be documented with just
these categories. It is the ability of this data dictionary to allow the
creation of other user-defined categories that allows us to consider the
dictionary a serious tool for systems analysis and documentation in
support of the current and new system applications.

Process Organisation and Interaction

Organization refers to the structure and order of hierarchical steps.
Organization means the arrangement of components things. Organization
means the arrangement of components so that we become able to
achieve our goals or objectives. For example in a typical company the
hierarchial relationships of the employees begins with the president at the
top. After president there may be vice presidents, department hands and
the hierarchy goes to blue-collar works. Such as relationship describes the
structure of authority, specifies the formal flow of communication and
formalize the chain of command. Another example of an organization is a
computer system which consists of input devices, output devices control
processing unit, etc., These components are organized or linked together
to achieve the goal, i.e., to process data, etc., Hence in a business system
the organization of different workers plays an important role for the
success of the system. Interaction describe the way in which each
component of a system functions with other components. For example, in
a factory purchasing must interact with production, advertising with sales,
and payroll with personnel. In a computer system each component should
interact with another in order to solve the problem. The central processing
unit should interact with input devices in order to take input and start
processing. In a business system there must be a proper interaction
between system. There must be a proper interaction between different
levels. Presidents should interact with managers with their subordinates
and so on. If there is interaction between different levels then the system
will run smoothly.

Process Descriptions
After defining all the data elements and data structures in the data
dictionary, the systems analyst begins to describe the processes. Process
descriptions are the tools for documenting the procedures and describing
the system logic. They contain the logic used to process the input data for
getting the output. The commonly used process description tools are–
(a) Structured English - used to describe a procedure in simple English
statements.
(b) Decision Tree - used to describe a set of conditions and actions
diagrammatically.
(c) Decision Table - used to describe a set of conditions and actions in a
tabular form.
Structured English
Structured English is used to describe the logic of a process. It consists of
simple narrative sentences and adheres to limited vocabulary and limited
syntaxes. Structured English uses narrative statements to describe a
procedure and reserve words for logical formulation. No strict syntaxes but
simple English words with vocabulary consisting of:
i. Imperative English language verbs
ii. Terms defined in data dictionary
iii. Reserved or key words for logic formulation
Eg. Keywords
BEGIN……END
IF….ELSE, ENDIF
REPEAT…..UNTIL
WHILE…..DO
It uses three basic types of statements -
(a) Sequence Structures: They include a set of instructions that are
carried out one after another and do not depend on any condition.
(b) Decision Structures: They include one or more sets of instructions
that are carried out depending upon one or more conditions. They
generally use the phrase IF THEN ELSE to carry out different actions.
(c) Iteration Structures: They include a set of instructions that are
repeated until a particular condition occurs. They generally use the
phrase DO WHILE ...ENDDO to repeat a set of instructions.
The examples of these three types of statements are illustrated in Table
4.3.

Table 4.3: Examples of Three Types of Statements

Sequential Structure: Decision Structure: Iteration Structure

Ans = “Y”
Accept employee code If Basic_Pay <=1000 Do while Ans = “Y”
Accept employee name HRA = 500 Accept employee code
Accept other details Store data Else Accept employee name
If Basic_Pay <= 3000 Accpet other details
HRA = 1000 Display “Continue (Y/N)?”
Else Accept Ans
HRA = 1500 Enddo
Endif
Endif

Decision Tables and Decision Trees

Decision tables and trees were developed long before the widespread use
of computers.
They not only isolate many conditions and possible actions, but they help
ensure that nothing has been overlooked.

Decision Tables
The decision table is a chart with four sections listing all the logical
conditions and actions. In addition the top section permits space for title,
date, author, system and comment
The condition stub displays all the necessary tests or conditions. Like the
diamond in a flowchart or the IF in pseudocode, these tests require yes or
no answers. The condition stub always appears in the upper left-hand
corner of the decision table, with each condition numbered to allow easy
identification.
Thus Condition stub is a list of all the necessary tests in a decision table. In
the lower left-hand comer of the decision table we find the action stub
where one may note all the processes desired in a given module. Actions,
like conditions, receive numbers for identification purposes. Thus Action
Stub is a list of all the processes involved in a decision table.
The upper right corner provides space for the condition entry - all possible
permutations of yes and no responses related to the condition stub. The
yes or no possibilities are arranged as a vertical column called rules. Rules
are numbered 1,2,3, and so on. We can determine the number of rules in a
decision table by the formula:
Number of rules = 2 h N where N represents the number of conditions and
h means exponentiation. Thus a decision table with four conditions has 16
(2M = 2x2x2x2 = 16) rules one with six conditions has 64 rules and eight
conditions yield 256 rules.
Thus Condition entry is a list of all the yes/no permutations in a decision
table. The lower right comer holds the action entry. X's or dots indicate
whether an action should occur as a consequence of the yes/no entries
under condition entry. X's indication action; dots indicate no action.
Thus Action entry Indicates via dot or X whether something should happen
in a decision table.

Figure 4.17

Returning to the assembly of a bicycle, let us assume we must assemble a

variety of containers full of parts. Since a bike can have either hand caliper
or foot coaster brakes, the decision table must show the two conditions
and five actions (figure 4.18). The two conditions necessitate four
condition entries, and the five actions produce 20 possible action entries.
When we build the yes or no rules for the condition entry, we must
construct all possible patterns of y's and n's. An arrangement that
guarantees thoroughness is to place two y's is succession followed by two
n's. In the second row, we place alternating pairs of y's and n's.
(a) Decision table for bicycle assembly:

Figure 4.18: Decision table for bicycle assembly

A decision table with four conditions (2M = 16) would have 16 different
sets of y's and n's and would result in the following pattern of yes and no
responses.
The first row therefore will have eight y's followed by eight n's. The second
row (corresponding to the second entry in the condition stub) has four y's,
four n's, four y's and four n's.
The complete four-condition entry would read:

This form ensures that the analyst includes all combinations with
duplication.
If large number of conditions exist (four conditions result in 16 condition
entries, six conditions in 64), decision tables can become unwieldy. To
avoid lengthy decision tables, analysts must remove redundancies and yet
still take precautions not to overlook anything. On occasion, two or more
rules may be combined to reduce or eliminate redundancy. In figures 4.19
and 4.20, rules 1 and 2 cause the last action in the action stub to occur.
Therefore, these two-rules could be combined to eliminate redundancy. To
indicate redundancy, we put a dash (-) in the condition entry to show that
this condition stub is irrelevant and can be ignored.
The decision table in figure 4.21 depicts the AP cheque module. Compare
with figure 4.16 (IPO). Although this format is fairly typical, in practice you
will encounter several different kinds of decision tables. Figure 4.22 called
limited entry, because the condition entry contains yes or no responses for
each rule.
Limited Entry: A type of decision table listing a y or n response for each
condition.

AP cheque decision table:

Figure 4.19: A limited entry decision table

Extended Entry: Type of decision table displaying values to be tested in the

condition entry (Figure 4.23).
AP cheque written as an extended-entry decision table:
 Figure 4.20: An extended-entry decision table

Mixed Entry; A type of decision table mixing values in the condition and
action entries.
AP cheque written as a mixed-entry decision table: Shown below in Fig.
4.24

Figure 4.20: A mixed-entry decision table

Open ended (1) A type of decision table that permits access to another
decision table. (2)
Questionnaire items that respondents must answer in their own words.
A mixed-entry decision table combines the values and yes or no (Figure
4.24), while an open-ended one allows an action entry specifying an
additional decision table(figure 4.25). An analyst may want to use one of
these other types of decision tables to make the table more readable for a
user or manger or to decompose a large (seven conditions leading to 128
rules) table into a series of smaller ones.
AP cheque decision table (open-ended):
 Figure 4.21: A open-ended decision table

Besides designing screen layout formats and determining screen

specifications, the design must develop input controls for interactive
dialogue and illustrate the way in which screens and menus are linked
together. Three tools which help the design team in doing this are dialogue
trees, decision trees, and picture-frame analyst With dialogue and decision
trees, the team is able to show the flow of control in processing, including
the actions users can take to halt or stop an input procedure. With picture-
frame analysis, the design team is able to provide a walk-through of how
screens will appear once a design becomes operational.

Tree
Once the data elements are defined in the data dictionary, we begin to
focus on the processes.
Trees provide a graphical representation of logics for non-technical people
to understand easily:

Example

If the analyst requires “What is the discount policy?” He may will be shown
a memo, which looks like:
Trade discount (to established booksellers) is 20%. For private customers
and libraries, 5% discount is allowed on orders for 6 books or more, 10%
on orders for 20 books or more, and 15% on orders for 50 or more. Trade
orders for 20 books and over receive the 10% discount in addition to the
trade discount. The tree for the process will be:
 Type of customer

Ordersie Discount
20 or more……………… 30%
Trade

Less than 20……………..20%

50 or more……………… 15%
20-49…………………….10%
6-19………………………5%
Private or Librarian
Less than 6…………………Nil

Figure 4.22: Tree Representation of Logic

The branches of the tree correspond to each of the logical possibilities.

A dialogue tree maps the static and dynamic messages that take place
between the computer and the user. Figure 4.27 shows the design of a
tree for a simple file processing menu.

Figure 4.23: Dialogue Tree showing branches from promoting menus

As shown, a dialogue tree has multiple branch points when menus are
used, and forks at yes or no points. If we trace the steps shown in figure
4.27, the dialogue tree should lead you to conclude the following:
1. When an initial response of 2 is received, the program branches to a
procedure to DELETE A RECORD from the employee master file.
2. Before a record is deleted, the user is asked to verify that the
employee name is correct. The message reads: EMPLOYEE NAME
OK?
3. If the name is correct, the tree forks and asks: SURE YOU WANT TO
DELETE?
4. If the name is incorrect, the tree forks and asks: NAME OK NOW?
5. If the name is correct (is OK now) and the user responds yes to the
question sure you want to Delete, the record is removed from the
file.
6. If the name is not correct, or if the name is correct but the user
decides not to delete control is shown as "return to start" - namely,
a loop back to the start of the tree.
Isn't this tree incomplete? If the employee name is not correct at node 2.0,
how could it be correct at node 2.1? an expanded dialogue tree, like the
one shown in figure 4.28, helps fill the missing messages. The more
detailed tree shown a node with an X. This is a nonrestricted node,
meaning that it is not restricted to a prescribed number of choices. The
first nonrestricted node indicates that it is necessary to find an employee
record before testing to determine whether the name is correct. Moreover,
if a record is found but the name is incorrect, a second attempt (as noted
by a second unrestricted node) is made to find the correct employee
record. If this second search is successful, the user is aksed: NAME OK
NOW?

Figure 4.24
Decision Trees
At times, a dialogue tree is too specific for design teams to work with.
What they prefer is an easier-to-follow mapping of a complex design. This
mapping should show branch points and forks, but not the details of the
user dialogue. A decision tree helps to show the paths that are possible in
a design following an action or decision by the user. Figure 4.29 illustrates
this second type of tree. As indicated, if the user selects 1, followed by M
and A, the algebra menu would be displayed.

Figure 4.25

What is the value of a tree such as this? It helps the designer visulaize how
the user will move through the design to reach a desired location. Thus, a
decision tree provides an overview of the flow of consol to be built into
computer programs.
Decision trees turn a decision table into a diagram (figure 4.30). This tool
is read from left to right, decisions result in a fork, and all branches end
with an outcome. Figure 4.30 shows the decision trees for printing the
accounts payable check. Trees can be easily ready by nontechnical users
who dined decision tables too complex. Users readily grasp branches,
folks, and outcomes.
 Figure 4.26: Decision trees she graphic equivalents of decision tables

The Process of Design

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 (system proposal) to a
document oriented to the programmers or data base personnel. Logical
and Physical Design Systems design goes through two phases of
development: logical and physical design. As we saw in Chapter 6, a data
flow diagram shows the logical flow of a system and defines the
boundaries of the system. For a candidate system, it describes the inputs
(source, outputs (destination), data bases (data stores), and procedures
(data flows)—all in a format that meets the user's requirements. When
analysts prepare the logical system design, they specify the user needs at
a level of detail that virtually determines the information flow into and out
of the system and the required data resources. The design covers the
following:
1. Reviews the current physical system—its data flows, file content,
volumes, frequencies, etc.
2. Prepares output specifications—that is, determines the format,
content, and frequency of reports, including terminal specifications
and locations.
3. Prepares input specifications—format, content, and most of the
input functions. This includes determining the flow of the document
from the input data source to the actual input location,
4. Prepares edit, security, and control specifications. This includes
speeding the rules for edit correction, backup procedures, and the
controls that ensure processing and file integrity.
5. Specifies the implementation plan.
6. Prepares a logical design walkthrough of the information flow,
output, input, controls, and implementation plan.
7. Reviews benefits, costs, target dates, and system constraints.
As an illustration, when a safe deposit tracking system is designed, system
specifications include weekly reports, a definition of boxes rented and
boxes vacant, and a summary of the activities of the week—boxes closed,
boxes drilled, and so on. The logical design also specifies output, input,
file, and screen layouts. In contrast, procedure specifications show how
data are entered, how files are accessed, and how reports are produced.
Following logical design is physical design. This produces the working
system by defining the design specifications that tell programmers exactly
what the candidate system must do. In turn, the programmer writes the
necessary programs or modifies the software package that accepts input
from the user, performs the necessary calculation through the existing file
or data base, produces the report on a hard copy or displays it on a
screen, and maintains an updated data are at all times. Specially, physical
system design consists of the following steps: or database, produces the
report.

Figure 5.1: Safe Deposit Tracking System

1. Design the physical-system.
(a) Specify input/output media.
(b) Design the data base an specify backup procedures.
(c) Design physical information flow through the system and a
physical design walkthrough.
2. Plan system implementation.
(a) Prepare a conversion schedule and a target date.
(b) Determine training procedure, courses, and timetable.
Devise a test and implementation plain and specify and new
hardware/software.
The physical design for our safe deposit illustration is a software pack-age
written in Pascal (a programming language). It consists of program steps
that accept new box rental information; change the number of boxes
available with every new box rental; print a report by box type, box size,
and box location; and store the information in the data base for reference.
The analyst instructs the software programmer to have the package
display a menu that specifies for the user how to enter a new box rental,
produce a report, or display various information on the screen. These and
other procedure specifications are tested and implemented as a working
model of the candidate system

Logical Models
Logical models show what a system is or does. They are implementation
independent; that is, they depict the system independent of any technical
implementation. As such, logical models illustrate the essence of the
system. Popular synonyms include essential model, conceptual model, and
business model.

Physical Models
Physical models show not only what a system is or does, but also how the
system is physically and technically implemented. They are
implementation-dependent because they reflect technology choices and
the limitations of those technology choices. Synonyms include
implementation model and technical model.
Systems analysts have long recognised the value of separating business
and technical concerns. That is why they use logical system models to
depict business requirements and physical system models to depict
technical designs. Systems analysis activities tend to focus on the logical
system models for the following reasons:
 Logical models remove biases that are the result of the way the
current system is implemented or the way that any one person thinks
the system might be implemented. Thus, we overcome the “we’ve
always done it that way” syndrome. Consequently, logical models
encourage creativity.
 Logical models reduce the risk of missing business requirements
because we are too preoccupied with technical details. Such errors
can be costly to correct after the system is implemented. By
separating what the system must do from how the system will do it
we can better analyse the requirements for completeness, accuracy,
and consistency.
 Logical models allow us to communicate with end-users in
nontechnical or less technical languages. Thus, we don’t lose
requirements in the technical jargon of the computing discipline. Here
we will focus exclusively on logical process modeling.

Logical Designing Requirements of a System

Once a commitment has been made by the user, the decision-makers, the
analyst and the designer work together to translate the logical model and
the tentative physical design into a firm physical design. Logical Designing
consists of the following phases:
a. Review the current physical system
The current physical system analyzed in order to perform the logical
design of the proposed system. This analysis consists of the
followings:
i. Physical Data Flows. A physical data flow represent the
planned implementation of an input to or output form a
physical process. It also indicates database action such as
create, delete, read or update a record. It also represents the
import of data from or the export of data to another
important system across a network. Finally, it represents the
data flows between two modules or subroutines within the
same program. Hence a physical data flow helps to
understand the system.
ii. File Contents: Now we have to analyze the files used by the
current system. We know that a file is the set of similar
records. there may be many types of files in a system such as
Master files, which contains the relatively permanent records;
Transaction files, which contain, the records that describes
the business events; Document files which contain the stored
copy of historical data for easy retrieval & review; Archival
files, which contain the record that are deleted from Master
and Transaction files from on – line storage; Audit files, which
are special records of update to other files, especially master
and transaction files. The analysis of the contents of these
files would helps to design the new system.
iii. Volumes: Volume analysis is the analysis of the data used by
the current system. The size of the database used by the
current system may severely large. We see that whether this
volume can be reduced. We try to design a new system with
respect to this volume.
iv. Frequency: In the last phase of the reviewing the current
system we analyze the frequency of the data used by the
system. That is, how frequently the data is used by the
 system. It may be possible that the data is retrieved after a
fixed period (a day, a week or a month etc.) for processing. If
this is the case then we can use sequential file system and a
batch processing system. If the records are accessed
frequently then we propose an on – line processing system
and we have to use a direct access file system.
b. Prepare Output Specification
This phase sees the output requirements of the system. It consists
of the following:
i. Format and Content of the Output: You must understand the
type and purpose of the output. Is the output an internal or
external report? If it’s an internal report, is it a historical,
detailed, summary, or exception report? If it‘s an external
report, is the form a turnaround document? After assuring
yourself that you understand what type of report the output
is and how it will be used, you need to address several design
issues.
– What medium would best serve the output? Various media
were discussed earlier in the chapter. You will have to
understand the purpose or use of the output to determine the
proper medium. You can select more than one medium, for
instance, video with optional paper. All these decisions arc
best addressed with the system users.
– What would be the best format for the report? Tabular? Zoned?
Graphic? Narrative? Some combination of these? After
establishing the format, you can determine what type of form
or paper will be used. Computer paper comes in three standard
sizes: 8½ by 11, 11 by 14, and 8½ by 14 inches. Many printers
can now easily compress 132 columns of print into an 8-inch
width. You need to determine the capabilities and limitations of
the intended printer. Despite the increase in larger 17-inch and
21-inch high-resolution monitors today, it is still recommended
that display outputs (thus, the entire application screen) are
designed for the lowest common denominator to ensure that
all users be able to run the application and see the screens on
their computers. Thus, it is still recommended that screen
applications be able to run on systems having 640 by 480
screen resolution.
– How many pages or sheets of output will be generated for a
single copy of a report? This information is necessary to
accurately plan paper and form consumption.
– Does the output require multiple copies? If so, how many?
Photocopy (doesn't tie up printer)? Carbons (most printers can
make not more than six legible carbons)? Duplicates (requires
the most printer time, although laser printers are changing this
situation)?
For external documents, there are also several alternatives.
Carbon and chemical carbon are the most common duplicating
techniques. Selective carbons are a variation whereby certain
 fields on the master copy will not be printed on one or more of
the remaining copies. The fields to be omitted must be
communicated to the forms manufacturer. Two-up printing is a
technique whereby two 'sets of forms, possibly including
carbons, are printed side by side on the printer.
– For printed outputs, have distribution controls been finalized?
For on-line outputs, access controls should be determined.
– For attributes contained on the output, what format should be
followed?
ii. Frequency of Reports
– How frequently is the output generated? On demand? Hourly?
Daily? Monthly? For scheduled outputs, when do system users
need the report? Today, reports are more commonly
generated by the users themselves. However, in the event
that reports are to be oriented by the information services
department, they must be worked into, the information
systems operations schedule. For instance, a report the
system user needs by 9:00 A.M. on Thursday may have to be
scheduled for 5:30 A.M. Thursday. No other time may be
available.
c. Prepare Input Specification
In order to design a user-friendly system we should take care of the
inputs to the system. Input specification consists of the formal,
content and most of the input functions.
i. Format: Format determines the way of taking the input of the
system. Input format should be convenient to user of the
system as well as to the implementer of the system. There
are several ways of taking input, e.g. Text Boxes, Radio
buttons, Check boxes, List boxes, Dropdown list and Combo
box etc. Each of these tools has its applications with certain
limitations.
ii. Contents: These general principles should be followed for
design:
– Capture only variable data. Do not enter constant data. For
instance, when deciding what elements to include in a SALES
ORDER input, we need PART NUMBERS for all parts ordered.
However, do we need to input PART DESCRIPTIONS for those
parts? PART DESCRIPTION is probably stored in a database
table. If we input PART NUMBER, we can look up PART
DESCRIPTION. Permanent (or semipermanent) data should be
stored in the database. Of course, inputs must be designed
for maintaining those database tables.
– Do not capture data that can be calculated or stored in
computer programs. For example, if you input QUANTITY
ORDERED and PRICE, you don't need to input EXTENDED
PRICE, which is equal to QUANTITY ORDERED X PRICE.
Another example is incorporating FEDERAL TAX
 WITHHOLDING data in tables (arrays) instead of keying in
that data every time.
– Use codes for appropriate attributes. Codes were introduced
earlier. Codes can be translated in computer programs by
using tables.
Second, if source documents are used to capture data they
should be easy for system users to complete and
subsequently enter into the system. The following
suggestions may help:
– Include instructions for completing the form. Also, remember
that people don't like to have to read instructions printed on
the back side of a form.
– Minimize the amount of handwriting. Many people suffer from
poor penmanship. The data entry clerk or CRT operator may
misread the data and input incorrect data. Use check boxes
wherever possible so the system user only needs to check
the appropriate values.
– Data to be entered (keyed) should be sequenced so it can be
read like this book, top to bottom and left to right. The data
entry clerk should not have to move from right to left on a
line or jump around on the form to find data items to be
entered.
– Ideally, portions of the form that are not to be input are
placed in or about the lower right portion of the source
document (the last portion encountered when reading top to
bottom and left to right). Alternatively, this information can
be placed on the back of the form.
d. Edit, Security & Control Specifications
This includes specifying rules for edit correction, backup procedures
and the controls that ensure the file integrity.
i. Edit Corrections: We should be able to edit the corrections
made, i.e., we can change the corrective made later if they
are proved wrong.
ii. Backup Procedures: This is an important part of the system.
We should take backup of what we have done. Backup is
generally taken periodically e.g. at the end of the day, the
week or the month. We design procedures to take backup of
the systems. All of these backup procedures should be tested
so that they will never fail.
iii. File Integrity: We should make certain controls the checks the
integrity of the file.
The controls are generally used after a transaction is made and
record is modified in the file.
e. Specifies the Implementation Plan
 This is the planning of the implementation of the proposed
system. Implementation involves the gathering information
about the organization. That is, is the organization where the
system is implemented has required hardware or software? Is
the staff has technical skills needed to handle the proposed
system? These points should be discussed earlier so that
there is no difficulty in the implementation of the system.
f. After computation of above issues, we prepare a logical design
walkthrough of the information flow, output, input and
implementation plan. Now we have a clear picture in mind and in
documents also about the input, file, screen layouts, how data is
entered, how files are accessed, how reports are produced, and how
to cope up with the difficulties in implementation.
g. Review benefits, costs target data and system constraints. This is
the last phase of logical design. In this phase we review the
earnings from the proposed system, and the cost of developing and
implement the new system. We also see the time feasibility i.e. is it
possible to develop the system within the given time limit. We
identify the constraint in developing as well as in the
implementation of the system. All of these points should be very
clear in mind prior to developing the system.

Physical Data
Physical
Files, Data
Procedures
Elements Data
Programs
Elements
Clerical
Database
Figure 4.3: Chart of Logical Requirements

This process involves 4 overlapping activities.

Refining the Logical Model

The logical model by this stage consists of the overall data flow diagrams,
logical level data dictionary entries for each major data flow, data
structure, data store, and processes. The detailed logic at this point has
not been specified.
Detailed data flow diagrams must be developed dealing with error and
exception handling and all the other processes that have yet not been
specified.
The logical design also specifies input forms, screen layouts, output screen
definitions, report formats etc.

Designing the Physical Data Base

From the logical data store contents, the information held in the data
dictionary, the designer must make a near-final commitment as to the
contents and organization of the physical files and/or data base.
If the system is to use an existing file or an existing database, the
designer must check that the existing contents and organization are
known and fit the data flows planned in the logical model.

Structure Chart Notations

The following notations (illustrated in Figure below) are used in a structure
chart:
(i) Rectangle: A rectangular box is used to represent a module. The
module name is written inside the rectangular box.
(ii) Arrows: They indicate the control relationships between calling and
called modules with an arrow pointing towards called module. They
also indicate the transfer of data or information between modules.
(iii) Circles: Circles represent two types of data parameters - data
couples and control flags. Data couples are the data items moved
from one module to another. They are represented by an arrow with
an empty circular tail. Control flags are the flags that assist to
control the logic of the two modules. They are represented by an
arrow with a filled circular tail.
(iv) Loop: It indicates that the instructions of called module are repeated
until a given condition is satisfied.
(v) Small Diamond: A small diamond below the rectangular box
indicates that one of the modules is being called depending upon
the validity of given condition.
 Figure 5.6: Structure Chart Notation

Strategies for Converting DFD to Structure Charts

Structure charts are drawn on the basis of logical DFD. The following two
strategies have been developed for converting data flow diagrams to
structure charts -
(a) Transform Analysis
(b) Transaction Analysis
Generally, both strategies are used to convert DFDs to structure charts.
Before discussing these strategies, let us first discuss the two types of
constructs, that are used while drawing structure charts. Two such
constructs are transform-centered and transaction-centered constructs.
In transform-centered construct, the main module calls three types of
modules, i.e., input, transform and output modules as illustrated in Figure
below. Input modules send inputs to the main-module and transform
modules receive these inputs and process them. The output modules
receive the processed data and give output data.
In transaction-centered construct, the main module calls one input, one
output and one of the different transaction modules depending upon the
transaction type of input module as illustrated in Figure below.

Figure 5.7: A Transform-centred Construct

 Figure 5.8: A Transaction-centred Construct

Database Design
As we have discussed that the organization selected for a particular file
mainly depends on the nature of the application for which it will be used.
Historically, Files have been designed based on specific application. Payroll
files are created containing all the data pertinent to a company's payroll
system. Similarly, individual files are created for use with the company's
personnel, accounts receivable, inventory, and other systems. If the data
contained on these files are not carefully delineated, it is very likely that
the same data will appear on several of these files. In other words, these
files would contain redundant data. For example, both a company's
personnel file and payroll file could contain the name and address of each
employee. This would mean that a simple change of address would have
to be processed twice and possibly three or four times, depending on the
number of other files on. which these data appear. Clearly, it would be
more practical to have each employee's name and address on one file
from which it can be accessed by all programs requiring these data. This
would reduce the amount of redundant data and minimise the possibility
that data contained on a file might be inaccurate because they were never
updated. This is but one of the reasons that database technology was
developed.
A DATABASE can be thought of as a set of logically related files organised
to facilitate access by one or more applications programs and to minimise
data redundancy. In other words, a database can be defined as a stored
collection of data, organised on the basis of relationships in the data
rather than the convenience of storage structures. It is not a replacement
for files.
Some general objectives in establishing a database are as follows:
– Eliminate redundant data as much as possible.
– Integrate existing data files.
– Share data among all users.
– Incorporate changes easily and quickly.
– Simplify the use of data files.
– Lower the cost of storing and retrieving data.
– Improve accuracy and consistency.
– Provide data security from unauthorised use.
– Exercise central control over standards.
In addition to the database itself, a set of programs is necessary to
facilitate adding new data as well as modifying and retrieving existing data
within a database. This set of programs is referred to as a Data Base
Management System (DBMS). A data base system merge data into one
pool shared by all systems so that any change automatically affects all
relevant systems. The following figures defines the difference between the
traditional file systems and database management system.
Figure below shows the Traditional file systems in which each system is
responsible for its own data.

Figure 5.12: Traditlonal File System

Figure below shows the Data Base Management Systems in which data is
centralised.

Figure 5.13: Data Base Management System

Specific advantages of data base are:

1. File Consolidation: Pooling data reduces redundancy and
inconsistency and promotes cooperation among different users.
Since data bases link records together logically, a data change in
one system will cascade through all the other system using the
data.
2. Program and file independence: This feature separates the
definition of the files from their programs, allowing a programmer to
concentrate on the logic of the program instead of precisely how to
store and retrieve data.
3. Access Versatility: Users can retrieve data in many ways. They enjoy
the best of both worlds - sequential access for reporting data in a
prescribed order and random access for rapid retrieval of a specific
record.
4. Data Security: Usually a DBMS includes a password system that
controls access to sensitive data. By limiting their access to read-
only, write-only, or specified records, or even fields in records,
passwords can prevent certain users from retrieving unauthorised
data.
5. Program Development: Programmers must use standard names for
data items rather than invent their own from program to program.
This allows the programmer to focus on desired function.
6. Program Maintenance: Changes and repairs to a system are
relatively easy.
7. Special Information: Special-purpose report generators can produce
reports with minimum effort.

Logical and Physical view of Data

In database design, several views of data must be considered along with
the persons who use them. In addition to data structuring, where
relationships are reflected between and within entities, we need to identify
the application program's logical views of data within an overall logical
data structure. The logical view is what the data look like, regardless of
how they are stored. The physical view is the way data exist in physical
storage. It deals with how data are stored, accessed, or related to other
data in storage. There are four views of data out of which three are logical
and one is physical. The logical views are the user's view, the
programmer's view and the overall logical view, called a schema.

SCHEMA
Once a database system has been designed, it will be possible to identify
each type of data item, data aggregate, record and set by a name or code.
It will be possible to state which data item types go together to make data
aggregate types and record types, and to identify which record types are
members and owners of set types. A coded set of tables describing this
information and stored in the computer system on direct access devices is
called a SCHEMA. It is a description of the data structure which is separate
from the data itself. The schema describes the areas, their identifiers and
page sizes, and indicates how these are related to the records and sets. In
other systems, a different set of tables is used for this.
The schema therefore, is the view of the data, the overall logical data
structure which is held by the DBMS. Each time a program requires data,
the DBMS will look up in the schema for the details of the structure of the
data requested. For example if the program requires an occurrence of a
set, the DBMS will look up in the schema which record types are required,
how to find the relevant records given a certain key by the program, and
perhaps also which areas the pages containing the relevant data are
stored in.
Sub-Schema
In a database system, it is not always possible to allow programmers to
write the data division of their choice for reasons of security or control. It
is more useful to provide the programmer with a standard description of
the logical data to be used in a particular application. All references to
data within the program will be for this description, which is called a
SUBSCHEMA and is similar to the Schema in structure. The DBMS has the
job of matching data requests on a subschema and data requests based
on the schema.

Types of Database
In conventional file systems, groups of bytes constitute a field, one or
more Fields make a record, and two or more records make a file. In a
database environment, a group of bytes constitutes a data item or
segment, a collection of segments a data entry, and a series of data
entries a data set. The complete collection of data sets is the database
itself. With traditional processing of files, records are not automatically
related, so a programmer must be concerned with record relationships.
Often the Files are stored and processed by record key, just as we sorted
the transaction file. Data bases relate data sets in one of three models:
hierarchical, network, or relational.

Hierarchical Model
In a hierarchical structure, sometimes referred to as a tree structure, the
stored data get more and more detailed as one branches further and
further out on the tree. Each segment, or node, may be subdivided into
two or more subordinate nodes, which can be further subdivided into two
or more additional nodes. However, each node can have only one "parent"
from which it emanates. The Figure below shows the hierarchical structure.

Figure 5.14: Hierarchical Structure

Network Model
The network related data sets are similar to hierarchical ones, except that
a node may have more than one parent. Thus a hierarchical DBMS is a
subset of network DBMS. The trade off between the simplicity of design of
a hierarchical structure and the storage efficiency of a network structure is
a very important consideration in database implementation. The Figure
below shows the Network structure.
 Figure 5.15: Network Structure

Relational Model
The relational structure, however, organises the data in terms of two
dimensional tables. That is. Relational data sets order data in a table of
rows and columns and differ markedly from their hierarchical or network
counterparts. "There are no parent or node data sets as shown in Fig. 1.8.
In a relational database management systems, we have the same concept
of files, records, and Fields. Files are represented by two-dimensional
tables, each of which is called a "relation". Records, which can be
visualized as rows in the table, are called "Tuples". Fields can be visualised
as columns, and are called by attribute names, or domains.
For example, note that in the supplier table in Figure below we have three
Tuples, or rows, and three attribute names or columns. If we need to know
the name of the supplier of blue chairs, the relational DBMS searches the
type and color columns of the Furniture, Table and Finds supplier number
30, and then it scans the supplier table for number 30, which turns out to
be PANKAJ'S. Since each "record" is a row in the table and each "Field" a
column, an inventory system of 1600 Tuples, each with 5 attributes, would
create a table of 1600 rows and 5 columns.

Figure 5.16: Relational Structure

A relational DBMS can perform the following basic operations:

– create or delete tables
– update, insert, or delete rows
– add or delete columns
– copy data from one table into another
– retrieve or query a table, row or column
– print, recognize, or read a table or row
– join or combine tables based on a value in a table.
Since the relational structure organises the data in terms of two
dimensional tables, they offer great flexibility and a high degree of data
security. The relational structure uses relatively little memory or secondary
storage. Unfortunately, the process of creating the tables is a rather
elaborate procedure. Another disadvantage of this structure is that it
generally requires more time to access information than either of the other
two structures. This is because much more information must be searched
in order to answer queries posed to the systems. In addition, some
implementation use a fixed amount of storage for each field, resulting in
insufficient storage utilisation. In spite of these disadvantages, the
relational structure has gained rapid acceptance and is currently the most
popular of the three structures. Many experts predict that it will eventually
replace the others completely.

Levels of Data Independence

The data independence may be of the following two levels:
(a) Physical Data Independence: If the data is designed in such a way
that the physical storage techniques of the data can be changed
without changing the application programs then this level of data
independence is called as physical data independence.
(b) Logical Data Independence: If the database is organised in such a
way that the logical structure can be changed without changing the
application program then this level of data independence is called
as logical data independence.

Reasons for Data Independence

Why the data independence is required? It is mainly due to the following
two reasons:
(1) The development of one application is generally very expensive and
time consuming. Therefore, the application should be developed
considering the possibility of changes required in specifications of
reports or queries in future. Hence, if the database is application
independent, then there would not be any need to modify the
application programs in future and hence will save time and money
of the organisation.
(2) The requirement of queries or reports may be changed in future
depending upon different applications. If the database is application
independent, then the data can be stored in one particular
 representation (e.g. say in binary) but can be viewed in another
representation (say in decimal). Sometimes the units of numeric
data can also be changed in future (say from centimeters to inches).
So, there are a lot of possibilities of modification of specifications
given by organisation in future. Therefore, the data independence
concept is ideal for such applications.

Conversion Methods/ Installation

Methods
Conversion is the process of changing from the old system to the new one.
It must be properly planned and executed. Four methods are common in
use. They are: parallel systems, direct conversion, pilot system and
systems phase-in. Each method should be considered in the light of the
opportunities that it offers and problems that it may create.
However, it may be possible that sometimes, we may be forced to apply
one method over others, even though other methods may be more
beneficial. In general, systems conversion should be accomplished in
shortest possible time. Long conversion periods create problems for all
persons involved including both analysts and users.

Parallel Systems
The most secure method of converting from an old to new system is to run
both systems in parallel. Under this approach, users continue to operate
the old system in the usual manner but they also start using the new
system. This method is the safest one because it ensures that in case of
any problems in using the new system, the organisation can still fall back
to the old system without loss of time and money.
The disadvantages of the parallel systems approach are:
 It doubles operating costs
 The new system may not get fair trial.

Direct Conversion
This method converts from the old to the new system abruptly, sometimes
over a weekend ( even overnight. The old system is used until a planned
conversion day, when it is replaced by the new system. There are no
parallel activities. The organisation relies fully on the new system. The
main disadvantages of this approach are: no other system to fall back on,
if difficulties arise with new system. Secondly, wise and careful planning is
required.

Pilot System
Pilot approach is often preferred in the case of the new system which
involves new techniques or some drastic changes in organisation
performance. In this method, a working version of the system is
implemented in one part of the organisation, such as a single work area or
department. The users in this area are aware that they are piloting a new
system and that changes can be made to improve the system. Based on
the feedback, changes are made and the system is installed in the
remaining departments of the organisation, either all at on (direct
conversion method) or gradually (phase-in method). This approach
provides experience and live test before implementation.

Phase-in Method
This method is used when it is not possible to install a new system
throughout an organisation all at once. The conversion of files, training of
personnel or arrival of equipment may force the staging of the
implementation over a period of time, ranging from weeks to months. It
allows some users to take advantage of the new system early. Also it
allows training and installation without unnecessary use of resources.

Hardware Acquisitions
Once a decision has been reached to install an in-house computing device,
the next step is to prepare a list of specifications of the proposed system
so that suitable vendors would be invited for meeting the specific
requirements.
The tender specifications are prepared as per norms of approved
feasibility report. Main technical parameters of the various units of the
required hardware objectives of the project and implementation schedule
are also included in the tender specifications. Vendors may also be asked
to quote separately in respect of leasing' and 'buying' options. In addition
to this, the vendors may be required to furnish the details of the
infrastructure which the customer will have to arrange.

Tender Evaluations
It is often seen that requirements as indicated by the customer do not
match with the offer made by individual vendors where the specification
given by the vendors are far below the essential requirements of the
customers, such offers may be rejected straightway from the purview of
short listing. Marginal shortfalls may be considered on merits. However, in
case of additional features in the offers which could be categorised as
'desirable', it becomes necessary to assign appropriate weights to such
features, in order to bring all the bids on equal footing. The additional
features include quantifiable differences are:
 One time costs as well as in the continually running and
maintenance costs.
 Equipment characteristics such as storage capacities, speeds of
various units of computing device.
 In-built spare capacity as well as capability of the system to support
additional peripherals.
 Additional support to be provided by the vendor.
Costing Factor
Cost consideration is quite important factor in computer acquisitions.
Costs are of two types:
(i) One-time costs such as post of site preparation (space, false
ceilings, special floorings, electrical fittings, air- conditioning etc.)
(ii) Continued running and maintenance costs of the entire installations.

Equipment Characteristics
Hardware device which provides higher transfer rates (that is arrange
number of bytes passing between various functional units per unit of
time), or has large storage capacity or in case of printers, if the printed
characters per line are quite high, then such additional characteristics get
entitled to weightage to the extent of their practical utility to the buying
organisation. Appropriate weightage can also be given to such
characteristics as high mean-time-between-failures (MTBF), compatibility
with the equipment, peripherals etc. available in the market

Potential for Growth

Following features can be considered in this category:
 Potentiality of the system to grow beyond the currently specified
capacity by adding on certain components,
 Potentiality of growth within a particular family of computer models,
 Capacity of the system to handle a large variety of peripherals,
 Ability of the system to handle additional workloads after
considering the peak hour load.

Vendor Support
The features to be given weightage under the vendor support include:
 hardware maintenance facilities offered.
 training facilities provided.
 assistance to be provided in software development
 back-up facilities provided by vendor in case of system failure
 comparative delivery periods offered by different vendors.

Service Suppliers
Outside computer services are commonly used by small firms or first time
users. Also called ‘Services’ they include the following:-
1. Computer manufacturers supply services such as system design,
programming, education and training and hardware maintenance.
2. Service bureaus run “bread and butter” applications for small firms.
Larger firms contract for specialised applications or for running jobs
during peak volume periods. The primary services are
programming, file and system conversions, system design and user
training.
3. Facilities management (FM) furnishes specialists to manage a
user installed computer on the users premises. In some cases
service is limited to developing application programs. The user runs
the system but calls on the service organisation for developmental
work and maintenance.
The FM concept has several benefits. The user pays only for the service
rendered. Turnover problems for the user are eliminated when the service
manages the centre. The main drawbacks, however, are loss of control
over the operation, valuerability of information, and the high fees charged
for the service.

Evaluation and Validation

The evaluation phase ranks vendor proposals and determines the one best
suited to the user’s needs. It looks into items such as price, availability,
and technical support. System validation ensures that the vendor can,
infact, match his/her claims, especially system performance. True
validation is verified by having each system demonstrated.

Role of Consultant
For a small firm, an analysis of competitive bids can be confusing. For this
reason, the user may wish to contract on outside consultant to do the job.
Consultants provide expertise and an objective opinion. A recent survey
found, however, that 50 percent of respondent users had an unfavourable
experience with the consultants they hired, and 25 percent said they
would never hire another consultant. With such findings, a decision to use
consultants should be based on careful selection and planning. A rule of
thumb is that the larger the acquisition the more serious should be the
consideration of using professional help.
Although the payoffs from using consulting services can be dramatic, the
costs are also high for many small companies that are exploring system
acquisition, for them, consulting services may be totally out of reach.
During 1984, the average rates of consultants were $600 - $1,800 a day,
not including travel and out-of-pocket expenses.
The past decade has seen the growth of internal management consultant
terms in large organisations as opposed to external consulting teams. The
figure below outlines the cases where an external or internal consultant is
appropriate.
Pros and Cons of Using Consultants

External Consultant Internal Consultant

Full-time internal consultant is not needed or An outside consultant is too costly; internal
is beyond the budget of the organisation. consultants can be much chapter.
Extra help on a project is needed for a short A fast decision necessitates using an internal
time, and internal person cannot afford the consultant.
time.

The internal staff does not possess the An external consultant often does not
expertise or broad knowledge needed for a understand the nature of the internal problem.
specific situation.

The political nature of the problem requires An internal consultant already exists who has
an objective, neutral opinion. an objective and technical understanding.

An outside opinion is desired in addition to An inside opinion is desired in addition to that

that of the internal consultant. of the external consultant.

Criteria for Vendor’s Selection

Mandatory requirement is that, if a vendor fails to meet them, he would be
screened out without any reason. The desirable characteristics would
surely be little bit difficult to evaluate because he may offer several
alternatives in lieu of them. The criteria of vendor selection may be listed
in descending order by importance as below:

Economic Factors
 Cost comparisons
 Return on investment
 Acquisition method

Hardware Factors
 Hardware performance and its reliability
 Facilities for back up facilities
 Provision for back up facilities
 Firmness of delivery data
 Compatibility with existing systems
 Expandability

Software Factors
 Performance of software and its price
 Efficiency and reliability of available software
 Programming languages available
 Availability of well documented package programs
 Firmness of delivery date for a promised software
 Ease of use and modification as per user requirements
 Portability and its capacity to interface with the environment.

Service Factors
 Facilities provided by the manufacturer for detecting errors in the
new programs
 Providing of good training facilities
 Assistance in software development and conversion facilities
provided
 Maintenance terms and quality

Reputation of Manufacturer
 Financial stability
 Past history for keeping promises
Three criteria may have to be further sub-divided particularly for hardware
performance and support services.

Software Selection
Software selection is a critical aspect of system development. As
mentioned earlier, the search starts with the software, followed by the
hardware. There are two ways of acquiring software: custom-made or "off-
the-shelf packages. Today's trend is toward purchasing packages, which
represent roughly 10 percent of what is costs to develop the same in
house. In addition to reduced cost, there are other advantages:
1. A good package can get the system running in a matter of days
rather than the weeks or months required for "home-grown"
packages.
2. MIS personnel are released for other projects.
3. Packages are generally reliable and perform according to stated
documentation.
4. Minimum risks are usually associated with large-scale systems and
programming efforts.
5. Delays in completing software projects in house often occur
because programmers quit 'n midstream.
6. It is difficult to predict the cost of "home-grown" software.
7. The user has a chance of seeing how well the package performs
before purchasing it.
There are drawbacks, however, to software packages:
1. The package may not meet user requirements adequately.
2. Extensive modification of a package usually results in loss of the
vendor support.
3. The methodology for package evaluation and selection is often
poorly defined. The result is a haphazard review based on a faulty
process or questionable selection criteria.
4. For first-time software package users, the overall expectation from
package is often unclear and ill defined.
It can be seen, then, that the quality of a software package cannot be
determined by price alone. A systematic review is crucial.

Criteria for Software Selection

Prior to selecting the software, the project team must set up criteria for
selection. Selection criteria fall into the categories described here.

Reliability

It is the probability that the software will execute for specified time period
without a failure, weighted by the cost to the user of each failure
encountered. It relates to the ease of recovery and ability to give
consistent results. Reliability is particularly important to the profession.

Users

For example, a pharmacist relies on past files on patients when filling

prescriptions. Information accuracy is crucial.
Hardware may become inoperative-because of design errors,
manufacturing errors, or deterioration caused by heat, humidity, friction,
and the like. In contrast, software does not fail or wear out. Any reliability
problems are attributable to errors introduced during the production
process. Furthermore, whereas hardware failure is based lately on random
failures software reliability is based on predestined errors.
Although reliable software is a desirable goal, limited progress has been
made toward improving it in the last decade. The fact of unreliable
software had led to the practice of securing maintenance agreements after
the package is in operation. In a sense, unreliability is rewarded.
Software reliability brings up the concept of modularity, or the ease with
which a package can be modified. This depends on whether the package
was originally designed as a package or was retrofitted after its original
development for single installation use. A package with a high degree
modularity has the capacity to operate in many machine configurations
and perhaps across manufacturers' product lines
With modularity comes expandability, which emphasizes the sensitivity of
a software package to handle an increased volume of transactions or to
integrate with other programs. The following questions should be
considered:
1. Is there room for expanding the master file?
2. How easily can additional fields, records, and files be added?
3. How much of the system becomes unusable when a part of it fails'.
4. Are there errors a user can make that will bring down the system?
5. What are the recovery capabilities?

Functionality
It is a definition of the facilities, performance, and. Other factors that the
user requires in the finished product. All such information comes from the
user. The following are key questions to consider
1. Do the input transactions, files, and reports contain the necessary
data elements?
2. Are all the necessary computations and processing performed
according to specifications?

Capacity

Capacity refers to the capability of the software package to handle the

user's requirements for size of files, number of data elements volume of
transactions and reports, and number of occurrences of data elements. All
limitations should be checked,

Flexibility

It is a measure of the effort required to modify an operational program.

One feature of flexibility is adaptability, which is a measure of the ease of
extending the product.

Usability

This criterion refers to the effort required to operate, prepare the input,
and interpret the output of a program. Additional points to be considered
are portability and understandability. Portability refers to the ability of the
software to be used on different hardware and operating systems.
Understandability means that the purpose of the product is clear to the
evaluator and that the package is clearly and simply written, is free of
jargon, and contains sufficient references to readily available documents
so that the reader can comprehend advanced contents. that the reader
can comprehend advanced contents.

Security

It is a measure of the likelihood that a system's user can accidentally or

intentionally access or destroy unauthorized data. A key question is: How
well can one control access of software or data files? Control provides
system integrity.

Performance

It is a measure of the capacity of the software package to do what it is

expected to do. This criterion focuses on throughput, or how effectively a
package performs under peak loads. Each package should the evaluated
for acceptance on the user's system.
The language in which a package is written and the operating system and
additional performance considerations. If we plan to modify or extend a
package, it is easier if it is written in a language that is commonly known
to programmers. Likewise, if the package runs only under a disk operating
system and the installation is under a full operating system, then either
the package will have to be upgraded to the larger operating system or
the system downgraded to handle the package as is. In either case, the
change could be costly and counterproductive.

Serviceability

This criterion focuses on documentation and vendor support. Complete

documentation is critical for software enhancement. It includes a narrative
description of the system, system logic and logic flowcharts, input-output
and file descriptions and layouts, and operator instructions. Vendor
support assures the user adequate technical support for software
installation, enhancements, and maintenance. The user should determine
how much on-site technical assistance is provided by the vendor,
especially during the first few weeks after the installation.
The user expects on-site training and support as part of most commercial
packages. It is vital to inquire about the amount of training provided. The
user may require training at several levels—clerical, operations,
programming, and management.

Ownership

Who owns the software once it is "sold" to the user? Most of the standard
license agreement forms essentially lease the software to the user for an
indefinite time. The user does not "own" it, which means that the source
code is inaccessible for modification, except by the vendor. Many users
enter into an escrow arrangement whereby the vendor deposits the source
code with a third-party escrow agent who agrees to release the code to
the user if the vendor goes out of business or is unable to perform the
services specified in the license.
In acquiring software, several questions should be asked:

Criterion Meaning

1. Reliability Gives consistent results

2. Functionality Functions to standards

3. Capacity Satisfies volume requirements

4. Flexibility Adapts to changing needs

5. Usability Easy to operate and understand-usually-friendly

6. Security Maintains integrity and prevents unauthorized

access

7. Performance Capacity to deliver as expected

8. Serviceability Good documentation and vendor support

9. Ownership Right to modify and share use of package

10. Minimal costs Affordable for intended application.

1. What rights to the software is the user buying?

2. Can the user sell or modify the software?
3. If the vendor is modifying the package especially for the user, can
the vendor sell it to others within the same industry the user is in?
4. What restrictions are there to copying the software or
documentation?"

Minimal Costs

Cost is a major consideration in deciding between in-house and vendor

software. Cost-conscious users consider the following points:
1. Development and conversion costs.
2. Delivery schedule.
3. Cost and frequency of software modifications.
4. Usable life span of the package.

Design of Input
The input design is the link that ties the information system into the world
of its users.
Input specifications describe the manner in which data enters the system
for processing.

Input design features can ensure the reliability of the system and produce
results from accurate data, or they can result in the production of
erroneous information.
Input design consists of developing specifications and procedures for data
preparation steps necessary to put transaction data into a usable form for
processing data entry, the activity of putting data into the computer for
processing

Objectives of Input Design

Five objectives guiding the design of input focus on

 Controlling the amount of input required

 Avoiding delay

 Avoiding errors in data

 Avoiding extra steps

 Keeping the process simple

Forms Requirements Design
We have learned that data provide the basis for information systems}
Without data there is no system, but data must be provided in the right
form for input and the information produced must be in a format
acceptable to the user. In either case, it is still data-the basic element of a
printed form.

What is a Form?
People read from forms, write on forms, and spend billions of hours
handling forms and filing forms. The data the forms carry come from
people, and the informational output of the system goes to people. So the
form is a tool with a message; it is the physical carrier of data-of
information. It also can constitute authority for action. For example, a
purchase order says BUY, a customer's order says SHIP, and a paycheck
says PAY TO THE ORDER OF. Each form is a request for action. It provides
information for making decisions and improving operations.
With this in mind, it is hard to imagine a business operating without using
forms. They are the vehicles for most communications and the blue-print
for many activities. As important as a printed form is, however, the
majority of forms are designed by poorly trained people. People are
puzzled by confusing forms they ask for directions on how to read them
and how to fill them out. When a form is poorly designed, it is a poor (and
costly) administrative tool.

Classification of Forms
A printed form is generally classified by what it does in the system. There
are three primary classifications: action, memory, and report forms. An
action form requests the user to do something-get action. (Examples are'
purchase orders and shop orders.! A memory form is a record of historical
data that remains in a file, is used for reference, and serves as control on
key details. (Examples are inventory records, purchase records, and bond
registers.! A report form guides supervisors and other administrators in
their activities. It provides data on a project or a job.
 Figure 4.4: Different Types of Forms

Requirements of Forms Design

Forms design follows analyzing forms, evaluating present documents, and
creating new or improved forms. Bear in mind that detailed analysis
occurs only after the problem definition stage and the beginning of
designing the candidate system. Since the purpose of a form is to
communicate effectively through forms design, there are several major
requirements:
1. Identification and wording. The form title must clearly identify its
purpose. Columns and rows should be labeled to avoid confusion. The
form should also be identified by form name or code number to make
it easy to reorder.
2. Maximum readability and use. The form must be easy to use and fill
out. It should be legible, intelligible, and uncomplicated. Ample writing
space must be provided for inserting data. This means analyzing for
adequate space and balancing the overall form’s layout,
administration, and use.
3. Physical factors. The form's composition, color, layout (margins,
space, etc.), and paper stock should lend themselves to easy reading.
Pages should be numbered when multipage reports are being
generated for the user.
4. Order of data items. The data requested should reflect a logical
sequence. Related data should be in adjacent positions. Data copied
from source documents should be in the same sequence on both
forms. Much of this design takes place in the forms analysis phase.
5. Ease of data entry. If used for data entry, the form should have field
positions indicated under each column of data and should have some
indication of where decimal points are (use broken vertical lines).
6. Size and arrangement. The form must be easily stored and filed. It
should provide for signatures. Important items must be in a prominent
location on the form.
7. Use of instructions. The instructions that accompany a form should
clearly show how it is used and handled.
8. Efficiency considerations. The form must be cost effective. This means
eliminating unnecessary data and facilitating reading lines across the
form. To illustrate, if a poorly designed form causes 10 supervisors to
waste 30 seconds each, then 5 minutes are lost because of the form.
If (the firm uses 10,000 of these forms per year, then 833 hours of lost
time could have been saved by a better forms design.
9. Type of report. Forms design should also consider whether the content
is executive summary, intem1ediate managerial information, or-
supporting-data. The user requirements for each type often
detem1ine the final form design.

Form Control
The first step in tonus control is to determine whether a, form is
necessary, Managing the hundreds of tonus in a typical organization
requires a forms control program. Forms control is a procedure for (1)
providing improved and effective forms (2) reducing printing costs, and
(3) securing adequate stock at all times.
The first step in a procedure for forms control is to collect group, index,
stock, and control the tonus of the organization. Each form is identified
and' classified by the function it pelf onus and whether it is a flat form, a
snap-out form, or something else. Once classified, a form is evaluated by
the data it requires, where it is used, and how much it overlaps with other
forms. The object is to get rid of unnecessary tonus and improve those
forms that are necessary.
Before launching a tonus control program, the designer needs to consider
several questions:
1. Who will be responsible for improving tonus design?
2. Should forms be produced in house or assigned10 an outside printer?
3. What quantity should be printed? What is the break-even point on
printing forms?
4. How much lead time is required to replenish forms?
5. How will one handle reorders? Who will initiate them? In what way?
6. How will obsolete forms be handled?
7. What should be the life of the form?
8. Where and how should the forms be stored?
If questions of this nature are not addressed in advance, the organization
is probably not ready to launch a tonus control program.

Input Stages
Several activities have to be carried out as part of the overall input
process. They include some or all of t following:
 data recording (i.e., collection of data at its source):
 data transcription (i.e., transfer of data to an input form);
 data conversion (i.e., conversion of the input data to a computer
acceptable medium);
 data verification (i.e. checking the conversion);
 data control (i.e. checking the accuracy and controlling the flow of the
data to the computer);
 data transmission (i.e. transmitting or transporting the data to the
computer);
 data validation (i.e. checking the input data by a program when it
enters the computer system)
 data correction (i.e. correcting the errors that are found in any of the
earlier stages).

Input Media
Once the input types and their contents have been examined the analyst
can start to think about input devices of which there is a very wide range.
Much careful thought has to be given to the choice of the input media and
devices. Consideration can be given to:
 type of input
 flexibility of format
 speed
 they -accuracy
 verification methods
 rejection rates
 ease of correction
 off-line facilities
 need for specialised documentation
 storage and handling requirements
 automatic features
 hard copy requirements
 security
 ease of use
 environment of data capture
 portability
 compatibility with other systems
 cost

Avoiding Errors in Data

Every effort must be made to ensure that input data remains accurate
from the stage at which it is recorded and documented to the stage at
which it is accepted by the computer. This can only be achieved by careful
control each time data is handled,
The rate at which errors occur depends on the quantity of data, since the
smaller the amount of data to input, of the fewer the opportunities for
errors.
Poor form design can lead to a
 Misunderstanding of the instructions
 Insufficient space to write clearly.
The effectiveness of checking data by verification or sight-checking can
only be assessed by keeping individual records of the preparations of the
input data and 'tracing' errors which are subsequently found by the
computer or even later in the system, back to their source.

CRT Screen Design

Many online data entry devices are CRT screens that provide instant visual
verification of input data and a means of prompting the operator. The
operator can make any changes desired before the data go to the system
for processing. A CRT screen is actually a display station that has a buffer
(memory) for storing data. A common size display is 24 rows of 80
characters each or 1,920 characters.
There are two approaches to designing data on CRT screens: manual and
software utility methods. The manual method uses a work sheet much like
a print layout chart. The menu or data to be displayed are blocked out in
the areas reserved on the chart and then they are incorporated into the
system to formalize data entry. For example, we use dBASE II software
commands to display a menu on the screen. The first command in the
partial program is interpreted by the, system as follows: "Go to row 10 and
column 10 on the screen and display (SAY) the statement typed between
quotes. The same applies to. the next three commands, The command
"WAIT TO A" tells the system to keep the menu on the screen until the
operator types the option next to the word "WAITING,"
The main objective of screen display design is simplicity for accurate and
quick data capture or entry. Other guidelines are:
1. Use the same format throughout the project.
2. Allow ample space for the data. Overcrowding causes eye strain and
may tax the interest of the user.
3. Use easy-to-learn and consistent terms, such as "add," "delete," and
"create."
4. Provide help or tutorial for technical terms or procedures.
The second approach to designing screen layouts is through software
utility, usually provided by the CRT vendor. For example, IBM provides a
Screen Design Aid (SDA) package that allows the designer (at the
terminal) to modify the display components.

Figure 4.5: The CRT Design

In online applications, information is displayed on the screen. The layout

sheet for displayed output is similar to the layout chal1 used for designing
input. Areas for displaying the information are blocked out, leaving the
rest of the screen blank or for system status information. Allowing the user
to review sample screens can be extremely important because the user is
the ultimate judge of the quality of the output and, in turn, the success (or
failure) of the system. For example, the following shows editing output for
a student birth date.
Display: DATE OF BIRTH (mm/dd/yy) 23/19/80
RESPONSE: MONTH EXCEEDS 12
SUGGESTS A RETRY: DATE OF BIRTH (mm/dd/yy)