Zion Technology and Business College

Department of Management

Course Title: - System Analysis and Design for Business

Management
Course Code: BUMA 401
Credit Hours: [Link]

2010 E.C
Hawassa, Ethiopia
CHAPTER 1:- SYSTEM AN OVERVIEW
[Link] Analysis and Design
Systems development is systematic process which includes phases such as planning, analysis, design,
deployment, and maintenance. Here, in this part, we will primarily focus on:
Systems Analysis
It is a process of collecting and interpreting facts, identifying the problems, and decomposition of a
system into its components.
System analysis is conducted for the purpose of studying a system or its parts in order to identify its
objectives. It is a problem solving technique that improves the system and ensures that all the
components of the system work efficiently to accomplish their purpose. Analysis specifies what the
system should do.
 System Design
It is a process of planning a new business system or replacing an existing system by defining its
components or modules to satisfy the specific requirement s. Before planning, you need to understand the
old system thoroughly and determine how computers can best be used in order to operate efficiently. System
Design focuses on how to accomplish the objective of the system. System Analysis and Design (SAD)
mainly focuses on:
System
Processes
Technology
[Link] and its Components
What is system?
The word System is derived from Greek word Systema, which means an organized relationship
between any set of components to achieve some common cause or objective.
A system is ―an orderly grouping of interdependent components linked together according to a plan to
achieve a specific goal.‖
A System is an interrelated set of business procedures (or components) used within one business unit,
working together for some purpose. For Example: - an inventory system in the materials department keeps
track of the raw materials supply.
 The system takes input from outside, processes it, and sends the resulting output back to its environment.
 A system can also defined as collections of people using information technology and processes that
define how people carry out their work. The system also includes informal interactions that take place in
an organization Ex. emails, phone calls.
Characteristics of a System
A System has nine characteristics
A. Organization:-Organization implies structure and order. It is the arrangement of components that helps to
achieve predetermined objectives.
System Analysis and Design Page 1
B. Interaction:-It is defined by the manner in which the components operate with each other. For example,
in an organization, purchasing department must interact with production department and payroll with
personnel department.
C. Interdependence:- Interdependence means how the components of a system depend on one
another. For proper functioning, the components are coordinated and linked together according to a
specified plan. The output of one subsystem is the required by other subsystem as input.
D. Integration: - Integration is concerned with how system components are connected together. It means that
the parts of the system work together within the system even if each part performs a unique function.
E. Central Objective:-The objective of system must be central. It may be real or stated. It is not uncommon
for an organization to state an objective and operate to achieve another. The users must know the main
objective of a computer application early in the analysis for a successful design and conversion.
F. Components – A component is either an irreducible part or an aggregate of parts, also called as a
subsystem.
G. Interrelated Components – The function of one component is tied to the functions of the others. Output
from one is input for another, the dependence of a part on one or more other parts.
H. Boundary – A system has boundary, within which all of its components are contained and which
establishes the limits of a system, separating it from other systems. Components within the boundary can
be changed whereas systems outside the boundary cannot be changed.

Figure-1: Characteristics of System

I. Purpose – All components work together to achieve the overall purpose of the system.
[Link] – A system exist within an environment, everything outside the system’s boundary that
influences and / or interacts the system.
K. Interfaces – The points at which the system meets its environment and there are also interfaces between
subsystems.
L. Input – System takes input from its environment

System Analysis and Design Page 2

[Link] - System returns output to its environment as a result of its functioning to achieve the purpose.
Output from individual subsystems may be inputs to other subsystems.
N. Constraints – There are limits to what the system can do (capacity, speed, and capability), some of these
constraints are imposed inside the system and others are imposed by the environment.
Some important Systems concepts
 Decomposition – is the process of breaking down a system into its smaller components, decomposing a
system also allows us to focus on one particular part of a system, making it easier to think of how to modify
that one part independently of the entire system.
 Modularity is a direct result of decomposition which divides a system into modules of a relatively uniform
size. This makes it easier to understand the system.
 Coupling means that subsystems are dependent on each other, messages are passed between subsystems.
A good system will have very independent subsystems with minimal flows of data between them. This
makes the system simpler and easier to change just one part of the system without affecting the other parts.
 Cohesion is the extent to which a subsystem performs single functions. Generally coupling must be
reduced and cohesion increased, so that it performs only one function.
Constraints of system
A system must have three basic constraints:
1.A system must have some structure and behavior which is designed to achieve a predefined objective.
[Link] and interdependence must exist among the system components.
[Link] objectives of the organization have a higher priority than the objectives of its subsystems.
For example, traffic management system, payroll system, automatic library system, human resources
information system.
Types of Systems
The systems can be divided into the following types:
1. Physical or Abstract Systems
Physical systems are tangible entities. We can touch and feel them.
Physical System may be static or dynamic in nature. For example, desks and chairs are the physical parts
of computer center which are static. A programmed computer is a dynamic system in which programs,
data, and applications can change according to the user's needs.
Abstract systems are non-physical entities or conceptual that may be formulas, representation or model
of a real system.
[Link] or Closed Systems
An open system must interact with its environment. It receives inputs from and delivers outputs to the
outside of the system. For example, an information system which must adapt to the changing
environmental conditions.
A closed system does not interact with its environment. It is isolated from environmental influences. A
completely closed system is rare in reality.
System Analysis and Design Page 3
 [Link] and Non Adaptive System
Adaptive System responds to the change in the environment in a way to improve their performance and
to survive. For example, human beings, animals.
Non Adaptive System is the system which does not respond to the environment. For example, machines.
[Link] or Temporary System
Permanent System persists for long time. For example, business policies.
Temporary System is made for specified time and after that they are demolished. For example, A DJ
system is set up for a program and it is dissembled after the program.
[Link] and Manufactured System
Natural systems are created by the nature. For example, Solar system, seasonal system.
Manufactured System is the man-made system. For example, Rockets, dams, trains.
[Link] or Probabilistic System
Deterministic system operates in a predictable manner and the interaction between system components
is known with certainty. For example, two molecules of hydrogen and one molecule of oxygen make
water.
Probabilistic System shows uncertain behaviour. The exact output is not known. For example, Weather
forecasting, mail delivery.
[Link], Human-Machine, Machine System
Social System is made up of people. For example, social clubs, societies.
In Human-Machine System, both human and machines are involved to perform a particular task. For
example, Computer programming.
Machine System is where human interference is neglected. All the tasks are performed by the machine.
For example, an autonomous robot.
[Link]–Made Information Systems
It is an interconnected set of information resources to manage data for particular organization, under
Direct Management Control (DMC).
This system includes hardware, System , communication, data, and application for producing
information according to the need of an organization. Man-made information systems are divided into
three types:
o Formal Information System: It is based on the flow of information in the form of memos,
instructions, etc., from top level to lower levels of management.
o Informal Information System: This is employee based system which solves the day to day work
related problems.
o Computer Based System: This system is directly dependent on the computer for managing business
applications. For example, automatic library system, railway reservation system, banking system, etc.
1.4. Fundamentals of Information Systems

System Analysis and Design Page 4

 What is an Information System?
An Information System is an arrangement of people, data, processes, interfaces, networks and technology
that interact for the purpose of supporting and improving both day-to-day operations in a business (data
processing) as well as supporting the problem solving and decision making needs of management (information
services).
An information system (IS) can be any organized combination of people, hardware, System ,
communications networks, and data resources that collects, transforms, and disseminates information in an
organization.
The Information System includes the following
 Hardware – Computers, servers and printers
 System – System and application System.
 Documentation and training materials – The materials created by Systems Analyst to help users to use
the System
 Specific job roles – The roles associated with the overall system, such as the people who run the computers
and the System operating.
 Controls- which are the parts of the System written to prevent fraud and theft
 People- Who uses the System in order to do their job.
Documents Information Technology

People
Database
Informal
Interactions
Computer
Network

Processes

Figure-2:The basic components of a computer based information system People, Processes, IT and informal interactions

System Analysis and Design Page 5

 Figure-3: Components of IS Application
Why Information Systems Are Important:
An understanding of the effective and responsible use and management of information systems is important
for managers and other business knowledge workers in today’s global information society. Information
systems and technologies have become a vital component of successful businesses and organizations.
Information systems constitute an essential field of study in business administration and management, as they
are considered a major functional area in business operations.
What you (managers) need to Know:
Managerial end users need to know how information systems can be employed successfully in a business
environment. The important question for any business end user or manager is: What do you need to know in
order to help manage the hardware, System , data, and network resources of your business, so they are used for
the strategic success of your company?
Foundation Concepts - basic behavioral, technical, business, and managerial concepts about components and
roles of IS
Business Applications - major uses of IS for the operations, management, and competitive advantage of an E-
business enterprise, including electronic business, commerce, decision-making using the Internet, intranets,
and Extranets
Development Processes - how business professionals and information specialists plan, develop and
implement IS to meet E-business opportunities using several strategic planning and application development
approaches.
Management Challenges - challenges of effectively and ethically managing E-business technologies,
strategies, and security at the end user, enterprise, and global levels of a business.

System Analysis and Design Page 6

Information Technologies - Major concepts, developments, and management issues in IT (hardware, System
, networks, data resource management, and other information processing technologies such as the Internet).
A system (sometimes called a dynamic system) has three basic interacting components or functions. These
include:
 Input involves capturing and assembling elements that enter the system to be processed.
 Processing involves transformation processes that convert input into output.
 Output involves transferring elements that have been produced by a transformation process to their
ultimate destination.
Two additional components of the system concept include feedback and control. A system with feedback and
control components is sometimes called a cybernetic system, that is, a self-monitoring, self-regulating system.
 Feedback is data about the performance of a system.
 Control involves monitoring and evaluating feedback to determine whether a system is moving toward
the achievement of its goals. The control function then makes necessary adjustments to a system's input and
processing components to ensure that it produces proper output.
Components of an Information System:
An information system model expresses a fundamental conceptual framework for the major components and
activities of information systems. An information system depends on the resources of people, hardware,
System , data, and networks to perform input, processing, output, storage, and control activities that convert
data resources into information products.
The information systems model outlined in the text emphasizes four major concepts that can be applied to all
types of information systems:
 People, hardware, System , data, and networks, are the five basic resources of information systems.
 A people resource include end users and IS specialists, hardware resources consist of machines and
media, System resources include both programs and procedures, data resources can include data and
knowledge bases, and network resources include communications media and networks.
 Data resources are transformed by information processing activities into a variety of information
products for end users.
 Information processing consists of input, processing, output, storage, and control activities
Information System Resources:
The basic IS model shows that an information system consists of five major resources:
 People resources
 Hardware resources
 System resources
 Data resources
 Network resources
People Resources:

System Analysis and Design Page 7

People are required for the operation of all information systems. This people resource include end users and IS
specialists.
 End Users (also called users or clients) are people who use an information system or the information it
produces. Most of us are information system end users. And most end users in business are knowledge
workers, that is, people who spend most of their time communicating and collaborating in teams of
workgroups and creating, using, and distributing information.
 IS Specialists are people who develop and operate information systems. They include system analysts,
System developers, system operators, and other managerial, technical, and clerical IS personnel.
o Systems analysts – design information systems based on the information requirements of end users.
(Example- LIB)
o System developers – create computer programs based on the specifications of systems analysts.
o System operators – monitor and operate large computer systems and networks.
Hardware Resources:
Hardware resources include all physical devices and materials used in information processing.
 Machines - physical devices (computers, peripherals, telecommunications networks, etc.)
 Media - all tangible objects on which data are recorded (paper, magnetic disks etc.)
Examples of hardware in computer-based information systems are:
 Computer Systems: - which consist of central processing units containing microprocessors, and a
variety of interconnected peripheral devices.
 Computer peripherals – which are devices such as a keyboard or electronic mouse for input of data
and commands, a video screen or printer for output of information, and magnetic or optical disks for
storage of data resources.
System Resources:
System resources include all sets of information processing instructions.
 Program - a set of instructions that causes a computer to perform a particular task.
 Procedures - set of instructions used by people to complete a task.
Examples of System resources are:
 System System – such as an operating system program, which controls and supports the operations of
a computer system. (e.g. Win, UNIX)
 Application System – are programs that direct processing for a particular use of computers by end
users. (Word, Photoshop)
 Procedures – are operating instructions for the people who will use an information system.
Data Resources:
Data versus Information: The word data is the plural of datum, though data is commonly used to represent
both singular and plural forms. The term’s data and information are often used interchangeably. However,
you should make the following distinction:

System Analysis and Design Page 8

Data: - are raw facts or observations, typically about physical phenomena or business transactions. More
specifically, data are objective measurements of the attributes (characteristics) of entities, such as people,
places, things, and events.
Information: - is processed data, which has been placed in a meaningful and useful context for an end user.
Data is subjected to a ―value-added‖ process (data processing or information processing) where:
 Its form is aggregated, manipulated, and organized.
 Its content is analyzed and evaluated
 It is placed in a proper context for a human user
Data constitutes a valuable organizational resource. Thus, data resources must be managed effectively to
benefit all end users in an organization. The data resources of information systems are typically organized
into:
 Databases - a collection of logically related records or files. A database consolidates many records
previously stored in separate files so that a common pool of data records serves many applications.
 Knowledge Bases - which hold knowledge in a variety of forms such as facts and rules of inference
about various subjects?
Network Resources:
Telecommunications networks like the Internet, intranets, and Extranets have become essential to the
successful electronic business and commerce operations of all types of organizations and their computer-
based information systems. Telecommunications networks consist of computers, communications
processors, and other devices interconnected by communications media and controlled by communications
System . The concept of network resources emphasizes that communications networks are a fundamental
resource component of all information systems. Network resources include:
 Communications media (twisted-pair wire, coaxial cable, fiber-optic cable, and microwave, cellular,
and satellite wireless systems.
 Network support (people, hardware, System , and data resources that directly support the operation
and use of a communications network).
Information System Activities:
Information processing (or data processing) activities that occur in information system include the
following:
 Input of data resources
 Processing of data into information
 Output of information products
 Storage of data resources
 Control of system performance (based on feedback)
Input of Data Resources:
 Data about business transactions and other events must be captured and prepared for processing by the

System Analysis and Design Page 9

 input activity. Input typically takes the form of data entry activities such as recording and editing.
 Once entered, data may be transferred onto a machine-readable medium such as magnetic disk or type,
until needed for processing.
Processing of Data into Information:
 Data is typically subjected to processing activities such as calculating, comparing, sorting, classifying,
and summarizing. These activities organize, analyze, and manipulate data, thus converting them into
information for end users.
 Quality of data stored in an information system must be maintained by a continual process of
correcting and updating activities.
Output of Information Products:
 Information in various forms is transmitted to end-users and made available to them in the output
activity. The goal of information systems is the production of appropriate information products for end
users.
Information Quality:
What characteristics would make information valuable and useful to you?
 Examine the characteristics or attributes of information quality. Information that is outdated,
inaccurate, or hard to understand would not be very meaningful, useful, or valuable to you or other end
users.
 People want information of high quality, that is, information products whose characteristics, attributes,
or qualities help make it valuable to them.
 Three dimensions of information are time, content, and form.
Storage of Data Resources:
Storage is a basic system component of information systems.
 Storage is the information system activity in which data and information are retained in an organized
manner for later use.
Control of System Performance:
An important information system activity is the control of its performance.
 An information system should produce feedback about its input, processing, output, and storage
activities.
 Feedback must be monitored and evaluated to determine if the system is meeting established
performance standards.
 Feedback is used to make adjustments to system activities to correct deficiencies.
The Fundamental Roles of IS Applications in Business:
Information systems perform three vital roles in any type of organization. That is, they support an
organization’s:
 Business processes and operations

System Analysis and Design Page 10

  Decision making by employees and managers
 Strategies for competitive advantage
The roles given to the information systems function have expanded significantly over the years.
1950s - 1960s - Data Processing - Electronic data processing systems
Role: Transaction processing, record keeping, and accounting, and other electronic data processing (EDP)
applications
1960s - 1970s - Management Reporting – Management information systems
Role: Providing managerial end users with predefined management reports that would give managers the
information they needed for decision-making purposes.
1970s - 1980s - Decision Support - Decision support systems
Role: The new role for information systems was to provide managerial end users with ad hoc support of their
decision-making process. This support would be tailored to the unique decision-making styles of managers as
they confronted specific types of problems in the real world.
1980s - 1990s - Strategic and End User Support
Role: End users could use their own computing resources to support their job requirements instead of waiting
for the indirect support of corporate information services departments.
1990s - 2000 – Electronic business and commerce systems
Role: The rapid growth of the Internet, intranets, Extranets, and other interconnected global networks has
revolutionizing the operations and management of today’s business enterprises.
The E-Business Enterprise:
The explosive growth of the Internet and related technologies and applications is revolutionizing the way
businesses are operated and people work, and how information technology supports business operations and
end user work activities.
Businesses are becoming E-business enterprises. The Internet and Internet-like networks inside the
enterprise (Intranets) and between an enterprise and its trading partners (Extranets) have become the primary
information technology infrastructure that supports the business operations of many companies. E-business
enterprises rely on such technologies to: they help:
 Reengineer and revitalize internal business processes.
 Implement electronic commerce systems among businesses and their customers and suppliers.
 Promote enterprise collaboration among business teams and workgroups.
E-business is defined as the use of Internet technologies to internetwork and empower business processes,
electronic commerce, and enterprise communication and collaboration within a company and with its
customers, suppliers, and other business stakeholders.
Enterprise collaboration systems involve the use of GroupWare tools to support communication,
coordination, and collaboration among the members of networked teams and workgroups. An internetworked

System Analysis and Design Page 11

E-business enterprise depends on Intranets, the Internet, Extranets, and other networks to implement such
systems.
Electronic commerce is the buying and selling, and marketing and servicing of products, services, and
information over a variety of computer networks. An internetworked E-business enterprise uses the Internet,
intranets, Extranets, and other networks to support every step of the commercial process.
Developing Business/IT Solutions:
Developing information system solutions to business problems is the responsibility of many business
professionals today. For example:
 As a business professional, you will be responsible for proposing or developing new or improved uses of
information technology for your company.
 As a business manager, you will frequently manage the development efforts of information systems
specialists and other business end users.
Managerial Challenges of Information Technology:
For managerial end users, the information systems function represents:
 A major functional area of business that is important to a business’ success
 An important factor affecting operational efficiency, employee productivity and morale, and customer
service and satisfaction.
 A major source of information and support needed to promote effective decision making by managers.
 An important ingredient in developing competitive products and services that give an organization a
strategic advantage in the marketplace.
 A major part of the resources of an organization and its cost of doing business
 A vital, dynamic, and challenging career opportunity for many men and women.
Ethics and IT:
As a prospective managerial end user and knowledge worker in a global society, you should also become
aware of the ethical responsibilities generated by the use of information technology. For example:
 What uses of information technology might be considered improper, irresponsible, or harmful to other
individuals or to society?
 What is the proper use of an organization’s information resources?
 What does it take to be a responsible end user of information technology?
 How can you protect yourself from computer crime and other risks of information technology? (will be
explained later)
1.5. Types of Information System Overviews (DSS, MIS, ES TPS)
An information system is a collection of hardware, System , data, people and procedures that are designed to generate
information that supports the day-to-day, short-range, and long-range activities of users in an organization. Information
systems generally are classified into five categories: office information systems, transaction processing systems,
management information systems, decision support systems, and expert systems. The following sections present each of
these information systems.
System Analysis and Design Page 12
 1. Office Information Systems
An office information system, or OIS (pronounced oh-eye-ess), is an information system that uses hardware, System
and networks to enhance work flow and facilitate communications among employees. Win an office information
system, also described as office automation; employees perform tasks electronically using computers and other
electronic devices, instead of manually. With an office information system, for example, a registration department
might post the class schedule on the Internet and e-mail students when the schedule is updated. In a manual system, the
registration department would photocopy the schedule and mail it to each student’s house.
An office information system supports a range of business office activities such as creating and distributing graphics
and/or documents, sending messages, scheduling, and accounting. All levels of users from executive management to
non-management employees utilize and benefit from the features of an OIS.
The System an office information system uses to support these activities include word processing, spreadsheets,
databases, presentation graphics, e-mail, Web browsers, Web page authoring, personal information management, and
groupware. Office information systems use communications technology such as voice mail, facsimile (fax),
videoconferencing, and electronic data interchange (EDI) for the electronic exchange of text, graphics, audio, and video.
An office information system also uses a variety of hardware, including computers equipped with modems, video
cameras, speakers, and microphones; scanners; and fax machines.
2. Transaction Processing Systems
A transaction processing system (TPS) is an information system that captures and processes data generated during an
organization’s day-to-day transactions. A transaction is a business activity such as a deposit, payment, order or
reservation.
Clerical staff typically performs the activities associated with transaction processing, which include the following:
1. Recording a business activity such as a student’s registration, a customer’s order, an employee’s timecard or a
client’s payment.
2. Confirming an action or triggering a response, such as printing a student’s schedule, sending a thank-you note to a
customer, generating an employee’s paycheck or issuing a receipt to a client.
3. Maintaining data, which involves adding new data, changing existing data, or removing unwanted data.
Transaction processing systems were among the first computerized systems developed to process business data – a
function originally called data processing. Usually, the TPS computerized an existing manual system to allow for
faster processing, reduced clerical costs and improved customer service.
The first transaction processing systems usually used batch processing. With batch processing, transaction data is
collected over a period of time and all transactions are processed later, as a group. As computers became more
powerful, system developers built online transaction processing systems. With online transaction processing (OLTP)
the computer processes transactions as they are entered. When you register for classes, your school probably uses
OLTP. The registration administrative assistant enters your desired schedule and the computer immediately prints your
statement of classes. The invoices, however, often are printed using batch processing, meaning all student invoices are
printed and mailed at a later date.
Today, most transaction processing systems use online transaction processing. Some routine processing tasks such as
calculating paychecks or printing invoices, however, are performed more effectively on a batch basis. For these
activities, many organizations still use batch processing techniques.
3. Management Information Systems

System Analysis and Design Page 13

While computers were ideal for routine transaction processing, managers soon realized that the computers’ capability of
performing rapid calculations and data comparisons could produce meaningful information for management.
Management information systems thus evolved out of transaction processing systems. A management information
system, or MIS (pronounced em-eye-ess), is an information system that generates accurate, timely and organized
information so managers and other users can make decisions, solve problems, supervise activities, and track progress.
Because it generates reports on a regular basis, a management information system sometimes is called a management
reporting system (MRS).
Management information systems often are integrated with transaction processing systems. To process a sales order, for
example, the transaction processing system records the sale, updates the customer’s account balance, and makes a
deduction from inventory. Using this information, the related management information system can produce reports that
recap daily sales activities; list customers with past due account balances; graph slow or fast selling products; and
highlight inventory items that need reordering. A management information system focuses on generating information
that management and other users need to perform their jobs.
An MIS generates three basic types of information: detailed, summary and exception. Detailed information typically
confirms transaction processing activities. A Detailed Order Report is an example of a detail report. Summary
information consolidates data into a format that an individual can review quickly and easily. To help synopsize
information, a summary report typically contains totals, tables, or graphs. An Inventory Summary Report is an example
of a summary report.
Exception information filters data to report information that is outside of a normal condition. These conditions, called
the exception criteria, define the range of what is considered normal activity or status. An example of an exception
report is an Inventory Exception Report is an Inventory Exception Report that notifies the purchasing department of
items it needs to reorder. Exception reports help managers save time because they do not have to search through a
detailed report for exceptions. Instead, an exception report brings exceptions to the manager’s attention in an easily
identifiable form. Exception reports thus help them focus on situations that require immediate decisions or actions.
4. Decision Support Systems
Transaction processing and management information systems provide information on a regular basis. Frequently,
however, users need information not provided in these reports to help them make decisions. A sales manager, for
example, might need to determine how high to set yearly sales quotas based on increased sales and lowered product
costs. Decision supports systems help provide information to support such decisions.
A decision support system (DSS) is an information system designed to help users reach a decision when a decision-
making situation arises. A variety of DSSs exist to help with a range of decisions.
A decision support system uses data from internal and/or external sources.
Internal sources of data might include sales, manufacturing, inventory, or financial data from an organization’s
database. Data from external sources could include interest rates, population trends, and costs of new housing
construction or raw material pricing. Users of a DSS, often managers, can manipulate the data used in the DSS to help
with decisions.
Some decision support systems include query language, statistical analysis capabilities, spreadsheets, and graphics that
help you extract data and evaluate the results. Some decision support systems also include capabilities that allow you to
create a model of the factors affecting a decision. A simple model for determining the best product price, for example,
would include factors for the expected sales volume at each price level. With the model, you can ask what-if questions

System Analysis and Design Page 14

by changing one or more of the factors and viewing the projected results. Many people use application System
packages to perform DSS functions. Using spreadsheet System , for example, you can complete simple modeling tasks
or what-if scenarios.
A special type of DSS, called an executive information system (EIS), is designed to support the information needs of
executive management. Information in an EIS is presented in charts and tables that show trends, ratios, and other
managerial statistics. Because executives usually focus on strategic issues, EISs rely on external data sources such as
the Dow Jones News/Retrieval service or the Internet. These external data sources can provide current information on
interest rates, commodity prices, and other leading economic indicators.
To store all the necessary decision-making data, DSSs or EISs often use extremely large databases, called data
warehouses. A data warehouse stores and manages the data required to analyze historical and current business
circumstances.
5. Expert Systems
An expert system is an information system that captures and stores the knowledge of human experts and then imitates
human reasoning and decision-making processes for those who have less expertise. Expert systems are composed of
two main components: a knowledge base and inference rules. A knowledge base is the combined subject knowledge
and experiences of the human experts. The inference rules are a set of logical judgments applied to the knowledge base
each time a user describes a situation to the expert system.
Although expert systems can help decision-making at any level in an organization, non-management employees are the
primary users who utilize them to help with job-related decisions. Expert systems also successfully have resolved such
diverse problems as diagnosing illnesses, searching for oil and making soup.
Expert systems are one part of an exciting branch of computer science called artificial intelligence. Artificial
intelligence (AI) is the application of human intelligence to computers. AI technology can sense your actions and, based
on logical assumptions and prior experience, will take the appropriate action to complete the task. AI has a variety of
capabilities, including speech recognition, logical reasoning, and creative responses.
Experts predict that AI eventually will be incorporated into most computer systems and many individual System
applications. Many word processing programs already include speech recognition.
Integrated Information Systems
With today’s sophisticated hardware, System and communications technologies, it often is difficult to classify a system
as belonging uniquely to one of the five information system types discussed. Much of today’s application System
supports transaction processing and generates management information. Other applications provide transaction
processing, management information, and decision support. Although expert systems still operate primarily as separate
systems, organizations increasingly are consolidating their information needs into a single, integrated information
system.
1.6. System and System Analyst- A key resource
 A system analyst bridges the communication gap between those who need the information system and
those who understand the technology
 A system analyst facilitates the study of the problems and needs of a business to determine how the
business systems and information technology can best solve the problem and accomplish improvements for
the business.

System Analysis and Design Page 15

 Involving End users – it is important to include the people (users or end users) who are involved in the
system. Since,
o They use the system, or will use the new system
o They know about the data and / or processes in the system
o They require reports from the system
 Involving mangers – managers in the business also need to be considered, since
o They define the business goals for projects
o They need to know what resources are required for a project
o They need to know how long the project will take
o They make the decisions
 To succeed as a systems analyst, the skills needed are analytical, technical, managerial and interpersonal.
 Analytical skill enables to understand the organization and its functions, to identify opportunities and
problems and to analyze and solve problems
 Technical skill helps to understand the potential and the limitations of information technology. Must be
able to work with programming languages and operating systems.
 Managerial skill helps to manage project, resources, risk and changes.
 Interpersonal skill enables to work with end users as well as other analysts and programmers. Effective
written and oral communication skills: a system analyst plays a major role as liaison among users,
programmers and other analyst. Hence effective written and oral communication skill, including
competence in leading meetings, interviewing end users, and listening are very much required.

CHAPTER 2: INFORMATION SYSTEMS DEVELOPMENT PROJECT

2.1. Managing Information System Project

System Analysis and Design Page 16

System project management is an essential part of system analysis and design. Projects need to be managed
because professional system analysis and design is always subject to organizational budget and schedule
constraints. The project manager’s job is to ensure that the system project meets and overcomes these
constraints as well as delivering high-quality system. The success criteria for project management obviously
vary from project to project but, for most projects, important goals are:
1. Deliver the system to the customer at the agreed time.
2. Keep overall costs within budget.
3. Deliver system that meets the customer’s expectations.
4. Maintain a happy and well-functioning development team.
Project managers take responsibility at some stage for some or all of the following activities:
1. Project planning
Project managers are responsible for planning, estimating and scheduling project development, and assigning
people to tasks. They supervise the work to ensure that it is carried out to the required standards and monitor
progress to check that the development is on time and within budget.
2. Reporting Project
Managers are usually responsible for reporting on the progress of a project to customers and to the managers
of the company developing the system. They have to be able to communicate at a range of levels, from
detailed technical information to management summaries. They have to write concise, coherent documents
that abstract critical information from detailed project reports. They must be able to present this information
during progress reviews.
3. Risk management
Project managers have to assess the risks that may affect a project, monitor these risks, and take action when
problems arise.
4. People management
Project managers are responsible for managing a team of people. They have to choose people for their team
and establish ways of working that lead to effective team performance.
5. Proposal writing
The first stage in a system project may involve writing a proposal to win a contract to carry out an item of
work. The proposal describes the objectives of the project and how it will be carried out. It usually includes
cost and schedule estimates and justifies why the project contract should be awarded to a particular
organization or team. Proposal writing is a critical task as the survival of many system development
companies depends on having enough proposals accepted and contracts awarded. There can be no set
guidelines for this task; proposal writing is a skill that you acquire through practice and experience.
2.1. Project Planning
Project planning includes the following activities:
A. Describing project scope, alternatives and feasibility

System Analysis and Design Page 17

This is Helps to understand the content and complexity of a project. Feasibility study: - determine if the
information system makes sense for the organization from an economic and operational standpoint.
B. Dividing the project into manageable tasks:-
Work breakdown structure: defining task and their sequence. (Some tasks can be parallel/or sequential).
Defining tasks in too much detail will make the management of the project unnecessarily complex. Through
experience, you will develop the skill of discovering the optimal level of detail for representing tasks. For
example, it may be difficult to list tasks that require less than one hour of time to complete in a final work
breakdown structure. Alternatively, choosing tasks that are too large in scope (e.g., several weeks long) will
not provide you with a clear sense of the status of the project or of the interdependencies between tasks.
Example: Work break down structure for gathering/defining requirements
Defining Requirements
Interview
Designing Interview Form
Schedule Appointments
Conduct interview
Review Current Reports
Collect reports
Review reports
Summarize Results
C. Estimating resource and creating resource plan
The goal of this activity is to estimate resource requirements for each project activity and use this information
to create a project resource plan. The resource plan helps assemble and deploy resources in the most effective
manner.
D. Developing a preliminary schedule
During this activity, you use the information on tasks and resource availability to assign time estimates to
each activity in the work breakdown structure. These time estimates will allow you to create target starting
and ending dates for the project. Target dates can be revisited and modified until a schedule produced is
acceptable to the customer. The schedule may be represented as a Gantt chart or network diagram which is
going to be discussed later in this chapter.
E. Developing a communication plan
The goal of this activity is to outline the communication procedures among management, project team
members, and the customer. The communication plan includes when and how written and oral reports will be
provided by the team, how team members will coordinate work, what messages will be sent to announce the
project to interested parties, and what kinds of information will be shared with vendors and external
contractors involved with the project.
F. Determining project standard and procedure
During this activity, you specify how various deliverables are produced and tested by you and your project
team. For example, the team must decide on which tools to use, how the standard SDLC (System
Development Life Cycle) might be modified, which SDLC methods will be used, documentation styles (e.g.,

System Analysis and Design Page 18

type fonts and margins for user manuals), how team members will report the status of their assigned
activities, and terminology.
G. Identifying and assessing risk
The goal of this activity is to identify sources of project risk and to estimate the consequences of those risks.
Risks might arise from the use of new technology, prospective users’ resistance to change, availability of
critical resources, competitive reactions or changes in regulatory actions due to the construction of a system,
or team member inexperience with technology or the business area. You should continually try to identify
and assess project risk.
H. Creating a preliminary budget
During this phase, you need to create a preliminary budget that outlines the planned expenses and revenues
associated with your project. The project justification will demonstrate that the benefits are worth these costs.
I. Developing a project scope statement
An important activity that occurs near the end of the project planning phase is the development of the project
scope statement. Developed primarily for the customer, this document outlines work that will be done and
clearly describes what the project will deliver.
J. Setting a baseline project plan
Once all of the prior projects planning activities have been completed, you will be able to develop a baseline
project plan. This baseline plan provides an estimate of the project’s tasks and resource requirements and is
used to guide the next project phase execution. As new information is acquired during project execution, the
baseline plan will continue to be updated.
2.2. Cost estimation
Project schedule estimation is difficult. You may have to make initial estimates on the basis of a high-level
user requirements definition. The system may have to run on unfamiliar computers or use new development
technology. The people involved in the project and their skills will probably not be known. There are so
many uncertainties that it is impossible to estimate system development costs accurately during the early
stages of a project. There are two types of technique that can be used to do this:
[Link]-based techniques: The estimate of future effort requirements is based on the manager’s
experience of past projects and the application domain. Essentially, the manager makes an informed
judgment of what the effort requirements are likely to be.
[Link] cost modeling: In this approach, a formulaic approach is used to compute the project
effort based on estimates of product attributes, such as size, and process characteristics, such as
experience of staff involved.
2.2.1. Experience-based techniques
Experience-based techniques rely on the manager’s experience of past projects and the actual effort expended
in these projects on activities that are related to system development. Typically, you identify the deliverables
to be produced in a project and the different system components or systems that are to be developed. You

System Analysis and Design Page 19

document these in a spreadsheet, estimate them individually, and compute the total effort required. It usually
helps to get a group of people involved in the effort estimation and to ask each member of the group to
explain their estimate. This often reveals factors that others have not considered and you then iterate towards
an agreed group estimate. The difficulty with experience-based techniques is that a new System project may
not have much in common with previous projects. System development changes very quickly and a project
will often use unfamiliar techniques
2.2.2. Algorithmic cost modeling
Algorithmic cost modeling uses a mathematical formula to predict project costs based on estimates of the
project size; the type of System being developed; and other team, process, and product factors. An
algorithmic cost model can be built by analyzing the costs and attributes of completed projects, and finding
the closest-fit formula to actual experience.
This is an empirical model that was derived by collecting data from a large number of system projects. These
data were analyzed to discover the formulae that were the best fit to the observations. These formulae linked
the size of the system and product, project and team factors to the effort to develop the system.
2.3. Project Scheduling and Staffing
The two most commonly used methods for project scheduling are Gantt charts and Network diagrams.
2.3.1. Gantt Chart
Gantt chart is a graphical representation of a project that shows each task as a horizontal bar whose length is
proportional to time. Gantt charts do not show how tasks must be ordered (precedence) but simply show
when an activity should begin and end.
No Tasks name Duration Oct.6-11 Oct 11-26 Oct 26-Nov 6 Nov 6-12

1 Project 5 days
proposal
2 Requirement 15 days
and design
3 Testing and 10 days
Coding
4 implementation 6 days

2.3.2. Network diagram

Network diagrams show the order of activities by connecting a task to its predecessors and successor task.
The difference between network and Gantt chart is
o Gantt shows the duration of tasks visually whereas network diagram shows sequence dependency between
tasks visually.
o Gantt visually shows the time overlap of tasks whereas network diagram does not show time overlaps but it
can show which task can be done parallel.
o Some forms of Gantt chart shows slack time available, network diagram shows time by data within
activities in rectangles.

System Analysis and Design Page 20

Network diagram is a critical path scheduling; it means it refers to a sequence of tasks activities whose
ordering or duration directly affects the completion date of the project. Network diagrams are composed of
circles or rectangles representing activities and connecting arrows showing required work flows,
One of the most difficult and most error-prone activities when constructing a project schedule is the
determination of the time duration for each task within a work breakdown structure. It is particularly
problematic to make these estimates when a high degree of complexity and uncertainty characterize a task.
PERT (Program Evaluation Review Technique) is a technique that uses optimistic, pessimistic, and realistic
time estimates to calculate the expected time for a particular task. This technique helps you obtain a better
time estimate when you are uncertain as to how much time a task will require to be completed.
The optimistic (o) and pessimistic (p) times reflect the minimum and maximum possible periods of time for
an activity to be completed. The realistic time (r), or most likely time, reflects the project manager’s ―best
guess‖ of the amount of time the activity will require for completion. Once each of these estimates is made
for an activity, an expected completion time (ET) can be calculated for that activity.

Commercial project management system such as Microsoft Project assists you in using PERT to make
expected time calculations. To construct network diagram we need the expected time for each activity and
activity precedence.
Example: the following table contains the summary of activities of a certain project.
Activity Time Required (in days) Immediate Predecessor activities
A 3 --
B 4 A
C 3 B
D 10 B
E 8 D
F 4 D
G 6 D
H 8 C,E,F,G
I 5 H
J 5 H
K 4 I
L 2 J
M 4 K,L
Task one: by using the above table construct the network diagram and fill each node as follows
ti = DURATION required to perform activity i
ESTi = earliest possible start for activity i
System Analysis and Design Page 21
 EFTi = earliest possible finish for activity i
LSTi = latest possible start for activity i
LFTi = latest possible finish for activity i
Task two: calculate the forward and the backward pass.
A Forward Pass through the network determines the earliest times each activity can start and finish – also
determine the total duration of the project
A Backward Pass through the network determines the latest times each activity can start and finish without
delaying completion of the project – with this information we can determine where we can delay activities
(have slack) and where we cannot
The Forward Pass
• The earliest start (EST) for the initial activity in a project is ―time zero‖;
• The EST of an activity is equal to the latest (or maximum) early finish of the activities directly preceding
it;
• The EFT of an activity is equal to its EST plus the duration required performing the activity

The Backward Pass

• The latest finish (LFT) for the final activity in a project is equal to its EFT as determined by the forward
pass;
• The LFT for any other activity is equal to the earliest (or minimum) LST of the activities directly
following (or succeeding) it;
• The LST of an activity is equal to its LFT minus the time required to perform the activity.

System Analysis and Design Page 22

Task three: determine the critical path
• Critical activities have zero slack and cannot be delayed without delaying the completion of the project;
• The slack for non-critical activities represents the amount of time by which the start of these activities can
be delayed without delaying the completion of the entire project (assuming that all predecessor activities
start at their earliest start times);

2.4. Managing people

A project manager should be aware of the potential problems of people management and should try to
develop people management skills.
There are four critical factors in people management:
1. Consistency: People in a project team should all be treated in a comparable way. No one expects all
rewards to be identical but people should not feel that their contribution to the organization is
undervalued.

System Analysis and Design Page 23

2. Respect: Different people have different skills and managers should respect these differences. All
members of the team should be given an opportunity to make a contribution. In some cases, of course,
you will find that people simply don’t fit into a team and they cannot continue, but it is important not to
jump to conclusions about this at an early stage in the project.
3. Inclusion: People contribute effectively when they feel that others listen to them and take account of their
proposals. It is important to develop a working environment where all views, even those of the most
junior staff, are considered.
4. Honesty: As a manager, you should always be honest about what is going well and what is going badly in
the team. You should also be honest about your level of technical knowledge and willing to defer to staff
with more knowledge when necessary. If you try to cover up ignorance or problems you will eventually
be found out and will lose the respect of the group.
2.4.1. Motivating people
As a project manager, you need to motivate the people that work with you so that they contribute to the best
of their abilities. Motivation means organizing the work and the working environment to encourage people to
work as effectively as possible. If people are not motivated, they will not be interested in the work they are
doing. They will work slowly, be more likely to make mistakes, and will not contribute to the broader goals
of the team or the organization.
To provide this encouragement, you should understand a little about what motivates people. People are
motivated by satisfying their needs. These needs are arranged in a series of levels, as shown in the figure
below.

People working in System development organizations are usually satisfied with their safety and physiological
needs. Therefore, making sure that people’s social, esteem, and self-realization needs are satisfied is most
important from a management point of view.
[Link] satisfy social needs, you need to give people time to meet their co-workers and provide places for
them to meet. This is relatively easy when all of the members of a development team work in the
same place but, increasingly, team members are not located in the same building or even the same
town or state. They may work for different organizations or from home most of the time. Social
networking systems and teleconferencing can be used to facilitate communications but with electronic
systems is that they are most effective once people know each other. You therefore need to arrange
some face-to-face meetings early in the project so that people can directly interact with other members

System Analysis and Design Page 24

 of the team. Through this direct interaction, people become part of a social group and accept the goals
and priorities of that group.
[Link] satisfy esteem needs, you need to show people that they are valued by the organization.
[Link], to satisfy self-realization needs, you need to give people responsibility for their work, assign
them demanding (but not impossible) tasks, and provide a training program where people can develop
their skills. Training is an important motivating influence as people like to gain new knowledge and
learn new skills.
Personality type also influences motivation. Professionals can be of three types:
1. Task-oriented people, who are motivated by the work they do. In System engineering, these are
people who are motivated by the intellectual challenge of System development.
2. Self-oriented people, who are principally motivated by personal success and recognition. They are
interested in System development as a means of achieving their own goals. This does not mean that
these people are selfish and think only of their own concerns. Rather, they often have longer-term
goals, such as career progression, that motivate them and they wish to be successful in their work
to help realize these goals.
3. Interaction-oriented people, who are motivated by the presence and actions of coworkers. As
System development becomes more user-centered, interaction-oriented individuals are becoming
more involved in system development.
2.4.2. Teamwork
Most professional system is developed by project teams that range in size from two to several hundred
people. However, as it is clearly impossible for everyone in large group to work together on a single problem,
large team are usually split into a number of groups. Each group is responsible for developing part of the
overall system. As a general rule, System development project groups should not have more than 10
members. When small groups are used, communication problems are reduced. Everyone knows everyone
else and the whole group can get around a table for a meeting to discuss the project and the system that they
are developing. Putting together a group that has the right balance of technical skills, experience, and
personalities is a critical management task. However, successful groups are more than simply a collection of
individuals with the right balance of skills. A good group is cohesive and has a team spirit. The people
involved are motivated by the success of the group as well as by their own personal goals.
In a cohesive group, members think of the group as more important than the individuals who are group
members.
The benefits of creating a cohesive group are:
1. The group can establish its own quality standards: Because these standards are established by
consensus, they are more likely to be observed than external standards imposed on the group.
2. Individuals learn from and support each other: People in the group learn from each other. Inhibitions
caused by ignorance are minimized as mutual learning is encouraged.

System Analysis and Design Page 25

 3. Knowledge is shared: Continuity can be maintained if a group member leaves. Others in the group can
take over critical tasks and ensure that the project is not unduly disrupted.
4. Refactoring and continual improvement is encouraged: Group members work collectively to deliver
high-quality results and fix problems, irrespective of the individuals who originally created the design
or program.
Good project managers should always try to encourage group cohesiveness. They may organize social events
for group members and their families, try to establish a sense of group identity by naming the group and
establishing a group identity and territory, or they may get involved in explicit group-building activities such
as sports and games. One of the most effective ways of promoting cohesion is to be inclusive. This means
that you should treat group members as responsible and trustworthy, and make information freely available.
2.2. Representing and Scheduling Project plans
2.2.1. Representing Project Plans
Any project involves a number of interrelated activities or jobs. The crux of Network Analysis is the
network diagram which reflects the logical flow of the work to be done. The activities are represented by
arrows which are linked as follows. Activities that logically are to follow each other are drawn in sequence
with the direction of the arrow indicating progress.
Activities that can be carried out concurrently are represented by parallel arrows. Exhibit 4.1 shows a
network diagram, also called an arrow diagram, for a small project. The diagram would, of course, be much
larger for a complex project and would take a considerable amount of time on the part of the project
manager and the project planning team to develop. Nevertheless it is worth the effort since the very act of
creating the arrow diagram ensures that all the jobs to be done are represented where they belong without
any omission. The final diagram enables the entire project scope to be immediately, and visually,
assimilated. It is superior to a prose description which could run into several pages for a complex project
resulting in the interrelationships being lost in the welter of words. The charting tools that are available in
several mainframe and personal computer packages enable the arrow diagram to be easily drawn, stored and
revised as necessary. Several customized packages for network analysis are also commercially available.
Viewed from the perspective of a Decision Support System, the arrow diagram represents the first step to
support the planning process for a project. It depicts in a graphical form:
o All the activities to be carried out the prerequisites (or predecessor activities†) for each
o Activity:- the activities that must be done before a given activity can be started
o Activities that are not dependent on each other, and hence can be undertaken concurrently.
2.2.2. Calculating Expected Time Duration using PERT
Project Evaluation and Review Techniques is commonly abbreviated to PERT. PERT is a method of
analyzing the tasks involved in completing a given project, especially the time needed to complete each task,
and to identify the minimum time needed to complete the total project. It incorporates uncertainty by making
it possible to schedule a project while not knowing precisely the details and durations of all the activities. It
is more of an event-oriented technique rather than start- and completion-oriented, and is used more in
System Analysis and Design Page 26
projects where time is the major factor rather than cost. It is applied to very large-scale, one-time, complex,
non-routine infrastructure and Research and Development projects.
Program Evaluation Review Technique (PERT) offers a management tool, which relies "on arrow and node
diagrams of activities and events: arrows represent the activities or work necessary to reach the events or
nodes that indicate each completed phase of the total project."
PERT and CPM are complementary tools, because "CPM employs one time estimate and one cost estimate
for each activity; PERT may utilize three time estimates (optimistic, expected, and pessimistic) and no costs
for each activity. Although these are distinct differences, the term PERT is applied increasingly to all critical
path scheduling."
Terminology in PERT
Events and activities
In a PERT diagram, the main building block is the event, with connections to its known predecessor events
and successor events.
PERT event: a point that marks the start or completion of one or more activities. It consumes no time and
uses no resources. When it marks the completion of one or more activities, it is not "reached" (does not
occur) until all of the activities leading to that event have been completed.
Predecessor event: an event that immediately precedes some other event without any other events
intervening. An event can have multiple predecessor events and can be the predecessor of multiple events.
Successor event: an event that immediately follows some other event without any other intervening
events. An event can have multiple successor events and can be the successor of multiple events.
Besides events, PERT also knows activities and sub-activities:
PERT activity: the actual performance of a task which consumes time and requires resources (such as
labor, materials, space, machinery). It can be understood as representing the time, effort, and resources
required to move from one event to another. A PERT activity cannot be performed until the predecessor
event has occurred.
PERT sub-activity: a PERT activity can be further decomposed into a set of sub-activities. For example,
activity A1 can be decomposed into A1.1, A1.2 and A1.3. Sub-activities have all the properties of activities;
in particular, a sub-activity has predecessor or successor events just like an activity. A sub-activity can be
decomposed again into finer-grained sub-activities
Time
PERT has defined four types of time required to accomplish an activity:
Optimistic time: the minimum possible time required to accomplish an activity (o) or a path (O), assuming
everything proceeds better than is normally expected
Pessimistic time: the maximum possible time required to accomplish an activity (p) or a path (P),
assuming everything goes wrong (but excluding major catastrophes).
Most likely time: the best estimate of the time required to accomplish an activity (m) or a path (M),
assuming everything proceeds as normal.
System Analysis and Design Page 27
Expected time: the best estimate of the time required to accomplish an activity (te) or a path (TE),
accounting for the fact that things don't always proceed as normal (the implication being that the expected
time is the average time the task would require if the task were repeated on a number of occasions over an
extended period of time).
te = (o + 4m + p) ÷ 6
Management tools
PERT supplies a number of tools for management with determination of concepts, such as:
Float or slack is a measure of the excess time and resources available to complete a task. It is the amount
of time that a project task can be delayed without causing a delay in any subsequent tasks (free float) or the
whole project (total float). Positive slack would indicate ahead of schedule; negative slack would indicate
behind schedule; and zero slack would indicate on schedule.
Critical path: the longest possible continuous pathway taken from the initial event to the terminal event. It
determines the total calendar time required for the project; and, therefore, any time delays along the critical
path will delay the reaching of the terminal event by at least the same amount.
Critical activity: An activity that has total float equal to zero. An activity with zero float is not necessarily
on the critical path since its path may not be the longest.
Lead time: the time by which a predecessor event must be completed in order to allow sufficient time for
the activities that must elapse before a specific PERT event reaches completion.
Lag time: the earliest time by which a successor event can follow a specific PERT event.
Fast tracking: performing more critical activities in parallel
Crashing critical path: Shortening duration of critical activities
Example
In the following example there are seven tasks, labeled A through G. Some tasks can be done concurrently
(A and B) while others cannot be done until their predecessor task is complete (C cannot begin until A is
complete). Additionally, each task has three time estimates: the optimistic time estimate (o), the most likely
or normal time estimate (m), and the pessimistic time estimate (p). The expected time (te) is computed using
the formula (o + 4m + p) ÷ 6.
Time Estimates
Activity Predecessor Expected time
pt. (o) Normal (m) Pess. (p)
A - 2 4 6 4.00
B - 3 5 9 5.33
C A 4 5 7 5.17
D A 4 6 10 6.33
E B,C 4 5 7 5.17
F D 3 4 8 4.50
G E 3 5 8 5.17
Applications of PERT
System Analysis and Design Page 28
These methods have been applied to a wide variety of problems in industries and have found acceptance
even in government organizations. These include
o Construction of a dam or a canal system in a region
o Construction of a building or highway
o Maintenance or overhaul of airplanes or oil refinery
o Space flight
o Cost control of a project using PERT / COST
o Designing a prototype of a machine
o Development of supersonic planes
Basic Steps in PERT / CPM
Project scheduling by PERT / CPM consists of four main steps
1. Planning
 The planning phase is started by splitting the total project in to small projects. These smaller projects in
turn are divided into activities and are analysed by the department or section.
 The relationship of each activity with respect to other activities are defined and established and the
corresponding responsibilities and the authority are also stated.
 Thus the possibility of overlooking any task necessary for the completion of the project is reduced
substantially.
2. Scheduling
 The ultimate objective of the scheduling phase is to prepare a time chart showing the start and finish
times for each activity as well as its relationship to other activities of the project.
 Moreover the schedule must pinpoint the critical path activities which require special attention if the
project is to be completed in time.
 For non-critical activities, the schedule must show the amount of slack or float times which can be used
advantageously when such activities are delayed or when limited resources are to be utilized effectively.
3. Allocation of resources
 Allocation of resources is performed to achieve the desired objective. A resource is a physical
variable such as labour, finance, equipment and space which will impose a limitation on time for
the project.
 When resources are limited and conflicting, demands are made for the same type of resources a
systematic method for allocation of resources become essential.
 Resource allocation usually incurs a compromise and the choice of this compromise depends on
the judgment of managers.
4. Controlling

System Analysis and Design Page 29

  The final phase in project management is controlling. Critical path methods facilitate the
application of the principle of management by expectation to identify areas that are critical to the
completion of the project.
 By having progress reports from time to time and updating the network continuously, a better
financial as well as technical control over the project is exercised.
 Arrow diagrams and time charts are used for making periodic progress reports. If required, a new
course of action is determined for the remaining portion of the project.
2.2.3. Constructing a Gantt chart and Network Diagram
GANTT charts
GANTT charts display the tasks in a project as a box or line showing the calendar duration of the task on the
horizontal axis (the horizontal length of the task box is proportional to the task duration). Tasks are normally
arranged in date order on the vertical axis. The time relation of all tasks to each other (for example, tasks
carried out simultaneously) is therefore clearly apparent in a Gantt chart. The project status can be easily
determined at intermediate dates in the project, and progress of individual tasks can be shown by filling in
the task boxes. Unlike PERT charts, GANTT charts do not show the critical path, however, dependencies
between tasks can be indicated by lines linking tasks.
GANTT charts – worked example
The following table shows the tasks, dependencies, and estimated times a project manager might input to a
basic GANTT chart for a System development project.
Project Start date: 12 June 2015
Task Predecessor
Task Description Time(days)
Identifier Task
1 Establish Project - 2
2 Establish customer requirements 1 3

3 Produce System specification documents 2 4

4 Write test plans 3 1

5 Write code 3 2

6 Developer testing 5 2

7 System Testing 4,6 4

8 Write customer documentation 3 3

Task 1 has no predecessors, and can thus start on 12 June 2015. The Gantt chart shows the task as a box starting on 12
June and finishing on 13 June on the horizontal access. Task 2 requires Task 1 to be completed, and the duration is
three days, so the box covers the dates 14 to 16 June. The line from the finish of Task 1 to the start of Task 2 indicates
the dependency. Note that Tasks 4, 5 and 8 all require Task 3 to be completed, and have no other dependencies, so

System Analysis and Design Page 30

these all start on the same date. The chart below show all seven days of the week, but often, weekend days are
excluded.
Network Diagram
A network diagram can be created by hand or by using diagram System . There are two types of network
diagrams, activity on arrow (AOA) and activity on node (AON). Activities on node diagrams are generally
easier to create and interpret. To create an AON diagram, it is recommended (but not required) to start with
a node named start. This "activity" has duration of zero (0). Then you draw each activity that does not have a
predecessor activity (a and b in this example) and connect them with an arrow from start to each node. Next,
since both c and d list a as a predecessor activity, their nodes are drawn with arrows coming from a. Activity
e is listed with b and c as predecessor activities, so node e is drawn with arrows coming from both b and c,
signifying that e cannot begin until both b and c have been completed. Activity f has d as a predecessor
activity, so an arrow is drawn connecting the activities. Likewise, an arrow is drawn from e to g. Since there
are no activities that come after f or g, it is recommended (but again not required) to connect them to a node
labeled finish.
By itself, the network diagram pictured above does not give much more information than a Gantt chart;
however, it can be expanded to display more information. The most common information shown is:
1. The Activity name
2. The expected duration time
3. The early start time (ES)
4. The early finish time (EF)
5. The late start time (LS)
6. The late finish time (LF)
7. The slack
In order to determine this information it is assumed that the activities and normal duration times are given.
The first step is to determine the ES and EF. The ES is defined as the maximum EF of all predecessor
activities, unless the activity in question is the first activity, for which the ES is zero (0). The EF is the ES
plus the task duration (EF = ES + duration).
In a network representation of a project certain definitions are used
1. Activity
Any individual operation which utilizes resources and has an end and a beginning is called activity. An
arrow is commonly used to represent an activity with its head indicating the direction of progress in the
project. These are classified into four categories
a) Predecessor activity: - Activities that must be completed immediately prior to the start of another
activity are called predecessor activities.
b) Successor activity:-Activities that cannot be started until one or more of other activities are
completed but immediately succeed them are called successor activities.

System Analysis and Design Page 31

 c) Concurrent activity:-Activities which can be accomplished concurrently are known as concurrent
activities. It may be noted that an activity can be a predecessor or a successor to an event or it may be
concurrent with one or more of other activities.
d) Dummy activity – An activity which does not consume any kind of resource but merely depicts the
technological dependence is called a dummy activity.
The dummy activity is inserted in the network to clarify the activity pattern in the following two situations
o To make activities with common starting and finishing points distinguishable.
o To identify and maintain the proper precedence relationship between activities that is not connected by
events.
For example, consider a situation where A and B are concurrent activities. C is dependent on A and D is
dependent on A and B both. Such a situation can be handled by using a dummy activity as shown in the
figure.

B A C 1
LFTi LSTi EFTi
D
4
2
2. Event
An event represents a point in time signifying the completion of some activities and the beginning of new
ones. This is usually represented by a circle in a network which is also called a node or connector.
The events are classified in to three categories
a) Merge event – When more than one activity comes and joins an event such an event is known as
merge event.
b) Burst event – When more than one activity leaves an event such an event is known as burst event.
c) Merge and Burst event – An activity may be merge and burst event at the same time as with respect
to some activities it can be a merge event and with respect to some other activities it may be a burst
event.

3 D M
u e
5
m r
3. Sequencing m g
y
The first prerequisite in the development of network is to maintain ethe precedence relationships. In order to
E
A be taken into considerations
make a network, the following points should v
c e
o What job or jobs precede it?
ti n
v
o What job or jobs could run concurrently? t
it
o What job or jobs follow it?
y
o What controls the start and finish of a job?
Since all further calculations are based on the network, it is necessary that a network be drawn with full care.
System Analysis and Design Page 32
Rules for Drawing Network Diagram
Rule 1
Each activity is represented by one and only one arrow in the network.

B M
Rule 2 a u e
r r
No two activities can be identified by the same end events.
s g
t e
b
a E &
v
b e B
n u
t r
s
Rule 3
t
In order to ensure the correct precedence relationship in the arrow diagram, following questions must be
E
checked whenever any activity is added to the network
v
o What activity must be completed immediately before this activity can start? e
n
o What activities must follow this activity?
t
o What activities must occur simultaneously with this activity?
In case of large network, it is essential that certain good habits be practiced to draw an easy to follow
network
o Try to avoid arrows which cross each other
o Use straight arrows
o Do not attempt to represent duration of activity by its arrow length
o Use arrows from left to right. Avoid mixing two directions, vertical and standing arrows may be used if
necessary.
o Use dummies freely in rough draft but final network should not have any redundant dummies.
o The network has only one entry point called start event and one point of emergence called the end event.
Common Errors in Drawing Networks
The three types of errors are most commonly observed in drawing network diagrams.
1. Dangling
2. To disconnect an activity before the completion of all activities in a network diagram is known as
dangling. As shown in the figure activities (5 – 10) and (6 – 7) are not the last activities in the network.
So the diagram is wrong and indicates the error of dangling. 8

12

1 2 3 4 5

System Analysis and Design Page 33

3. Looping or Cycling
4. Looping error is also known as cycling error in a network diagram. Drawing an endless loop in a
network is known as error of looping as shown in the following figure.

7 21
20

14
23
Da 13
ngli
10 ng 12
0
5. Redundancy
Unnecessarily inserting the dummy activity in network logic is known as the error of redundancy as shown
in the following diagram.

22

Lo
15
opi
ng

System Analysis and Design Page 34

CHAPTER 3:- THE SYSTEM DEVELOPMENT LIFE CYCLE
An effective System Development Life Cycle (SDLC) should result in a high quality system that meets
customer expectations, reaches completion within time and cost evaluations, and works effectively and
efficiently in the current and planned Information Technology infrastructure.
System Development Life Cycle (SDLC) is a conceptual model which includes policies and procedures for
developing or altering systems throughout their life cycles.
The System development life cycle (SDLC) the series of steps used to mark the phases of development for
an information system. It is a common methodology for systems development
SDLC is used by analysts to develop an information system. SDLC includes the following activities:

Figure-4: System Development Life Cycle

 Like any other processes, the development of information system is too follows a life cycle.
Example: - a commercial product such as a Marathi car follows a life cycle: It is created, tested and
introduced to the market. Its sales increase, peak and decline. Finally the product is removed from the
market and replaced by something else.
 The life cycle of an information system may as follows. Someone has idea for an information system
and what it should do. A careful study is done of how the organization currently handles the work the
system will support.
 Professionals develop a strategy for designing the new system, which is then either built or purchased.
Once complete, the system is installed in the organization, and after proper training, the users begin to
incorporate the new system into their daily work.
 The common four SDLC steps are 1) Planning and selection 2) Analysis 3) Design and 4)
Implementation and operation.
 The specific steps and their sequence are meant to be adapted as required for a project, if necessary the
project can return to an earlier phase.
 Some activities in one phase in parallel with some activities of another phase. Sometimes the life cycle
is iterative.

System Analysis and Design Page 35

  Each phase has specific outcomes and deliverables that feed important information to other phase.
These deliverables are reviewed by parties outside the project team, including managers and executives.
The SDLC is a structured approach; it uses data-oriented approach.

11

10 12

Planning and Selection

 Identify needs
 Feasibility study
 Define Scope &
Constraints
 Proposal

Figure-5: System Development Life Cycle- Detailed

Systems Planning and Selection
The first phase in the SDLC has two primary activities
 Identifying the need for a new or enhanced system
Information needs of the organization are examined and projects to meet these needs are identified from
- Requests to deal with problems in current procedures
- The desire to perform additional tasks
- The realization that information technology could be used to improve the organization
The Systems analyst prioritizes and translates the needs into a written plan including a schedule for
developing new systems.
The organization may decide whether or not the resources devoted for the project and a careful feasibility
study is conducted to determine the economic and organizational impact of the system
 The second task is investigating the system and determining the proposed system’s scope. Then a
specific plan for the proposed project for the team to follow is produced. This Baseline Project Plan
customizes the standardized SDLC and specifies the time and resources needed for its execution
Systems Analysis
It has three sub phases,
 First sub phase involves the systems analyst to determine the requirements of the system, i.e., what the
users want from a proposed system
 Next, the requirements gathered are structured (DFD, ERD) according to their interrelationships,
eliminating the redundancies
System Analysis and Design Page 36
 Third, system analyst has to generate alternative initial designs to match the requirements, best suited
design is selected for the development after the comparison of all alternative designs
Systems Design
 The system analyst converts the description of recommended solution into logical and physical designs
 Logical design involves in designing the user interface, databases and compute processes, irrespective of
the programming languages ( Algorithms, input and output forms, reports, table normalization)
 During the Physical design, the analyst team decides the programming language, database systems to be
used, hardware platform, operating systems and network environment.
 The final outcome of the design phase is the physical system specifications, presented in the form such as
a diagram or written report ready to be turned over to programmers and other system builders for
construction.
Systems Implementation and operation
 In this phase the information system is coded, tested and installed in the organization, and in which the
information system is systematically repaired and improved
 Planning for both testing and installation is to be done as early as the project planning and selection
phase, because they both require extensive analysis in order to develop exactly the right approach.
 This phase also includes the initial training to the users and documentation of the system documented
throughout the life cycle.
 During operation part, the problems faced by the users should be solved, and changes and enhancements
(new versions) are to be made as per the users’ desire to reflect changing business conditions.
 There inevitably comes a time, when an information system is no longer performing as desired, when the
costs of keeping a system running become prohibitive, or when an organization’s needs have changed
substantially. Such problems indicate that it is time to begin designing the system’s replacement, thereby
completing the loop and starting the life cycle over again.
Approaches for Development
Prototyping, rapid application development (RAD), Joint application design (JAD) and Participatory design
(PD) are four approaches that streamline and improve the systems analysis and design process.
Prototyping
 Designing and building a scaled-down version of the desired information system with the help of CASE
tools
 Prototyping is a key tool that supports rapid application development. RAD involves gaining user
acceptance of the interface and developing key system capabilities as quickly as possible.
Joint Application Design
 A structured process in which users, managers and analysts work together for several days in a series of
intensive meetings to specify or review system requirements.
Participatory design

System Analysis and Design Page 37

  PD involves users in the development process; they have an equal voice in determining system
requirements and in approving system design.
Systems Analysis and Design – core concepts
Systems Analysis
Systems Analysis is the study of a business problem domain for the purpose of recommending
improvements and specifying the business requirements for the solution.
Systems Design
Systems Design is the specification or construction of a technical, computer based solution for the business
requirements identified during systems analysis.
Systems Analysis and Design (SAD)
 Information systems analysis and design is a method used by companies to create and maintain
information systems that perform basic business functions.
 The main goal of SAD is to improve organizational systems through developing or acquiring
application System that can help employees accomplish key business tasks more easily and efficiently.
 An application System is designed to support a specific organizational function or process, such as
inventory management, payroll. The goal of application System is to turn data into information.
 An Information System is developed by following System Engineering Process, which consists of
proven methodologies, techniques and tool. These three process work together to form an organization
approach to SAD

Implementation &
Operation
 Coding, testing,
installation
 Documentation,
Training and support
 Fixes
 Enhancements Design
Analysis  Logical
 Describe the Design
current system  Physical
 Determine Design
requirements
 Initial design
model
of new system

Figure 1 System Engineering Process

 Methodologies are sequence of step by step approaches that helps to develop the final product. The
methodologies incorporate techniques like, direct observations and interviews with users.
 Techniques provide support for a wide range of tasks including conducting interviews with users,
planning and managing the activities of a project and designing the reports.

System Analysis and Design Page 38

  Tools are computer programs, such as computer aided System engineering (CASE) tools, that make it
easy to use specific techniques.
Approaches to Systems Analysis and Design
Every Information System consists of three key components that anyone who analyzes and designs must
understand, they are data, data flows and processing logic.
Data are raw facts that describe people, objects and events in an organization. Example:-customer’s
account no, account type, balance amount.
Dataflow are groups of data that move and flow through a system. Example:- customer’s account number is
captured when he uses a credit card for purchase
Data Flow Account no and trans. date

Methodolo
gies

Validate
Credit
Card purchase
Tools
Techniques

Prepare
Statement

Figure-2: Data flow

Processing Logic describes the steps that transform the data and the events that trigger these steps. Ex.
processing logic in a credit card bill preparation
Process Oriented approach
Traditionally, Systems Analysts designed an Information System based on what the system was meant to
do, such as billing or inventory control.
The focus was on outputs and processing logic, in other words, on the flow, use and transformation of data.
The data used as inputs were seen as important also, but secondary to the application
Each system would contain its own files and data storage areas
The data in each system would match the specifications for that system only
Each systems was considered ( looked at) separately
The analysis involved in creating drawings / diagrams that show how the data moves around the system and
where it is stored in between flows.

System Analysis and Design Page 39

The problems with this approach are, first the existence of several files of data each locked with different
applications and programs. Second, many of the files in different applications contains same data, updating
the data becomes tedious process, it also difficult to combine data files created for specific applications.

Valid account no.

Transaction and transaction data

Registration Class Student DB

System Scheduling
Account no.
and transaction

Statement

Figure-3: Process Oriented Approach

Data Oriented approach
Over time the approach changed to being a more data-oriented. This was a response to the problems above
This approach tends to focus on how the data should be represented independently of where and how data
are used in the system
A data model is produced, which describes the data and relationships between the data. Business rules
define how the organization deals with the data
Databases are designed around the subjects such as customers, suppliers, parts. This lets use the dame
databases for many different applications
This means that the application is independent of data and data definitions it is called as application
independence
Systems Integration approach
Today, systems development focuses on systems integration. Systems integration allows hardware and
System from different vendors to work together in an application.
Courses DB Courses DB

Staff DB Class Scheduling Registration

System

System Analysis and Design Page 40

 Figure-4: Data Oriented Approach

CHAPTER 4: SYSTEMS PLANNING AND SELECTION

Systems Planning and Selection
This first phase of the systems development life cycle deals with the process of identifying, selecting,
initiating, planning projects and assessing project feasibility.
Project Identification and Selection
The first step is to identify the need for a system, which can be the result of
 Problems in existing system or process
 New feature required in an existing system
 A new idea for which in Information System is required
 A requirement to improve efficiency in the organization
 Compulsory standards or bench marks by an external organization Ex. Government
 The need to keep up with competitors
During this activity a senior manager, a business group, an Information System manager or a steering
committee identifies and assess all possible systems development projects, which are all may yield significant
organizational benefits.

Figure -1: Key Sources for IS project

The requests for developing information system can come from three key sources
 Managers and business units who want to replace or extend and existing system in order to gain needed
information or to provide a new service to customers.
 Information Systems managers who want to make a system more efficient, less costly to operate or want to
move a system to a new operating environment.
 Formal planning group that want to improve an existing system in order to help the organization meet its
corporate objectives, such as providing better customer service.
 The Selection Process may vary in different organizations, but the general process is discussed below.

System Analysis and Design Page 41

 General Process of Identifying and Selection Information Systems development Projects
 Process of identifying and selection consists of three activities : Identifying potential development
projects, classifying and ranking projects and selecting projects for development
 Identifying potential development projects: This process may be performed by a key member of top
management, or a steering committee composed of a cross section managers, or User departments, or the
development group
 Projects identified by top management have a strategic organizational focus, by the steering committees
have a cross functional focus, by the individual departments have a narrow, tactical focus. The development
group identifies projects based on the ease with existing hardware and systems.
 Hence, projects may be identified by both top-down and bottom-up initiatives.
 The systems analyst should support these groups, to describe their information needs.
Classifying and ranking IS development projects: Done by top managers, a steering committee, business
units or the IS development group.
 The criteria commonly used to evaluate projects are
o Value chain analysis: Extent to which activities add greatest benefits
o Strategic alignment: Extent the projects achieves the long term goals
o Potential benefits: Extent to which the project helps to improve profits,
o Customer service, etc and the duration of the benefits
o Resource availability: Amount and type of resources required for the
Project
o Project size / duration: Number of individuals and duration to complete
o Technical difficulty / risk: Level of technical difficult to complete.

 Selecting IS development Project: The short and long term projects most likely to achieve the business
objectives are considered.
 As business conditions change over time, the relative importance of any single project may change.

Figure 2: Factors to be considered during the project selection

System Analysis and Design Page 42

 The factors must be considered when selecting a project are
o Perceived needs of the organization
o Existing systems and ongoing projects
o Resource availability
o Evaluation criteria
o Current business conditions
o Perspective of the decision makers
Deliverables and outcomes
 The primary deliverable or end product form the project identification and selection phase is a schedule of
specific IS development projects.
 These projects may come from both top down and bottom up sources
 The selected project move into the second activity called Project initiation and planning

Figure 3: Deliverables from Project Identification and selection phase

Project Initiation and Planning
 The objective of project initiation and planning is to transform a vague system requirements into a tangible
project description
 Proper project initiation and planning can reduce the time consumption of further phases
 Activities performed in this phase could also be completed during the next phase, System analysis
 A rule of thumb is that 10 – 20 % of the entire effort should be expended in this phase
General Process of Initiating and Planning Systems development Projects
 Project Initiation focuses on activities that will help to organize a team to conduct project planning
 During initiation, one or more analysts are assigned to work with a customer to establish work standards
and communication procedures.
 Project Planning focuses on defining clear, discrete tasks and the work needed to complete each task

System Analysis and Design Page 43

 The objective of the project planning is to produce two documents: a Baseline Project Plan (BPP) and the
Statement of Work (SOW).
 The BPP is an internal document used by the development team but not shared with customers
 The BPP contains all information collected and analyzed during the project initiation and planning activity.
 The BPP reflects the best estimate of the project’s scope, benefits, costs, risks and resource requirements.
 The BPP specifies detailed project activities for the next life cycle phase- Systems analysis and less detail
for subsequent phases.
 The SOW is a short document prepared for the customers that describes what the project will deliver and
outlines all work required to complete the project
 The SOW is a useful communication tool that assures that both system analysts and customers have a
common understanding of the project.
Feasibility Study
 Most Information System projects have budgets and deadlines; the analysis of factors for feasibility forms
the business case (analysis of the assumptions like resource availability and potential problems and system
cost and benefits) that justifies the expenditure of the resources on the project. The feasibility factors are in
six categories
oEconomic Feasibility
- Concerned with assessing the financial benefits and costs associated with the project. To do this, it is
necessary to quantify the monetary value of the costs and benefits of the project. This is also called a
cost-benefit analysis.
- Benefits and costs can be tangible or intangible
- Tangibles are items which can be quantified in monetary terms and with certainty. Ex. equipment costs,
staff/personnel costs, materials costs, conversion costs, training costs.
- Intangibles are items for which a value cannot be precisely determined, and where the value may be the
result of subjective judgment. Ex. Customer goodwill, employee morale. Operational efficiency
- The sum value of all costs identified for the project gives the cost of the system
- The sum value of all the benefits identified for the project gives the benefit of the systems
- These are then used to determine if the project is economically feasible. There are two methods for doing
this are work sheet method and present value method
oOperational Feasibility
- This process examines whether the new project will attain its desired objectives.
- The goal of this study is to understand the degree to which the proposed system will likely solve the
business problems or take advantage of the opportunities specified in the Systems requirement
documents.
oTechnical Feasibility
- The goal of this study is to understand the organization’s ability to construct the proposed system.

System Analysis and Design Page 44

- This analysis also includes an assessment of the development group’s understanding of the possible target
hardware, System and operating environments as well as the size, complexity and the group’s experience
with similar systems
oSchedule Feasibility
- The process of assessing the degree to which the potential time frame and completion dates for all major
activities within a project meet organizational deadlines and constraints for affecting change.
oLegal and Contractual Feasibility
- The process of assessing potential legal and contractual ramification due to the construction of a system
- Considerations may include copyright or nondisclosure violation, labor laws, antitrust legislation, foreign
trade regulations and financial reporting standards as well as current or pending contractual obligations.
oPolitical Feasibility
- The process of evaluating how key stakeholders within the organization view the proposed system
Building the Baseline Project Plan
o All the information collected during project initiation and planning is collected and organized into a
document called the Baseline Project Plan.
o Once the BPP is completed, a formal review of the project can be conducted with customers.
o BPP contains four major sections
1. Introduction
2. System Description
3. Feasibility assessment
4. Management issues
o Introduction section provides a brief overview of the entire document and outline a recommended
course of action for the project
o It provides an executive summary that specifies the project’s scope, feasibility, justification, resource
requirements and schedules. Additionally, a brief statement of the problem, the environment in which
the system is to be implemented and constraints that affect the project are provided
o Recommendation provides a summary of important findings from the planning process and
recommendations for subsequent activities
o System Description section provides a list of alternatives system configuration
o It provides a description of the selected configuration and a narrative of input information, tasks
performed and resultant information
o Feasibility Assessment outlines project costs and benefits and technical difficulties. High level project
schedules are specified using PERT and Gantt charts. The greatest amount of project planning effort is
typically expended on feasibility assessment activities.
oManagement Issues
- Team Configuration and Management: Provides a description of the team member roles and reporting
relationships
System Analysis and Design Page 45
 - Communication plan: Provides a description of the communication procedures to be followed by
management, team members and the customer
- Project standards and procedures: Provides a description of how deliverables will be evaluated and
accepted by the customer
- Other project-specific topics: Provides a description of any other relevant issues related to the project
uncovered during planning.
Reviewing the Baseline Project Plan
 Before submitting the BPP to some project approval body, it is to be reviewed by the users, management
and development groups.
 The objectives of this review is to assure that the proposed system conforms to organizational standards and
to make sure that all relevant parties understand and agree with the information contained in the BPP.
 A common method for performing this review is called a structured walkthrough, a peer group review of
any product created during the systems development process.
 The walkthrough may have specific agenda that highlights what is to be covered and the expected
completion time.
 Individuals attending the meeting have specific roles
- Coordinator
- Presenter
- User
- Secretary
- Standard-bearer
- Maintenance oracle
 In addition to reviewing the BPP, the walkthrough can be used for the following activities
- System specifications
- Logical and physical designs
- Code or program segments
- Test procedures and results
- Manuals and documentation
 The key advantage of using a structured review process is to ensure that found review points occur during
the project. At each phase of the project, a formal review should be conducted to make sure that all aspects
of the projects are satisfactory accomplished before assigning additional resources to project
 This conservative approach of reviewing each major activity with continuation contingent on successful
completion of the prior phase is called incremental commitment.

System Analysis and Design Page 46

CHAPTER 5 SYSTEM ANALYSIS: DETERMINING SYSTEM REQUIREMENT
System analysis is the study of a business problem for the purpose of recommending improvements and
specifying the business requirements for the solution. It has three parts: determining requirements, structuring
requirements and selecting the best alternative design strategy. These steps are may be parallel and repetitive
Requirements Determination
 Requirement determination means gathering information on what the system should do from as many
sources as possible.
 Analysts use system requirements determination to understand current problems and opportunities as well
as what is needed and desired in future systems.
 The sources can be the users of the current system, reports, forms and procedures. All the system
requirements are carefully documented and made ready for structuring.
 The characteristics of a good systems analyst in determining the requirements are
o Impertinence: You should question about each and every aspects involved in the system.
o Impartiality: The role of a SA is to find the best solution to a business problem or opportunity. Not to
justify the purchase of new hardware or to insist some requirements. The issues raised by all parties must
be considered and to find the best organizational solution.
o Relaxing of Constraints: Assume that anything is possible and eliminate the infeasible and traditions.
Traditions are different from rules and policies, it may be good but as the organization and its
environments changes, the traditions not to be appreciated.
o Attention to details: Every fact must fit with every other fact. One element out of place means that the
ultimate system will fail at some time.
o Reframing: Analysis is, in part, a creative process; the organization must be viewed in new ways. Not to
jump to this conclusion that ―I worked on a system like that once - this new system must work the same
way as the one I built before‖.
Deliverables and outcomes
 The primary deliverables from requirements determination are the types of information gathered and the
information can take many forms such as transcripts of interviews, notes from observation and analysis of
documents, analyzed responses from questionnaires, set of forms, reports, job descriptions and other
documents.
 In addition a SA need to understand the following components of an organization
o The business objectives that drive what and how work is done
o The information people need to do their jobs
o The data handled within the organization to support the jobs
System Analysis and Design Page 47
 o When, how and by whom or what the data are moved, transformed and stored
o The sequence and other dependencies among different data handling activities
o The rules governing how data are handled and processed
o Policies and guidelines that describe that nature of the business and the market and environment in which
it operates
o Key events affecting data values and when these events occur.
 These all information must be organized for the purpose of requirements structuring
Traditional Methods for gathering requirements
 The traditional ways to get information directly from those who have the information is by conducting
interviews, questionnaires and direct observation.
 And collecting documentation on the current system and organizational operation in the form of written
procedures, forms, reports and other hard copy.
 All the methods can be used to gather requirements and build up information about the current system.
Asking questions and observing can help to gather knowledge about the informal system, what people
actually do in their work. Analyzing documentation and asking questions can help to gather knowledge
about the formal system- what is expected of the system.
Interviewing
 The SA has to spend a large amount of time in interviewing the people about their work, the information
they use to do it and the types of information processing that might supplement their work
 Other people are too interviewed to understand organizational direction, policies and expectations that
managers have on the units they supervise.
 The facts, opinion and speculation (rumor) are gathered, the body language, emotions and other signs of
what people want and how they assess current systems.
 SA can sometimes determine if people are answering truthfully or fully by the words they use, whether
they make direct eye contact, the tone of voice they use or their body language.
 Some guidelines to conduct the interview effectively are
o Prepare thoroughly before the interview. Set up an appointment at a convenient time for the interviewee.
The general nature of the interview should be explained to the interviewee in advance.
o You want the interview to be natural and to some degree, you want to direct the interview spontaneously
as you discover what expertise the interviewee brings to the session.
o Prepare and interview guide or checklist so that you know in which sequence to ask your questions and
how much time to spend in each area of the interview.
o The interviewee may provide information you were not expecting, you may not follow the guide in
sequence. However check off questions you have asked and write remainders to yourself to return to or
skip other questions as the interview takes place.
Choosing interview Questions
 The open-ended and closed-ended questions must be mixed.
System Analysis and Design Page 48
 Open-ended questions in interviews and on questionnaires that have no pre-specified answers.
 The advantages of open-ended questions: previously unknown information can surface, and interviewee
may get more of a sense of involvement and control in the interview.
 The major disadvantage of open-ended questions in the length of time it can take for the questions to be
answered.
 Closed-ended questions provide a range of answers from which the interviewee may choose.
 These sorts of questions works well when the major answers to questions are well known. Another plus is
that interviews based on these questions do not require a large time.
 The major disadvantage of closed-ended questions is that useful information that does not quite fit the
defined answers may be overlooked as the respondent tries to make a choice instead of providing his or her
best answers.
Interview Guidelines
1. Don’t phrase a question in a way that implies a right or wrong answer. Enable the respondents to feel free
to tell their true opinions and perspectives and make them to trust that their ideas will be considered
carefully.
2. Listen carefully to what is being said, take notes, or if possible record the interview with their permission.
Schedule follow ups.
3. Once the interview is over, key in or document it within 48 hours, otherwise your memory of the interview
will fade quickly. Organize the notes; write down the additional questions that might arise from lapses in
the document or ambiguous information. Separate facts from your opinions and interpretations. Make a list
of unclear points that need clarification. Call the person and get answers to these questions. You may send
a written copy of your notes to the person you interviewed to check for accuracy. Make sure to thank the
person for his or her time.
4. Be careful during the interview not to set expectations about the new or replacement system unless you are
sure these features will be part of the delivered system. Let the interviewee understand the steps to the
project. Due to the repetitive nature of the systems development process, it is premature to say now exactly
what the ultimate system will or will not do.
5. Seek a variety of perspectives from different people: potential users of the system, users of other system
that might be affect by this new system, managers, superiors, information systems staff and others.
Encourage people to think about current problems and opportunities and what new information services
might better serve the organization.
Questionnaires
 Questionnaires have the advantage of gathering information from many people in a relatively short time.
Interviews are quite expensive and time-consuming process, but the questionnaires are not expensive.
 Questionnaires are passive and often yield less rich information than interviews.
 Questionnaires are most useful in the requirements determination process when used for very specific
purposes rather than for more general information gathering.
System Analysis and Design Page 49
 Choosing Questionnaire Respondents
 It must be decided which questionnaire to be given to which group of people. It should be send to
representatives of all users.
 The representatives can be selected by any one or combination of these following
o Those convenient to sample: The people those willing to be surveyed, or those most
motivated to respond.
o A random group: the nth person of all users list can be chosen randomly
o A purposeful sample: Only people who satisfy certain criteria, such as users of the system.
Designing Questionnaires
 Questionnaires are less expensive means that the people can complete the questionnaire without help. Also
answers can be provided at the convenience of the respondent.
 Questionnaires may include closed-end questions and open-end questions, preferably closed-end
questions, because they are easier to complete and they define the exact coverage required.
 A few open-ended questions give the person being surveyed an opportunity to add insights not anticipated
by the designer of the questionnaire.
 The questions must be extremely clear in meaning and logical in sequence, without ambiguity in question
and answers.
Choosing between Interviews and Questionnaires
 The interviews are good tools for collecting rich, detailed information and that interview allow exploration
and follow-ups but quite time intensive and expensive.
 The questionnaires are inexpensive and take less time, as specific information can be gathered from many
people at once but the information gathered is less rich and follow up questions is more difficult as it often
involves interview or phone calls
 These differences are important to remember during the analysis phase. Deciding which method to use and
what strategy to employ to gather information will vary with the system being studied and its
organizational context.
Direct observation
 It is also possible to gather information about a system by watching the users of the system at work.
 This method can bring more objective information - as the analyst can see what the person does
(behavior), rather than what they say they do.
 This can be used to supplement or confirm the information obtained by asking questions.
 Observation can take place in two ways.
1. By the analyst participating in the user’s work Ex. becoming a member of the team for a week
2. By watching the users at work – this can be done in person or by video camera.
 The advantages of observation over asking questions is that the analyst can see what the user’s behavior
and interactions with the system actually are, not what they say they are.

System Analysis and Design Page 50

 There are also disadvantages to observation – while being observed, people may not behave normally (if
they know they are being observed) – they may change their behavior. Also the time at which the
observation takes place may mean that the analyst sees only a small subset of the work done by the user.
Analyzing Documents (Reports, forms, procedures and manuals)
 Another way to gather information about the current system or possible improvements to it is to review
and analyze documentation
 This can provide information about :
o Problems with existing systems (Ex. Missing information, redundant steps)
o Possible new features that can be added to existing systems, if certain new information is now available
(Ex. analysis of sales based on customer type)
o Special Circumstances that occur irregularly but may not be identified by any other requirements
gathering technique (Ex. if special handling is required for a few very large volume customers, where
customized customer ordering procedures are required)
Data definitions, rules for processing data (Business rules) in the system.
 Relevant type of documentation include:
o Written work procedures for an individual role or a work group – a work procedure describes how a
particular job or task is carried out, it includes the data and information used and created in the process.
o Business forms – forms are used for many business functions Ex. in a bank, there are forms for making
deposits, withdrawals, transfers etc. forms can provide good understanding of a system because they
explicitly show what data flows in and out of the system.
o Reports generated by current systems- it is possible to work back from the information on the report to
understand what data was used to generate the report. Analysis of reports can determine what data needs
to be captured over time and over what time periods, and how the data needs to be manipulated or
transformed.
o Documentation about current computer systems – if the team that analyzed, designed and built the
existing system also produced good documentation about the system (specifications, test plans, user
manuals etc.) then this can be a good source of information about the system.
Modern methods for gathering requirements
 The modern methods are additional techniques to collect information about the current system, the
organizational area requesting the new system, and what the new system should be like: the modern
methods are Joint Application Design and Prototyping.
 These techniques reduce the time of collecting and structuring the requirements.
Joint Application Design (JAD)
 JAD is a means to bring together the key users, managers, and systems analysts involved in the analysis of
a current system.
 The goal of JAD is to collect systems requirements simultaneously from the key people involved in the
system.
System Analysis and Design Page 51
 JAD sessions are usually conducted in a location away from where the people normally work, to keep
them away from all distractions, so that they can concentrate fully on systems analysis.
 The people involved in a JAD are
o JAD session leader: To organize and run the JAD- should be trained in facilitation and group
management and is usually a systems analyst. Sets the agenda, resolves conflicts and disagreements,
keeps the session on track and gets all ideas from participants
o Users: Key users of the existing and new system
o Mangers of User group: To provide information about the organization’s direction and the motivations
and impacts of the systems also to support the requirements determined during the JAD.
o Systems Analysts: To learn from users and mangers, may participate and advise on IS issues
o Sponsor : A senior person in the organization who is supporting and providing the budget for the
development, usually attends only at start and end of session
o Scribe: To take notes during the sessions and record the outcomes of the meeting ( on a laptop or PC if
possible)
o IS staff: To learn from the discussion , may also contribute ideas on technical feasibility or limitations of
systems
 JAD sessions are held in a special room equipped with white boards, audiovisual tools, overhead
projector, flip charts and computer generated displays.

Figure-1 A typical room layout for a JAD session

Business Process Re-engineering (BPR)

System Analysis and Design Page 52

 BPR means the search for, and implementation of, radical change is business processes to achieve
breakthrough improvements in products and services.
 BPR is a process in which existing methods of doing business are replaced with new and updated methods
 In many businesses, the systems in place consist of programs that were written some time ago and still use
old methods and technologies. They often support only one business unit. These are called legacy systems
 These systems were designed around the processes that took place in the business unit
 In some organizations, the management is looking for new ways to perform current task , ie to improve or
change the way things are done- ie to change the business processes. This is called Business Process Re-
engineering.
 The overall process by which current methods are replaced with radically new methods is referred as BPR.
 The new ways of doing things may be very different form the old ways, but the benefits may be big, since
the processes become more efficient.
 Since, the legacy systems were built around the business, a business re-engineering process often requires
changes to the information systems.
Prototyping
 Prototyping allows to quickly converting basic requirements into a working, though limited, version of the
desired information system. The user can view and test the prototype.
 The goal of prototyping is to support requirements determination to develop concrete specifications for the
ultimate system, not to build the ultimate system.
 Prototyping is most useful in the following circumstances
o User requirements are not clear or well understood
o Only one or a few users involved
o Possible designs are complex
o Communication problems have existed in the past, between users and analysts
 It also has some disadvantages
o Analysts may avoid creating formal documentation of the system
o The prototype may be very influenced by the initial user who reviews it- and thus might not be adaptable
to other users
o Often build as a stand-alone system, which may result in interfaces with other systems being ignored
during this phase.

System Analysis and Design Page 53

 CHAPTER 6 SYSTEM ANALYSIS: STRUCTURING SYSTEM REQUIREMENTS
The information gathered during the requirements gathering process needs to be organized into a form that is
a meaningful representation of the existing system and of the requirements for the new system.
This is done by producing models of the processing elements and data transformations and then of the
structure of the data. This entire process is called structuring requirements
There are three stages in the structuring process
 Process modeling
 Logical Modeling
 Conceptual data modeling
Process modeling involves graphically representing the processes, or actions that capture, manipulate, store
and distribute data between a system and its environment and among the components within a system.
A common form of a process model is a data flow diagram (DFD). DFD is a graphic that illustrates the
movement of data between external entities and the processes and data stores within a system.
Conceptual Data Modeling involves representing the data in a system or organization, to show the overall
structure of the data. A data model should be independent of any DBMS and of other implementation
considerations.
Entity-Relationship diagram(ER) data models are commonly used diagrams that show how data is
organized in a system.
Data Flow Diagrams
 The DFD is an excellent communication tool for analysts to model processes and functional requirements.
One of the primary tools of the structured analysis efforts of the 1970's it was developed and enhanced by
the likes of Yourdon, McMenamin, Palmer, Gane and Sarson. It is still considered one of the best
modeling techniques for eliciting and representing the processing requirements of a system
Data Flow diagramming mechanics
 DFD’s are versatile programming tools. With only four symbols, it can represent both physical and logical
information systems.
Data flow
 The directional movement of data to and from external entities, the process and data stores. If it flows into
a data store, means a write, update, delete, etc. Flows out of data stores, mean read, query, display, select
types of transaction.
 Symbol: Solid line with arrow. Each data flow is identified with a descriptive name that represents the
information on the data flow.
Example:
Registration data

Process
System Analysis and Design Page 54
 Is a work or actions performed on data so that they are transformed, stored, or distributed. When modeling
the data processing of a system, it doesn’t matter whether process is performed manually or by a computer.
 Depending on the level of the diagram it may represent the whole system as in a Context (level 0) diagram
or a business area, process (activity), function, etc. in lower levels.
 Symbol: Circle or a Rounded Rectangle.
Example:
Student
DB

Data Store
 A repository of information. In the physical model, this represents a file, table.
 Symbol: Two parallel lines or open ended rectangle
Example:
D1: Student Master

External Entity
 It is a source/sink (the origin and /or destination of the data).
 A person or group which interacts with the system. Something outside the system. eg. Customer, supplier,
government agency, accounting dept, etc. usually external to the business or system but may be internal
 Data must be originated outside a system from one or more sources, and the system must produce
information to one or more sinks.
 Symbol: rectangular box which may be shaded.
Example:

Courses DB

Developing DFD’s
 The DFD for Hoosier burger food ordering system - An example
 A context diagram is a DFD that provides a general overview of a system, other DFD’s can be used to
focus the details of a context diagram.
 This context diagram contains only one process, no data stores, four data flows, and three external entities.
The single process labeled ―0.‖, represents the entire system.
 All context diagrams have only one process labeled ―0‖. No data stores appear on a context diagram, since
the data stores of the system are conceptually inside the one process.

System Analysis and Design Page 55

 Figure-1: Context diagram (Level-0) for Hoosier burger automated system
 After drawing the context diagram, the next step is to analyze the processes are represented by the single
process. There are four main processes are identified, the processes represent the major functions of the
system, the major functions are
o Capturing data from different sources (process 1)
o Maintaining data stores (process 2 and 3)
o Producing and distributing data to different sinks (process 4)
o High level descriptions of data transformation operations (process 1)
 The flow from first process 1. are 1) the food order is transmitted to the kitchen, 2) the customer order is
transformed into a list of goods sold, 3) the customer order is transformed into inventory data, and 4) the
process generates a receipt for the customer.
 Two of the data flows generated by the process, receive and transform customer food order, go to external
entities, not to concern about what happens outside of our system.

System Analysis and Design Page 56

 Figure-2: Level 1- diagram of Hoosier Burgers food ordering system
 The data labeled Goods Sold go to process 2, update Goods Sold file. The output for this process is labeled
Formatted Goods Sold Data. The output updates a data store labeled Goods Sold File. Daily Goods Sold
amounts are then used as input to process 4, Produce Management reports. Similarly the data flow
generated by process 1 called Inventory Data, serves as input for process 3, Update Inventory File. The
Daily Inventory Depletion amounts are then used as input to process 4.
 The DFD hides the physical characteristics of the system it describes. Process 1 and 3 are coupled to each
other, since the data flow from process 1 must be readily accepted by process 3.
 Process 2 and 4 are decoupled by placing a buffer, a data store.
Data Flow Diagramming Rules
Process
A. No process can have only outputs. It is making data from nothing. If an object has only outputs, then it
must be a source.
Incorrect Diagram Correct Diagram

B. No process can have only inputs. If an object has only inputs, then it must be a sink

C. A process has a verb phrase label

Data Store
D. Data cannot move directly from one data source to another data source. Data must be moved by a process

System Analysis and Design Page 57

E. Data cannot move directly from an outside source to a data store. Data must be moved by a process that
receives data from the source and places the data into the data store.

F. Data cannot move directly to an outside sink from a data store. Data must be moved by a process.

G. A data store has a noun phrase label.

External Entity (Source / Sink)
H. Data cannot move directly from a source to a sink. They must be moved by a process if the data are of any
concern to our system. Otherwise, the data flow is not shown on the DFD.

I. A source/sink has a noun phrase label

Data Flow
J.A data flow has only one direction of flow between symbols. It may flow in both directions between a
process and a data store to show a read before an update. The latter is usually indicated, however by two
separate arrows because these happen at different times.

K. A fork in a data flow means that exactly the same data go from a common location to two or more
different processes, data stores, or sources/sinks.

A A
B A

L. A join in a data flow means that exactly the same data come from any of two or more different processes ,
data stores, or sources/sinks to a common location

A A

B A
System Analysis and Design Page 58
M. A data flow cannot go directly back to same process it leaves. There must be at least one other process
that handles the data flow, produces some other data flow, and returns the original data flow to the
beginning process.

A B

N. A data flow to a data store means update (delete or change)

O. A data flow from a data store means retrieve of use
P.A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as
long as all of the flows on the same arrow move together as one package.
Decomposition of DFD’s
The act of going from a single system to more component processes is called decomposition
The functional decomposition is a repetitive process of breaking the system into finer and finer detail.
Each of the processes (or subsystem) is also candidate for decomposition. Each process may consist of
several sub processes. Each sub process may also be broken down into smaller units.
Decomposition continues until no sub process can logically be broken down any further. The lowest level
of DFD is called primitive DFD.
The first process in the figure-2 can be decomposed into four different outputs. 1) Receive a customer
order, 2) transform the entered order into a printed receipt for the customer, 3) transform the order into a
form meaningful to the kitchens system 4) transform the order into goods sold data, and 5) transform the
order into inventory data.
The decomposition of Process 1 is given below

System Analysis and Design Page 59

 Figure-3: Decomposition of Process 1 (Level-2)
The context and level-0 diagram will show the sources and sinks. No sources or sinks are represented in
figure-3. We can decompose processes 2, 3, or 4 in a similar manner. In general, a level-n diagram is a
DFD that is generated is form n nested decompositions from a level-0 diagram.
As a rule of thumb, no DFD should have more than about seven processes in it.
The labels for the processes and numbering rules for clear communication, process names should be clear
and concise, it may begin with an action verb, such as receive, calculate, transform, generate or produce.
Process 4 can be further decomposed into level-1, level-2 as given below.

Figure-4: level-1 and level-2 DFDs of Process 4.0

System Analysis and Design Page 60

 Balancing DFDs
The conservation of inputs and outputs to a data flow diagram process when that process is decomposed to
a lower level.
For Ex. Process 1, which appears in a level-0 diagram, must have the same inputs and outputs when
decomposed into a level-1 diagram is called balancing.
The principle of balancing and goal of keeping a DFD as simple as possible lead to four additional,
advanced rules for drawing DFDs.
o A composite data flow on one level can be split into component data flows at the next level, but no
new data can be added and all data in the composite must be accounted for in one or more sub flows.
oThe input to a process must be sufficient to produce the outputs from the process. Thus all outputs can
be produced, and all data in inputs move somewhere, either to another process or to a data store outside
the process or on a more detailed DFD showing a decomposition of that process.
oAt the lowest level of DFDs, new data flows may be added to represent data that are transmitted under
exceptional conditions, these data flows typically represent error messages or confirmation notices.
oTo avoid having data flow lines cross each other, you may repeat data store or entities on a DFD. Use
an additional symbol, like a double line on the middle vertical line of a data store symbol, or a diagonal
line in a corner of a entity square, to indicate a repeated symbol.
Additional guidelines for drawing DFDs
 Completeness: It refers to whether the DFDs include all the components necessary for the system you are
modeling. If the DFD contains data flows that do no lead anywhere, or data store, processes, or external
entities that are not connected to anything else, that DFD is not complete.
 Consistency: It refers to whether or not the depiction of the system shown at one level of a DFD is
compatible with the depictions of the system shown at other level. A gross violation of consistency
would be a level-1 diagram with no level-0 diagram. Another example of inconsistency would be a data
flow that appears on higher level DFD but not on lower levels.
 Timing considerations: On a given DFD, there is no indication of whether a data flow occurs at what time
and there is also no indication of when a system would run. When you draw DFDs, then draw them as if
the system you are modeling has never started and will never stop.
 The iterative nature of drawing DFDs: Iterative development recognizes that requirements determination
and requirements structuring are interaction, not sequential, sub-phases of the analysis phase of the
SDLC. One rule of thumb is that it should take you about three revisions for each DFD.
 Drawing primitive DFDs: The lowest level DFD is the primitive DFD, one rule is to stop drawing when
the lowest logical level is reached. It is not easy to know what the lowest level is, hence few concrete
rules for when to stop decomposing are
o When you have reduced each process to a single decision or calculation or to a single database operation
such as retrieve, update, create or delete.
o When each data store represents data about a single entity, such as customer, employee, product, or order
System Analysis and Design Page 61
o When every data flow does not need to be split further to show that different data are handled in various
ways
o When there is a separate process for each choice on all lowest-level menu options.
Using Data flow diagramming in the analysis process
 Gap Analysis: The process of discovering discrepancies between two or more sets of data flow diagrams
or discrepancies within a single DFD.
 DFD can be used for gap analysis. Once DFD is completed, it is examined for problems like redundant
data flows, data that are captured but not used by the system, and data are updated identically in more
than one location.
Logical Modeling
 Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all
DFD data elements that is, details and definitions of data flows, data stores, data stored in data stores,
and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an important role in
building a database. Most DBMSs have a data dictionary as a standard feature. For example, refer the
following table:
SrNo. Data Name Description No. of Character
1 ISBN International standard Number of a book 13
2 TITLE Title of a book 60
3 SUB Subject of a book 80
4 ANAME Author Name 15
 Decision Tree
Decision trees are a method for defining complex relationships by describing decisions and avoiding the
problems in communication. A decision tree is a diagram that shows alternative actions and conditions
within horizontal tree framework. Thus, it depicts which conditions to consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A square node
indicates an action and a circle indicates a condition. It forces analysts to consider the sequence of
decisions and identifies the actual decision that must be made. 1
Cust
2. omer
0 Action 9
9 Staff
U
DB
p Action 4
8 d
5 3
10 at
e 2
S 4
t
u 6
d 7
e
System Analysis and Design n Page 62
ts
D
The major limitation of a decision tree is that it lacks information in its format to describe what other
combinations of conditions you can take for testing. It is a single representation of the relationships between
conditions and actions.
 Decision Table
Decision tables are a method of describing the complex logical relationship in a precise manner which
is easily understandable. It is useful in situations where the resulting actions depend on the occurrence of or
several combinations of independent conditions. It is a matrix containing row or columns for defining a
problem and the actions.
Components of a Decision Table
Condition Stu b: It is in the upper left quadrant which lists all the condition to be checked.
 Action Stub: It is in the lower left quadrant which outlines all the action to be carried out to meet such
condition.
 Condition Entry: - It is in upper right quadrant which provides answers to questions asked in
condition stub quadrant.
 Action Entry: - It is in lower right quadrant which indicates the appropriate action resulting from the
answers to the condition in the condition entry quadrant.
The entries in decision table are given by decision rules which define the relationships between combination
of condition and course of action. In rules sections,
 Y shows the existence of condition.
 N represents the condition, which is not satisfied.
 A blank against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For Example, refer the following table:
Conations Rule 1 Rule 2 Rule 3 Rule 4
Advancement payment made Y N N N
Purchas amount =ETB 10,00 - Y Y N
Regular Customer - Y N -
Actions
Give 5% discount X X - -
Give no discount - - X X
 Structured English
Structured English is derived from structured programming language which gives more understandable and
precise description of process. It is based on procedural logic that uses construction and imperative sentences
designed to perform operation for action.
It is best used when sequences and lops in a program must be considered and the problem needs sequences of
actions with decisions.

System Analysis and Design Page 63

It does not have strict syntax rule. It expresses all logic in terms of sequential decisions structure and
iterations. For example, see the following sequences of action

If the customer pay advance

Then
Give 5% Discount
Else
If purchase amount>=10,000
Then
If the customer is a regular customer
Then
Give 5% Discount
Else
No Discount
End If
End If
End IF
Conceptual Data Modeling (E-R Diagram)
An entity-relationship model, a graphical representation of entities and their relationships to each other,
describes the organization of data within databases or information systems. An entity is a piece of data—an
object or concept about which data is stored. A relationship is how the data is shared between entities. ER
diagram expresses the overall logical structure of a database graphically. There are three types of relationships
between entities:
 One-to-one: one instance of an entity (A) is associated with one other instance of another entity (B). For
example, in a database of employees, each employee name (A) is associated with only one social security
number (B).
 One-to-many: one instance of an entity (A) is associated with zero, one or many instances of another
entity (B), but for one instance of entity B there is only one instance of entity A. For example, for a
company with all employees working in one building, the building name (A) is associated with many
different employees (B), but those employees all share the same singular association with entity A.
 Many-to-many: one instance of an entity (A) is associated with one, zero or many instances of another
entity (B), and one instance of entity B is associated with one, zero or many instances of entity A. For
example, for a company in which all of its employees work on multiple projects, each instance of an
employee (A) is associated with many instances of a project (B), and at the same time, each instance of a
project (B) has multiple employees (A) associated with it.
Developing Entity Relationship Diagrams (ERDs)

System Analysis and Design Page 64

 Entity Relationship Diagrams are a major data modeling tool and will help organize the data in your
project into entities and define the relationships between the entities.
 This process has proved to enable the analyst to produce a good database structure so that the data can be
stored and retrieved in a most efficient manner.
INFORMATION
Entity
 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. E.g. employee,
payment, campus, book. Specific examples of an entity are called instances. E.g. the employee John
Jones, Mary Smith's payment, etc.
Relationship
 A data relationship is a natural association that exists between one or more entities. E.g. Employees
process payments.
 Cardinality defines the number of occurrences of one entity for a single occurrence of the related entity.
E.g. an employee may process many payments but might not process any payments depending on the
nature of her job.
Attribute
 A data attribute is a characteristic common to all or most instances of a particular entity. Synonyms
include property, data element, and field. E.g. Name, address, Employee Number, pay rate are all
attributes of the entity employee.

1. Identify Entities Identify the roles, events, locations, tangible things or concepts about
which the end-users want to store data.
2. Find Relationships Find the natural associations between pairs of entities using a relationship
matrix.
3. Draw Rough ERD Put entities in rectangles and relationships on line segments connecting
the entities.
4. Fill in Cardinality Determine the number of occurrences of one entity for a single
occurrence of the related entity.
5. Define Primary Identify the data attribute(s) that uniquely identify one and only one
Keys occurrence of each entity.
6. Draw Key-Based Eliminate Many-to-Many relationships and include primary and foreign
ERD keys in each entity.
7. Identify Attributes Name the information details (fields) which are essential to the system
under development.
8. Map Attributes For each attribute, match it with exactly one entity that it describes.

System Analysis and Design Page 65

 9. Draw fully Adjust the ERD from step 6 to account for entities or relationships
attributed ERD discovered in step 8.  An
10. Check Results Does the final Entity Relationship Diagram accurately depict the system attri
data? but
e or
combination of attributes that uniquely identifies one and only one instance of an entity is called a
primary key or identifier. E.g. Employee Number is a primary key for Employee.

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY

(One way of doing it)
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

System Analysis and Design Page 66

 Project uses

3. Draw Rough ERD

We connect the entities whenever a relationship is shown in the entity Relationship Matrix.

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

The primary keys are Department Name, Supervisor Number, Employee Number, Project Number.

System Analysis and Design Page 67

 6. Draw Key-Based ERD
There are too 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
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 Name Department Supervisor Number Supervisor
Employee Number Employee Supervisor Name Supervisor
Employee Name Employee Project Name Project
Project Number Project

System Analysis and Design Page 68

 9. Draw Fully Attributed ERD

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

System Analysis and Design Page 69

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 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 crow’s 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

System Analysis and Design Page 70

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
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.

System Analysis and Design Page 71

CHAPTER 7: DESIGN OF NEW SYSTEMS
7.1. Selecting computerization application
System design is the phase that bridges the gap between problem domain and the existing system in a
manageable way. This phase focuses on the solution domain, i.e. ―how to implement?‖
It is the phase where the SRS document is converted into a format that can be implemented and decides how
the system will operate.
In this phase, the complex activity of system development is divided into several smaller sub-activities, which
coordinate with each other to achieve the main objective of system development.
Inputs to System Design
System design takes the following inputs:
 Statement of work
 Requirement determination plan
 Current situation analysis
 Proposed system requirements including a conceptual data model, modified DFDs, and Metadata (data
about data).
Outputs for System
Design System design gives the following outputs:
 Infrastructure and organizational changes for the proposed system.
 A data schema, often a relational schema.
 Metadata to define the tables/files and columns/data-items.
 A function hierarchy diagram or web page map that graphically describes the program structure.
 Actual or pseudo code for each module in the program.
 A prototype for the proposed system.
Types of System Design
a) Logical Design
Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the system. It
describes the inputs (sources), outputs (destinations), databases (data stores), procedures (data flows) all in a
format that meets the user requirements.
While preparing the logical design of a system, the system analyst specifies the user needs at level of detail
that virtually determines the information flow into and out of the system and the required data sources. Data
flow diagram, E-R diagram modelling are used.
b) Physical Design
Physical design relates to the actual input and output processes of the system. It focuses on how data is
entered into a system, verified, processed, and displayed as output.
It produces the working system by defining the design specification that specifies exactly what the candidate
system does. It is concerned with user interface design, process design, and data design.
It consists of the following steps:
System Analysis and Design Page 72
  Specifying the input/output media, designing the database, and specifying backup procedures.
 Planning system implementation.
 Devising a test and implementation plan, and specifying any new hardware and System .
 Updating costs, benefits, conversion dates, and system constraints.
c) Architectural Design
It is also known as high level design that focuses on the design of system architecture. It describes the
structure and behavior of the system. It defines the structure and relationship between various modules of
system development process.
d) Detailed Design
It follows Architectural design and focuses on development of each module.
e) Conceptual Data Modelling
It is representation of organizational data which includes all the major entities and relationship. System
analysts develop a conceptual data model for the current system that supports the scope and requirement for
the proposed system.
The main aim of conceptual data modelling is to capture as much meaning of data as possible. Most
organization today uses conceptual data modelling using E-R model which uses special notation to represent
as much meaning about data as possible.
f) Entity Relationship Model
It is a technique used in database design that helps describe the relationship between various entities of an
organization.
Design strategies
 Top-Down Strategy
The top-down strategy uses the modular approach to develop the design of a system. It is called so because it
starts from the top or the highest-level module and moves towards the lowest level modules.
In this technique, the highest-level module or main module for developing the System is identified. The main
module is divided into several smaller and simpler sub-modules or segments based on the task performed by
each module. Then, each sub-module is further subdivided into several sub-modules of next lower level. This
process of dividing each module into several sub-modules continues until the lowest level modules, which
cannot be further subdivided, are not identified.
 Bottom-Up Strategy
Bottom-Up Strategy follows the modular approach to develop the design of the system. It is called so because
it starts from the bottom or the most basic level modules and moves towards the highest level modules. In this
technique,
 Modules at the most basic or the lowest level are identified.
 These modules are then grouped together based on the function performed by each module to form the
next higher level modules.
 Then, these modules are further combined to form the next higher-level modules.
System Analysis and Design Page 73
  This process of grouping several simpler modules to form higher level modules continues until the
main module of system development process is achieved.
 Structured Design
Structured design is a data-flow based methodology that helps in identifying the input and output of the
developing system. The main objective of structured design is to minimize the complexity and increase the
modularity of a program. Structured design also helps in describing the functional aspects of the system.
In structured designing, the system specifications act as a basis for graphically representing the flow of data
and sequence of processes involved in a System development with the help of DFDs. After developing the
DFDs for the System system, the next step is to develop the structure chart.
 Modularization
Structured design partitions the program into small and independent modules. These are organized in top
down manner with the details shown in bottom.
Thus, structured design uses an approach called Modularization or decomposition to minimize the complexity
and to manage the problem by subdividing it into smaller segments.
Advantages
 Critical interfaces are tested first.
 It provides abstraction.
 It allows multiple programmers to work simultaneously.
 It allows code reuse.
 It provides control and improves morale.
 It makes identifying structure easier.
Structured Charts
Structured charts are a recommended tool for designing a modular, top down systems which define the
various modules of system development and the relationship between each module. It shows the system
module and their relationship between them.
It consists of diagram consisting of rectangular boxes that represent the modules, connecting arrows, or lines.
 Control Module: It is a higher-level module that directs lower-level modules, called subordinate
modules.
 Library Module: It is a reusable module and can be invoked from more than one point in the chart.
We have two different approaches to design a structured chart:
 Transform-Centered Structured Charts: They are used when all the transactions follow same path.
 Transaction–Centered Structured Charts: They are used when all the transactions do not follow the
same path.
Objectives of Using Structure Flowcharts
 To encourage a top-down design.
 To support the concept of modules and identify the appropriate modules.
 To show the size and complexity of the system.

System Analysis and Design Page 74

  To identify the number of readily identifiable functions and modules within each function.
 To depict whether each identifiable function is a manageable entity or should be broken down into
smaller components.
Factors Affecting System Complexity
To develop good quality of system System , it is necessary to develop a good design. Therefore, the main
focus on while developing the design of the system is the quality of the System design. A good quality
System design is the one, which minimizes the complexity and cost expenditure in System development.
The two important concepts related to the system development that help in determining the complexity of a
system are coupling and cohesion.
Coupling
Coupling is the measure of the independence of components. It defines the degree of dependency of each
module of system development on the other. In practice, this means the stronger the coupling between the
modules in a system, the more difficult it is to implement and maintain the system.
Each module should have simple, clean interface with other modules, and that the minimum number of data
elements should be shared between modules.
High Coupling
These types of systems have interconnections with program units dependent on each other. Changes to one
subsystem leads to high impact on the other subsystem.
Low Coupling
These types of systems are made up of components which are independent or almost independent. A change
in one subsystem does not affect any other subsystem.
Coupling Measures
 Content Coupling: When one component actually modifies another,then the modified component is
completely dependent on modifying one.
 Common Coupling: When amount of coupling is reduced somewhat by organizing system design so that
data are accessible from a common data store.
 Control Coupling: When one component passes parameters to control the activity of another component.
 Stamp Coupling: When data structures is used to pass information from one component to another.
Data Coupling: When only data is passed then components are connected by this coupling.
Cohesion
Cohesion is the measure of closeness of the relationship between its components. It defines the amount of
dependency of the components of a module on one another. In practice, this means the systems designer must
ensure that:
 They do not split essential processes into fragmented modules
 They do not gather together unrelated processes represented as processes on the DFD into meaningless
modules.

System Analysis and Design Page 75

The best modules are those that are functionally cohesive. The worst modules are those that are coincidentally
cohesive.
The worst degree of cohesion
 Coincidental cohesion is found in a component whose parts are unrelated to another.
 Logical Cohesion: It is where several logically related functions or data elements are placed in same
component.
 Temporal Cohesion: It is when a component that is used to initialize a system or set variables performs
several functions in sequence, but the functions are related by timing involved.
 Procedurally Cohesion: It is when functions are grouped together in a component just to ensure this
order.
 Sequential Cohesion: It is when the output from one part of a component is the input to the next part of it.
7.2 Design methodology.
7.3 Output design.
The design of output is the most important task of any system. During output design, developers identify the
type of outputs needed, and consider the necessary output controls and prototype report layouts.
Objectives of Output Design
The objectives of input design are:
 To develop output design that serves the intended purpose and eliminates the production of unwanted
output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.
Let us now go through various types of outputs:
External Outputs
Manufacturers create and design external outputs for printers. External outputs enable the system to leave
the trigger actions on the part of their recipients or confirm actions to their recipients.
Some of the external outputs are designed as turnaround outputs, which are implemented as a form and re-
enter the system as an input.
Internal outputs
Internal outputs are present inside the system, and used by end-users and managers. They support the
management in decision making and reporting.
There are three types of reports produced by management information:
 Detailed Reports: They contain present information which has almost no filtering or restriction
generated to assist management planning and control.
 Summary Reports: They contain trends and potential problems which are categorized and summarized
that are generated for managers who do not want details.
System Analysis and Design Page 76
 Exception Reports: They contain exceptions, filtered data to some condition or standard before
presenting it to the manager, as information.
Output Integrity Controls
Output integrity controls include routing codes to identify the receiving system, and verification messages to
confirm successful receipt of messages that are handled by network protocol.
Printed or screen-format reports should include a date/time for report printing and the data. Multipage
reports contain report title or description, and pagination. Pre-printed forms usually include a version
number and effective date.
7.4 Input design.
Information system, input is the raw data that is processed to produce output. During the input design, the
developers must consider the input devices such as PC, MICR, OMR, etc. Therefore, the quality of system
input determines the quality of system output. Well-designed input forms and screens have following
properties:
 It should serve specific purpose effectively such as storing, recording, and retrieving the information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles regarding:
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.
Objectives for Input Design
The objectives of input design are:
 To design data entry and input procedures.
 To reduce input volume.
 To design source documents for data capture or devise other data capture methods.
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.
Data Input Methods
It is important to design appropriate data input methods to prevent errors while entering data. These methods
depend on whether the data is entered by customers in forms manually and later entered by data entry
operators, or data is directly entered by users on the PCs.
A system should prevent user from making mistakes by:
 Clear form design by leaving enough space for writing legibly.
 Clear instructions to fill form.
 Clear form design
 Reducing key strokes.
 Immediate error feedback
System Analysis and Design Page 77
 Some of the popular data input methods are:
 Batch input method (Offline data input method)
 Online data input method
 Computer readable forms Interactive data input
Input Integrity Controls
Input integrity controls include a number of methods to eliminate common input errors by end-users. They
also include checks on the value of individual fields; both for format and the completeness of all inputs.
Audit trails for data entry and other system operations are created using transaction logs which gives a
record of all changes introduced in the database to provide security and means of recovery in case of any
failure .
Forms Design
Both forms and reports are the product of input and output design and are business document consisting of
specified data. The main difference is that forms provide fields for data input but reports are purely used for
reading. For example, order forms, employment and credit application, etc.
 During form designing, the designers should know:
o who will use them
o where would they be delivered
o the purpose of the form or report
 During form design, automated design tools enhance the developer’s ability to prototype forms and
reports and present them to end users for evaluation.
Objectives of Good Form Design
A good form design is necessary to ensure the following:
 To keep the screen simple by giving proper sequence, information, and clear captions.
 To meet the intended purpose by using appropriate forms.
To ensure the completion of form with accuracy.
 To keep the forms attractive by using icons, inverse video, or blinking cursors etc.
 To facilitate navigation.
Types of Forms
Flat Forms
 It is a single copy form prepared manually or by a machine and printed on a paper. For additional copies
of the original, carbon papers are inserted between copies.
 It is a simplest and inexpensive form to design, print, and reproduces, which uses less volume.
Unit Set/Snap out Forms
 These are papers with one-time carbons interleaved into unit sets for either handwritten or machine use.
 Carbons may be either blue or black, standard grade medium intensity.
 Generally, blue carbons are best for handwritten forms while black carbons are best for machine use.
Continuous strip/Fanfold Forms

System Analysis and Design Page 78

  These are multiple unit forms joined in a continuous strip with perforations between each pair of forms.
 It is a less expensive method for large volume use.
No Carbon Required (NCR) Paper
 They use carbonless papers which have two chemical coatings (capsules), one on the face and the other
on the back of a sheet of paper.
 When pressure is applied, the two capsules interact and create an image.

System Analysis and Design Page 79

CHAPTER 8:- SYSTEM IMPLEMENTATION
The System system needs to be checked for its intended behavior and direction of progress at each
development stage to avoid duplication of efforts, time and cost overruns, and to assure completion of the
system within stipulated time.
System testing and quality assurance come to aid for checking the system. It includes:
 Product level quality (Testing)
 Process level quality.
Testing
Testing is the process or activity that checks the functionality and correctness of System according to
specified user requirements in order to improve the quality and reliability of system. It is an expensive, time
consuming, and critical approach in system development which requires proper planning of overall testing
process.
A successful test is one that finds the errors. It executes the program with explicit intention of finding error,
i.e., making the program fail. It is a process of evaluating system with an intention of creating a strong system
and mainly focuses on the weak areas of the system or System .
Characteristics of System Testing
System testing begins at the module level and proceeds towards the integration of the entire System system.
Different testing techniques are used at different times while testing the system. It is conducted by the
developer for small projects and by independent testing groups for large projects.
Stages of System Testing
The following stages are involved in testing:
Test Strategy
It is a statement that provides information about the various levels, methods, tools, and techniques used for
testing the system. It should satisfy all the needs of an organization.
Test Plan
It provides a plan for testing the system and verifies that the system under testing fulfills all the design and
functional specifications. The test plan provides the following information:
 Objectives of each test phase
 Approaches and tools used for testing
 Responsibilities and time required for each testing activity
 Availability of tools, facilities, and test libraries
 Procedures and standards required for planning and conducting the tests
 Factors responsible for successful completion of testing process
Test Case Design
 Test cases are used to uncover as many errors as possible in the system.
 A number of test cases are identified for each module of the system to be tested.

System Analysis and Design Page 80

 Each test case will specify how the implementation of a particular requirement or design decision is to be
tested and the criteria for the success of the test.
 The test cases along with the test plan are documented as a part of a system specification document or in
a separate document called test specification or test description.
Test Procedures
It consists of the steps that should be followed to execute each of the test cases. These procedures are
specified in a separate document called test procedure specification. This document also specifies any special
requirements and formats for reporting the result of testing.
Test Result Documentation
Test result file contains brief information about the total number of test cases executed, the number of errors,
and nature of errors. These results are then assessed against criteria in the test specification to determine the
overall outcome of the test.
Types of Testing
Testing can be of various types and different types of tests are conducted depending on the kind of bugs one
seeks to discover:
Unit Testing
Also known as Program Testing, it is a type of testing where the analyst tests or focuses on each program or
module independently. It is carried out with the intention of executing each statement of the module at least
once.
 In unit testing, accuracy of program cannot be assured and it is difficult to conduct testing of various
input combination in detail.
 It identifies maximum errors in a program as compared to other testing techniques.
Integration Testing
In Integration Testing, the analyst tests multiple modules working together. It is used to find discrepancies
between the system and its original objective, current specifications, and systems documentation.
Here the analysts are try to find areas where modules have been designed with different specifications for data
length, type, and data element name. It verifies that file sizes are adequate and that indices have been built
properly.
Functional Testing
Function testing determines whether the system is functioning correctly according to its specifications and
relevant standards documentation. Functional testing typically starts with the implementation of the system,
which is very critical for the success of the system.
Functional testing is divided into two categories:
 Positive Functional Testing: It involves testing the system with valid inputs to verify that the outputs
produced are correct.
 Negative Functional Testing: It involves testing the System with invalid inputs and undesired operating
conditions.
System Analysis and Design Page 81
Rules for System Testing
To carry out system testing successfully, you need to follow the given rules:
 Testing should be based on the requirements of user.
 Before writing testing scripts, understand the business logic should be understood thoroughly.
 Test plan should be done as soon as possible.
 Testing should be done by the third party.
 It should be performed on static System .
 Testing should be done for valid and invalid input conditions.
 Testing should be reviewed and examined to reduce the costs.
 Both static and dynamic testing should be conducted on the System .
 Documentation of test cases and test results should be done.
Quality Assurance
It is the review of system or System products and its documentation for assurance that system meets the
requirements and specifications.
 Purpose of QA is to provide confidence to the customers by constant delivery of product according to
specification. System quality Assurance (SQA) is a techniques that includes procedures and tools applied
by the System professionals to ensure that System meet the specified standard for its intended use and
performance.
 The main aim of SQA is to provide proper and accurate visibility of System project and its developed
product to the administration.
 It reviews and audits the System product and its activities throughout the life cycle of system
development.
Objectives of Quality Assurance
The objectives of conducting quality assurance are as follows:
 To monitor the System development process and the final System developed.
 To ensure whether the System project is implementing the standards and procedures set by the
management.
 To notify groups and individuals about the SQA activities and results of these activities.
 To ensure that the issues, which are not solved within the System are addressed by the upper
management.
 To identify deficiencies in the product, process, or the standards, and fix them.
Levels of Quality Assurance
There are several levels of QA and testing that need to be performed in order to certify a System product.
Level 1: Code Walk-through
At this level, offline System is examined or checked for any violations of the official coding rules. In general,
the emphasis is placed on examination of the documentation and level of in-code comments.
Level 2: Compilation and Linking
System Analysis and Design Page 82
At this level, it is checked that the System can compile and link all official platforms and operating systems.
Level 3: Routine Running
At this level, it is checked that the System can run properly under a variety of conditions such as certain
number of events and small and large event sizes etc.
Level 4: Performance test
At this final level, it is checked
Implementation is a process of ensuring that the information system is operational. It involves:
 Constructing a new system from scratch
 Constructing a new system from the existing one.
Implementation allows the users to take over its operation for use and evaluation. It involves training the users
to handle the system and plan for a smooth conversion.
Training
The personnel in the system must know in detail what their roles will be, how they can use the system, and
what the system will or will not do. The success or failure of well-designed and technically elegant systems
can depend on the way they are operated and used.
Training Systems Operators
Systems operators must be trained properly such that they can handle all possible operations, both routine and
extraordinary. The operators should be trained in what common malfunctions may occur, how to recognize
them, and what steps to take when they come.
Training involves creating troubleshooting lists to identify possible problems and remedies for them, as well
as the names and telephone numbers of individuals to contact when unexpected or unusual problems arise.
Training also involves familiarization with run procedures, which involves working through the sequence of
activities needed to use a new system.
User Training
 End-user training is an important part of the computer-based information system development, which
must be provided to employees to enable them to do their own problem solving.
 User training involves how to operate the equipment, troubleshooting the system problem, determining
whether a problem that arose is caused by the equipment or System .
 Most user training deals with the operation of the system itself. The training courses must be designed to
help the user with fast mobilization for the organization.
Training Guidelines
 Establishing measurable objectives
 Using appropriate training methods
 Selecting suitable training sites
 Employing understandable training materials
Training Methods
 Instructor-led training
System Analysis and Design Page 83
It involves both trainers and trainees, who have to meet at the same time, but not necessarily at the same
place. The training session could be one-on-one or collaborative. It is of two types:
 Virtual Classroom
In this training, trainers must meet the trainees at the same time, but are not required to be at the same place.
The primary tools used here are: video conferencing, text based Internet relay chat tools, or virtual reality
packages, etc.
 Normal Classroom
The trainers must meet the trainees at the same time and at the same place. They primary tools used here are
blackboard, overhead projectors, LCD projector, etc.
 Self-Paced Training
It involves both trainers and trainees, who do not need to meet at the same place or at the same time. The
trainees learn the skills themselves by accessing the courses at their own convenience. It is of two types:
 Multimedia Training
In this training, courses are presented in multimedia format and stored on CD-ROM. It minimizes the cost in
developing an in-house training course without assistance from external programmers.
 Web-based Training
In this training, courses are often presented in hyper media format and developed to support internet and
intranet. It provides just–in-time training for end users and allows organization to tailor training requirements.
Conversion
It is a process of migrating from the old system to the new one. It provides understandable and structured
approach to improve the communication between management and project team.
Conversion Plan
It contains description of all the activities that must occur during implementation of the new system and put it
into operation. It anticipates possible problems and solutions to deal with them. It includes the following
activities:
 Name all files for conversions.
 Identifying the data requirements to develop new files during conversion.
 Listing all the new documents and procedures that are required.
 Identifying the controls to be used in each activity.
 Identifying the responsibility of person for each activity.
 Verifying conversion schedules.
Conversion Methods
The four methods of conversion are:
 Parallel Conversion
 Direct Cutover Conversion
 Pilot Approach
 Phase-In Method
System Analysis and Design Page 84
File Conversion
It is a process of converting one file format into another. For example, file in WordPerfect format can be
converted into Microsoft Word. For successful conversion, a conversion plan is required, which includes:
 Knowledge of the target system and understanding of the present system
 Teamwork
 Automated methods, testing and parallel operations
 Continuous support for correcting problems
 Updating systems/user documentation, etc
Many popular applications support opening and saving to other file formats of the same type. For example,
Microsoft Word can open and save files in many other word processing formats.
Post-Implementation Evaluation Review (PIER)
A PIER is a tool or standard approach for evaluating the outcome of the project and determine whether the
project is producing the expected benefits to the processes, products or services. It enables the user to verify
that the project or system has achieved its desired outcome within specified time period and planned cost.
PIER ensures that the project has met its goals by evaluating the development and management processes of
the project.
Objectives of PIER
The objectives of having a PIER are as follows:
 To determine the success of a project against the projected costs, benefits, and timelines.
 To identify the opportunities to add additional value to the project.
 To determine strengths and weaknesses of the project for future reference and appropriate action.
 To make recommendations on the future of the project by refining cost estimating techniques.
The following staff members should be included in the review process:
 Project team and Management#
 User staff
 Strategic Management Staff
 External users
System Maintenance/Enhancement
Maintenance means restoring something to its original conditions. Enhancement means adding, modifying the
code to support the changes in the user specification. System maintenance conforms the system to its original
requirements and enhancement adds to system capability by incorporating new requirements.
Thus, maintenance changes the existing system, enhancement adds features to the existing system, and
development replaces the existing system. It is an important part of system development that includes the
activities which corrects errors in system design and implementation, updates the documents, and tests the
data.
Maintenance Types
System maintenance can be classified into three types:
System Analysis and Design Page 85
 Corrective Maintenance: Enables user to carry out the repairing and correcting leftover problems.
 Adaptive Maintenance: Enables user to replace the functions of the programs.
 Perfective Maintenance: Enables user to modify or enhance the programs according to the users’
requirements and changing needs.
System Audit
It is an investigation to review the performance of an operational system. The objectives of conducting a
system audit are as follows:
 To compare actual and planned performance.
 To verify that the stated objectives of system are still valid in current environment.
 To evaluate the achievement of stated objectives.
 To ensure the reliability of computer based financial and other information.
 To ensure all records included while processing.
 To ensure protection from frauds.
Audit of Computer System Usage
Data processing auditors audits the usage of computer system in order to control it. The auditor need control
data which is obtained by computer system itself.
The System Auditor
The role of auditor begins at the initial stage of system development so that resulting system is secure. It
describes an idea of utilization of system that can be recorded which helps in load planning and deciding on
hardware and System specifications. It gives an indication of wise use of the computer system and possible
misuse of the system.
Audit Trial
An audit trial or audit log is a security record which is comprised of who has accessed a computer system and
what operations are performed during a given period of time. Audit trials are used to do detailed tracing of
how data on the system has changed.
It provides documentary evidence of various control techniques that a transaction is subject to during its
processing. Audit trials do not exist independently. They are carried out as a part of accounting for recovering
lost transactions.
Audit Methods
Auditing can be done in two different ways:
Auditing around the Computer
 Take sample inputs and manually apply processing rules.
 Outputs with computer outputs
Auditing through the Computer
 Establish audit trial which allows examining selected intermediate results
 Control totals provide intermediate checks
Audit Considerations
System Analysis and Design Page 86
Audit considerations examine the results of the analysis by using both the narratives and models to identify
the problems caused due to misplaced functions, split processes or functions, broken data flows, missing data,
redundant or incomplete processing, and non-addressed automation opportunities. The activities under this
phase are as follows:

 Identification of alternative solutions
 Evaluation and feasibility analysis of each solution
 Selection and recommendation of most practical and appropriate solution
 Project cost estimation and cost benefit analysis
Security
System security refers to protecting the system from theft, unauthorized access and modifications, and
accidental or unintentional damage. In computerized systems, security involves protecting all the parts of
computer system which includes data, System , and hardware. Systems security includes system privacy and
system integrity.
 System privacy deals with protecting individuals systems from being accessed and used without the
permission/knowledge of the concerned individuals.
 System integrity is concerned with the quality and reliability of raw as well as processed data in the
system.
Control Measures
There are varieties of control measures which can be broadly classified as follows:
Backup
 Regular backup of databases daily/weekly depending on the time criticality and size.
 Incremental back up at shorter intervals. Backup copies kept in safe remote location particularly
necessary for disaster recovery.
 Duplicate systems run and all transactions mirrored if it is a very critical system and cannot tolerate any
disruption before storing in disk.
Physical Access Control to Facilities
 Physical locks and Biometric authentication. For example, finger print
 ID cards or entry passes being checked by security staff.
 Identification of all persons who read or modify data and logging it in a file.
Using Logical or System Control
 Password system.
 Encrypting sensitive data/programs.
 Training employees on data care/handling and security.
 Antivirus System and Firewall protection while connected to internet.
Risk Analysis

System Analysis and Design Page 87

A risk is the possibility of losing something of value. Risk analysis starts with planning for secure system by
identifying the vulnerability of system and impact of this. The plan is then made to manage the risk and cope
with disaster. It is done to accesses the probability of possible disaster and their cost.
Risk analysis is teamwork of experts with different backgrounds like chemicals, human error, and process
equipment. The following steps are to be followed while conducting risk analysis:
 Identification of all the components of computer system
 Identification of all the threats and hazards that each of the components faces.
 Quantify risks i.e. assessment of loss in the case threats become reality.
Risk Analysis – Main Steps
As the risks or threats are changing and the potential losses are also changing, management of risk should be
performed on periodic basis by senior managers. Risk management is a continuous process and it involves the
following steps:
 Identification of security measures.
 Calculation of the cost of implementation of security measures.
 Comparison of the cost of security measures with the loss and probability of threats.
 Selection and implementation of security measures.
 Review of the implementation of security measures

System Analysis and Design Page 88

CHAPTER 9: STANDARDS AND DOCUMENTATION
Documentation is a process of recording the information for any reference or operational purpose. It helps
users, managers, and IT staff, who require it. It is important that prepared document must be updated on
regular basis to trace the progress of the system easily.
After the implementation of system if the system is working improperly, then documentation helps the
administrator to understand the flow of data in the system to correct the flaws and get the system working.
Programmers or systems analysts usually create program and system documentation. Systems analysts usually
are responsible for preparing documentation to help users learn the system. In large companies, a technical
support team that includes technical writers might assist in the preparation of user documentation and training
materials.
Advantages
 It can reduce system downtime, cut costs, and speed up maintenance tasks.
 It provides the clear description of formal flow of present system and helps to understand the type of
input data and how the output can be produced.
 It provides effective and efficient way of communication between technical and nontechnical users about
system.
 It facilitates the training of new user so that he can easily understand the flow of system.
 It helps the user to solve the problems such as troubleshooting and helps the manager to take better final
decisions of the organization system.
 It provides better control to the internal or external working of the system.
Types of Documentations
When it comes to System Design, there are following four main documentations:
 Program documentation
 System documentation
 Operations documentation
 User documentation
Program Documentation
 It describes inputs, outputs, and processing logic for all the program modules.
 The program documentation process starts in the system analysis phase and continues during
implementation.
 This documentation guides programmers, who construct modules that are well supported by internal and
external comments and descriptions that can be understood and maintained easily.
Operations Documentation
Operations documentation contains all the information needed for processing and distributing online and
printed output. Operations documentation should be clear, concise, and available online if possible. It includes
the following information:
 Program, systems analyst, programmer, and system identification.
System Analysis and Design Page 89
 Scheduling information for printed output, such as report, execution frequency, and deadlines.
 Input files, their source, output files, and their destinations.
 E-mail and report distribution lists.
 Special forms required, including online forms.
 Error and informational messages to operators and restart procedures.
 Special instructions, such as security requirements.
System documentation is detailed information about a system’s design specifications, its internal workings,
and its functionality. It is meant for maintenance programmers. It is further divided into internal and external
documentation. Internal documentation is part of the program source code or is generated at compile time.
External documentation includes the outcome of all of the structured diagramming techniques such as DFD
and ERD.
 It describes each program within the IS and the entire IS itself.
 It describes the system’s functions; the way they are implemented, each program's purpose within the
entire IS with respect to the order of execution, information passed to and from programs, and overall
system flow.
 It includes data dictionary entries, data flow diagrams, object models, screen layouts, source documents,
and the systems request that initiated the project
 Most of the system documentation is prepared during the system analysis and system design phases.
 During systems implementation, an analyst must review system documentation to verify that it is
complete, accurate, and up-to-date, and including any changes made during the implementation process.
User documentation is written or visual information about an application system, how it works and how to
use it. The kinds of user documents are reference guide, user’s guide, release description, system
administrator’s guide and acceptance sign-off. The reference guide consists of exhaustive list of the system’s
functions and commands usually in alphabetical order. The purpose of the reference guide is to provide
information on how users can use computer systems to perform specific tasks. The information in user’s guide
is typically ordered by how often tasks are performed and how complex they are. The release description
contains information about a new system release, including a list of complete documentation for the new
release, features and enhancements, known problems and how they have been dealt with in the new release
and information about installation.
 The systems administrator’s guide is intended to those who will install and administer a new system and
contains information about the network on which the system will run, System interfaces for peripherals
such as printers, trouble shooting, and setting up user accounts.
 The acceptance sign-off allows users to test for proper system installation and then signify their
acceptance of the new system and its documentation with their signatures.
User documentation should include:
 A system overview that clearly describes all major system features, capabilities, and limitations.
 Description of source document content, preparation, processing, and, samples.
System Analysis and Design Page 90
 Overview of menu and data entry screen options, contents, and processing instructions.
 Examples of reports that are produced regularly or available at the user’s request, including samples.
 Security and audit trail information.
 Explanation of responsibility for specific input, output, or processing requirements.
 Procedures for requesting changes and reporting problems.
 Examples of exceptions and error situations.
 Frequently asked questions (FAQs).
 Explanation of how to get help and procedures for updating the user manual.

System Analysis and Design Page 91