System Analysis & Design

INDEX
TOPIC PAGE NO.
1. INTRODUCTION TO SYSTEM CONCEPT 2--22
2. GENERAL PHASES OF SDLC 23--57
3. REQUIREMENT AND STRUCTRED ANALYSIS 58--92
4. DATABASE DESIGN AND IMPLEMENTATION 93--126

TECHNIQUE
5. USER INTERFACE DESIGN 127--142
1
INTRODUCTION TO SYSTEMS CONCEPT
Introduction
Scholars in various disciplines who are concerned about the tendency

toward the fragmentation of knowledge and the increasing complexity of
phenomena have sought a unifying approach to knowledge. Ludwig von
Bertalanffy, a biologist, developed a general systems theory that applies to any
arrangement of elements such as cells, people, societies, or even planets.
Norbert Wiener, a mathematician, observed that information and communications
provide 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 design for 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 overlook other equally
important components. General systems theory is concerned with "developing, a
systematic, theoretical framework upon which to make decisions.” It discourage
thinking in vacuum and encourages consideration of all activities of the
organization and its external environment Pioneering 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. so involves a set of techniques that helps in solving problems. .
Definition
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, the
accounting system, the production system, and for over two decades, the
computer system. Similarly, we talk of the business system and of the
organization as a system consisting of interrelated departments (sub systems
such as production, sales, personnel, and an information system. None of these
subsystems is of much use as a single, independent unit. When they are properly
coordinated, however, the firm can work effectively and profitably.
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
2
achieve a specific objective. The word component may refer to physical parts
(engines, wings of aircraft, wheels of a cal'), managerial steps (planning,
organizing, directing, and controlling) 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 of work for the system to achieve the
intended goal. This Orientation requires an orderly grouping of the components
for the design of a successful system.
The study of systems concepts, then, has three basic implications:

1. A system must be designed to achieve a predetermined objective.
2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have a higher priority than the
objectives of its subsystems. For example, computerizing personnel applications
must conform to the organization's policy' on privacy, confidentiality, and security,
as well as making selected data (e.g., pay;' roll available to the accounting
division on request.
CHARACTERISTICS OF SYSTEM
Our definition of a system suggests some characteristics that are present in all
systems. These are
1. Organization (order)
2. Interaction,
3. Interdependence,
4. Integration,
5. Central objective.
1) Organization
Organization implies structure and order. It is the arrangement of compo-
nents that helps to achieve objectives. In the design of a business system, for
example, the Hierarchical relationships starting with the president on top and
leading downward to the blue-coller 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). Like wise, a computer system
is designed around an input device, a central processing unit, an output device,
and one or more storage units. When linked together they work as a whole
system for producing information.
3
2) 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 interact with the 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.
Fig 1-1: Organization Structure
3) Interdependence
Interdependence means that parts of the organization or computer system

depend on one another. They are coordinated and linked together according to a
plan. One subsystem depends on the input of another subsystem for proper
functioning that is; the output of one subsystem is the required input for another
subsystem. This interdependence is crucial in systems work.
To illustrate these system characteristics, Figure 1-2 shows three levels of

subsystems. Each of the top inner circles represents a major subsystem of a
production firm. The personnel subsystem, in turn, may be viewed as a system
that consists of subsystems such as benefits, health and safety, and
employment. Health and safety as a key personnel subsystem consists of lower-
level elements that are considered vital in personnel operation. Each element
4
may be represented by a computer-based package or is part of a human
resource data base that provides information on unemployment, insurance
benefits, and the like.
Fig1-2: Major Subsystems Of Production Dept.
In summary, no subsystem can function. in isolation because it is dependent

on the data (inputs) It receives from other subsystems to perform its required
tasks. Interdependence is further illustrated by the activities and support of
systems analysts, programmers, and the operations staff in a computer center.
5
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.
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. Successful integration will typically
produce a synergistic effect and greater total impact than if each component
works separately.
Central Objective
The last characteristic of a system is its central objective. Objectives 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 operates to achieve
another. The important point is that users must know the central objective of a
computer application early in the analysis for a successful design and
conversion. Later in the book, we will show that political as well as organizational
considerations often cloud the real objective. This means that the analyst must
work around such obstacles to identify the real objective of the proposed change.
ELEMENTS OF A SYSTEM
In most cases, systems analysts operate in a dynamic environment where

change is a way of life. The environment may be a business firm, a business
application, or a computer system. To reconstruct a system, the following key
elements must be considered:
1. Outputs and inputs.
2. Processor(s).
3. Control.
4. Feedback.
5. Environment.
6. Boundaries and interlace.
6
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 (goods, services, or information), it must
be in line with the expectations of the intended user. Inputs are the elements
(material, human resources, information) 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
computer system-that is, specification of the output that the computer is expected
to provide for meeting user requirements. Input and processing design follow
(see Figure 1-3).
Fig 1-3: Inputs and Outputs in a Business Organization
7
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 a system. Processors may
modify the input totally or partially, depending on the specifications of the output.
This means that as the output specifications change, so does the processing. 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

subsystem that controls the pattern of activities governing input, processing, and
output. In an organizational context, management as a decision-making body
controls the inflow, handling, and outflow of activities that affect the welfare of the
business. In a computer system, the operating system and accompanying
software influence the behavior of the system. Output specifications determine
what and how much input is needed to keep the system in balance (see Figure 1-
3)
In systems analysis, knowing the attitudes of the individual who controls the
area for which a computer is being considered can make a difference between
the success and failure of the installation. Management support is required for
securing control and supporting the objective of the proposed change.
Feedback
Control in a dynamic system is achieved by feedback. Feedback
measures output against a standard in some form of cybernetic procedure that
includes communication and control. In Figure 1-3, output information is fed back
to the input and/or to management (controller) for deliberation. After the output is
compared against performance standards, changes can result in the input or
processing and, consequently, the output.
Feedback may be positive or negative, routine or informational. Positive

feedback reinforces the performance of the system. It is routine in nature.
Negative feedback generally provides the controller with information for action. In
systems analysis, feedback is important in different ways. During analysis, the
user may be told that the problems in a given application verify his/her initial
concerns 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.
8
Environment
The environment is the "suprasystem" within which an organization

operates. It is the source of external elements that impinge on the system. In
fact, it often determines how a system must function. As shown in Figure 1-3, the
organization's environment, consisting of vendors, competitors, and others, may
provide constraints and, consequently, influence the actual performance of the
business.
Boundaries and Interface
System should be defined by its boundaries-the limits that identify its

components, processes, and interrelationships when it interfaces with another
system. For example, a teller system in a commercial bank is restricted to the
deposits, withdrawals, and related activities of customers' checking and savings
accounts. It may exclude mortgage foreclosures, trust activities, and the like.
Each system has boundaries that determine its sphere of influence and
control, although in an integrated banking-wide computer system design, a
customer who has a mortgage and a checking account with the same bank may
write a check through the "teller system" to pay the premium that is later
processed by the "mortgage loan system." Recently, system design has been
successful in allowing the automatic transfer of funds from a bank account to pay
bills and other obligations to creditors, regardless of distance or location. This
means that in systems analysis, knowledge of the boundaries of a given system
is crucial in determining the nature of its interface with other systems for
successful design.
TYPES OF SYSTIMS
The frame of reference within which one views a system is related to the use of
the systems approach for analysis. Systems have been classified in different
ways. Common classifications are:
1. Physical or abstract,
2. open or closed,
3.”Man-made" information systems.
9
Physical or Abstract Systems
Physical systems are tangible entities that may be static or dynamic in

operation. For example, the physical parts of the computer center are the offices,
desks, and chairs that facilitate operation of the computer. They can be seen and
counted; they are static. In contrast; a programmed computer is a dynamic
system. Data, programs, output, and applications change as the user's demands
or the priority of the information requested changes.
Abstract systems are conceptual or nonphysical entities. They may be as

straightforward as formulas of relationships among sets of variables or models-
the abstract conceptualization of physical situations. A model is a representation
of a real or a planned 'System. The use of models makes it easier for the analyst
to visualize relationships in the system under study. The objective is to point out.
The significant elements and the key interrelationships of a complex system.
Systems Models
In no field are models used more widely and with greater variety than in
systems analysis. The analyst begins by creating a model of the reality (facts,
relationships, procedures, etc.) with which the system is concerned. Every
computer system deals with the real world, a problem area, or a reality outside
itself. For example, a telephone switching system is made up of subscribers,
telephone handsets, dialing, conference calls, and the like. The analyst begins by
modeling this reality before considering the functions that the system is to
perform.
Various business system models are
1. Schematic Models,
2. Flow Models,
3. Static Models,
4. Dynamic system models.
Schematic Models.
A schematic model is a two-dimensional chart depicting system elements
and their linkages.
Flow System Models.

A flow system model shows the flow of the material, energy, and
information that hold the system together. There is an. orderly flow of logic in
such models. A widely known example is PERT (Program Evaluation and Review
Technique) It is used to abstract a real world system in mo el form, manipulate
specific values to determine the critical path, interpret the relationships, and relay
them back as a control. The probability of completion within a time period is
considered in connection with time, resources, and performance specification.
10
Fig 1-4: PERT Example.
Static System Models.

This type of model exhibits one pair of relationships such as activity-time
or cost-quantity.
Dynamic System Modals.

Business organizations are dynamic systems. A dynamic/model
approximates the type of organization or applications that analysts deal with. It
depicts an ongoing, constantly changing system. As mentioned earlier, it consists
of (1) inputs that enter the system, (2) the processor through which
transformation takes place, (3) the program(s) required for processing, and (4)
the output(s) that result from processing (see figure 1-3).
Open or Closed Systems

Another classification of systems is based on their degree of
independence An open system has many interfaces with its environment. It
permits interaction across its boundary; it receives inputs from and delivers
outputs to the outside. An information system falls into this category, since it
must adapt to the changing demands of the user. In -contrast, a closed system is
isolated from environment8I influences. In reality, a completely closed system is
rare. In systems analysis, organizations, applications, arid computers are
invariably open, dynamic systems influenced by their environment.
11
A focus on the characteristics of an open system is particularly timely in
the light of present -day business concerns with computer fraud, invasion of
privacy, security controls, and ethics in computing. Whereas the technical
aspects of systems analysis deal with internal routines within the user's
application area, systems analysis as an open system tends to expand the scope
of analysis to relationships between the user area and other users, and to
environmental factors that must be considered before a new system is finally
approved. Furthermore, being open to suggestions implies that the analyst has to
be flexible and the system being designed has to be responsive to the changing
needs of the user and the environment.
Five important characteristics of open systems can be identified.

1. Input from outside. Open systems are self-adjusting and self-regulating,
When functioning properly, an open system reaches a steady state or
equilibrium. In a retail firm, for example, a steady state exists when goods are
purchased and sold without being either out of stock or overstocked. An
increase in the cost of goods forces a comparable increase in prices or
decrease in operating costs. This response gives the firm its steady state.
2. Entropy. All dynamic systems tend to run down over time, resulting in entropy
Or loss of energy. Open systems resist entropy by seeking new inputs or
modifying the processes to return to a steady state. In our example, no reaction
to increase in cost of merchandise makes the business unprofitable which could
force it into insolvency-a state of disorganization.
3. Process, output, and cycles. Open systems produce useful output and
operate in cycles, following a continuous flow path.
4. Differentiation. Open systems have a tendency toward an increasing

specialization of functions and a greater differentiation of their components. In
business, the roles of people and machines tend toward greater specialization
and greater interaction. This characteristic offers a compelling reason for the
increasing value of the concept of systems in the systems analyst's thinking.
5. Equifinality. The term implies that goals are achieved through differing
courses of action and a variety of paths. In most systems, there is more of a
consensus on goals than on paths to reach the goals.
Understanding system characteristics helps analysts to identify their role and

relate their activities to the attainment of the firm's objectives as they undertake a
system project. Analysts are themselves part of the organization. They have
opportunities to adapt the organization to changes through computerized
applications so that the system does not "run down." A key to this process is
information feed hack from the prime user the new system as well as from top
management.
12
Man-Made Information Systems
Ideally, information reduces uncertainty about a state or event. For

example, information that the wind is calm reduces the uncertainty that the boat
trip will 1m pleasant. An information system is the basis for interaction between
user and the analyst. It provides instructions. commands. an feedback. It
determines the nature of the relationships among decision making. In fact, it may
he viewed as a decision center for personnel at all levels. From this has is, an
information system may he 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. In
systems analysis, it is important to keep in mind that considering an alternative
system means improving one or more of these criteria.
Many practitioners fail to recognize that a business has several informa-

tion systems; each is designed for a purpose and works to accommodate data
flow, communications, decision making, control, and effectiveness. The major
information systems are formal, informal, and computer based.
Formal Information Systems

A formal information system is based on the organization represented by
the organization chart. The chart is a map of positions and their authority
relationships, indicated by boxes and connected by straight lines. It is concerned
with the pattern of authority, communication, and work flow. Information is
formally disseminated in instructions, memos, or reports from top management to
the intended user in organization. This structure also allows feedback up the
chain of command for follow-up. In Figure 1-1 input from the environment
provides impetus for policy decisions by top management. Policies are
generalizations that specify what an organization ought to do. Policies are
translated into directives, rules, and regulations and transmitted to lower-level
management for implementation. The output represents employee performance.
Categories of Information. There are three categories of information related

to managerial levels and the decisions managers make .The first level is strategic
information, which relates to long-range planning policies that are of direct
interest to upper management. Information such as population growth, trends in
financial investment, and human resources changes would be of interest to top
company officials who are responsible for developing policies and determining
long-range goals. This type of information is achieved with the aid of decision
support systems (DSS).
The second level of information is managerial information. It is of direct use to

middle management and department heads for implementation and control.
Examples are sales analysis, cash flow projections, and annual financial
statements. This information is of use in short- and intermediate range planning-
13
that is, months rather than years. It is maintained with the aid of management
information systems (MIS).
The third information level is operational information, which is short-term, daily

information used to operate departments and enforce the day to-day rules and
regulations of the business. Examples are daily employee absence sheets,
overdue purchase orders, and current stocks available foil sale. Operational
information is established by data processing systems (OPS). (Fig: 1-5)
Fig: 1-5 : Management and Information Levels in a Organization.
The nature of the information and managerial levels is also related to the major
types of decision making: structured and unstructured decision making. An
organizational process that is closed, stable, and mechanistic tends to be more
structured, computational, and relies on routine decision making for planning and
control. Such decision making is related to lower level management and is
readily supported with computer systems. In contrast, open, adaptive, dynamic
processes increase the uncertainty associated with decision making and are
generally evidenced by a lack of structure in the decision-making process. Lack
of structure as well as extra organizational and incomplete information makes it
difficult to secure computer support. Table 1-1 summarizes the characteristics of
decision making and the information required at different managerial levels.
Therefore, in designing an information system, the analyst needs to determine

the type of information needed, the level of the information, how it is structured,
and in what format it is before deciding on the system needed to produce it. This
is another reason for having a background in systems theory and organizations.
14
Table 1-1: Information required at various Managerial Levels
Informal Information Systems
The formal information system is a power structure designed to achieve

company goals. An organization's emphasis on control to ensure performance
tends to restrict the communication flow among employees, however. As a result,
an informal information system develops. It is-an employee based system
designed to meet personnel and vocational needs and to help solve, work-related
problems. It also funnels information upward through indirect channels. In this
respect, it is a useful system because it works within the framework of the
business and its stated policies.
In doing a systems study, the analyst should have knowledge of the chain of
command, the power-authority-influence network, and how decisions are made
to get a feel for how much support can be expected for prospective installation.
Furthermore, knowledge about the inner workings of the employee-based system
is useful during the exploratory phase of analysis. Employee cooperation and
participation are crucial in preventing sabotage and training users. Since
computers cannot provide reliable information without user staff support, a proper
interlace with the informal communication channels could mean the difference
between the success and failure of new systems.
Computer-Based information Systems
A third class of information system relies on the computer for handling

business applications. The computer is now a required source of information.
Systems analysis relies heavily on computers for problem solving. This suggests
15
that the analyst must be familiar with computer technology and have experience
in handling people in an organizational context.
Management Information Systems (MIS).
The computer has had a significant impact on the techniques used by

management to operate a business. The level of the manager in the organization
is also a factor in
Determining the kind of information needed to solve problem Lower-level
management needs detailed internal information to make day-to-day, relatively
structured control decisions. Higher-level management, for whom long-range
objectives are the primary concerns, requires summarized information from a
variety of sources to attain goals. In either case, management action is based on
information that is accurate, relevant, complete, concise, and timely. MIS has
been successful in meeting these information criteria quickly and responsively.
MIS is a person-machine system and a highly integrated grouping of

information-processing functions designed to provide management with a
comprehensive picture of specific operations. It is actually a combination of
information systems;-To do the job, it should operate in real time, handling
inquiries as quickly as they are received. Management information must also be
available early enough to affect a decision. Operationally, MIS should provide for
file definition, file maintenance and updating, transaction and inquiry processing,
and one or more data bases linked to an organizational data base. Within MIS,
a single transaction can simultaneously update all related data files in the
system. In so doing, data redundancy (duplication) and the time it takes to
duplicate data are kept to a minimum, thus insuring that data are kept current at
all times.
A key element of MIS is the data base a non redundant collection of

interrelated data items that can be processed through application programs and
available to many users. All records must be related in some way. Sharing
common data means that many programs can use the same files or records,
Information is accessed through a data base management system (DBMS)' It is
a part of the software that handles virtually every activity involving the physical
data base.
There are several advantages to a data base system:
1. Processing time and the number of programs written are substantially

reduced.
2. All applications share centralized files.
3. Storage space duplication is eliminated.
16
4. Data are stored once in the data base and are easily accessible when needed.
The two primary drawbacks of a data base are the cost of specialized
personnel and the need to protect sensitive data from unauthorized access.
The primary users of MIS are middle and top management, operational
managers,- and support staff. Middle and top management use MIS for preparing
forecasts, special, requests for analysis, long-range plans, and periodic reports.
Operational managers use MIS primarily for short-range planning and periodic
and exception reports. The support staff finds MIS useful for the special analysis
of information and reports to help management in planning and control. Providing
data for use in MIS is the function of most levels of personnel in the organization.
Once entered into the system, the information is no longer owned by the initiating
user but becomes available to all authorized users.
Today's typical MIS poses several problems. Most MIS reports are his-
torical and tend to be dated. Another problem is that many installations have data
bases that are not in line with user requirements. This means that many MIS
environments have not been congruent with the real world of the user. Finally, an
inadequate or incomplete update of the data base jeopardizes the reliability for all
users.
A major problem encountered in MIS design is obtaining the acceptance

and support of those who will interface with the system. Personnel who perceive
that their jobs are threatened may resist the implementation of MIS. In
understanding both technology and human behavior, the analyst faces the
challenge of selling change to the right people for a successful installation.
Decision Support Systems (DSS)
One reason cited in the literature for management's frustration with MIS is the
limited support it provides top management for decision making. DSS- advances
the capabilities of MIS. It assists management in making decisions. It is actually a
continually evolving model that relies heavily on operations research.
Since Gorry and Morton coined the term decision support system (DDS) in their
seminal article, the literature has been bursting with controversy. The origin of
the term is simple:
Decision--emphasizes decision making in problem situations, not information

processing, retrieval, or reporting.
Support--requires computer-adided decision situations with enough "structure" to

permit computer support.
17
System--accentuates the integrated nature of problem solving, suggesting a
combined "man," machine, and decision environment.
Fig 1-6 :Decision Making Process
Beginning with management decision systems in the early 1970s, the

concept of interactive computer based systems supporting unstructured decision
making has been expanded to include everything but transaction processing
systems. A typical early definition required an interactive computer-based system
to help users use data and models to solve unstructured problems. There are
authors today who view DSS as an extension of MIS, DSS as independent of
MIS, or MIS as a subset of DSS. The commonly accepted view in the literature
views DSS as a second-generation MIS. MIS is generated when we add
predefined managerial reports that are spun out of the transaction processing,
report generation, and online inquiry capabilities-all integrated with a given
functions area such as production MIS or personnel MIS. DSS - results from
adding external data sources, accounting and statistical models, and interactive
query capabilities. The outcome is a system designed to serve all levels of
management, and top management in particular, in dealing with "what if"
unstructured problem situations. It is a system with the intrinsic capability to
support ad hoc data analysis as well as decision-modeling activities.
The field of DSS is young and evolving. The analyst's present role is to look at
existing DSS packages, their attributes, capabilities, and design considerations,
consider how they differ from MIS design, and learns more about the
methodology needed to provide a proper fit between DSS as a future-oriented
system and management requirements for various levels of decision making.
Since DSS appears to be the wave of the future (evidenced by the surge of DSS
software packages and the technology that supports them), systems analysts will
need to upgrade their knowledge to meet the changing demands of users and
organizations alike.
18
Herbert Simon described decision making as a three phases continuous
process model beginning with intelligence and moving toward design choice. The
process is invoked by the recognition of a problem. The resulting decision is then
directed as solving the problem.
The intelligence phase of decision making involves the awareness of a

problem at symptomatic level; it requires a closer look at the problem and a
thorough evaluation of the variables and their relationships. For example, the
symptom of a problem is a large number of auto accidents, but the actual cause
of the problem turns out to be that the state discontinued auto inspections,
lowered the minimum drinking age, has an inadequate police force, or a
combination of all these factors. The more intelligence management has about
the cause of a problem; the better is the likelihood of designing a good decision.
A DSS can provide intelligence through information retrieval and statistical
packages.
The design phase of decision making focuses on the evaluation of decision

alternatives. During this phase, computer-based deterministic or stochastic
models may be used for decision design. DSS plays a major role in decision
design under uncertainty. The output of the model(s) is the basis for the choice
phase of decision making.
Transaction Processing Systems
The most fundamental computer-based system in an organization pertains

to the processing of business transactions. Transaction processing systems
(TPS) are aimed at improving the routine business activities on which all
organizations depend. A transaction is any event or activity that affects the
organization. Common transactions include placing orders, billing customers,
hiring employees, and depositing checks. The types of transactions that occur
vary from organization to organization. However, virtually all firms process
transactions as a major part of their daily business activities. The most
successful firms carry out this work in an orderly and efficient manner.
Transaction processing, the set of procedures for handling the transactions,

often includes these activities:
Calculation
Storage and retrieval
Classification
Summarization
Sorting
19
Studying a sample of organizations will show that similar characteristics exist in
each firm:
1. There is a high volume of transactions.
2. Each transaction is similar.
3. The procedures for processing the transaction are well understood and can be
described in detail.
4. Few exceptions to the normal procedures occur.
These characteristics allow routines to be established for handling the

transactions. The routines describe what to look for in each transaction, what
steps to take and procedures to follow, and what to do when exceptions occur.
Transaction processing procedures are often called standard operating
procedures.
The routines associated with general banking transactions typify the use
of standard operating procedures for the handling of deposits and withdrawals,
cashing of checks, and other processes.
Automated teller systems allow the teller to use a computer terminal to

enter details of the transaction while the customer is at the bank window. The
procedures are built into the computer software that runs the system. Similarly,
when customers make withdrawals at automated teller machines, the software
used to operate the system ensures that the proper procedure is followed:
CUSTOMERACTIVITY SYSTEM ACTIVITY
Enter account number. Verify that account number is

acceptable.
Enter password. Verify that password is valid for

account.
Enter withdrawal amount. Verify that amount is within limits set

by the bank.
Verify that amount is within

account balance.
Record transaction in ledger.
Dispense money.
20
Issue receipt for transaction.
Remove receipt and money. Prepare for next transaction.
This activity will be repeated many times in a single day at most automated teller
machines.
The high volume of well-understood transactions associated with the

operating level of an organization, as well as the ability for managers to develop
specific procedures for handling them, often leads to the implementation of
computer assistance. Most firms begin to seek computer assistance because of
the need to develop more effective and efficient ways to process transaction
data. (This is as true for small organizations as it is for large firms.) The
procedures are embedded in computer programs that control the entry of data,
processing of details, and storage and presentation of data and information.
Transaction processing systems provide speed and accuracy, and can be
programmed to follow routines without any variance. Systems analysts design
the systems and the processes to handle activities such as the banking activities
discussed in this example.
21
GENERAL PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE
The systems development life cycle (SDLC) is a conceptual model used in

system development that describes the stages involved in an information system
development project, from an initial feasibility study through maintenance of the
completed application.
SDLC is the Nine Phases Process. Phases are
1 Initiation Phase
2 System Concept Development Phase
3 Planning Phase
4 Requirements Analysis Phase
5 Design Phase
6 Development Phase
7 Integration and Test Phase
8 Implementation Phase
9 Operations and Maintenance Phase
1 Initiation Phase
The Initiation Phase begins when management determines that it is necessary to

enhance a business process through the application of information technology.
The purposes of the Initiation Phase are to:
Identify and validate an opportunity to improve business accomplishments

of the organization or a deficiency related to a business need,
Identify significant assumptions and constraints on solutions to that need,
and
Recommend the exploration of alternative concepts and methods to
satisfy the need.
IT projects may be initiated as a result of business process improvement

activities, changes in business functions, advances in information technology, or
22
may arise from external sources, such as public law, the general public or
state/local agencies. The Project Sponsor articulates this need within the
organization to initiate the project life cycle. During this phase, a Project Manager
is appointed who prepares a Statement of Need or Concept Proposal. When an
opportunity to improve business/mission accomplishments or to address a
deficiency is identified, the Project Manager documents these opportunities in the
Concept Proposal.
TASKS AND ACTIVITIES
The following activities are performed as part of the Initiation Phase. The
results of these activities are captured in the Concept Proposal. For every IT
project, the agency should designate a responsible organization and assign that
organization sufficient resource to execute the project.
1. Identify the Opportunity to Improve Business Functions
Identify why a business process is necessary and what business benefits

can be expected by implementing this improvement. A business scenario and
context must be established in which a business problem is clearly expressed in
purely business terms. Provide background information at a level of detail
sufficient to familiarize senior managers to the history, issues and customer
service opportunities that can be realized through improvements to business
processes with the potential support of IT. This background information must not
offer or predetermine any specific automated solution, tool, or product.
2. Identify a Project Sponsor
The Project Sponsor is the principle authority on matters regarding the

expression of business needs, the interpretation of functional requirements
language, and the mediation of issues regarding the priority, scope and domain
of business requirement.
3. Form (or appoint) a Project Organization
This activity involves the appointment of a project manager who carries

both the responsibility and accountability for project execution. For small efforts,
this may only involve assigning a project to a manager within an existing
organization that already has an inherent support structure. For new, major
projects, a completely new organizational element may be formed - requiring the
hiring and reassignment of many technical and business specialists.
Each project shall have an individual designated to lead the effort. The
individual selected will have appropriate skills, experience, credibility, and
availability to lead the project. Clearly defined authority and responsibility must
be provided to the Project Manager.
23
4. Document the Phase Efforts
The results of the phase efforts are documented in the Concept Proposal.
5. Review and Approval to Proceed
The approval of the Concept Proposal identifies the end of the Initiation
Phase.
ROLES AND RESPONSIBILITIES
Project Manager.
The appointed project manager is charged with leading the efforts to

ensure that all business aspects of the process improvement effort are identified
in the Concept Proposal. This includes establishing detailed project plans and
schedules.
2. System Concept Development Phase
System Concept Development begins when the Concept Proposal has

been formally approved and requires study and analysis that may lead to system
development activities.
The review and approval of the Concept Proposal begins the formal
studies and analysis of the need in the System Concept Development Phase and
begins the life cycle of an identifiable project.
1. Study and Analyze the Business Need
The project team, supplemented by enterprise architecture or other

technical experts, if needed, should analyze all feasible technical, business
process, and commercial alternatives to meeting the business need. These
alternatives should then be analyzed from a life cycle cost perspective. The
results of these studies should show a range of feasible alternatives based on life
cycle cost, technical capability, and scheduled availability. Typically, these
studies should narrow the system technical approaches to only a few potential,
desirable solutions that should proceed into the subsequent life cycle phases.
2. Plan the Project
The project team should develop high-level (baseline) schedule, cost, and
performance measures which are summarized in the System Boundary
Document. These high-level estimates are further refined in subsequent phases.
24
3. Form the Project Acquisition Strategy
The acquisition strategy should be included in the SBD. The project team
should determine the strategies to be used during the remainder of the project
concurrently with the development of the CBA and Feasibility Study. Will the
work be accomplished with available staff or do contractors need to be hired?
Discuss available and projected technologies, such as reuse or Commercial Off-
the-Shelf and potential contract types.
4. Study and Analyze the Risks
Identify any programmatic or technical risks. The risks associated with

further development should also be studied. The results of these assessments
should be summarized in the SBD and documented in the Risk Management
Plan and CBA.
5. Obtain Project Funding, Staff and Resources
Estimate, justify, submit requests for, and obtain resources to execute the
project in the format of the Capital Asset Plan and Justification.
6. Document the Phase Efforts
The results of the phase efforts are documented in the System Boundary
Document, Cost Benefit Analysis, Feasibility Study, and Risk Management Plan.
7. Review and Approval to Proceed
The results of the phase efforts are presented to project stakeholders and
decision makers together with a recommendation to (1) proceed into the next life-
cycle phase, (2) continue additional conceptual phase activities, or (3) terminate
the project. The emphasis of the review should be on (1) the successful
accomplishment of the phase objectives, (2) the plans for the next life-cycle
phase, and (3) the risks associated with moving into the next life-cycle phase.
The review also addresses the availability of resources to execute the
subsequent life-cycle phases. The results of the review should be documented
reflecting the decision on the recommended action.
Project Manager:
The appointed project manager is charged with leading the efforts to accomplish
the System Concept Development Phase tasks discussed above. The Project
Manager is also responsible for reviewing the deliverables for accuracy,
approving deliverables and providing status reports to management.
25
Component. Chief Information Officer (CIO) and Executive Review Board
(ERB):
The CIO/ERB approves the Systems Boundary Document. Approval allows the
project to enter the Planning Phase.
3 Planning Phase
Many of the plans essential to the success of the entire project are created
in this phase; the created plans are then reviewed and updated throughout the
remaining SDLC phases. In the Planning Phase, the concept is further developed
to describe how the business will operate once the approved system is
implemented and to assess how the system will impact employee and customer
privacy. To ensure the products and/or services provide the required capability
on-time and within budget, project resources, activities, schedules, tools, and
reviews are defined. Additionally, security certification and accreditation activities
begin with identification of system security requirements and the completion of a
high-level vulnerability assessment.
The following tasks are performed as part of the Planning Phase. The
results of these activities are captured in various project plans and solicitation
documents.
1. Refine Acquisition Strategy in System Boundary Document
Refine the role of system development contractors during the subsequent

phases. For example, one strategy option would include active participation of
system contractors in the Requirements Analysis Phase. In this case, the
Planning Phase must include complete planning, solicitation preparation, and
source selection of the participating contractors (awarding the actual contract
may be the first activity of the next phase). If contractors will be used to complete
the required documents, up-front acquisition planning is essential.
2. Analyze Project Schedule
Analyze and refine the project schedule, taking into account risks and
resource availability. Develop a detailed schedule for the Requirements Analysis
Phase and subsequent phases.
26
3. Create Internal Processes
Create, gather, adapt, and/or adopt the internal management,

engineering, business management, and contract management internal
processes that will be used by the project office for all subsequent life-cycle
phases. This could result in the establishment of teams or working groups for
specific tasks, (e.g., quality assurance, configuration management, changes
control). Plan, articulate, and gain approval for the resulting processes.
4. Staff Project Office
Further staff the project office with needed skills across the broad range of
technical and business disciplines. Select Technical Review Board members and
document roles and responsibilities. If needed, solicit and award support
contracts to provide needed non-personal services that are not available through
agency resources.
5. Establish Agreements with Stakeholders
Establish relationships and agreements with internal and external

organizations that will be involved with the project. These organizations may
include agency and DOJ oversight offices, agency personnel offices, agency
finance offices, internal and external audit organizations, and agency resource
providers (people, space, office equipment, communications, etc).
6. Develop the Project Management Plan
Plan, articulate and gain approval of the strategy to execute the

management aspects of the project (Project Management Plan). Develop a
detailed project work breakdown structure.
7. Develop the Systems Engineering Management Plan
Plan, articulate, and gain approval of the strategy to execute the technical
management aspects of the project (SEMP). Develop a detailed system work
breakdown structure.
8. Review Feasibility of System Alternatives
Review and validate the feasibility of the system alternatives developed

during the previous phase (CBA, Feasibility Study). Confirm the continued
validity of the need (SBD).
9. Study and Analyze Security Implications
27
Study and analyze the security implications of the technical alternatives
and ensure the alternatives address all aspects or constraints imposed by
security requirements (System Security Plan).
10. Plan the Solicitation, Selection and Award
During this phase or subsequent phases, as required by the Federal

Acquisition Regulation (FAR), plan the solicitation, selection and award of
contracted efforts based on the selected strategies in the SBD. Obtain approvals
to contract from appropriate authorities (Acquisition Plan). As appropriate,
execute the solicitation and selection of support and system contractors for the
subsequent phases.
11. Develop the CONOPS
Based on the system alternatives and with inputs from the end-user
community, develop the concepts of how the system will be used, operated, and
maintained. This is the Concept of Operations.
12. Revise Previous Documentation
Review previous phase documents and update if necessary.
Project Manager. The project manager is responsible and accountable

for the successful execution of the Planning Phase. The project manager
is responsible for leading the team that accomplishes the tasks shown
above. The project manager is also responsible for reviewing deliverables
for accuracy, approving deliverables, and providing status reports to
management.
Project Team. The project team members (regardless of the organization

of permanent assignment) are responsible for accomplishing assigned
tasks as directed by the project manager.
Contracting Officer. The contracting officer is responsible and
accountable for the procurement activities and signs contract awards.
Oversight Activities. Agency oversight activities, including the IRM office,
provide advice and counsel to the project manager on the conduct and
requirements of the planning effort. Additionally, oversight activities
provide information, judgments, and recommendations to the agency
decision makers during project reviews and in support of project decision
milestones.
28
4 Requirements Analysis Phase
The Requirements Analysis Phase will begin when the previous phase
documentation has been approved or by management direction. Documentation
related to user requirements from the Planning Phase shall be used as the basis
for further user needs analysis and the development of detailed user
requirements. The analysis may reveal new insights into the overall information
systems requirements, and, in such instances, all deliverables should be revised
to reflect this analysis.
During the Requirements Analysis Phase, the system shall be defined in

more detail with regard to system inputs, processes, outputs, and interfaces. This
definition process occurs at the functional level. The system shall be described in
terms of the functions to be performed, not in terms of computer programs, files,
and data streams. The emphasis in this phase is on determining what functions
must be performed rather than how to perform those functions.
The following tasks are performed during the Requirements Analysis Phase.
1 Analyze and Document Requirements.
Include all possible requirements including those for:
functional and capability specifications, including performance, physical

characteristics, and environmental conditions under which the software
item is to perform;
interfaces external to the software item;
qualification requirements
safety specifications, including those related to methods of operation and
maintenance, environmental influences, and personnel injury;
security specifications, including those related to compromise of sensitive
information
human-factors engineering (ergonomics), including those related to
manual operations, human-equipment interactions,
constraints on personnel, and areas needed concentrated human
attention, that are sensitive to human errors and training
data definition and database requirements;
installation and acceptance requirements of the delivered software product
at the operation and maintenance site(s)
user documentation
user operation and execution requirements
user maintenance requirements
29
2 Develop Test Criteria and Plans
Establish the test criteria and begin test planning. Include all areas where
testing will take place and who is responsible for the testing. Identify the testing
environment, what tests will be performed, test procedures; and traceability back
to the requirements.
3 Develop an Interface Control Document
The project team responsible for the development of this system needs to
articulate the other systems (if any) this system will interface with. Identify any
interfaces and the exchange of data or functionality that occurs. All areas that
connect need to be documented for security as well as information flow
purposes.
4 Conduct Functional Review
The Functional and Data Requirements Review is conducted in the

Requirements Analysis Phase by the technical review board.
5 Revise Previous Documentation
Review and update previous phase documentation if necessary before

moving to the next phase.
Project Manager.
The project manager is responsible and accountable for the successful

execution of the Requirements Analysis Phase. The project manager is
responsible for leading the team that accomplishes the tasks shown above.
The Project Manager is also responsible for reviewing deliverables for
accuracy, approving deliverables and providing status reports to managers.
Technical Review Board.
Formally established board that examines the functional requirements

documented in the FRD for accuracy, completeness, clarity, attainability, and
traceability to the high-level requirements identified in the Concept of
Operations.
Project Team.
30
The project team members (regardless of the organization of permanent
assignment) are responsible for accomplishing assigned tasks as directed by
the project manager.
Contracting Officer.
The contracting officer is responsible and accountable for the procurement

activities and signs contract awards.
5 Design Phase
The objective of the Design Phase is to transform the detailed, defined

requirements into complete, detailed specifications for the system to guide the
work of the Development Phase. The decisions made in this phase address, in
detail, how the system will meet the defined functional, physical, interface, and
data requirements. Design Phase activities may be conducted in an iterative
fashion, producing first a general system design that emphasizes the functional
features of the system, then a more detailed system design that expands the
general design by providing all the technical detail.
The following tasks are performed during the Design Phase.
1 Establish the Application Environment
Identify/specify the target, the development and the design and testing
environment. How and where will the application reside. Describe the
architecture where this application will be developed and tested and who is
responsible for this activity.
2 Design the Application
In the system design, first the general system characteristics are defined.
The data storage and access for the database layer need to be designed. The
user interface at the desktop layer needs to be designed. The business rules
layer or the application logic needs to be designed.
Establish a top-level architecture of the system and document it. The

architecture shall identify items of hardware, software, and manual-operations.
All the system requirements should be allocated among the hardware
configuration items, software configuration items, and manual operations.
Transform the requirements for the software item into an architecture that
describes its top-level structure and identifies the software components. Ensure
that all the requirements for the software item are allocated to its software
31
components and further refined to facilitate detailed design. Develop and
document a top-level design for the interfaces external to the software item and
between the software components of the software item.
3 Develop Maintenance Manual
Develop the maintenance manual to ensure continued operation of the

system once it is completed.
4 Develop Operations Manual
Develop the Operations Manual for mainframe systems/applications and

the System Administration Manual for client/server systems/applications.
5 Conduct Preliminary Design Review
This is an ongoing interim review of the system design as it evolves

through the Design Phase. This review determines whether the initial design
concept is consistent with the overall architecture and satisfies the functional,
security, and technical requirements in the Functional Requirements Document.
6 Design Human Performance Support (Training)
Identify the users and how they will be trained on the new system. Be sure
to address the Americans with Disabilities Act (ADA) requirements to ensure
equal access to all individuals.
7 Design Conversion/Migration/Transition Strategies
If current information needs to be converted/migrated/transitioned to the

new system, plans need to be designed for those purposes, especially if
converting means re-engineering existing processes.
8 Conduct a Security Risk Assessment
Conduct a security risk assessment by addressing the following

components: assets, threats, vulnerabilities, likelihood, consequences and
safeguards. The risk assessment evaluates compliance with baseline security
requirements, identifies threats and vulnerabilities, and assesses alternatives for
mitigating or accepting residual risks.
9 Conduct Critical Design Review
The Project Manager and System Proponent conduct the critical design
review and approve/disapprove the project into the Development Phase. This
review is conducted at the end of the Design Phase and verifies that the final
32
system design adequately addresses all functional, security, and technical
requirements and is consistent with the overall architecture.
Review documents from the previous phases and assess the need to revise
them during the Design Phase. The updates should by signed off by the Project
Manager.
Project Manager.

execution of the Design Phase. The project manager is responsible for
leading the team that accomplishes the tasks shown above. The Project
Manager is also responsible for reviewing deliverables for accuracy,
Project Team.

The contracting officer is responsible and accountable for procurement

Oversight Activities.
Agency oversight activities, including the IRM office, provide advice and
counsel to the project manager on the conduct and requirements of the
Design Phase. Additionally, oversight activities provide information,
judgments, and recommendations to the agency decision makers during
project reviews and in support of project decision milestones.
6 Development Phase
The objective of the Development Phase will be to convert the

deliverables of the Design Phase into a complete information system. Although
much of the activity in the Development Phase addresses the computer
programs that make up the system, this phase also puts in place the hardware,
software, and communications environment for the system and other important
elements of the overall system.
33
The activities of this phase translate the system design produced in the Design
Phase into a working information system capable of addressing the information
system requirements. The development phase contains activities for building the
system, testing the system, and conducting functional qualification testing, to
ensure the system functional processes satisfy the functional process
requirements in the Functional Requirements Document (FRD). At the end of this
phase, the system will be ready for the activities of the Integration and Test
Phase.
1 Code and Test Software
Code each module according to established standards.
2 Integrate Software
Integrate the software units, components and modules. Integrate the

software units and software components and test in accordance with the
integration plan. Ensure that each module satisfies the requirements of the
software at the conclusion of the integration activity.
3 Conduct Software Qualification Testing.
Conduct qualification testing in accordance with the qualification requirements

for the software item. Ensure that the implementation of each software
requirement is tested for compliance. Support audit(s) which could be conducted
to ensure that:
As-coded software products (such as software item) reflect the design

documentation
The acceptance review and testing requirements prescribed by the
documentation are adequate for the acceptance of the software products
Test data comply with the specification
Software products were successfully tested and meet their specifications
Test reports are correct and discrepancies between actual and expected
results have been resolved
User documentation complies with standards as specified
4 Integrate System
Integrate the software configuration items with hardware configuration

items, manual operations, and other systems as necessary, into the system. The
aggregates shall be tested, as they are developed, against their requirements.
5 Conduct System Qualification Testing.
34
Conduct system qualification testing in accordance with the qualification
requirements specified for the system.
6 Install Software
Install the software product in the target environment as designed and in

accordance with the Installation Plan. The resources and information necessary
to install the software product shall be determined and be available.
7 Document Software Acceptance Support.
Acceptance review and testing shall consider the results of the Joint
Reviews, Audits, Software Qualification Testing, and System Qualification
Testing (if performed). The results of the acceptance review and testing shall be
documented.
Review and update previous phase documentation, as needed.
Project Manager.
The project Manager is responsible and accountable for the successful

execution of the Development Phase. The project Manager is responsible for
leading the team that accomplishes the tasks shown above. The Project
Manager is also responsible for reviewing deliverables for accuracy,
Project Team.


counsel to the project manager on the conduct and requirements of the
Development Phase. Additionally, oversight activities provide information,
35
Developer.
The developer is responsible for the development activities to include coding,

testing, documenting and delivering the completed system.
7 Integration and Test Phase
The objective of this phase is to prove that the developed system satisfies
the requirements defined in the FRD. Several types of tests will be conducted in
this phase. First, subsystem integration tests shall be executed and evaluated by
the development team to prove that the program components integrate properly
into the subsystems and that the subsystems integrate properly into an
application. Next, the testing team conducts and evaluates system tests to
ensure the developed system meets all technical requirements, including
performance requirements. Next, the testing team and the Security Program
Manager conduct security tests to validate that the access and data security
requirements are met. Finally, users participate in acceptance testing to confirm
that the developed system meets all user requirements as stated in the FRD.
Acceptance testing shall be done in a simulated “real” user environment with the
users using simulated or real target platforms and infrastructures.
The tasks and activities actually performed depend on the nature of the project.
1 Establish the Test Environment
Establish the various test teams and ensure the test system(s) are ready.
2 Conduct Integration Tests
The test and evaluation team is responsible for creating/loading the test
database(s) and executing the integration test(s).
3 Conduct Subsystem/System Testing
The test and evaluation team is responsible for creating/loading the test
database(s) and executing the system test(s).
4 Conduct Security Testing
36
The test and evaluation team will again create or load the test database(s)
and execute security (penetration) test(s). All tests will be documented, similar to
those above.
5 Conduct Acceptance Testing
The test and evaluation team will create/load the test database(s) and
execute the acceptance test(s). All tests will be documented, similar to those
above. Failed components will be migrated back to the development phase for
rework, and passed components will migrate ahead for implementation.
6 Revise previous documentation
During this phase, the Systems Technical Lead or the Developers will
finalize the Software Development Document from the Development Phase.
Project Manager.

execution of the Integration and Test Phase. The project manager is
responsible for leading the team that accomplishes the tasks shown above.
The Project Manager is also responsible for reviewing deliverables for
accuracy, approving deliverables and providing status reports to
management.
Project Team.

the project manager. This includes establishing the test environment.

counsel for the project manager on the conduct and requirements of the
Integration and Test Phase. Additionally, oversight activities provide
information, judgments, and recommendations to the agency decision makers
during project reviews and in support of project decision milestones.
37
User.
Users participate in acceptance testing to ensure systems perform as

expected.
8 Implementation Phase
In this phase, the system or system modifications are installed and made
operational in a production environment. The phase is initiated after the system
has been tested and accepted by the user and Project Manager. Activities in this
phase include notification of implementation to end users, execution of the
previously defined training plan, data entry or conversion, and post
implementation review. This phase continues until the system is operating in
production in accordance with the defined user requirements.
The new system can fall into three categories, replacement of a manual
process, replacement of a legacy system, or upgrade to an existing system.
Regardless of the type of system, all aspects of the implementation phase should
be followed. This will ensure the smoothest possible transition to the
organization’s desired goal.
.A description of these tasks and activities is provided below.
1 Notify users of new implementation
The implementation notice should be sent to all users and organizations

affected by the implementation. Additionally, it is good policy to make internal
organizations not directly affected by the implementation aware of the schedule
so that allowances can be made for a disruption in the normal activities of that
section. Some notification methods are email, internal memo to heads of
departments, and voice tree messages. The notice should include:
The schedule of the implementation;

a brief synopsis of the benefits of the new system;
the difference between the old and new system;
responsibilities of end user affected by the implementation during this
phase; and
The process to obtain system support, including contact names and phone
numbers.
2 Execute training plan
It is always a good business practice to provide training before the end

user uses the new system. Because there has been a previously designed
38
training plan established, complete with the system user manual, the execution of
the plan should be relatively simple. Typically what prevents a plan from being
implemented is lack of funding. Good budgeting should prevent this from
happening.
3 Perform data entry or conversion
With the implementation of any system, typically there is old data which is
to be included in the new system. This data can be in a manual or an automated
form. Regardless of the format of the data, the tasks in this section are two fold,
data input and data verification.
4 Install System
To ensure that the system is fully operational, install the system in a

production environment.
5 Conduct post-implementation review
After the system has been fielded a post-implementation review is

conducted to determine the success of the project through it’s implementation
phase. The purpose of this review is to document implementation experiences to
recommend system enhancements and provide guidance for future projects.
6 Revise previous documentation
During this phase, the ICD is revised from the Requirements Analysis
Phase. The CONOPS, System Security Plan, Security Risk Assessment,
Software Development Document, System Software and the Integration
Document are also revised and finalized during the Implementation Phase.
Project Manager.

execution of the Implementation Phase. The project manager is responsible
for leading the team that accomplishes the tasks shown above. The project
manager is also responsible for reviewing deliverables for accuracy,
Project Team.

39

counsel for the project manager on the conduct and requirements of the
Implementation Phase. Additionally, oversight activities provide information,
9 Operations and Maintenance Phase
More than half of the life cycle costs are attributed to the operations and
maintenance of systems. In this phase, it is essential that all facets of operations
and maintenance are performed. The system is being used and scrutinized to
ensure that it meets the needs initially stated in the planning phase. Problems
are detected and new needs arise. This may require modification to existing
code, new code to be developed and/or hardware configuration changes.
Providing user support is an ongoing activity. New users will require training and
others will require training as well. The emphasis of this phase will be to ensure
that the users needs are met and the system continues to perform as specified in
the operational environment. Additionally, as operations and maintenance
personnel monitor the current system they may become aware of better ways to
improve the system and therefore make recommendations. Changes will be
required to fix problems, possibly add features and make improvements to the
system. This phase will continue as long as the system is in use.
1 Identify Systems Operations
Ensure that systems and networks are running and available during the
defined hours of Operations;
Implement non-emergency requests during scheduled Outages, as
prescribed in the Operations Manual;
Ensure all processes, manual and automated, are documented in the
operating procedures. These processes should comply with the system
documentation;
Acquisition and storage of supplies (i.e. paper, toner, tapes, removable
disk);
Perform backups (day-to-day protection, contingency);
40
Perform the physical security functions including ensuring adequate UPS,
Personnel have proper security clearances and proper access privileges
etc.;
Ensure contingency planning for disaster recovery is current and tested ;
Ensure users are trained on current processes and new processes;
Ensure that service level objectives are kept accurate and are monitored;
Maintain performance measurements, statistics, and system logs.
Examples of performance measures include volume and frequency of data
to be processed in each mode, order and type of operations;
Monitor the performance statistics, report the results and escalate
problems when they occur.
2 Maintain Data / Software Administration
A checklist of Data / Software Administration tasks and activities are:
Performing a periodic Verification / Validation of data, correct data related

problems;
Performing production control and quality control functions (Job
submission, checking and corrections);
Interfacing with other functional areas for Day-to-day checking /
corrections;
Installing, configuring, upgrading and maintaining data base(s). This
includes updating processes, data flows, and objects (usually shown in
diagrams);
Developing and performing data / data base backup and recovery routines
for data integrity and recoverability. Ensure documented properly in the
Operations Manual;
Developing and maintaining a performance and tuning plan for online
process and data bases;
Performing configuration/design audits to ensure software, system,
parameter configuration are correct.
3 Identify Problem and Modification Process
One fact of life with any system is that change is inevitable. Users need an
avenue to suggest change and identified problems. A User Satisfaction Review
(Appendix C-37 ) which can include a Customer Satisfaction Survey, can be
designed and distributed to obtain feedback on operational systems to help
determine if the systems are accurate and reliable. Systems administrators and
operators need to be able to make recommendations for upgrade of hardware,
architecture and streamlining processes. For small in-house systems,
modification requests can be handled by an in-house process. For large
integrated systems, modification requests may be addressed in the
Requirements document and may take the form of a change package or a formal
Change Implementation Notice (Appendix C-32) and may require justification and
41
cost benefits analysis for approval by a review board. The Requirements
document for the project may call for a modification cut-off and rollout of the
system as a first version and all subsequent changes addressed as a new or
enhanced version of the system. A request for modifications to a system may
also generate a new project and require a new project initiation plan.
4 Maintain System / Software
Daily operations of the system /software may necessitate that

maintenance personnel identify potential modifications needed to ensure that the
system continues to operate as intended and produces quality data. Daily
maintenance activities for the system, takes place to ensure that any previously
undetected errors are fixed. Maintenance personnel may determine that
modifications to the system and databases are needed to resolve errors or
performance problems. Also modifications may be needed to provide new
capabilities or to take advantage of hardware upgrades or new releases of
system software and application software used to operate the system. New
capabilities may take the form of routine maintenance or may constitute
enhancements to the system or database as a response to user requests for
new/improved capabilities. New capabilities needs may begin a new problem
modification process described above.
At this phase of the SDLC all security activities have been completed.
This list briefly outlines some of the roles and responsibilities for key
maintenance personnel.
Systems Manager.
The Systems Manager develops documents and executes plans and

procedures for conducting activities and tasks of the Maintenance Process.
To provide for an avenue of problem reporting and customer satisfaction, the
Systems Manager should create and discuss communications instructions
with the systems customers.
Technical Support.
Personnel which proved technical support to the program. This support

may involve granting access rights to the program. Setup of workstations or
terminals to access the system. Maintaining the operating system for both
server and workstation. Technical support personnel may be involved with
issuing user ids or login names and passwords. In a Client server
42
environment technical support may perform systems scheduled backups and
operating system maintenance during downtime.
Operations or Operators
(Turn on/off systems, start tasks, backup etc). For many mainframe
systems, technical support for a program is provided by an operator. The
operator performs scheduled backup, performs maintenance during downtime
and is responsible to ensure the system is online and available for users.
Operators may be involved with issuing user ids or login names and
passwords for the system.
Customers.
The customer needs to be able to share with the systems manager the
need for improvements or the existence of problems. Some users live with a
situation or problem because they feel they must. Customers may feel that
change will be slow or disruptive. Some feel the need to create work-around.
A customer has the responsibility to report problems or make
recommendations for changes to a system.
Program Analysts or Programmer.
Interprets user requirements, designs and writes the code for specialized
programs. User changes, improvements, enhancements may be discussed in
Joint Application Design sessions. Analysts programs for errors, debugs the
program and tests program design.
Users Group or Team.
A group of computer users who share knowledge they have gained

concerning a program or system. They usually meet to exchange information,
share programs and can provide expert knowledge for a system under
consideration for change.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated. Deficiencies are identified. This can be

done by interviewing users of the system and consulting with support
personnel.
2. The new system requirements are defined. In particular, the deficiencies in
the existing system must be addressed with specific proposals for
improvement.
3. The proposed system is designed. Plans are laid out concerning the
physical construction, hardware, operating systems, programming,
communications, and security issues.
43
4. The new system is developed. The new components and programs must
be obtained and installed. Users of the system must be trained in its use,
and all aspects of performance must be tested. If necessary, adjustments
must be made at this stage.
5. The system is put into use. This can be done in various ways. The new
system can phased in, according to application or location, and the old
system gradually replaced. In some cases, it may be more cost-effective
to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be
exhaustively evaluated. Maintenance must be kept up rigorously at all
times. Users of the system should be kept up-to-date concerning the latest
modifications and procedures.
System Development Life Cycle Models (SDLC Models)
1. Waterfall Model or Classic Life Cycle Model (or) Linear Sequential

Model:
This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or)
Waterfall Method. This has the following activities.
1. Feasibility
2. System/Information Engineering and Modeling
3. Software Requirements Analysis
4. Systems Analysis and Design
5. Code Generation
6. Testing
7. Maintenance
44
Feasibility
The feasibility study determines whether a particular development project

should go ahead. If the project is to proceed then a project plan and budget
estimate for the other stages of development will be produced.
System/Information Engineering and Modeling
As software is always of a large system (or business), work begins by

establishing requirements for all system elements and then allocating some
subset of these requirements to software. This system view is essential when
software must interface with other elements such as hardware, people and other
resources. System is the basic and very critical requirement for the existence of
software in any entity. So if the system is not in place, the system should be
engineered and put in place. In some cases, to extract the maximum output, the
system should be re-engineered and spruced up. Once the ideal system is
engineered or tuned, the development team studies the software requirement for
the system.
Figure 1: The Waterfall Model of Software Development
45
Software Requirement Analysis
This is also known as feasibility study. In this phase, the development

team visits the customer and studies their system. They investigate the need for
possible software automation in the given system. By the end of the feasibility
study, the team furnishes a document that holds the different specific
recommendations for the candidate system. It also includes the personnel
assignments, costs, project schedule, and target dates. The requirements
gathering process is intensified and focused specially on software. To
understand the nature of the program(s) to be built, the system engineer
("analyst") must understand the information domain for the software, as well as
required function, behavior, performance and interfacing. The essential purpose
of this phase is to find the need and to define the problem that needs to be
solved.
System Analysis and Design
In this phase, the software development process, the software's overall

structure and its nuances are defined. In terms of the client/server technology,
the number of tiers needed for the package architecture, the database design,
the data structure design etc are all defined in this phase. A software
development model is created. Analysis and Design are very crucial in the whole
development cycle. Any glitch in the design phase could be very expensive to
solve in the later stage of the software development. Much care is taken during
this phase. The logical system of the product is developed in this phase.
Code Generation
The design must be translated into a machine-readable form. The code

generation step performs this task. If the design is performed in a detailed
manner, code generation can be accomplished without much complication.
Programming tools like Compilers, Interpreters, and Debuggers are used to
generate the code. Different high level programming languages like C, C++,
Pascal, and Java are used for coding. With respect to the type of application, the
right programming language is chosen.
Testing
Once the code is generated, the software program testing begins.

Different testing methodologies are available to unravel the bugs that were
committed during the previous phases. Different testing tools and methodologies
are already available. Some companies build their own testing tools that are tailor
made for their own development operations.
46
Maintenance
Software will definitely undergo change once it is delivered to the

customer. There are many reasons for the change. Change could happen
because of some unexpected input values into the system. In addition, the
changes in the system could directly affect the software operations. The software
should be developed to accommodate changes that could happen during the
post implementation period.
2. Prototyping Model:
This is a cyclic version of the linear model. In this model, once the
requirement analysis is done and the design for a prototype is made, the
development process gets started. Once the prototype is created, it is given to
the customer for evaluation. The customer tests the package and gives his/her
feed back to the developer who refines the product according to the customer's
exact expectation. After a finite number of iterations, the final software package is
given to the customer. In this methodology, the software is evolved as a result of
periodic shuttling of information between the customer and developer. This is the
most popular development model in the contemporary IT industry. Most of the
successful software products have been developed using this model - as it is
very difficult (even for a whiz kid!) to comprehend all the requirements of a
customer in one shot. There are many variations of this model skewed with
respect to the project management styles of the companies. New versions of a
software product evolve as a result of prototyping.
3. Spiral Model:
The spiral model, original1y proposed by Boehm is an evolutionary software

process model that couples the iterative nature of proto typing with the controlled
and systematic aspects of the linear sequential model. It provides the potential
for rapid development of incremental versions of the software. Using the spiral
model, software is developed in a series of incremental releases. During early
iterations, the incremental release might be a paper model or prototype. During
later iterations, increasingly more complete versions of the engineered system
are produced.
A spiral model is divided into a number of framework activities, also called task
regions. 6lYPically, there are between three and six task regions. Figure 2.8
depicts a spiral model that contains six task regions:
.
Customer communication-tasks required to establish effective communication
between developer and customer.
47
. Planning-tasks required defining resources, timelines, and other project related
information.
. Risk analysis-tasks required to assess both technical and management risks.
. Engineering-tasks required building one or more representations of the

application.
. Construction and release-tasks required to construct, test, install, and provide

user support (e.g., documentation and training).
Customer evaluation-tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage
and implemented during the installation stage.
Each of the regions is populated by a set of work tasks, called a task set, that
are adapted to the characteristics of the project to be undertaken. For small
projects, the number of work tasks and their formality is low. For larger, more
critical projects, each task region contains more work tasks that are defined to
achieve a higher level of formality.
As this evolutionary process begins, the software engineering team moves

around the spiral in a clockwise direction, beginning at the center. The first circuit
around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop prototype and-
then progressively more sophisticated versions of the software. Each pass
through the planning region results in adjustments to the project plan. Cost and
schedule are adjusted based on feedback derived from customer evaluation. In
addition, the project manager adjusts the planned number of iterations required
to complete the software.
Unlike classical process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer
software. An alternative view of the spiral model can be considered by examining
the project entry point axis, also shown in Figure. Each cube placed along the
axis can be used to represent the starting point for
48
Different types of projects. A "concept development project" starts at the core of
the spiral and will continue (multiple iterations occur along the spiral path that
bounds the central shaded region) until concept development is complete. If the
concept is to be developed into an actual product, the process proceeds through
the next cube (new product development project entry point) and. a "new
development project" is initiated. The new product will evolve through a number
of iterations around the spiral. Following the path that bounds the region that hast
somewhat lighter shading than the core. In essence, the spiral, when
characterized! in this way, remains operative until the software is retired. There
are times when the; process is dormant, but whenever a change is initiated, the
process starts at the appropriate entry point (e.g., product enhancement).
The spiral model is a realistic approach to the development large-scale systems,

and software. Because software evolves as the process progresses, the
developer and' customer better understand and react to risks at each
evolutionary level. The spiral model' uses prototyping as a risk reduction
mechanism but, more important, enables the developer to apply the prototyping
approach at any stage in the evolution of the product.
49
4. Fourth Generation Technique:
The term fourth generation techniques (4GT) encompass a broad array of

software tools that have one thing in common. Each enables the software
engineer to specify some characteristic of software at a high level. The tool then
automatically generates source code based on the developer's specification.
There is little debate that the higher the level at which software can be specified
to a machine, the faster a program can be built. The 4GT paradigm for software
engineering I focus on the ability to specify software using specialized language
forms or a graphic notation that describes the problem to be solved in terms that
the customer can understand.
Currently, a software development environment that supports the 4GT

paradigm includes some or all of the following tools: nonprocedural languages for
database query, report generation, data manipulation, screen interaction and
definition, code generation; high-level graphics capability; spreadsheet capability,
and automated generation of HTML and similar languages used for Web-site
creation using advanced software tools. Initially, many of the tools noted
previously were available only for very specific application domains, but today
4GT environments have been extended to address most software application
categories.
Like other paradigms, 4GT begins with a requirements gathering step.

Ideally, the customer would describe requirements and these would be directly
translated into an operational prototype. But this is unworkable. The customer
may be unsure of what is required, may be ambiguous in specifying facts that are
known, and may be unable or unwilling to specify information in a manner that a
4GT tool can consume. For this reason, the customer/developer dialog described
for other process models remains an essential part of the 4GT approach.
Implementation using a 4GL enables the software developer to represent

desired results in a manner that leads to automatic generation of code to create
those results. Obviously, a data structure with relevant information must exist and
be readily accessible by the 4GL.
To transform a 4GT implementation into a product, the developer must

conduct thorough testing, develop meaningful documentation, and perform all
other solution integration activities that are required in other software engineering
paradigms. In addition, the 4GT developed software must be built in a manner
that enables maintenance to be performed expeditiously.
There is some merit in the claims of both sides and it is possible to summarize
the current state of 4GT approaches:
50
1. The use of 4GT is a viable approach for many different application areas
.Coupled with computer-aided software engineering tools and code generators;
4GT offers a credible solution to many software problems.
2.. Data collected from companies that use 4GT indicate that the time required to
produce software is greatly reduced for small and intermediate applications and
that the amount of design and analysis for small applications is also reduced.
3. However, the use of 4GT for large software development efforts demands as
much or more analysis, design, and testing (software engineering activities) to
achieve substantial time savings that result from the elimination of coding.
To summarize, fourth generation techniques have already become an

important part of software engineering. When coupled with component-based
development approaches the 4GT paradigm may become the dominant
approach to software development.
System Analyst
The role of the analyst has been emerging with changing technology. The
literature suggests several definitions of analyst, but there seems to be a
common thread. A representative definition is the Random House Dictionary: "a
person who conducts a methodical study and evaluation of an activity such as a
business to identify its desired objectives in order to, determine procedures by
which these objectives can be gained.” A similar: definition is offered by Nicholas:
"The task of the systems analyst is to elicit needs and resource constraints and
to translate these into a viable operation."
Skills Required for System Analyst:
An analyst must possess various skills to effectively carry out the job.
Specifically, they may be divided into two categories:
1. Interpersonal Skill
2. Technical skills
Both are required for system development.
Interpersonal skills deal with relationships and the interface of the analyst with
people business. They are useful in establishing trust, resolving conflict, and
communicating information.
Technical skills, on the other hand, focus on procedures and techniques for
operations analysis, systems analysis, and computer science.
51
The interpersonal skills relevant to systems work include the following
1. Communication
Having the ability to articulate and speak the Language of the user, a "flare"
for mediation, and a knack for working wit virtually all managerial levels in the
organization. Communication is no just reports, telephone conversations, and
interviews. It is people talking, listening, feeling, and reacting to one another,
their experience and reactions. Some indicators of a climate of closed
communication a defensive memos, excessive correspondence, and a failure
to speak u for fear of being identified. Therefore, opening communication
channels are a must for system development.
2. Understanding
Identifying problems and assessing their ramifications, having a grasp of

company goals and objectives, and showing sensitivity to the impact of the
system on people at work.
3. Teaching
Educating people in use of computer systems, selling the system to the user and
giving support when needed.
4. Selling
Selling ideas and promoting innovations in problem solving using computers.
Technical skills include:
1. Creativity
Helping user’s model ideas into concrete plans and developing candidate
systems to match user requirements.
2. Problem solving
Reducing problems to their elemental levels for analysis, developing alternative

solutions to a given problem, and delineating the pros and cons of candidate
systems.
52
3. Project management
Scheduling, performing well under time constraints, coordinating team efforts,

and managing costs and expenditures.
4. Dynamic interface
Blending technical and non technical considerations in functional specifications

and general design.
5. Questioning attitude and inquiring mind
Knowing the what, when, why, where, who, and how a system works. .
6. Knowledge of the basics of the computer and the business Function.

Systems analysts require interpersonal as well as technical skills, although the
necessity for both skills depends on the stages of system development. Fig
illustrates the skills expected across the phases of system development:
analysis, design, implementation, and maintenance. During analysis, there is
greater need for interpersonal skills-working with the user to determine
requirements and translate them into design criteria. During design, the major
thrust is to develop a detailed design of candidate system-highly technical
procedures and methodologies. Even then, there is some emphasis on the
interpersonal factor-the user interface and user participation as a step toward
training and implementation. During program construction, coding and testing are
carried out with some user 'participation.
During system implementation, technical and interpersonal skills converge.

The technical aspects focus on "proving" the software and preparing for the final
conversion of files and documentation. The interpersonal aspects deal with user
training and selling the user on the benefits and potential of the candidate
system. During the maintenance stage the role of the analyst drops off, except
when unanticipated problems develop.
Overall, it can be seen that a successful analyst blends the realities of the human
factor with the structured techniques and procedures that permit problem solution
through the computer. Both skills are required for a lasting interface.
Academic and Personal Qualifications
How does the analyst acquire these skills? The answer is in education,
experience, and personality. Most of today's analysts are college graduates with
majors in accounting, management, or information systems. The latter major is
becoming so popular that more and more universities have programs that include
courses in systems analysis, project management, and data base design. More
than 30 universities offer doctorates in the field.
53
The background and experience of analysts include:
1. A background in systems theory and organization behavior.
2. Familiarity with the makeup and inner workings of major application areas
such as financial accounting, personnel administration, marketing and sales,
operations management, model building, and production control.
3. Competence in system tools and methodologies and a practical knowledge of

one or more programming and data base languages.
4. Experience in hardware and software specifications, which is important for

selection.
Fig: Interpersonal and Technical Skills Necessary in System Development
Roles of the Analyst:
Among the roles an analyst performs are change agent, monitor, architect,
psychologist, salesperson, motivator, and politician. Let's briefly describe I each
role.
54
Change Agent
The analyst may be viewed as an agent of change. A candidate system is
designed’ to introduce change and reorientation in how the user organization
handles information or makes decisions. It is important, then; that change be
accepted by the user.' The way to secure user acceptance is through user
participation during design and implementation. The knowledge that people
inherently resist change, and can become ineffective because of excessive
change should alert us to carefully plan, monitor, and implement change into the
user domain. In the role of a change agent, the systems analyst may select
various styles to introduce change to the user organization.
Investigator and Monitor
In defining a: problem, the analyst pieces together the information gathered to

determine why the present system does not work well and what changes will
correct the problem, In one respect, this work is similar to that of an investigator-
extracting ,the real problems from existing systems and creating information
structures that uncover previously unknown trends that may have a dimctimp4ct
on the Organization.
Related to the role of investigator' is that of monitor, To undertake and

successfully complete a project, the analyst must monitor programs in relation to
time, cost, and quality. Of these resources, time is the most Important. If time
"gets away," the project suffers from increased costs and wasted human
resources. Implementation delays also mean the system will not be ready on
time, which frustrates users and customers alike.
Architect
The architect's primary function as liaison between the client's abstract:

design requirements and the contractor's detailed building plan may mi compared
to the analyst's role as liaison between the user's logical designs Requirements
and the detailed physical system design. As architect, tire analyst also creates a
detailed physical design. of candidate systems. He/she aids users in formalizing
abstract ideas and provides details to build the. End product-the candidate
system.15
Psychologist
In systems development, systems are built around people. This is perhaps a bit
exaggerated, but the analyst plays the role of a psychologist in the way he,/she
55
reaches people, interprets their thoughts, assesses their behavior, and draws
conclusions from these interactions. Understanding interventional relationships is
important.
As can be seen, it is important that the analyst be aware of people's feelings

and be prepared to get around things in a graceful way. The ar1of listening is
important in evaluating responses and feedback.
Salesperson
Selling change be as crucial as initiating change. The oral presentation of

the system proposal has one objective- , selling the user on the system. Selling
the system actually takes place at each step in the system life cycle, however.
Sales skills and persuasiveness, then, are crucial to the-success of the system.
Motivator
A candidate system must be well designed and acceptable to the user.

System acceptance is achieved through user participation in its development,
effective user training, and proper motivation to use the system. The analyst's
role as a motivator becomes obvious during the first few weeks after
implementation and during times when turnover results in new people being
trained to work with the candidate system. the amount of dedication it takes to
motivate users often taxes the analysts abilities to maintain the pace. What was
once viewed as a challenge can easily become a frustration if the user's staff
continues to resist the system.
Politician
Related to the role of motivator is that of politician. In' implementing a

candidate system, the analyst tries to appease all parties involved. Diplomacy
and finesse in dealing with people can improve acceptance of the system.
Inasmuch as a politician must have the support of his/her constituency, so is the
analyst's goal to have the support of the users' staff. He/she represents their
'thinking and tries to achieve their goals through computerization.
56
REQIREMENT AND STRUCTURED ANALYSIS
Fact Finding Technique
No two projects are ever the same. This means that the analyst must decide
on the information gathering tool and how it must, be used. Although there are no
standard rules for specifying their use, a important rule is that information must
be acquired accurately, methodically, under the right conditions, and with
minimum interruption to user personnel. For example, if the analyst needs only
information available in existing manuals, then interviewing is unnecessary
except where the manual is not up to date. If additional information is needed,
.on-site observation or a questionnaire may be considered. Therefore, we need
to be familiar with various information-gathering tools. 'Each tool has a special
function, depending on the Information needed. There are four fact finding tools
are there.
1. Review of Written Documents

2. On Site observation
3. Interviews
4. Questionnaires
1. Review of Written Documents
Very few system problems are unique. The increasing number of software
packages suggests that problem solutions are becoming standardized.
Therefore, as a first step, a search of the literature through professional
references and procedures manuals, textbooks, .company studies, government
publications, or consultant studies may prove invaluable. The primary drawback
of this search is time. Often it is difficult to get certain reports, publications may
be expensive, and the information, may be outdated due to a time lag in
publication.
Procedures manuals and forms are useful sources for, the analyst. They
describe the format and functions of the present system. Included in most
manuals are systems requirements that help determine how well various
objectives are met. Up-to-date manuals save hours of information-gathering time.
Unfortunately, in many cases, manuals do not exist or are seriously out of date.
Included in the study of procedures and manuals is a close look. At existing,
forms. Printed forms are wider used for capturing and providing information.
2. On Site Observation
57
Another information-gathering tool used in system studies is on-site
observation. It is the process of recognizing and noting people, objects, and
occurrences to obtain information. The analyst’ role is that of an information
seeker who is expected to be detached (therefore unbiased) from the system
being observed. This role permits participation with the user staff openly and
freely.
The major objective of on-site observation is to get as close as possible to the
"real" system being studied. For this reason it is important that analyst is
knowledgeable about the general makeup and activities of the system. For
example, if the focus of the analysis is communication. One needs to know as
much as possible about the modes of communication available through the
organization structure and the aspects of the physical layout that might adversely
affect communication. The following questions can serve as a guide for on-site
observations:
1. What kind of system is it? What does it do?
2. Who runs the system? Who are the important people in it?
3. What is the history of the system? How did it get to its present stage of
development?
4. Apart from its formal function, what kind of system is inn comparison with other
systems in the organization? Is it a primary or a secondary contributor to the
organization? Is it fast paced or is it a leisurely system that responds slowly to
external crises?
As an observer, the analyst follows a set of rules. While making

observations, he/she is more likely to listen than talk and to listen with a
sympathetic and genuine interest when information is conveyed. The emphasis is
not on giving advice or passing moral judgment on what is observed.
Furthermore, care is taken not to argue with the persons being observed or to
show hostility toward one person and undue friendliness toward another.
. ' .
When human observers are used, four alternative observation method are
considered:
1. Natural or contrived:
A natural observation occurs in a setting such as the employee's place of

work; a contrived observation is set up by the observer in a place like a
laboratory.
2. Obtrusive or unobtrusive:
58
An obtrusive observation takes place w!1en the respondent knows he/she
is being observed; an unobtrusive observation takes place in a contrived way
such as behind a one-way mirror.
3. Direct or indirect:
A direct observation takes place when the analyst actually observes the
subject or the system at work. In an indirect observation, the analyst uses
mechanical devices such as cameras and videotapes to capture information.
4. Structured or unstructured:
In a structured observation, the observer looks for and records a specific

action such as the number of soup cans a shopper picks up before choosing one.
Unstructured methods place the observer in a situation to observe whatever
might be pertinent at the time.
Any of these methods may be used in information gathering. Natural, direct,

obtrusive, and unstructured observations are frequently used to get an overview
of an operation. The degree of structure is increased when observations have a
specific purpose. An example is tracing the route of a sales invoice through a
system. The degree of obtrusiveness may decrease when one wants to observe
the tasks that make up a given job. For example, the analyst may want to create
a list of the activities of a production supervisor by observing him/her from a
remote location. Indirect observations could be used in a similar manner. For
instance, the daily routine of a bank teller may be observed indirectly via a video
camera. Finally, contrived situations are used to test or debug a candidate
system. They are also used in training programs to help evaluate the progress of
trainees.
Electronic observation and monitoring methods are becoming widely used

information-gathering tools because of their speed, efficiency and low cost. For
example, some truck fleets use an electronic recorder system that records,
analyzes, and reports information (online) about the hours and minutes a vehicle
was driven faster than 60 miles per hour, the number of hours an engine was idle
in a day, and how much out-of-service time a vehicle had. These and other
electronic methods expedite the information-gathering process in systems
analysis.
On-site observations are not without problems:
1. Intruding into the user's area often results in adverse reactions by the staff.
Therefore adequate preparation and training are important.
2. Attitudes and motivations of subjects cannot be readily observed-only the
actions that result from them.
59
3. Observations are subject to error due to the observer's misinterpretation
and subjective selection of what to observe, as well as the s4bjects' altered
work pattern during observation.
5. Unproductive, long hours are often spent in an attempt to observe specific,

one-time activities or events.
In deciding to use an on-site observation, several questions are considered:
1. What behavior can be observed that cannot be described in other ways?
2. What data can be obtained more easily or more reliably by observation than by
other means?
3. What assurances can- be given, that the observation process, is not seriously
affecting the system or the behavior being observed?
4. What interpretation needs to be made about observational data to avoid being

misled by the obvious?
5. How much skill is required and available for the actual observation?
For on-site observation to be done properly in a complex situation it can be very
time-consuming. Proper sampling procedures must be used to ascertain The
stability of the behavior being observed Without a knowledge of stability
inferences drawn from small samples of behavior (small time slices) can be
inaccurate. .
3. Interviews
The interview is a face-to-face interpersonal role situation in which a

person called the interviewer asks a person being interviewed questions
designed to gather information about a problem area. The, interview is the oldest
and most often used device for gathering information in systems work. It has
qualities that behavioral and on-site observations do not possess. It can be used
for two main purposes: (1) as an exploratory device to identify relations or verify
information, and (2) to 'capture information as it exits.
Validity is no small problem. Special pains are taken to eliminate interview

bias. We assume that information is more valid, the more freely it is given. Such
an assumption stresses the voluntary character of the interview as a relationship
freely and willingly entered into by the respondent. If the interview is considered a
requirement, the interviewer might gain the respondent’s time and attention, but
cannot be certain of the accuracy of the information gathered during the
interview.
60
In an interview, since the analyst (interviewer) and the person interviewed
meet face-to face, there is an opportunity for flexibility in eliciting information. The
analyst is also in a position to observe the subject. In contrast, the information
obtained through a questionnaire is limited to the subject's written responses to
predefined questions.
There are four primary advantages of the interview:
1. Its flexibility makes the interview a superior technique for exploring areas
where not much is known about what questions to ask or how to formulate
questions. .
2. It offers a better opportunity than the questionnaire to evaluate the validity of
the information gathered. The interviewer can observe not only what subjects say
but also how they say it.
3. It is an effective technique for eliciting information about complex subjects and
for probing the sentiments underlying expressed opinions. .
4. Many people enjoy being interviewed, regardless of the subject. They usually
cooperate in a study when all they have to do is talk. In contrast, the percentage
of returns to a questionnaire is relatively low: often less than 20 percent.
Attractively designed questionnaires that are simple to return, easy to follow, and
presented in a context that inspires cooperation improve the return rate.
The major drawback of the interview is the long preparation time. Interviews
also take a lot of time to conduct, which means time and money. So whenever a
more economical alternative captures the same information, the interview is
generally not used.
The Art of Interviewing:
Interviewing is an art. Few analysts learn it in school, but most of them

develop expertise through' experience. The interviewer's art consists of creating
a permissive situation in which the answers offered a reliable. Respondents'
opinions are offered with no fear of being criticized by others. Primary
requirements for a successful interview are to create a friendly atmosphere and
to put the respondent at ease. Then the interview proceeds with asking questions
properly, obtaining reliable responses, and recording them accurately and
completely.
Arranging the Interview:
The interview should be arranged so that the physical location, time of the
interview, and order of interviewing assure privacy and minimal interruption.
Usually a neutral location that is no threatening to the respondent is preferred.
Appointments should be made well in advance and a fixed time period adhered
61
to as closely as possible. Interview schedules generally begin at the top of the
organization structure and work down So as not to offend anyone.
Guides to a Successful Interview.
Interviewing should be approached as logically as programming. In an interview,

the following steps should be taken:
1. Set the stage for the interview.

2. Establish rapport; put the interviewee at ease.
3. Phrase questions clearly and succinctly.
4. Be a good listener avoid arguments.
5. Evaluate the outcome of the interview.
1. Stage setting: This is an "ice breaking," relaxed, informal phase where the
analyst opens the interview by focusing on (a) the purpose of the interview, (b)
why the subject was selected, and (c) the confidential nature of the interview.
After a favorable introduction, the analyst asks the first question and the
respondent answers it and goes right through the interview. The job of the
analyst should be that of a reporter rather than a debater. The direction of the
interview is controlled by discouraging distracting conversation.
During stage setting the interviewer evaluates the cooperation of the interviewee.
Both the content and tone of the responses are evaluated: How well the interview
goes depends on whether the interviewee is the friendly type, the timid type who
needs to be coaxed to talk, or the resident expert, who bombards the analyst with
opinions disguised as facts.
2. Establishing rapport: In one respect, data collection is an imposition on user

staff time and an intrusion into their privacy. Even though the procedure is
authorized by management in advance, many staff members are reluctant to
participate. There is seldom a direct advantage in supplying information to
outsiders, regardless of their credentials. There is a strong perception that it may
do them harm. This factor makes it important to gain and maintain rapport with
the user staff. The investigation is an art. Although there are no ground rules to
follow, there are pitfalls 'to avoid.
a. Do not deliberately mislead the user staff about the purpose of the study. A
careful, well-thought-out briefing of participants should not provide any more
detail than is necessary. Too much technical detail may tend to confuse people.
The briefing should be consistent for all participants to avoid rumors.
b. Assure interviewees confidentiality that no information they offer will be

released to unauthorized person el. The promise of anonymity is very important.
62
c. Avoid personal involvement in the affairs of the user's department or
identification with one faction at the cost of another. This may be difficult when
several groups are involved in the study.
d. Avoid showing off your knowledge or sharing information received from other
sources.
e. Avoid acting like an expert consultant or confidant. This can reduce the
objectivity of the approach and discourage people from freely giving information.
f. Respect the time schedules and preoccupations of your subjects. Do not make
an extended social event out of the meeting. If the subject does not complain,
subordinates might, especially if they are waiting to see the subject (boss).
g. Do not promise anything you cannot or should not deliver, such as advice or
feedback.
h. Dress and behave appropriately for the setting and the circumstances of the
user contact.
i. Do not interrupt the interviewee. Let him/her finish talking.
3. Asking the questions:

Except in unstructured interviews, it is important that each question is
asked exactly as it is worded. Rewording or impromptu explanation may provoke
a different answer or bias the response. The questions must also be asked in the
same order as they appear on the interview schedule. Reversing the sequence
could destroy the comparability of the interviews. Finally, each question must be
asked unless the respondent, in answering a previous question, has already
answered the next one.
4. Obtaining and recording the response:

Interviewers must be prepared to coax respondents to elicit further
information when necessary. The "probing" technique enables the interviewer to
act as a catalyst, for example:
a. Interviewer: I see what you mean. Could you elaborate further on that?
b. Analyst (interviewer): How do you feel about, separating the present loan
division into commercial and loan departments?
Financial vice president (respondent): Well, I'm not sure. Sometimes I think that
we have to take this route eventually.
Analyst: I see. Can you tell me more about that?

These statements indicate that the analyst is listening, is interested,
understands what the respondent is trying to say; and is making an effort to gain
63
more information. The information received during the interview is recorded for
later analysis.
6. Data recording and the notebook:

Many system studies fail because of poor data recording. Care must be
taken to record the data, their source, and the time of collection. If there is no
record of a .conversation, the analyst runs the risk of not remembering
enough details, attributing them to the wrong source, or otherwise distorting
the data.
4. Questionnaires
In contrast to the interview is the questionnaire, which is a term used for

almost any tool that has questions to which individuals respond. This usually
associated with self-administered tools with .items of the closed or fixed
alternative type. By its nature, a questionnaire offers the following advantages:
1. It is economical and requires less skill to administer than the interview.
2. Unlike the interview, which generally questions one subject at time,

questionnaire can be administered to large nuP1bers of individuals
simultaneously.
3. The standardized wording and order of the questions and the standardized
instructions for reporting responses ensure uniformity of questions. In contrast,
the interview situation is rarely uniform from one interview to the next.
4. The respondents feel greater confidence in the anonymity of a questionnaire

than in that of an interview. In an interview, the analyst usually knows the user
staff by name, job function, or other identification. With a questionnaire,
respondents give opinions without fear that the answer will be connected to their
names.
5. The questionnaire places less pressure on subjects for immediate responses.

Respondents have time to think the questions over and do calculations to provide
more accurate data.
The advantages of the self-administered questionnaire outweigh disadvantages

especially when cost is a consideration. The' principal disadvantage is a low
percentage of returns. Another disadvantage is that many people have difficulty
expressing themselves in writing, especially when responding to essay (open)
questions. Many dislike writing. Because of these disadvantages, the interview is
probably superior to the questionnaire.
64
Types of Interviews and Questionnaires
Interviews and questionnaires vary widely in form and structure. Interviews

range from the highly unstructured, where neither the questions nor the
respective responses are specified in advance, to the highly structured
alternative in which the questions and responses are fixed. Some variation within
this range is possible.
1. The Unstructured Alternative.
The unstructured interview is a relatively nondirective information gathering

technique. It allows respondents to answer questions freely in their own words.
The responses are spontaneous rather than forced. They are self-revealing and
personal rather than general and superficial. The role of the analyst as an
interviewer is to encourage the respondent to talk freely and serve as a catalyst
to the expression of feelings and opinions. This is best achieved in a permissive
atmosphere in which the subjects have no feeling of disapproval.
2. The Structured Alternative
In the structured approach, the questions are presented with exactly the same
wording and the same order to all subjects. If the analyst asks subject, "Would
you like to see a compute e approach to solving your accounts receivable
problem?" and asks another subject, "How do you feel about computers handling
accounts ,receivable?" the response may not be the same even though the
subjects both have the same opinion. Standardized questions improve 'the
reliability of the responses by ensuring that all subjects are responding to the
same questions.
Feasibility Study
Many feasibility studies are disillusioning for both users and analysts. First,
the study often presupposes that when the feasibility document is being
prepared, the analyst is in a position to evaluate solutions. Second, most studies
tend to overlook the confusion inherent in system development the constraints
and the assumed attitudes. If the feasibility study is to serve as a decision
document, it must answer three key questions:
1. Is there a new and better way to do the job that will benefit the user?
2. What are the costs and savings of the alternative(s)?
65
3. What is recommended?
The most successful system projects are not necessarily the biggest or most
visible in a business but rather those that truly meet user expectations. More
projects fail because of inflated expectations than for any other reason.
Feasibility Considerations
Three key considerations are involved in the feasibility analysis: economic,

technical, behavioral. Let's briefly review each consideration and how it relates to
the systems effort.
1. 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 t e 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 ongoing effort that improves in
accuracy at each phase of the system life cycle.
2. Technical Feasibility
Technical feasibility centers on 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 percent 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.
3. Behavioral Feasibil1ty
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 toward 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.
66
Steps in Feasibility Analysis
Feasibility analysis involves eight steps:
1. Form a project team and appoint a project leader.
2. Prepare system flowcharts.
3. Enumerate potential candidate systems.
4. Describe and identify characteristics of candidate systems.
5. Determine and evaluate performance and cost effectiveness of each candidate

system.
6. Weight system performance and cost data.
7. Select the best candidate system.
8. Prepare and report final project directive to management.
Form a Project Team and Appoint a Project Leader
The concept behind a project team is that future system users should be
involved in its design and implementatiol1, Their knowledge and experience in
the operations are essential to the success of the system. For small projects, the
analyst and an assistant usually suffice; however, more complex studies require
a project team. The team consists of analysts and user staff-enough collective
expertise to devise a solution to the problem, In many cases, an outside
consultant and an information specialist join the team until the job is completed.
Projects are planned to occupy a specific time period, ranging from several
weeks to months. The senior systems analyst is generally appointed as project
leader. He/she is usually the most experienced analyst in the team. The
appointment is temporary lasting as long as the project. Regular meetings take
place to keep up the momentum and accomplish the mission-selection of the
best candidate system. A record is kept of the progress made in each meeting.
Regarding the safe deposit case, since the whole user area consists of five
employees, the analyst handled most of the work.
Prepare System Flowcharts
67
The next step in the feasibility study is to prepare generalized system
flowcharts for the system. Information-oriented charts and data flow diagrams
prepared in the initial investigation are also reviewed at this time. The charts
bring up the importance of inputs, outputs, and data flow among key points in the
existing system. All other flowcharts needed for detailed evaluation are
completed at this point.
Enumerate Potential Candidate Systems
This step identifies the candidate systems that are capable of producing the
outputs included in the generalized flowcharts. This requires a transformation
from logical to physical system models. Another aspect of this step is
consideration of the hardware that can handle the total system requirements. In
the safe deposit case, it was found that virtually any microcomputer system with
more than 128K -byte memory an dual disk drive will do the job. It was also
learned that a microcomputer can be designed to interlace with the bank's
mainframe. In this design, actual processing is handled by the microcomputer,
whereas information such as payments and credits are transmitted to the main
computer files for proper adjustment through the customer's checking account.
The question here is: Which microcomputer (IBM, Apple, Digital, etc.) should be
selected? This is taken up in step 6 of the study.
An important aspect of hardware is processing and main memory. There are a

large number of computers with differing processing sizes, main memory
capabilities, and software support. The project team may contact vendors for
information on the processing capabilities of the system available.
Describe and Identify Characteristics of Candidate Systems
From the candidate systems considered, the team begins a preliminary

evaluation in an attempt to reduce them to a manageable number. Technical
knowledge and expertise in the hardware/software area are critical for
determining what each candidate system can and cannot do.
These packages were the result of a preliminary evaluation of more than 15
other packages-all purporting to meet the requirements of the safe deposit billing
system. When the number is reduced to three key packages, the next step is to
describe in some detail the characteristics of each package. For example, the
first candidate system runs on an IBM PC with minimum of 128K-bytes of
memory. The software is written in Pascal, a relatively new language. In case of
enhancements, change has to be made through the software house, since the
source code is not available to the user. The first package was installed in Jan
1982. More than 200 packages have been installed to date.
Determine and Evaluate Performance and Cost Effectiveness of Each

Candidate System
68
Each candidate system's performance is evaluated against the system
performance requirements set prior to the feasibility study. Whatever the criteria,
there has to be as close a match as practicable, although trade-off's are often
necessary to select the best system. In the safe deposit case, the criteria chosen
in advance were accuracy, growth potential, and response time less than five
seconds, expandable main and auxiliary storage, and user friendly software.
Often these characteristics do not lend themselves to quantitative measures.
They are usually evaluated in qualitative terms (excellent, good, etc,) based on
the subjective judgment of the project team.
The cost encompasses both designing and installing the system. It include
user training, updating the physical facilities, and documenting. System
performance criteria are evaluated against the cost of each system to determine
which system is likely to be the most cost effective and also meets the
performance requirements. The safe deposit problem is easy.
Costs are more easily determined when the benefits of the system are tangible
and measurable. An additional factor to consider is the cost of the study design
and development.
Table: Project cost Estimation of final system
Study phase (4 Charges(Per Total

days) day)
Analyst $400 $1600
Design phase (6
days)
Analyst 400 $2,40
0
Programmer 250 1,500 3,900
Development phase
(9 days)
Data entry operator 80 720
Programmer 250 2,250 2790
$8470
Weight System Performance and Cost Data
In some cases, the performance and cost data for each candidate system
show which system is the best choice. This outcome terminates the feasibility
study. Many times, however, the situation is not so clear-cut.
The procedure for weighting candidate systems is simple:
1. Assign a weighting factor to each evaluation criterion based on the criterion's
effect on the success of the system. For example, if the usability criterion is twice
69
as important as the accuracy factor, usability is assigned weight 4 and accuracy
is assigned weight 2.
2. Assign a quantitative rating to each criterion's qualitative rating. For example,
ratings (poor, fair, good, very good, excellent) by assigned respective values (1,
2, 3, 4, 5).
3. Multiply the weight assigned to each category by the relative rating to determine
the score.
4. Sum. the score column for each candidate system.
Select the Best Candidate System

The system with the highest total score is judged the best system. This
assumes the weighting factors are fair and the .rating of each evaluation criterion
is accurate. According to our safe deposit example, the IBM PC is the best
system for the job. Growth potential was the criterion that had the greatest effect
on the total score. The HP 100 and the Apple III were given lower ratings than
the IBM PC because they were not judged to grow as easily and quickly:
Additionally, user training was judged superior for the PC than for other
candidate systems.
Most feasibility studies select from more candidate systems than we used in our
safe deposit example. The criteria chosen and the constraints are also more
complex. In any case, management should not make the selection without having
the experience to do so. Management cooperation and comments, however, are
encouraged.
TABLE Weighted Candidate Evaluation

Matrix
IBM PC HPl00 Apple III
Weightin
g
Evaluation Factor Rating Score Rating Score Rating Scor
Criteria e
Performance
System 3 5 15 5 15 5 15
accuracy
Growth potential 4 4 16 3 12 3 12
Response time 2 4 8 4 8 4 8
User-friendly 2 5 10 4 8 4 8
Costs
System 5 3 15 4 20 4 15
development
User training 3 5 15 3 9 3 9
System 2 4 8 2 4 4 8
operation
Payback 3 4 12 3 9 5 15
70
99 85 90
Feasibility Report
The culmination of the feasibility study is a feasibility report directed to

management; it evaluates the impact of the proposed changes on the area(s) in
question. The report is a formal document for management use, brief enough
and sufficiently non technical to be understandable, yet detailed enough to
provide the basis for system design.
There is no standard format for preparing feasibility reports. Analysts usually

decide on a format that suits the particular user and system. Most reports,
however, begin with a summary of findings and recommendations followed by
documented details. Starting with summary information highlights the essence of
the report, giving management the option of reviewing the details later. The
report contains the following sections:
1. Cover letter formally presents the report and briefly indicates to management
the nature, general findings, and recommendations to be considered.
2. Table of contents specifies the location of the various parts of the report.
Management quickly refers to the sections that concern them.
3. Overview is a narrative explanation of the purpose and scope of the project,

thereason for undertaking the feasibility study, and the departments involved or
affected by the candidate system. Also included are the names of the persons
who conducted the study, when it began, and other information that explains the
circumstances surrounding study.
4. Detailed findings outline the methods used in the present system. The system
effectiveness and efficiency as well as operating costs are emphasized. The
section also provides a description of the objectives and general procedure of the
candidate system. A discussion of the output reports, costs, and benefits gives
management a feel for the pros and cons of the candidate system.
5. Economic justification details point-by-point cost comparisons and preliminary

cost estimates for the development and operation of the candidate system. A
return on investment analysis of the project is also included.
6. Recommendations and conclusions suggest to management the most beneficial

and cost-effective system. They are written only as a recommendation, not a
command. Following the recommendations, any conclusions from the study may
be included.
71
7. Appendixes document all memos and data compiled during the
investigation. They are placed at the end of the report for reference.
Disapproval of the feasibility report is rare if it has been conducted properly.

When a feasibility team has maintained good rapport with the, user and his/her
staff it makes the recommendations easier to approve. Technically, the report is
only a recommendation, but it is an authoritative one. Management has the final
say. Its approval is required before system design is initiated.
Decision Tree and structured English
Once the data elements are defined in the data dictionary, we begin to focus on
the processes. Consider the following discount policy Example.
Bookstores get a trade discount of 25% ; for orders from libraries and individu3il
5% allowed on orders of 6-19 copies per book title; 10% on orders for 20-49
copies per book title; 15% on orders for 50 copies or more per book title.
A policy statement like this can be time-consuming to describe an time

confusing to implement. The analyst needs to use tools to portray the logic of the
policy. The first such tool is the decision tree. As shown in fig, a decision tree has
as many branches as there are logical alternatives It simply sketches the logical
structure based on the stated policy. In this respect, it is an excellent tool: It is
easy to construct, easy to read. And easy to update. It shows only the
skeletal/aspects of the policy. however, in the sense that it does not lend itself to
calculations or show logic as a set of instructions for action. The alternative, then,
is the use of a second tool called structured English.
Structured English borrows heavily from structured programming; it uses
logical construction and imperative sentences designed to carry out instructions
for action. Decisions are made through IF, THEN, ELSE, and SO statements.
The structured English for our publisher's discount policy is shown in Figure .
Note the correlation between the decision tree and structured English. .
We can actually make structured English more compact by using terms
defined in the data dictionary. For example, the process ORDER may have the
data element ORDER-SIZE, which defines four values:
MINIMUM: 5 or fewer copies per book title
SMALL: 6 to 19 copies
MEDIUM: 20 to 49 copies
LARGE: 50 or more copies

Using these values, the structured English is shown in fig
72
From these examples we see that when logic is written out in English
sentences using capitalization and multilevel indentation, it is structured English.
In this tool, the logic of processes of the system is expressed by using the
capitalized key words IF, THEN, ELSE, and SO. Structures are indented to
reflect the logical hierarchy. Sentences should also be clear, concise and
precise in wording and meaning.
Fig: Decision Tree An Example
Structured English-An Example
COMPUTE-DISCOUNT
Add up the number of copies per book title
IF order is from bookstore

and-IF order is for 6 copies or more per book title
THEN: Discount is 25%
ELSE (order is for fewer than 6 copies per book title)
So: no discount is allowed
ELSE (order is from libraries or individual customers)
so-IF order is for 50 copies or more per book title

discount is 15%
ElSE IF order is for 20 to 49 copies per book title
discount is 10%
73
ElSE IF order is for 6 to 19 copies per book title
discount is 5%
ElSE (order is for less than 6 copies per book order)
SO: no discount is allowed
Decision Tables
A major drawback of a decision tree is the lack of information in Its format to tell
us what other combinations of conditions to test. This is where the decision table
is useful. A decision table is a table of contingencies for defining a problem and
the actions to be taken. It is a single representation of the relationships between
conditions and actions. Figure shows a decision table that represents our
discount policy.
Bookstores get a trade discount of 25% ; for orders from libraries and individu3il
5% allowed on orders of 6-19 copies per book title; 10% on orders for 20-49
copies per book title; 15% on orders for 50 copies or more per book title.
A decision table consists of two parts: stub and entry. The stub part is divided
into an upper quadrant called the condition stub and a lower quadrant called the
action stub. The entry part is also divided into an upper quadrant, called the
condition entry and a lower quadrant called the action entry. The four elements
and their definitions are summarized in Figure.
Fig : Decision Table an Example
74
Note in above Figure that the answers are represented by a Y to signify yes,
an N to signify no, or a blank to show that the condition involved has not been
tested. In. the action entry quadrant, an X (or a check mark will do) indicates the
response to the answer(s) entered in the condition entry quadrant. Furthermore,
each column represents
decision or a rule. For example, rule 1 states:
IF customer is a bookstore and order size is 6 copies or more,

THEN allow 25% discount
Fig : Elements and Definitions in a Decision Table
75
So, according to the decision table, we have six decisions and therefore six rules.
A look at the table provides each decision (answer) immediately. The following
rules should be followed in constructing decision tables:
1. A decision should be given a name, shown in the top left of the table.
2. The logic of the decision table is independent of the sequence in which the
condition rules are written, but the action takes place in the order in which the
events occur.
3. Standardized language must be used consistently.
4. Duplication of terms or meanings should be eliminated, where possible.
Pseudocode:
Pseudocode is another programming analysis tool, which is used for

planning program logic. "Pseudo" means imitation or false, and "Code" refers to
the instructions written in a programming language. Pseudocode, therefore, is an
imitation of actual computer instructions. These pseudo:-instructions are phrases
written in ordinary natural language (e.g., English, French, German, etc.), which
cannot be understood by the computer. Instead of using symbols to describe the
logic steps of a program, as in flowcharting, pseudocode uses a structure, which
resembles computer instructions. When pseudocode is used for program
planning, a programmer can concentrate solely, on developing the logic of the
program, without worrying about the syntax for writing the program instructions,
because pseudocode does not have any syntax rules for formulating instructions.
Once the programmer is convinced that the program logic is sound, he/she can
easily convert the pseudocode into a suitable programming language, which can
be r1.\l1 on a computer. Since, pseudocode emphasizes the design of the
program, it is also called Program Design Language (PDL).
Pseudocodes for Basic Logic (Control) Structures
During the early days of program development, many programmers

developed program logics for large programs with mazes of branches Uumps
from one portion of the program to another), which altered the sequence of
processing operations. Such programs are now referred to as "spaghetti code",
because their program flowcharts appeared more like a plate of spaghetti than
like logical analyses of programming problems. Understanding the logic of such
programs was very difficult for someone other than the developer, and many
times even for the developer after a lapse of few months. Hence, these programs
76
were very difficult to modify for incorporating suggested enhancements, and
quickly became nightmares for those responsible for their maintenance.
It was later discovered that any program logic, no matter how complex, could be
expressed by using only the following three simple logic (control) structures:
1. Sequence logic,
2. Selection logic, and
3. Iteration (or looping) logic.
It was found that when programs are structured by using only these three
logic structures, they can be read from top to bottom, and are easier to
understand. That is, by conceptualizing the logic of a program in the form of
these three logic structures, programmers can avoid writing spaghetti code, and
produce programs, which are easy to understand and maintain. It was found that
this also helped in reducing program errors, and the time spent in program
testing. The use of these three basic control structures resulted in a more
scientific approach to solving a programming problem, and was later termed as
structured programming technique.
After realizing the advantages of structured programming technique, many

organizations now impose the use of the three basic logic structures in all their
programs. It is generally advised as good programming practices to develop
program logics, and write programs using the three basic logic structures. Hence,
in the discussion below, we will see the pseudocodes for the three basic logic
structures (flowcharts of these logic structures have also been shown for those
who are more comfortable with flowcharts).
SEQUENCE
Sequence is a linear progression where one task is performed

sequentially after another. Sequential control is indicated by writing one action
after another, each action on a line by itself, and all actions aligned with the same
indent. The actions are performed in the sequence (top to bottom) that they are
written.
Example (non-computer)
Brush teeth
Wash face
Comb hair
Smile in mirror
Example
77
READ height of rectangle
READ width of rectangle
COMPUTE area as height times width
Common Action Keywords
Several keywords are often used to indicate common input, output, and
processing operations.
Input: READ, OBTAIN, GET

Output: PRINT, DISPLAY, SHOW
Compute: COMPUTE, CALCULATE, DETERMINE
Initialize: SET, INIT
Add one: INCREMENT, BUMP
IF-THEN-ELSE
IF-THEN-ELSE is a decision (selection) in which a choice is made

between two alternative courses of action.Binary choice on a given Boolean
condition is indicated by the use of four keywords: IF, THEN, ELSE, and ENDIF.
The general form is:
IF condition THEN
sequence 1
ELSE
sequence 2
ENDIF
The ELSE keyword and "sequence 2" are optional. If the condition is true,
sequence 1 is performed, otherwise sequence 2 is performed.
Example
IF HoursWorked > NormalMax THEN

Display overtime message
ELSE
Display regular time message
ENDIF
WHILE
WHILE is a loop (repetition) with a simple conditional test at its beginning. The
WHILE construct is used to specify a loop with a test at the top. The beginning
and ending of the loop are indicated by two keywords WHILE and ENDWHILE.
The general form is:
78
WHILE condition
Sequence
ENDWHILE
The loop is entered only if the condition is true. The "sequence" is performed for
each iteration. At the conclusion of each iteration, the condition is evaluated and
the loop continues as long as the condition is true.
Example
WHILE Population < Limit

Compute Population as Population + Births - Deaths
ENDWHILE
Example
WHILE employee.type NOT EQUAL manager AND personCount <

numEmployees
INCREMENT personCount
CALL employeeList.getPerson with personCount RETURNING employee
ENDWHILE
CASE
CASE is a multiway branch (decision) based on the value of an expression.

CASE is a generalization of IF-THEN-ELSE. A CASE construct indicates a
multiway branch based on conditions that are mutually exclusive. Four keywords,
CASE, OF, OTHERS, and ENDCASE, and conditions are used to indicate the
various alternatives. The general form is:
CASE expression OF
condition 1 : sequence 1
condition 2 : sequence 2
...
condition n : sequence n
OTHERS:
default sequence
ENDCASE
The OTHERS clause with its default sequence is optional. Conditions are
normally numbers or characters
indicating the value of "expression", but they can be English statements or some
other notation that specifies the condition under which the given sequence is to
79
be performed. A certain sequence may be associated with more than one
condition.
Example
CASE Title OF
Mr : Print "Mister"
Mrs : Print "Missus"
Miss : Print "Miss"
Ms : Print "Mizz"
Dr : Print "Doctor"
ENDCASE
Example
CASE grade OF
A : points = 4
B : points = 3
C : points = 2
D : points = 1
F : points = 0
ENDCASE
REPEAT-UNTIL
REPEAT-UNTIL is a loop with a simple conditional test at the bottom.

REPEAT-UNTIL is a loop with a simple conditional test at the bottom. This loop
is similar to the WHILE loop except that the test is performed at the bottom of the
loop instead of at the top. Two keywords, REPEAT and UNTIL are used. The
general form is:
REPEAT
Sequence
UNTIL condition
The "sequence" in this type of loop is always performed at least once, because
the test is performed after the sequence is executed. At the conclusion of each
iteration, the condition is evaluated, and the loop repeats if the condition is false.
The loop terminates when the condition becomes true.
FOR
80
This loop is a specialized construct for iterating a specific number of times, often
called a "counting" loop. Two keywords, FOR and ENDFOR are used. The
general form is:
FOR iteration bounds

sequence
ENDFOR
In cases where the loop constraints can be obviously inferred it is best to
describe the loop using problem domain vocabulary.
Example
FOR each month of the year (good)

FOR month = 1 to 12 (ok)
FOR each employee in the list (good)

FOR empno = 1 to listsize (ok)
NESTED CONSTRUCTS
The constructs can be embedded within each other, and this is made clear by
use of indenting. Nested constructs should be clearly indented from their
surrounding constructs.
Example
SET total to zero

REPEAT
READ Temperature
IF Temperature > Freezing THEN
INCREMENT total
END IF
UNTIL Temperature < zero
Print total
In the above example, the IF construct is nested within the REPEAT construct,
and therefore is indented.
Dataflow Diagram
81
A data flow diagram (DFD) is a graphical representation of the "flow" of
data through an information system. A data flow diagram can also be used for
the visualization of data processing (structured design). It is common practice for
a designer to first draw a context-level DFD first which shows the interaction
between the system and outside entities. This context-level DFD is then
"exploded" to show more detail of the system being modeled.
Data flow diagrams were invented by Larry Constantine, the original

developer of structured design, based on Martin and Estrin's "data flow graph"
model of computation.
In analyzing a business, several sets of DFD's are drawn. Initial DFD's

might model the existing system (flaws and all), while later DFD's may model a
solution to the problem being analyzed. For these solution DFD's a logical and
physical DFD is drawn. Physical DFD's represent physical files and transactions,
while logical or conceptual DFD's can be used to represent business functions or
processes.
Symbols used in the DFD
A data flow diagram illustrates the processes, data stores, and external entities in
a business or other system and the data flows between these things. Four
diagrammatical components are used to develop a DFD. These are:
Data Flow (represented by an arrow)

Data Process (represented by a circle or rounded rectangle)
External Entity (represented by a square or oval, also called a
'Source/Sink')
Data Store (represented by two parallel lines, sometimes connected by a
vertical line)
Data flow
A data flow is the core of the data flow diagram. Each data flow in the system
should be unique and demonstrate data flowing between two other elements in
the system. Depending on the notation used, several rules apply to data flows,
such as a limitation on two-sided arrows. It is generally agreed that each data
flow should be uniquely labeled in the Dataflow Diagram. Dataflow are pipelines
through which packets of information flow. Label the arrows with the name of the
data that moves through it.
82
Dataflow Notations
Data process
A data process represents the transformation of data in the system. Generally,

this represents something that happens in the system, such as 'student
enrollment'. Data that flows into a process should be different than the data that
flows out of the process. A process transforms incoming data flow into outgoing
data flow
Yourdon and Coad

Process Notations
Gane and Sarson

Process Notation
Data store
An data store represents 'data at rest'. Data stores generally store data on a
specific category, such as 'students' or 'employees'. Data flowing out of a data
store is considered a read, while data flowing into a data store is considered a
write or update. Datastores are repositories of data in the system. They are
sometimes also referred to as files.
Datastore Notations
83
Yourdon and Coad
Datastore Notation
Gane and Sarson

Datastore Notations
External entities
External entities are objects outside the system, with which the system
communicates. External entities are sources and destinations of the system's
inputs and outputs.An external entity represents the source or sink of data
external to the system. When modeling a DFD, the designer is not interested in
the inner workings of the external entity, but only what data is produced/needed
by the entity.
External Entity Notations
84
Data Flow Diagram Layers
There are mainly three levels
1. Context Level Diagram

2. 1st Level Diagram
3. 2nd Level Diagram
Draw data flow diagrams in several nested layers. A single process node on
a high level diagram can be expanded to show a more detailed data flow
diagram. Draw the context diagram first, followed by various layers of data
flow diagrams.
The nesting of data flow layers
Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It
only contains one process node (process 0) that generalizes the function of
the entire system in relationship to external entities.
85
First level Diagram:
The first level DFD shows the main processes within the system. Each of
these processes can be broken into further processes in second level
Diagram.
Second level Diagram:
The first level DFD shows the main processes within the system. In Second
level we can divide processes into sub processes until you reach
pseudocode.
Drawing DFD:
There are several common modeling rules that I follow when creating DFDs:
1. All processes must have at least one data flow in and one data flow
out.
2. All processes should modify the incoming data, producing new forms
of outgoing data.
3. Each data store must be involved with at least one data flow.
4. Each external entity must be involved with at least one data flow.
5. A data flow must be attached to at least one process.
6. Processes should be named and numbered for easy reference. Each
name should be representative of the process.
7. Direction of flow is from top to bottom and from left to right. Data
traditionally flow from the source (upper left comer) to the destination
lower right comer), although they may flow back to a source. One way
to indicate this is to draw a long flow line back to the source. An
alternative " way is to repeat the source symbol as a destination. Since
it is used more than once in the DFD, it is marked with a short diagonal
in the lower right corner.
8. When a process is exploded into lower-level details, they are
numbered. Like 1.1, 1.2 etc. where 1.1 and 1.2 are the sub processes
of process.
9. The names of data stores, sources, and destinations are written in
capital letters. Process and data flow names have the first letter of
each word capitalized.
How detailed should a DFD be? As mentioned earlier, the DFD is designed to
aid communication. If it contains dozens of processes and data stores, it gets too
unwieldy. The rule of thumb is to explode the DFD to a functional level, so that
the next sublevel does not exceed 10 processes. Beyond that, it is best to take
86
each function separately and expand it to show the explosion of the single
process. If a user wants to know what happens within a given process, then the
detailed explosion of that process. may be shown.
A DFD typically shows the minimum contents of data stores. Each data store
should contain all the data elements that flow in and out. Questionnaires can be
used to provide information for a first cut. All discrepancies, missing interfaces,
redundancies, and the like are then accounted for often through interviews.
The DFD methodology is quite effective, especially when required design is

unclear and the user and the analyst need a notational language for
communication. The DFD is easy to understand after a brief orientation.
Example : Fixed Deposit System
Banks provide schemes through which people can deposit the money with a
bank as a fixed deposit for a certain period of time. The banks pay interest for
this period and return the money when the fixed deposit period is over. Interest
rate depends upon the period as follows.
Fixed Deposit Period Interest Rates

30 to 180 Days 10 %
181 to 364 Days 11%
1 to 2 Years 12.5%
2 to 3 Years 14%
More than 3 years 15.5 %
(These are the sample Fixed Deposit rates)
The Depositor may choose to renew the FD for another time period. Depositor
may get loan against the deposits. A maximum of 75 % of the deposit amount is
allowed as the loan amount. The interest payable on the loan is slightly higher
than the interest payable by the bank.
Inputs Expected From the Fixed Deposit

System
DFD applications containing the details of depositor, FD amount, period, date of
issue etc.
2. Instruction from the depositor for renewal! closure is another
input.
3. Loan application details.
87
4. Repayment details of loan.
Outputs Expected From the Fixed Deposit System
1. FD Certificate.
2. Interest cheques & counterfoils.
3. FD Maturity details.
4. Covering letter for interest, certificate
etc.
5. Loan-interest statement, etc.
Fig: Context Level Diagram
Fig: First Level DFD for Fixed deposit system
88
Fig : Second level DFD for Interest Rate Maintenance
Fig : Second level DFD for FD Account opening
89
Fig : Second level DFD for FD Account closing
Fig : Second level DFD for FD Loan Sanction and Payment
Fig : Second level DFD for Repayment
90
Fig : Second level DFD for Reports.
91
DATABASE DESIGN AND DOCUMENTATION TECHNIQUE
The Entity-Relationship Diagram
The Entity-Relationship (ER) model was originally proposed by Peter in 1976

[Chen76] as a way to unify the network and relational database views. Simply
stated the ER model is a conceptual data model that views the real world as
entities and relationships. A basic component of the model is the Entity-
Relationship diagram which is used to visually represents data objects. Since
Chen wrote his paper the model has been extended and today it is commonly
used for database design For the database designer, the utility of the ER model
is:
It maps well to the relational model. The constructs used in the ER model
can easily be transformed into relational tables.
It is simple and easy to understand with a minimum of training. Therefore,
the model can be used by the database designer to communicate the
design to the end user.
In addition, the model can be used as a design plan by the database
developer to implement a data model in a specific database management
software.
Basic Constructs of E-R Modeling
The ER model views the real world as a construct of entities and association
between entities.
Entities
Entities are the principal data object about which information is to be collected.
Entities are usually recognizable concepts, either concrete or abstract, such as
person, places, things, or events which have relevance to the database. Some
specific examples of entities are EMPLOYEES, PROJECTS, INVOICES. An
entity is analogous to a table in the relational model.
Entity
Weak Entity
92
Entities are classified as independent or dependent (in some
methodologies, the terms used are strong and weak, respectively). An
independent entity is one that does not rely on another for identification. A
dependent entity is one that relies on another for identification.
An entity occurrence (also called an instance) is an individual occurrence

of an entity. An occurrence is analogous to a row in the relational table. entities
are represented by labeled rectangles. The label is the name of the entity. Entity
names should be singular nouns.
Relationships
A Relationship represents an association between two or more entities.

Relationships illustrate how two entities share information in the database
structure. Following is the notation for Relationship.
Relationship
Weak
Relationship
An example of a relationship would be:
employees are assigned to projects
projects have subtasks
departments manage one or more projects
Relationships are classified in terms of degree, connectivity, cardinality, and

existence. Relationships are represented by a solid line connecting two entities.
The name of the relationship is written above the line. Relationship names should
be verbs
93
Attributes
Attributes describe the entity of which they are associated. A particular instance
of an attribute is a value. For example, "Jane R. Hathaway" is one value of the
attribute Name. The domain of an attribute is the collection of all possible values
an attribute can have. The domain of Name is a character string.
Attribute
Attributes can be classified as identifiers or descriptors. Identifiers, more

commonly called keys, uniquely identify an instance of an entity. Attributes, when
included, are listed inside the entity rectangle. Attributes which are identifiers are
underlined. Attribute names should be singular nouns.
Classifying Relationships
Relationships are classified by their degree, connectivity, cardinality, direction,

type, and existence. Not all modeling methodologies use all these classifications.
Degree of a Relationship
The degree of a relationship is the number of entities associated with the

relationship. The n-ary relationship is the general form for degree n. Special
cases are the binary, and ternary, where the degree is 2, and 3, respectively.
Binary relationships, the association between two entities are the most common
type in the real world. A recursive binary relationship occurs when an entity is
related to itself. An example might be "some employees are married to other
employees".
A ternary relationship involves three entities and is used when a binary

relationship is inadequate. Many modeling approaches recognize only binary
relationships. Ternary or n-ary relationships are decomposed into two or more
binary relationships.
Connectivity and Cardinality
The connectivity of a relationship describes the mapping of associated entity

instances in the relationship. The values of connectivity are "one" or "many". The
94
cardinality of a relationship is the actual number of related occurrences for each
of the two entities. The basic types of connectivity for relations are:
1. one-to-one,
2. one-to-many,
3. many-to-many.
A one-to-one (1:1) relationship is when at most one instance of a entity A is

associated with one instance of entity B. For example, "employees in the
company are each assigned their own office. For each employee there exists a
unique office and for each office there exists a unique employee.
A one-to-many (1:N) relationships is when for one instance of entity A, there are
zero, one, or many instances of entity B, but for one instance of entity B, there is
only one instance of entity A. An example of a 1:N relationships is
A department has many employees
Each employee is assigned to one department
A many-to-many (M:N) relationship, sometimes called non-specific, is when for

one instance of entity A, there are zero, one, or many instances of entity B and
for one instance of entity B there are zero, one, or many instances of entity A. An
example is:
Employees can be assigned to no more than two projects at the same time;
Projects must have assigned at least three employees
A single employee can be assigned to many projects; conversely, a single project

can have assigned to it many employee. Here the cardinality for the relationship
between employees and projects is two and the cardinality between project and
employee is three. Many-to-many relationships cannot be directly translated to
relational tables but instead must be transformed into two or more one-to-many
relationships using associative entities.
Cardinality of many is represented by a line ending in a crow's foot. If the crow's

foot is omitted, the cardinality is one.
95
Direction
The direction of a relationship indicates the originating entity of a binary

relationship. The entity from which a relationship originates is the parent entity;
the entity where the relationship terminates is the child entity.
The direction of a relationship is determined by its connectivity. In a one-

to-one relationship the direction is from the independent entity to a dependent
entity. If both entities are independent, the direction is arbitrary. With one-to-
many relationships, the entity occurring once is the parent. The direction of
many-to-many relationships is arbitrary.
Type
An identifying relationship is one in which one of the child entities is also a

dependent entity. A non-identifying relationship is one in which both entities are
independent.
Existence
Existence denotes whether the existence of an entity instance is

dependent upon the existence of another, related, entity instance. The existence
of an entity in a relationship is defined as either mandatory or optional. If an
instance of an entity must always occur for an entity to be included in a
relationship, then it is mandatory. An example of mandatory existence is the
statement "every project must be managed by a single department". If the
instance of the entity is not required, it is optional. An example of optional
existence is the statement, "employees may be assigned to work on projects".
Existence is represented by placing a circle or a perpendicular bar on the

line. Mandatory existence is shown by the bar (looks like a 1) next to the entity
for an instance is required. Optional existence is shown by placing a circle next to
the entity that is optional.
AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY: (One way of doing

it)
Identify the roles, events, locations, tangible things or concepts about which
1. Identify Entities
the end-users want to store data.
Find the natural associations between pairs of entities using a relationship
2. Find Relationships
matrix.
Put entities in rectangles and relationships on line segments connecting the
3. Draw Rough ERD
entities.
Determine the number of occurrences of one entity for a single occurrence of
4. Fill in Cardinality
the related entity.
5. Define Primary Keys Identify the data attribute(s) that uniquely identify one and only one occurrence
96
of each entity.
Eliminate Many-to-Many relationships and include primary and foreign keys in
6. Draw Key-Based ERD
each entity.
Name the information details (fields) which are essential to the system under
7. Identify Attributes
development.
8. Map Attributes For each attribute, match it with exactly one entity that it describes.
Adjust the ERD from step 6 to account for entities or relationships discovered
9. Draw fully attributed ERD
in step 8.
10. Check Results Does the final Entity Relationship Diagram accurately depict the system data?
A SIMPLE EXAMPLE
A company has several departments. Each department has a supervisor and at

least one employee. Employees must be assigned to at least one, but possibly
more departments. At least one employee is assigned to a project, but an
employee may be on vacation and not assigned to any projects. The important
data fields are the names of the departments, projects, supervisors and
employees, as well as the supervisor and employee number and a unique project
number.
1. Identify Entities
The entities in this system are Department, Employee, Supervisor and Project.
One is tempted to make Company an entity, but it is a false entity because it has
only one instance in this problem. True entities must have more than one
instance.
2. Find Relationships
We construct the following Entity Relationship Matrix:
Department Employee Supervisor Project

Department is assigned run by
Employee belongs to works on
Supervisor runs
Project uses
3. Draw Rough ERD
We connect the entities whenever a relationship is shown in the entity

Relationship Matrix.
97
4. Fill in Cardinality
From the description of the problem we see that:
Each department has exactly one supervisor.

A supervisor is in charge of one and only one department.
Each department is assigned at least one employee.
Each employee works for at least one department.
Each project has at least one employee working on it.
An employee is assigned to 0 or more projects.
5. Define Primary Keys
98
The primary keys are Department Name, Supervisor Number, Employee
Number, Project Number.
6. Draw Key-Based ERD
There are two many-to-many relationships in the rough ERD above, between
Department and Employee and between Employee and Project. Thus we need
the associative entities Department-Employee and Employee-Project. The
primary key for Department-Employee is the concatenated key Department
Name and Employee Number. The primary key for Employee-Project is the
concatenated key Employee Number and Project Number.
7. Identify Attributes
99
The only attributes indicated are the names of the departments, projects,
supervisors and employees, as well as the supervisor and employee NUMBER
and a unique project number.
8. Map Attributes
Attribute Entity Attribute Entity

Department Department Supervisor Supervisor
Name Number
Employee Employee Supervisor Supervisor
Number Name
Employee Employee Project Project
Name Name
Project Project
Number
9. Draw Fully Attributed ERD
100
10. Check Results
The final ERD appears to model the data in this system well.
FURTHER DISCUSSION:
Step 1. Identify Entities
A data entity is anything real or abstract about which we want to store data.
Entity types fall into five classes: roles, events, locations, tangible things, or
concepts. The best way to identify entities is to ask the system owners and users
to identify things about which they would like to capture, store and produce
information. Another source for identifying entities is to study the forms, files, and
reports generated by the current system. E.g. a student registration form would
refer to Student (a role), but also Course (an event), Instructor (a role), Advisor (a
role), Room (a location), etc.
Step 2. Find Relationships
There are natural associations between pairs of entities. Listing the entities down
the left column and across the top of a table, we can form a relationship matrix by
filling in an active verb at the intersection of two entities which are related. Each
row and column should have at least one relationship listed or else the entity
associated with that row or column does not interact with the rest of the system.
In this case, you should question whether it makes sense to include that entity in
the system.
. A student is enrolled in one or more courses
subject verb objects
Step 3. Draw Rough ERD
Using rectangles for entities and lines for relationships, we can draw an Entity
Relationship Diagram (ERD).
Step 4. Fill in Cardinality
At each end of each connector joining rectangles, we need to place a symbol

indicating the minimum and maximum number of instances of the adjacent
rectangle there are for one instance of the rectangle at the other end of the
relationship line. The placement of these numbers is often confusing. The first
symbol is either 0 to indicate that it is possible for no instances of the entity
joining the connector to be related to a given instance of the entity on the other
side of the relationship, 1 if at least one instance is necessary or it is omitted if
more than one instance is required. For example, more than one student must be
101
enrolled in a course for it to run, but it is possible for no students to have a
particular instructor (if they are on leave).
The second symbol gives the maximum number of instances of the entity joining
the connector for each instance of the entity on the other side of the relationship.
If there is only one such instance, this symbol is 1. If more than 1, the symbol is a
crows foot opening towards the rectangle.
If you read it like a sentence, the first entity is the subject, the relationship is the
verb, the cardinality after the relationship tells how many direct objects (second
entity) there are.
I.e. A student is enrolled in one or more courses

subject verb objects
Step 5. Define Primary Keys
For each entity we must find a unique primary key so that instances of that entity
can be distinguished from one another. Often a single field or property is a
primary key (e.g. a Student ID). Other times the identifier is a set of fields or
attributes (e.g. a course needs a department identifier, a course number, and
often a section number; a Room needs a Building Name and a Room Number).
When the entity is written with all its attributes, the primary key is underlined.
Step 6. Draw Key-Based ERD
Looking at the Rough Draft ERD, we may see some relationships which are non-
specific or many-to-many. I.e., there are crows feet on both ends of the
relationship line. Such relationships spell trouble later when we try to implement
the related entities as data stores or data files, since each record will need an
indefinite number of fields to maintain the many-to-many relationship.
Fortunately, by introducing an extra entity, called an associative entity for each

many-to-many relationship, we can solve this problem. The new associative
entity's name will be the hyphenation of the names of the two originating entities.
It will have a concatenated key consisting of the keys of these two entities. It will
have a 1-1 relationship with each of its parent entities and each parent will have
the same relationship with the associative entity that they had with each other
before we introduced the associative entity. The original relationship between the
parents will be deleted from the diagram.
The key-based ERD has no many-to-many relationships and each entity has its
primary and foreign keys listed below the entity name in its rectangle.
Step 7. Identify Attributes
102
A data attribute is a characteristic common to all or most instances of a particular
entity. In this step we try to identify and name all the attributes essential to the
system we are studying without trying to match them to particular entities. The
best way to do this is to study the forms, files and reports currently kept by the
users of the system and circle each data item on the paper copy. Cross out those
which will not be transferred to the new system, extraneous items such as
signatures, and constant information which is the same for all instances of the
form (e.g. your company name and address). The remaining circled items should
represent the attributes you need. You should always verify these with your
system users. (Sometimes forms or reports are out of date.)
Step 8. Map Attributes
For each attribute we need to match it with exactly one entity. Often it seems like
an attribute should go with more than one entity (e.g. Name). In this case you
need to add a modifier to the attribute name to make it unique (e.g. Customer
Name, Employee Name, etc.) or determine which entity an attribute "best'
describes. If you have attributes left over without corresponding entities, you may
have missed an entity and its corresponding relationships. Identify these missed
entities and add them to the relationship matrix now.
Step 9. Draw Fully-Attributed ERD
If you introduced new entities and attributes in step 8, you need to redraw the
entity relationship diagram. When you do so, try to rearrange it so no lines cross
by putting the entities with the most relationships in the middle. If you use a tool
like Systems Architect, redrawing the diagram is relatively easy.
Even if you have no new entities to add to the Key-Based ERD, you still need to
add the attributes to the Non-Key Data section of each rectangle. Adding these
attributes automatically puts them in the repository, so when we use the entity to
design the new system, all its attributes will be available.
Step 10. Check Results
Look at your diagram from the point of view of a system owner or user. Is
everything clear? Check through the Cardinality pairs. Also, look over the list of
attributes associated with each entity to see if anything has been omitted.
FLOWCHARTS
THEIR PURPOSE
103
Flowcharts, which have been in use for many years, have become more
and more specialized as the areas using them became better defined. A form of
charting we all recognize is the diagram of electrical circuits. We do not
understand these charts, but to the persons schooled and working in electronics
they are highly meaningful. In the same way, the data processing industry has
developed its own set of special symbols for use in picturing the activities in the
processing of data.
The first formal flowchart is attributed to John Von Neumann in 1945. A
flowchart is simply a method of assisting the programmer to layout in visual, two-
dimensional format, the ideas as to how to organize the sequence of steps or
events necessary to solve a problem with a computer. In other words, flowcharts
are symbolic diagrams of operation sequence, data flow, and control flow .and
processing logic in information processing. The charts are read in the same
manner that we learned to read a page, from the upper left-hand corner of a
page, left to right and top to bottom. The symbols used are simple and easy to
learn. Flowcharts, very important planning and working tools in programming,
have many purposes. They Provide communication Flowcharts are an excellent
means of communication. They quickly and clearly impart ideas and descriptions
of algorithms to other programmers, students, teachers, computer operators and
users.
Provide an overview. Flowcharts provide a clear overview of the entire
problem and its algorithm for solution. They show all major elements and their
relationships. They help avoid the possibility of overlooking important details,
leaving incomplete branches, etc.
Aid in algorithm development and experimentation. Flowcharts are a quick

method of illustrating program flow. It is much easier and faster to try an idea with
a flowchart than to write a program and test it on a computer. Experimenting with
alternative algorithms is facilitated with flowcharts.
Check program logic.
Flowcharts show all major parts of a program.
All details in program logic must be clarified and specified.
This is a valuable check for maintaining accuracy in logic flow.
Facilitate coding. A programmer can code the programming instructions in
a computer language (code) with more ease with a comprehensive
flowchart as a guide. The flowchart specifies all the steps to be coded and
helps to prevent omissions or errors.
Provide program revision. Flowcharts facilitate modification of running
programs; they are an indispensable guide in inserting changes and
alterations without disrupting program flow.
Provide program documentation. The flowchart provides a permanent
recording of program logic. It documents the steps followed in an
104
algorithm. A comprehensive, carefully drawn flowchart is an
indi5tpensable part of documentation for each program.
Basic Flowchart Symbols
Only a few symbols are needed to indicate the necessary operations in a

flowchart. These basic flowchart symbols have been standardized by the
American National Standards Institute (ANSI). They are shown in Figure and
their functions are discussed below.
1. Terminal
The terminal symbol is used to indicate the beginning (Start), end (Stop),
and pauses (Halt) in the program logic flow. It is the first symbol and the last
symbol in the program logic. In addition, if the program logic calls for a pause in
the program, the pause is also indicated by a terminal symbol. A pause is
normally used in the program logic under some error conditions or if forms had to
be changed in the computer's line printer during the processing that program.
2. Input/Output.
The input/output symbol is used to denote any function of an input/output
device in the program. If there is a program instruction to input data from the disk
tape, terminal, or any other type of input device, that step will be indicated in the
flowchart with an input/output symbol. Similarly, all output instructions, whether it
is ou!l2l!LQn a printer, magnetic tape, magnetic disk, terminal screen, or any
output device, are indicated in the flowchart with an input/output symbol.
3. Processing.
A processing symbol is used in a flowchart to represent arithmetic and data
movement instructions. Hence, all arithmetic processes of adding, subtracting,
multiplying and dividing are shown by a processing symbol. The logical process
of moving data from one location of the main memory to another is also denoted
by this symbol. When more than one arithmetic and data movement instructions
are to be executed consecutively, they are normally placed in the same
processing box and they are assumed to be executed in the order of their
appearance.
4. Decision.
The decision symbol is used in a flowchart to indicate a point at which a
decision has to be made, and a branch one of two or more alternative points is
possible. Three different ways in which a decision symbol can be used. It may be
noted from these examples that the criterion for making the decision should be
indicated clearly within the decision box. Moreover, the condition upon which
each of the possible exit paths will be executed should be identified, and all the
105
possible paths should be accounted for. During execution, the appropriate path is
followed depending upon the result of the decision.
.
5. Flow lines
Flow lines with arrowheads are used to indicate the flow of operation,
that is, the exact sequence in which the instructions are to be executed. The
normal flow of flowchart is from top to bottom and left to right. Arrowheads are
required only when the normal top to bottom flow is not to be followed. However,
as a good practice, and to avoid ambiguity, flow lines are usually drawn with an
arrowhead at the point of entry to a symbol. Good practice also dictates that flow
lines should not cross each other, and that such intersections should be avoided
whenever possible.
6. Connectors
Whenever a flowchart becomes complex enough that the number and
direction of flow lines is confusing, or it spreads over more than one page, it is
useful to utilize the connector symbol as a substitute for flow lines. This symbol
represents an entry from, or an exit to another part of the flowchart. A connector
symbol is-represented by a circle, and a letter or digit is placed within the circle to
indicate the link. A pair of identically labeled connector symbols is commonly
used to indicate a continued flow, when the use of a line is confusing. Hence, two
connectors with identical labels serve the same function as a long flow line. That
is, they show an exit to some other chart section, or they indicate an entry from
another part of the chart. How is it possible to determine if a connector is used as
106
an entry or an exit point? It is very simple - if an arrow enters, but does not leave
a connector, it is an exit point, and program control is transferred to the
identically labeled connector, which does have an outlet. It may be noted that
connectors do not represent any operation, and their use in a flowchart is only for
the sake of convenience and clarity.
Advantages and Limitations of Flowcharts
Advantages
The following benefits may be obtained when flowcharts are used for the purpose
of program planning:
1. Better Communication. A flowchart is a pictorial representation of a program.

Hence, it is easier for a programmer to explain the logic of a program to some
other programmer, or to his/her boss through a flowchart, rather than the
program itself.
2. Proper Program Documentation. Program documentation involves
collecting, organizing, storing, and otherwise maintaining a complete historical
record of programs, and the other documents associated with a system. Good
documentation is needed for the following reasons:
Documented knowledge belongs to an organization, and does
not disappear with the departure (resignation/retirement) of a
programmer.
If projects are postponed, documented work will not have to be
duplicated.
If programs are modified in future, the programmer will have a
more understandable record of what was originally done.
Flowcharts often provide valuable documentation support.
3. Efficient Coding. Once a flowchart is ready, programmers find it very easy to

write the corresponding program, because the flowchart acts as a road map for
them. It guides them to go from the starting point of the program to the final point,
ensuring that no steps are omitted. The ultimate result is an error-free program,
developed at a faster rate.
4. Systematic Debugging. A flowchart is very helpful in detecting, locating, and
removing mistakes (bugs) in a program in a systematic manner, because
programmers find it easier to follow the logic of the Flowchart.
The process of removing errors (bugs) in a program is known as debugging. .
5. Systematic Testing. Testing is the process of confirming whether a program
will successfully do all the jobs for which it has been designed under the
specified constraints. For testing a program, different sets of data are fed as input
to that program to test the different paths in the program logic.
107
A flowchart proves to be very helpful in designing the test data for systematic
testing of programs.
Limitations
In spite of their many obvious advantages, flowcharts have some limitations,
which are as follows:
1. Flowcharts are very time consuming, and laborious to draw with proper
symbols and spacing, especially for large complex programs. In this chapter, you
have seen examples of small program flowcharts, developed for relatively small
programs. You can very well imagine how difficult it would be to develop a
detailed program flowchart for a program containing over 50,000 statements.
2. Owing to the symbol-string nature of flowcharting, any changes or

modifications in the program logic will usually require a completely new flowchart.
Redrawing a flowchart being a tedious task, many programmers do not redraw or
modify the corresponding flowchart when they modify their programs. This leaves
the program and its flowchart in an inconsistent state. That is, the logic used in
the program, and that shown in its flowchart, do not match. This defeats the
purpose of use of flowcharts as documentation support for programs. To take
care of this problem, many companies use software tools, which automatically
generate flowcharts directly from the program code. These software tools read
the program's instructions and draw a flowchart of its logic. That is, this is a
backward approach in which flowcharts are drawn from program codes mainly for
documentation purpose.
3. There are no standards determining the amount of detail that should be

included in a flowchart.
CONSTRUCTING FLOWCHARTS
Eight steps that will insure complete preparation and execution of a flowchart are:
1. Research the problem
2. Decide on the method of solution
3. Plan the solution
4. Outline the system by drawing the system flowchart
5. Check the system flowchart
6. Draw a detailed program flowchart for each program.
7. Check the program flowchart
8. Test the program flowchart and system flowchart by using data that has been
prepared.
As preparation and planning proceed, more information may be needed.

These steps may not be treated as an absolute rule: they are intended only as
108
guidelines, and must be treated as such. When constructing flowcharts, you
should attempt to observe the following guidelines:
1. The flow of the flowchart should be from top to bottom and from left to
right.
2. Use meaningful descriptions in the symbols. The flowchart is part of the
program documentation, and the symbol description should be meaningful
to any programmer:
3. If the flowchart is complex, connectors should be used to reduce the
number of flow lines.
4. A void intersecting flow lines.
5. Legibility is important. Print clearly and use a flowcharting template.
6.
When possible, construct flowcharts on special flowcharting forms that allow
symbols to be' placed n fixed
Example:
Find out how many males and females are present in a seminar. It also gives the
printout of the total number of males, total number of females and total number of
persons present. Suppose we are required to write a flowchart to calculate marks
and grade obtained by each student in a class and also find out:
1. total class strength ?
2. Total students in Grade 'A', 'B', 'C', 'D'?
3. Total number of students failed?
Rules for evaluation:
If average mark is = 80 then grade is 'A'

If average mark is = 70 and 80 then grade is 'B'
If average mark is = 60 and 70 then grade is 'C'
If average mark is = 50 and 60 then grade is 'D'
Otherwise grade is 'FAIL"
Subjects are BASIC, COBOL, dbase IV,

Pascal, FORTRAN.
Input is Roll Number, BASIC Marks, and COBOL Marks, dBase IV Marks, Pascal
Marks and FORTRAN Marks.
Stopping condition is Roll Number 9999. Marks for each subject is 100.
109
110
System Flow-chart
System flowchart describes the data flow for a data processing system. It
provides a logical diagram of how the system operates. It represents the flow of
documents, the operations performed in data processing system. It also reflects
the relationship between inputs, processing and outputs. Following are the
features of system flowcharts:
the sources from which data is generated and device used for this
purpose
various processing steps involved
the intermediate and final output prepared and the devices used for their
storage
The system to be flow-charted must be identified. Systems usually have some

sort of input, a means of processing and an output. Before beginning the flow-
chart drawing it is necessary to break the system down into relevant sub-
systems. Each sub-system is an individual function or process in its own right,
but the sub-system's flow-chart should have cross reference points that
demonstrate the sub-system interrelationships.
It is essential that flow-charting techniques within the Section are

standardized so that all flow-charts produced can be followed by all staff. The
following criteria are therefore required:
1. Style
The Skinner and Anderson style, which describes the flow of documents,
using specialized and uniform symbols.
2. Flow-lines
Flow-lines are used to show how documents and records are related.
Arrowheads are used to indicate the direction of flow. In preparing flow-charts the
flow-lines should cross as infrequently as possible.
3. Separation of Duties
Areas of responsibility are established on flow-charts as vertical columns

or sections through which the flow of documents takes place. This technique
allows the reader to identify clearly changes in responsibility as the documents
flow through the system.
4. Internal Controls
111
The inclusion of significant internal controls in a flow-chart aids the auditor
in evaluating internal control. Examples include authorizations, internal
verification and reconciliations.
5. Written Comments
The use of comments and explanations is encouraged whenever it will

make a flow-chart easier to understand. Internal controls can normally be
identified most effectively by written comments.
6. Document Source
Show the source of every document in the flow-chart, whether from within
the system being flow-charted, external to the system being flow-charted or
external to the department.
7. Process Symbol
Use a process symbol for every document or record prepared: Every

document must result from some type of action. The action should be shown by
the use of a process symbol.
8. Disposition of Documents
Indicate the final user or storage location of every document and record
contained in the flow-chart.
9. Identification
Each flow-chart should also include details of:
date of drawing;
who drew the flow-chart;
relevant system's name;
sub-system name;
sub-system objective;
resources involved in processing; and
volume of items processed.
112
System Flow-chart symbols
The following is a list of basic flow-charting symbols:
Example of System Flow-chart
The following is a simplified version of a flowchart for College Admission System

to demonstrate the use of forms, and general layout required:
113
114
Structured Flow Charts
Structured flowcharts, also called Nassi-Schneiderman charts, are graphic

tools that force the designer to structure software that is both modular and top-
down. They provide a structure that can be retained by programmers who
develop the application software.
Organization responsibilities vary. In some organizations, analysts are
responsible for developing module logic, while in others that responsibility is
delegated to the programmer. In either case, the programmer should be well
versed in the use of structured flowcharts.
Basic Elements
There are three basic elements used in developing structured flowcharts:

process, decision, and iteration. (There are many similarities between these
elements and the components used in structured English. )
Process
Simple processes or steps in a program are represented by a rectangular

box, the process symbol. This symbol represents initialization of values, input
and output activities, and calls to execute other procedures.
A name or brief description written in the box states the purpose of the
process. The succession of steps is shown using several process boxes.
Decision
The decision symbol represents alternative conditions that can occur and
that the program must have a manner of handling. They show the equivalent of
the IF-THEN-ELSE structures discussed previously under structured English and
common in many programming languages. As examples will show, the decision
symbol may show actions for more than two alternatives at the same time.
Iteration
The iteration symbol represents looping and repetition of operations while

a certain condition exists or until a condition exists. The form of the iteration
symbol clearly shows the scope of the iteration, including all processes and
decisions that are contained within the loop. The left-hand portion of the symbol
shows the path of repetition to follow until the conditions controlling the iteration
are satisfied.
115
Using Structured Flowcharts
Structured flowcharts use no arrows or continuations on separate pages.

Each structured flowchart is shown on a single sheet of paper (or single display
screen, if developed online).
When designing a structured flowchart the systems analyst specifies the logic
in a top-down fashion. The first consideration in a process or decision is the top
element. The second in sequence is the next one shown, and so forth. Similarly,
there is a single exit from the process.
The analyst begins with a major process and introduces other symbols to
subdivide the process. Each process is named, but, if the name is not underlined,
it is a reference to some other diagram or description. This simple convention
makes it possible to link together easily different procedures that are performed
to complete an entire activity.
Figure shows the steps needed to produce customer invoices during a

monthly processing cycle. The structure chart reads from top to bottom and left to
right. Each activity is nested within the iteration and alternative processes of
which it is a part. In addition, each condition is clearly shown.
Individual parts of processes are often further described in lower level

diagrams. For example, the purchase, payment, debit, and credit transactions
are identified in the module described in Figure. But individual modules are
referenced to handle the processing for each type of transaction.
An important use of structured flowcharts for the designer concerned about

verifying systems specifications against planned software logic is to identify
conditions and procedures followed when the conditions exist. The fact that the
structure chart is easy to read will enable the analyst to determine whether the
debit adjustment transaction, for example, has been added by the programmer or
is a part of the original systems specifications.
Fig :Stuctured Flow Chart
116
Functional Decomposition Diagram
Before an analyst can plan what systems to build for the organization, it is
helpful to first understand the business functions that the organization needs to
perform. Then it is much easier to identify processes that occur within the
business functions, and ultimately the systems that will support those processes.
This is a top-down approach to systems development.
The process of starting at a high level and moving into smaller and smaller
subsystems is called decomposition. The functional decomposition diagram
(FDD) is a planning tool for identifying business functions and the processes that
comprise them.
The functional decomposition diagram itself does not depict process flows,
but rather the hierarchical organization of functions and the processes that they
include.
In this supplement, we first explain how to read functional decomposition

diagrams and describe their basic syntax. Then we describe the way in which
117
FDDs are built: identifying the functions of the organization and identifying their
respective processes.
Reading a Functional Decomposition Diagram
Figure shows a functional decomposition diagram of the Department of

Motor Vehicles1. Notice that it depicts a more traditional view of the organization
in that the primary functions (i.e., rectangles) correspond to the departments
within the DMV: Registration, Licensing, and Regulation. By examining this FDD,
an analyst can understand the high-level functions that the DMV performs and
the system that is needed to support each function. Take a moment and examine
the diagram before reading the next paragraph. How much do you understand?
Figure : Department of Motor Vehicles Functional Decomposition Diagram
D epa rtmen t o f
M o t o r V eh icles
M o t o r V eh icle
R eg ist ra t io n Licen sin g R eg u la t io n
D epa rtmen t D epa rtmen t D epa rtmen t
R eg ist ra t io n D riv er's Licen sing

S y st em S y st em R eg u la t io n S y st em
Issue D riv in g
Tests Issue Licen se
U pda te D M V
Get Ph o to g ra p h C rea te Licen se D a ta b a se
Most people start reading in the top center of the FDD; however, you
should note that there is no particular order implied by the boxes. Instead, the
FDD depicts a hierarchy whereby top-level functions are organized into
decomposed functions, and then processes, and finally into sub processes. The
first item at the top of the FDD in Figure 1 is the Department of Motor Vehicles
function, which represents the organization under analysis. Beneath this function
are three sub functions, which correspond to the main functional areas within the
118
DMV. They are connected by lines (i.e., connectors) that communicate the
hierarchical relationships among parts of the diagram.
Notice that the rectangles on the third level of the FDD have rounded
corners, representing processes. A process is activity that needs to be performed
to support some function. Notice how lines are drawn to show subprocesses that
correspond to the processes. For example, the Driver's License process includes
an Issue License subprocess, which in turn includes three subprocesses: Get
Photograph, Create License, and Update DMV Database.
This diagram is an example of the beginning of a basic FDD. In practice, most

FDDs are much more complex.
Syntax
Function
A functional decomposition diagram is composed of functions, which are cross-
organizational collections of activities . A traditional view is that functions
correspond to departments within an organization, such as research and
development, purchasing, and marketing; however, the current trend is for
functions to represent major organizational processes that may cross
departmental boundaries, such as order fulfillment or inventory management.
Functions are denoted by rectangles with square corners representing

collections of both manual and automated processes. Figure shows the basic
elements of a function, and how they are usually recorded in CASE tools. Every
function has a name, and a description, which is described in the CASE
repository. Descriptions clearly and precisely describe the collection of activities
within the function, and ultimately they are used to guide the analysts who need
to determine what systems are needed within the organization to support the
business.
Functions may include a variety of subfunctions. These are functions that

are drawn below a function on the FDD and connected with a straight line.
Organizations are very complex, and the use of subfunctions allows analysts to
break down functions into simpler components that are easier to understand and
plan. A function is a parent to a subfunction, and a subfunction is a child of a
function. If a function only has one child, the child usually is not included on the
FDD because it adds little to the meaning of the diagram. Also, a child can have
only one parent.
119
Figure : FDD Elements
Symbol
FDD Element Typical
CASE Fields
Every Function has Label (Name)
A name Type (Function)
Zero or more than one Description
children (What it is) Name
Zero or one parent Notes
Every Process has Label (Name)
A name Type (Process)
Zero or more than one Description
children (What it is) Name
One parent Notes
Every Connector None
Has no name
Connect any two of the
above elements
An Off-page connector None
Is denoted by the
hexagon
Has a title
Is used when the NAME
diagram is too large to
fit everything on the
same page
Process
The FDD can include several levels of functions that are broken down into
finer gradations. At some point, one that is entirely up to you, you can break
down functions into processes. A process is an activity that is performed for
some specific business reason, and it is denoted by a rectangle with rounded
corners The conceptual dividing point is somewhat arbitrary, but you can usually
differentiate a process from a function by the amount of activity that it represents.
A process represents a tangible activity that occurs within the organization, such
as issuing a driving test or creating a license.
Names should be short, yet contain enough information so that the reader
can easily understand exactly what they do. In general, each process performs
120
only one activity, so most system analysts avoid using the word "and" in process
names because it suggests that the process performs several activities.
Like functions, processes include actions that must be performed no

matter how the system is implemented, and they can be broken down into
smaller parts called subprocesses. Another similarity with functions is that child
processes can be a parent of more than one subprocess, and a child process
can only have one parent.
Connectors
Connectors are lines between functions, processes, and from a function to
a process. They specify hierarchical relationships among the components of the
FDD. Unlike processes and functions, connectors are not named, but instead
their presence implies the phrase "consists of." For example, the Driver's
Licensing System process consists of the Issue Driving Tests and Issue License
subprocesses. Every component on an FDD should be connected to at least one
other component.
A related symbol found on the FDD is the off-page connector FDDs can become
quite unwieldy, especially when depicting a large or complex program. A
hexagon is used to continue the diagram on another page.
Building the Structure Chart

Now that you understand the individual components of the functional
decomposition diagram, the next step is to learn how to put them together to form
an effective planning tool for the new system.
Identify Functions
To create the functional decomposition diagram, you simply draw one
function symbol for the business being modeled and place this at the top center
of the diagram. You then add rectangles on the next line to represent the primary
functions of the business. You likely will get the information to create this diagram
from the business leaders of the organizations, particularly members of the top
management team.
Identify Processes
Next, it is important to identify the processes that are needed to support
the functions that exist on the FDD. The first level of processes usually
represents the overall system that supports the function (e.g., the Driver's
License System), and the second level includes the major activities that the
system will perform. For example, in the case of the DMV, the Driver's License
system includes two main processes – issuing the driving tests and issuing the
driver's licenses.
When creating this portion of the diagram, the analyst will have to learn
more details about how the business performs its functions, and it is usually
121
helpful to gather information from people in the company who are actually
involved with the processes. Again, interviews and JAD sessions are the
requirements gathering techniques of choice.
The steps of identifying functions and processes are iterative. As the

analysts gather more and more information about the business and its
processes, the FDD will be changed and refined.
Balance with Process Models

Once the analyst is far enough along with the FDD, he or she can use the
diagram as a starting point for process modeling. In fact, components of the FDD
directly correspond to components on data flow diagrams. Each process on the
first level of processes on the FDD is placed within its own Context diagram.
Thus, the Driver's License System process on the FDD in Figure becomes the
main process on the context diagram describing that system.
Similarly, the FDD's first level of sub processes are the processes that
exist on the Level 0 DFD. Based on Figure 1, the Level 0 DFD for the Driver's
License System will include two processes: 1. Issue Driving Tests and
2. Issue License.
Below Figure presents a checklist that summarizes the rules of FDDs that have
been described in the last few sections.
Figure : Checklist for Functional Decomposition Diagram Quality
 All functions and processes are connected to at least one other function or
process
 Every parent has at least two children
 Every child only has one parent
 Labels are descriptive
 Connectors are not named (assumed to be "consists of")
 Each process on the first level of a FDD becomes a system on a context
diagram
 Each subprocess on the second level of an FDD becomes a process on the
Level 0 data flow diagram
Applying Concepts at CD Selections

Now that you are familiar with the basic components of the functional
decomposition diagram, the best way to learn how to build the diagram is to step
through an example that shows how to create one. Creating a decomposition
diagram is usually a three-step iterative process. First, the analyst identifies the
top-level functions and then decomposes them into lower levels or subfunctions.
Second, the analyst adds the processes and subprocesses that support the
122
business functions. Finally, the analyst reviews the FDD and revises it again and
again until it is complete, making sure that the diagram balances with its related
process models (i.e., DFDs).
Identifying Business Functions

CD Selections is a CD company that has both brick-and-mortar retail
stores, as well as an interest in moving towards Internet sales. Before embarking
upon the project for a new Internet Sales system, the project team felt that it
would be wise to take a top-down approach and first understand the main
functions of CD Selections as an organization. They then would better
understand which business functions the new system should support.
The project team applied a variety of different information gathering

techniques. They met with the business sponsor as well as three members of the
senior management team in one-on-one interviews. The first interview was with
the company's President; they were given half an hour to get a feel for how he
envisioned the functions of CD Selections from a strategic perspective. The next
interviews were with the Vice President of Supply Chain Management and the
Vice President of Marketing and Sales to better understand the actual operations
of CD Selections and its functions and major processes. As each of the
interviewees described the major organizational responsibilities of CD Selections,
the team translated these into business functions.
During the interviews, the project team learned about the CD Selections
value chain, and the major functions of the organization were identified as major
activities of the value chain: Inbound Logistics, Operations, Outbound Logistics,
Marketing and Sales, and Service. Human Resource Management was also
included as an important internal function. These functions were placed on the
Decomposition Diagram as shown in Figure 3.
Figure : Decomposition Diagram for CD Selections – Take 1
C D S electio n s
M a rketing a nd Huma n R eso u rce

Inb o u nd Lo g istics Opera tio ns Outb o u nd Lo g istics Sa les Serv ice M a na g emen t
123
Identify Processes
Next, the project team needed to understand the activities within the
organization that were performed to support the business functions, with a focus
on Marketing and Sales. To do this, they again gathered requirements using
interviews, and they also conducted JAD sessions with some low-level managers
and supervisors who were directly in charge of some of the key processes.
Ultimately, they were able to document the processes of the major functions;
below Figure describes the project team's understanding of the Marketing and
Sales business function. Based on the information in Figurethe project team
created the FDD found in Figure .
Figure : Description of the Marketing and Sales Function
The Internet sales system will have a database of basic information about the
CDs that it can sell over the Internet, similar to the CD database at each of the
retail stores (e.g., title, artist, id number, price, quantity in inventory). Every day,
the Internet sales system will receive an update from the distribution system
that that will be used to update this CD database. Some new CDs will be
added, some will be deleted, and others will be revised (e.g., a new price). The
Electronic Marketing (EM) Manager (a position that will need to be created) will
also have the ability to update information (e.g., prices for sales).
The Internet sales system will also maintain a database of marketing materials
about each CD that will help Web users learn more about them. Vendors will
be encouraged to e-mail marketing materials (e.g., music reviews, links to Web
sites, artist information, and sample sound clips) that promote their CDs. The
EM Manager will go through the e-mails and determine what information to
place on the Web. He or she will add this information to a marketing materials
database (or revise it or delete old information) that will be linked to the Web
site.
Customers will access the Internet sales system to look for CDs of interest.
Some customers will search for specific CDs or CDs by specific artists, while
other customers want to browse for interesting CDs in certain categories (e.g.,
rock, jazz, classical). When the customer has found all the CDs he or she
wants, the customer will "check out" by providing personal information (e.g.,
name, e-mail, address, credit card), and information regarding the order (e.g.,
the CDs to purchase, and the quantity for each item). The system will verify the
customer's credit card information with an online credit card clearance center
and either accept the order or reject it.
124
Every hour or so, the orders will be pulled out of the order database and sent to
the distribution system. The distribution system will handle the actual sending
of CDs to customers; however, when CDs are sent to customers (via UPS or
mail), the distribution system will notify the Internet sales system, which in turn
will e-mail the customer. Weekly reports can be run by the EM manager to
check the order status.
Figure : FDD – Take 2
C D Selectio ns
M a rketing a nd Huma n R eso urce

Inbo und Lo g istics Opera tio ns Outbo und Lo g istics Sa les Serv ice M a na g ement
R eta il Sa les Internet Sa les

Sy stem Sy stem
M a inta in
M a inta in C D M a rketing
Info rma tio n Ta ke Order M a inta in Order
Info rma tio n
125
USER INTERFACE DESIGN
WHAT IS AN INTERFACE?
An interface is the common boundary between the user and computer system
application-the point where the computer a individual interact. Its features
influence the effectiveness of I of the system, as well as the frequency of
mistakes and error, entering data or instructions.
Purpose of Interface
The systems analyst's objective is to design an interface I Accomplish the
following purposes:
1. Tell the system what actions to take:
Select processing actions; enter, change, or retrieve data between system
functions
2. Facilitate use of the system:

Allow users to accomplish processing actions or activity efficiently and effectively,
and in a manner they perceive as being a Natural and reasonable way to request
and carry out activities includes the use of methods that will not grow tiresome or
unacceptable to frequent users who become familiar with the system but that will
facilitate equally effective use by novice users.
3. Avoid user errors:

Prevent the taking of any action that will create a processing error or interrupt
the expected actions of the computer system.
Systems analysts frequently consider the interface as a window he
system, a view of a portion of the entire system's features. Users, in contrast,
tend to view the interface window as the entire system. Their experience with
the interface forms the basis for their judging system's features. And they may
have little appreciation internal and invisible technical details or the elegance of
the computer code, as the senior analyst pointed out in the vignette at inning of
this chapter. If the interface does not allow easy entry of data or the initiation of
actions, with simplicity and without .of making serious mistakes, we cannot
expect users and others affected by the system to judge it to be acceptable.
Characteristics of Interface
Characteristics of the interface in online systems include the devices used to

enter and receive data, the dialogue which prompts and guides users, and the
methods and patterns followed In display of information.
Common interface devices in online systems are the keyboard mouse, light pen,
scanner, touch screen, or voice.
126
The dialogue guides the interaction between system and user. As we will
see, the dialogue determines the amount of information that must pass between
system and user. The particular design influences the detail one must specify
and the way in which it is articulated. Poor dialogue can undermine the best
interface devices, but the right dialogue can make the boundary between user
and system seems nonexistent.
Users also react to the manner in which information is organized for display
in an online system. The way the physical area of a display is structured, as well
as the particular methods of highlighting and signaling can enhance the
readability of display information.
Actions Occurring at Interface
Three types of actions occur at the system interface. Users tell the system
which pages of information to display or how to move between different
functions. We call this navigation. In addition, the interface includes features that
allow users to signal the system which processing functions to perform. Third,
messages received through the interface inform the user of system actions and
responses. All these activities are necessary and the design features of a system
can either impede or accommodate their performance.
Navigation
In a manual system of reports and documents, users can see how to skip
through the information they have before them. For example, they know that to
begin review of a lengthy report, they must simply flip open the cover. To see the
next page of information, they need only turn the page. They can also tell when
they are near the beginning of the multi-page report, near the end, or somewhere
in the middle.
These actions, which seem so obvious in a manual system, take on

added importance in a computer-based application. Because the display
screen, the user's window into the records and files, presents only one page
of information at a time, the analyst must keep the user informed about
which page is being displayed, how to access other pages, and how to move
about.
Users must always know or be able to find out what to do next, and they
must know which actions are valid. Put yourself in the position of a computer
user examining a display screen filled with information in a new application.
Here are some of the questions you might ask:
Where am I in the system?

Where do I go next?
How do I go to the beginning?
How do I move backward?
127
How do I cancel the effect of my last action?
How do I correct my mistake?
,
You can add others, but the point is that the answers to these important
questions are not as obvious in an online system as they are in \ a manual
system.
Keep in mind a fundamental principle in the design of computer Information

systems. If the system is well-designed, users are hardly aware that there is a
system at all, a point that was emphasized in the vignette at the beginning of
this chapter. The actions they take seem normal and comfortable and can be
taken with little thought; so much so that they are not aware they are using a
computer.
Processing Actions
In our design, we have to include ways to let the user know how to take each of
the following actions
Data entry
The input of data, using any of several data entry methods; includes a
description of each data item and its position on the display screen. The system
must show the user which data item it is addressing as each character is
entered.
Data editing
Changing a previously entered data item. The system must indicate which data
items on a display screen are in edit mode (i.e., can be changed) at a certain
moment.
Data storage
The transfer of data from the active input area to storage, usually on secondary
storage devices such as magnetic disk, diskette, or tape.
Data retrieval
The specification of data or records to be located and retrieved from

storage for display, editing, or output.
As we will see, we can combine the features of menus with navigation needs to
fill these user requirements.
128
Receiving of Messages
An important part of the interface is the communication of messages

between system and user. Individuals want to know when to initiate or take
actions, the status of certain events and activities, and when a task is completed.
Of course, they also need to know when errors and interruptions of processing
occur. These messages are as essential to good systems design as the layout of
a display.
The nature of actions occurring at the interface-navigation through a

system, the selection of processing actions, and the use of messages-will
depend on the dialogue strategy the analyst selects when designing the
application.
DESIGNING DIALOGUE
A dialogue is the user's way to interact with the computer system and
application. Its characteristics not only determine the "friendliness" of the system
but even influence a person's decision to use the system at all. Experience has
shown that if a system is hard to use because of the dialogue, individuals will
tend to avoid the system, even if they could be more productive or effective by
using it.
Dialogue Charts
Analysts often depict the activities in an information system in the form of simple
graphic illustrations. Dialogue charts, as they are called, show what sequence of
activities a system can perform and how to initiate the actions. They also
illustrate how the user can exit (i.e., interrupt) an activity. In a sense, you might
say the dialogue chart is a road map through the system.
Systems analysts often build in user-assistance features in the form of "help

screens". In general, help screens stay behind the scenes until they are needed,
at which time they can be invoked by the user. When invoked, they use all or
part of the display screen to provide information about how to use a certain
function or initiate a particular action. When planning online dialogue that
includes help functions, analysts show these functions residing in the
background by drawing the help screen behind the primary screen.
Dialogue Design Decision
The flow of conversation between user and system is entirely dependent on the
design of the dialogue, a principle that was stressed throughout the vignette at
the beginning of the chapter. An easy-to-use dialogue means that conversation
129
can flow easily. Awkward designs impede system usage. These decisions, which
the analyst must make in designing dialogues, determine the nature of dialogue:
Overall dialogue strategy

Data entry dialogue
Paging and scrolling
Messages and comments
User navigation
Key assignment
Help systems
DIALOGUE STRATEGIES
An online conversation uses one of the three general dialogue strategies: menu-
driven, keyword, or question/answer. The strategy used will largely influence the
user perception of the system. We will see first why novice users rate the menu
form, the most common dialogue strategy, as the simplest and easiest way to
access an information system.
Menu-Driven Dialogue
Since online systems provide several input and processing options to users, a
method is needed to show users the available alternatives. Menus serve
this purpose. A menu is an exhaustive list of available system functions that
are displayed on the terminal or workstation so the user can choose among
them. Dialogues that use this method of interaction are said to be menu-
driven.
Menu Alternatives
If the system is well designed, the user should be able to select and invoke any
menu alternative by depressing a single key that corresponds to the desired
alternative.. To invoke any option, the user need only enter the number
corresponding to the description of the function. Thus, to initiate printing in some
systems, the user need only depress the 4 key.
Menu dialogues can also be designed to use interface devices other than the
keyboard. For example, some systems allow users to select a function by
pointing to it on the screen rather than by keying in a number. Touch-sensitive
screens allow users to initiate an action by touching a spot on the display screen,
termed a soft key. Some systems can accommodate a light pen to invoke the
desired processing or allow the user to move a bar of light over the desired menu
function to be selected. Still others allow users to point 10 the desired option with
a mouse, a small manual interface device. Depressing a button on the mouse
when the pointer is directed at the desired option will invoke the function.
130
The menu of options can be positioned on the display screen in several ways.
Many transaction processing and reporting systems use the main part of the
screen to present options. Sufficient room is available on the display screen to
list a phrase identifying each choice. Two vertical columns can be used if
needed, although a single column should contain at most eight to ten choices.
When the analyst wants to retain business information on the display and at
the same time offer menu selections to users, the menu can be shown
horizontally at the top or bottom of the screen, or vertically down the side of the
display. This approach is commonly used in the design for electronic
spreadsheet software, the display of a transaction or master file record (for
example, the details of an order transaction), or a display of a multiple-line report.
Menu choices can be presented in a single word. This approach, known as

keyword dialogue, assumes that the user understands the purpose of a specific
function so well that seeing a keyword will immediately communicate the
meaning. Single-word menus typically require that only the first letter of the menu
choice be entered. POI example, to print a report, the user may need only enter
P to invoke the printing function.
In systems that use a mouse, it is now common to feature pull down menus.
In this case, when the mouse points to a keyword at the top of the screen, a
menu of alternatives drops down (the mouse pulls down the menu), overwriting a
portion of the screen. The advantage is that the main work area remains on the
screen while permitting several alternatives to be considered very quickly.
Nested Menus
When there is an extensive set of processing alternatives to choose from, menus

are often nested; that is, a selection from one set of choices leads to a
subsequent decision about other alternatives included within the one. In a sense,
the decisions are made in a top. down fashion: general decisions are followed by
more specific choices.
Menus should be nested when one or more of the following conditions

exist:
The number of alternatives is too large to fit on a single computer

screen
A series of interrelated choices must be made (each choice depends on
the previous choice) .
A complicated application may require a series of choices that
progressively specify more detail about the application.
Menu nesting leads the user step-by-step through the choices in a way
that avoids having to choose from an overwhelming or confusing number of
131
options, thus reducing complexity and easing the number of alternatives to
choose from at one time.
However, nested menus can be frustrating to users who rely on the

system daily and use the same features each time. When users know what
choices they want, they may want the ability to enter all choices together, not one
at a time. Similarly, when exiting from the system, it should not be necessary to
step backwards through each choice (from bottom to top). Good design practices
allow a direct exit from the system. Frequently the escape key is used to
implement this feature: Press it to go back to the menu. Press it again to go back
at the main menu for exit to the operating system.
Keyword Dialogue
With the keyword dialogue, users invoke processing activities by entering
a command the system understands. The three forms of keyword dialogue
include the single command, the mnemonic, and the natural language forms.
1. Single Command Form
Under the single command form, users enter the keyword that the system
will associate with the performance of a specific process. The words are
commands that the analyst has built into the system and that programmers will
account for in the source code. Each unique command has special meaning
within the application and will invoke specific processing.
2. Mnemonic Command Form
A special form of single-word command relies on the use of mnemonics,

abbreviations based on longer phrases. For example, the phrase" compile, load,
and execute" is often represented through the simple mnemonic CLGO. Enter
the word in some systems and the actions of three types of processing will begin,
one following the other ("go" means execute in many information systems
groups).
2. Natural Language Form
An increasing number of systems features the natural language form,

which allows users to instruct the system with less rigid commands. Instead of
using conventional command syntax, the users apply their own vocabulary of
words or operations. The application, relying on the technology of expert
systems and artificial intelligence (i.e., determining meaning from the context in
which words are used), automatically translates these words and operations into
instructions it understands to perform the appropriate tasks. The user's
commands are stated in plain English, termed natural language, and the system
itself performs the translation.
132
Natural language systems motivate people to make use of their system
without learning special commands or sequences. The complexity of the
system commands is embedded in the computer software and is not apparent
in the procedures the user follows. Because the system must translate natural
language commands into a form it can understand, this form of system may
operate more slowly during some activities.
Question/ Answer Dialogue

Question/answer dialogues, as their name suggests, rely on the presen-
tation of a question to the user. The answer guides the resulting processing.
The format may involve yes/no answers ("Do you wish to display the
information on a property?") or narrative responses ("Which property do you
wish to review?"). The question/answer strategy allows the presentation of
more elaborate questions and alternatives than do the other strategies. It
requires the analyst to anticipate every possible answer a user might provide, a
potentially difficult task. It is also the wordiest dialogue strategy (thus, the
analyst should minimize the number of words used to speed user-system
interaction and to avoid possible errors).
"
DATA ENTRY DIALOGUES
The entry of data will be affected by the way the system assists users
and prompts them for the data. This section discusses the data entry strategies
of using templates and question/answer prompts.
1. Data Entry Templates

A data entry template is a form or an outline showing the information to be
entered. In addition to titles and headings on the screen, the template contains
labels (or instructions) that identify the data to be entered. It resembles a printed
form on the display screen. Each data entry area is set off by blank areas, field
markers, highlighted spaces, dotted lines, or dashes, as selected by the analyst.
When data are entered into one area, the cursor moves to the next area on
the screen for entry of the item. In the best-designed systems, the software
suggests the sequence of items and the user keys the entry. Alternatively, users
can determine the sequence of moving up and down or back and forth on the
screen using the cursor control arrows, but the extra steps involved make this
less desirable.
Templates are most useful when certain information must be collected and
the details needed can be shown as an electronic form(the operator need only fill
in the form). Templates also offer the advantage of allowing the user to see all
133
information that will be needed at once (in contrast to answering a series of
questions one at a time).
Good design practices ensure that the order of details on the electronic form is
logical and that it corresponds with the natural order in which people usually think
of personal information (e.g., name, then address, then telephone number) or as
it comes off the source document.
2. Question/Answer Prompt
In some systems with small displays (such as a point-of-sale terminal or a
bank card terminal) the question/answer prompt is the only feasible option. It is
not physically possible to show all choices on a single display line.
Users are prompted for data by questions the system poses Notice that a
question is posed and the user then keys in the data before the next question is
asked (of course, several questions could be presented at one time, in which
case the user would provide the information for each one individually).
The question/answer method, which is simple to use, offers the additional
advantage of allowing full control of the sequence in which information is
received.
However, if only one question can be prompted at a time and the

procedure is slow, users will tire of a seemingly endless dialogue. For a single
bank card transaction, this is acceptable, but computer users would not want to
enter thousands of such transactions in this manner.
Editing in Online Systems
In batch systems, when corrections to data are necessary, a new trans-
action containing the corrections is created and submitted for processing,
perhaps as part of a batch other than the one in which the error was made.
However, in online systems, all changes are made through the terminal or
workstation.
Editing refers both to making changes to records already entered or stored or

to the deletion of records.
To understand how editing occurs in an online system, you might consider

addition of new records to be a special case of editing. In other words, when you
enter data to create a new record to store in the system, you are going through
many of the same steps as in editing, including keying in the data you want
stored, making corrections for any keying mistakes, and telling the system to
store the data. The data that are keyed in overwrite blanks, dots, dashes, or lines
on the source document. But you are keying over something. Editing does the
same thing: it allows you to key over something to change the current values.
However, instead of blanks or dashes, it is usually numbers or characters. If you
think of online editing in this manner, it will be quite easy to understand.
134
Identifying Data for Editing
To design an edit function, you must first provide a way for users to tell the
system which record of data they wish to edit.
Deleting Records in Online Editing
Deleting records in online systems requires the analyst to provide a way

for the users to indicate the proper record, as described above, as well as to
instruct the system that the transaction is a deletion.
Two methods are common. The first allows the user to depress a key that
instructs the system to delete the current record on the screen. (Some analysts
use a design that requires the user to change a record key to blanks to delete
records. However, such a design can be desirable, since it is too easy for the
user to forget to blank out the key field.) This method requires that the proper
record first be retrieved and displayed on the screen.
The other method for deleting procedures asks the user to identify the
proper record by entering the record key (such as item number) and then
depressing a key telling the system to delete the record.
Both methods are common, although the first is preferred, since it allows
the user to view the record before telling the system to delete the record. Some
online systems ask for confirmation of the intended deletion before actually
deleting the record from the files.
Screen Management
Display screens should follow an overall design that provides for

consistent usage of the areas or windows on the display. Design concerns
include standardizing window usage, handling of navigation and escape
sequences, and paging and scrolling.
1. Window Usage
The importance of windows, areas of the display screen that present

information independently of other areas of the same screen. Having good
standards for use of windows is essential in online systems and in the dialogue. It
is the basis for good screen management.
Since the area on a computer display is limited, it is important louse the
available area in the best possible fashion, one that is both consistent and
effective. And remember, for the user, the screen is the system. In designing the
system's display screen layouts, the analyst must provide for the following
window areas:
135
Title window
Identifies the title of the screen, function to be performed, or application
running; may include system date.
Instruction window
Tells the user how to enter data, select a processing alternative, or exit
from system; typically includes a single instruction to initiate the next system
action.
Main text window

Largest portion of screen; includes data entry templates, menus or
processing alternatives, or data.
Navigation and menu area

Instructs user how to move between pages of information, display
screens, or menus; also identifies escape information.
Message window
Contains information and control messages.
Flag window
An alternative that may be used to signal current activities or instructions
being processed.
No one window design has been proven best. Several commonly used
ones are shown in Figure. Although this chapter demonstrates several different
window standards, in actual practice a particular application should follow one
standard.
Several guidelines can improve your use of windows. The contents of

windows, particularly the main text area, should page or scroll. The guidelines
for paging and scrolling design apply even though only a portion of the screen is
involved.
When designing error messages to appear in windows, it is essential to

keep in mind their purpose: they signal the status of important events. Thus, their
first purpose is to get the user’s attention; the second is to relay the message.
Analysts often use blinking as a highlighting technique in error messages. With
this method, it is important to keep in mind that the error messages themselves
should not blink (that would make the message too difficult to read). Instead, the
message can be surrounded with a box that blinks. The blinking box will serve as
an effective attention-getter, but it will not impede viewing the message.
The location of the status line should always be consistent (usually it is the
first or last line on an 80-column screen so that it is easy to find. It contains a
brief explanation of system status (for example, it indicates whether the CAPS
136
key is locked on or whether the keyboard is in numeric mode). The status line is
intended for reference only. If additional information is needed, the user can
invoke the help function.
2. Facilitating User Navigation
Users sometimes become lost and thus require a roadmap through the
system. Deeply nested menus can preclude ease of navigation. Consider how
confused users would feel if they have to move through several levels to exit a
system: from the data edit template, to selecting a data verification alternative,
to specifying the customer identification number, to selecting customer versus
item editing, to specifying the edit function, to the main menu, and finally exiting
the system.
Special care should be taken to avoid losing or confusing users when they
are expected to move between two levels or between display screens and
printed source or reference documents:
Use windows to facilitate using information that comes from several
display screens. Most users have difficulty keeping information in short-
term memory (recall how quickly you forget an unfamiliar telephone
number). Designing the system to display reference information
simultaneously with the screen in which it will be used can overcome this
human limitation.
Coordinate the sequence of data items for online and offline usage.
Applications that require comparisons of display and print versions of
information should be designed so that the sequence and location of items
on the two match.
When only part of the information on display changes, redisplay only the
portion that changes; redisplaying the entire screen can confuse users
and cause them to wonder if other items have changed.
3. Paging and Scrolling
Depending on the nature of the application, there may be too much

information to show on a single display screen. Paging can handle such a
situation. A page is one screen of information. With paging, a larger set of
information, occupying more than one display screen, can be presented and
the user can leaf forward or backward through the pages. Page numbers
(typically displayed at the top of the screen) identify which of several displays
is on the screen and guide the user through the information.
Scrolling can be useful when users need to scan individual lines of a

listing. A display is said to scroll when individual data lines roll up or down; as
lines roll off the top of the display, an equivalent number of lines rolls on from the
bottom of the screen.
137
If the user needs the capability to quickly skim the stock number,
description, cost, and quantity on hand of inventory-all the data for one item
will fit on a single line-scrolling is appropriate. The user will find scrolling easier
and quicker than having a separate page for each item.
When designing screens for scrolling, it is important to specify that only the
data should scroll. Headings and messages should remain fixed on the display.
Messages and Comments
Messages are the system's way of communicating with users. Earlier in

discussing dialogue strategies, we indicated that the systems analyst should
develop the method of interaction between the user and the application so that
alternative actions are obvious and the method for invoking each alternative is
evident. Doing this minimizes the amount of explanation needed. Messages also
provide the information users need to control the system. In general, messages
serve one of the following purposes:
Indicate the status of processing
Indicate that an error has been detected .
Request user to select an action
Verify that a selected action is correct
Status Messages
Display screens should never be blank. Otherwise computer users will

wonder what is taking place and they may even initiate inappropriate actions to
interrupt or change what the system does. Status messages inform the user of
the progress being made in specific processing. For example, in searching a
database in response to a query, the system may be designed to tell the user the
number of records examined or the percentage of processing completed.
Similarly, a message can be displayed on the computer screen to show the
record number or record key currently being examined (as the next one is
examined, its number will be displayed over the preceding one).
A display of status is particularly useful when the processing requested

takes place at a location away from the user. For example, in a network
environment, the messages "Report printing" or "Record transmitted" or
"Connected" indicate that the actions are taking place. Otherwise, users may
think that nothing is happening.
Error Messages
138
Error messages report mistakes or unexpected events that the system
has detected. This category covers a wide range of information about the
system, from hardware ("Printer not turned on or improperly connected"), to
software ("Error number 12 encountered in line 5001"), to data ("Unexpected end
of file encountered").
The input validation tests discussed in the last chapter should also be
linked with error messages. If data are missing, out of the ordinary range, or in
incorrect format, the system should tell the operator of an online system about it.
A properly designed error message will accomplish this.
Whenever error messages are displayed, the user should be required to

take an action, even if it is nothing more than depressing a key. In this way, the
likelihood will increase that the user has seen the message. Experience has
proven that in designs where a message displayed for a specified number of
seconds or written to a printed log, they are often not seen by the intended
recipient. The strategy of requiring a response avoids that problem.
Action Request Messages
In our examples, we have used many action request messages. If you

look back through the illustrations, you will see such messages as "Enter your
selection" and "Press the enter key.” These action request messages tell the
user what to do, but they are hardly noticeable because they are so natural. A
brief message, rather than display of a question mark or other graphic prompt, is
preferred for this purpose.
The manner in which the system prompts the user for an action is important.
Messages should be designed to tell users what action to take and when. Yet,
like all messages, action request messages should be brief and unobtrusive.
Action Verification Messages
In general, every command entered should be acknowledged, either by

the immediate initiation of the requested action or by the display of a concise
message. However, requests that will produce significant changes or that may
initiate long-running processes need verification. Analysts should design
messages to inform users of the following conditions:
When large amounts of data (in memory or in files) will be deleted .

When master file records will be deleted
When a long-running process has been requested and it is important to
verify that the user recognizes that the elapsed time will be substantial
(in-memory processing, printing, sorting, indexing, and reading data from
secondary storage)
When termination of processing or exit from the system is requested
139
When termination of communication with another location is requested
Help Systems
Messages and comments are intended to inform, not instruct, system

users. When it is anticipated that some users or some activities may require
brief explanations about a certain activity or process, it may be desirable to
design a help function in the system.
Help functions, which can be in the form of reference responses or more

in-depth explanations, are intended to serve the following purposes:
Aid the user in fixing a problem or completing a task as quickly as
possible; expedite the accomplishment of a task
Use the least amount of dialogue or conversation possible to
accomplish an action by providing answers to essential questions, such
as "What do I do to accomplish. . . .", "How do I . . . .", or "What will
happen if I . . . ."
Help Features
A help system can be designed in any of several ways One form uses an
index of terms and keywords. The user enters the appropriate keyword (perhaps
a command to STORE) and an explanation for using the command is given. A list
of all keywords can be displayed on request if the user is unsure of the proper
keyword. If additional detail is needed, the user can request a second level of
explanation.
A second form uses dialogue to instruct the user in performing the task
step-by-step: "Examine the. . . ; move the. . . " This format is much wordier and
thus is disliked by experienced users. However, the novice user may truly
appreciate the support this method provides.
Some help systems are termed context-sensitive; that is, they deter-
mine what the user is attempting to accomplish and provide information
about the attempted action. For example, they may recognize that an exit at
one level of a system is safe and will not cause the loss of data. But at
another level, say, in the edit portion, an exit before storing the data will
result in the loss of all changes entered to that point. (The help system may
thus tell the user to store the changes before requesting the exit.) The latter
form is more sophisticated than the others because it must keep track of
system activity.
Help Guidelines
140
A common key should always be designated to invoke help, regardless
of the function being performed. Thus, whether doing data entry, editing, or
preparing a report, the user should be able to depress the same key (a "panic
button") and receive assistance. If the individual must stop and think about which
key invokes help In a certain part of the system, the help function will become
part of the problem, not part of the solution.
Help should always involve the entire system; no functions should be

omitted. Imagine how frustrating it is to a user to ask for help and receive a
response indicating that help is not available for that function.
Finally, help should teach the user about using the system, not how to do
the job. Thus, in an accounting application, it is appropriate for help to provide
guidance on how to enter debits and credits or post entries to journals. It is
inappropriate to provide guidance on whether an entry should be a debit or
credit, or to which journal an entry is posted.
141

System Analysis &amp; Design

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

System Analysis &amp; Design

Загружено:

Авторское право:

Доступные форматы

INDEX

TOPIC PAGE NO.

1. INTRODUCTION TO SYSTEM CONCEPT 2--22

2. GENERAL PHASES OF SDLC 23--57

3. REQUIREMENT AND STRUCTRED ANALYSIS 58--92

4. DATABASE DESIGN AND IMPLEMENTATION 93--126

5. USER INTERFACE DESIGN 127--142

Scholars in various disciplines who are concerned about the tendency

Systems analysis and design for information systems were founded in

The study of systems concepts, then, has three basic implications:

2. Interrelationships and interdependence must exist among the components.

Fig 1-1: Organization Structure

Interdependence means that parts of the organization or computer system

To illustrate these system characteristics, Figure 1-2 shows three levels of

Fig1-2: Major Subsystems Of Production Dept.

In summary, no subsystem can function. in isolation because it is dependent

In most cases, systems analysts operate in a dynamic environment where

1. Outputs and inputs.

6. Boundaries and interlace.

A major objective of a system is to produce an output that has value to its

Fig 1-3: Inputs and Outputs in a Business Organization

The control element guides the system. It is the decision-making

Feedback may be positive or negative, routine or informational. Positive

The environment is the "suprasystem" within which an organization

Boundaries and Interface

System should be defined by its boundaries-the limits that identify its

3.”Man-made" information systems.

Physical systems are tangible entities that may be static or dynamic in

Abstract systems are conceptual or nonphysical entities. They may be as

Flow System Models.

Static System Models.

Dynamic System Modals.

Open or Closed Systems

Five important characteristics of open systems can be identified.

4. Differentiation. Open systems have a tendency toward an increasing

Understanding system characteristics helps analysts to identify their role and

Ideally, information reduces uncertainty about a state or event. For

Many practitioners fail to recognize that a business has several informa-

Formal Information Systems

Categories of Information. There are three categories of information related

The second level of information is managerial information. It is of direct use to

The third information level is operational information, which is short-term, daily

Fig: 1-5 : Management and Information Levels in a Organization.

Therefore, in designing an information system, the analyst needs to determine

Informal Information Systems

The formal information system is a power structure designed to achieve

Computer-Based information Systems

A third class of information system relies on the computer for handling

Management Information Systems (MIS).

The computer has had a significant impact on the techniques used by

MIS is a person-machine system and a highly integrated grouping of

A key element of MIS is the data base a non redundant collection of

There are several advantages to a data base system:

1. Processing time and the number of programs written are substantially

2. All applications share centralized files.

3. Storage space duplication is eliminated.

A major problem encountered in MIS design is obtaining the acceptance

Decision Support Systems (DSS)

Decision--emphasizes decision making in problem situations, not information

Support--requires computer-adided decision situations with enough "structure" to

Fig 1-6 :Decision Making Process

Beginning with management decision systems in the early 1970s, the

The intelligence phase of decision making involves the awareness of a

System Analysis & Design

System Analysis & Design