AIS Best Teaching Material

AIS AIS
Accounting Information System: An Overview
Chapter One
Accounting Information Systems: An Overview
Chapter Outlines
> What is an AIS?
> Why do we study an AIS?
> Role of AIS in Value Chain and Supply Chain
> Information and Decision making
> Information Technology and Corporate Strategy
Chapter Objectives
After completing this chapter, a student should be able to:
> Explain what an accounting information system (AIS) is and describe the basic functions it
performs.
> Discuss why studying the design and understanding of AIS is important.
> Explain the role played by the AIS in a companys value chain and discuss ways that the
AIS can add value to a business.
> Describe and contrast the basic strategies and strategic positions that a business can adopt.
1.1) What Is an Accounting Information System?

To answer the question what is accounting information system (AIS), one should first define a
system, then define an information system and, finally define an accounting information system.
What is a System?
System is a set of two or more interrelated components that interact and work together to achieve
a goal. That is, a system is a set of inter-dependent components which collectively accomplish
certain objectives. System is a method of doing something. This indicates a system has three main
elements: inputs, processes, and outputs. The input is data, raw materials, or any thing that is must
be processed and converted into the output. Processes refer to methods or activities or procedures
used or applied to convert input into output. Output is the goal to be achieved or the end result of
a system.
Systems are almost always composed of smaller subsystems, each performing a specific function
important to and supportive of the main system. That is, most systems are composed of smaller
subsystems (some of which may be systems in their own right) and vice versa. The subsystems
should be designed to maximize achievement of the organizations goals even to the detriment of
the subsystem itself. For example, the production department (a subsystem) of a company might
have to forego its goal of staying within its budget in order to meet the organizations goal of
delivering product on time. There might be goal conflict or goal congruence in a system. Goal
conflict occurs when the activity of a subsystem is not consistent with another subsystem or with
the larger system. Goal congruence occurs when the subsystems goals are in line with the
organizations goals. The larger and more complicated a system, the more difficult it is to achieve
goal congruence. The system concept encourages integration (i.e., minimizing the duplication of
recording, storing, reporting and processing).
1
AIS AIS
What is Information System?

An Information system is a framework in which data is collected, processed, controlled and
managed through stages in order to provide information to users. It evolves over time and
becomes more formalized as a firm grows and becomes more complex. It can be a manual or
computerized system. Firms depend on information systems in order to survive and stay
competitive. An Information System is a set of interrelated subsystems that work together to
collect, process, store, and distribute information, which helps to plan, make decisions, and control
activities. An information system differs from other kinds of systems in that its objective is to
monitor and document the operations of some other system, which is called a target system. An
information system can not exist without such a target system. For example, production activities
would be the target system for a production scheduling system, human resources activities would
be the target system of a human resource information system, and so on. It is important to recognize
that human resource activities (Human Resource Cycle) in a firm have a component/sub-system
that can be considered an information system (Human Resource Information System). Every
operating system will have a subsystem that can be considered an information system whose
objective is to monitor and control such an operating system. It should be obvious that all
information systems are systems but not all systems are information systems. A vending machine,
for example, is a system that is not an information system.
Major Types of Information Systems

The term information system suggests the use of computer technology in an organization to
provide information to users. A computer based information system is a collection of computer
hardware and software designed to transform data into useful information. There are several types
of computer based information systems. These include the following:
Categories of Information Systems:
1. Operational-Level Information Systems - Support operational managers by
monitoring the day-to-days elementary activities and transactions of the organization.
E.g. TPS
2. Knowledge-Level Information Systems - Support knowledge and data workers in
designing products, distributing information, and coping with paperwork in an
organization. E.g. KWS, OAS
3. Management-Level Information Systems - Support the monitoring, controlling,
decision-making, and administrative activities of middle managers. E.g. MIS, DSS
4. Strategic-Level Information Systems - Support long-range planning activities of senior
management. E.g. ESS
Types of Information System (IS)
1. Transaction Processing Systems (TPS) Computerized system that performs and records
the daily routine transactions necessary to conduct the business; these systems serve the
operational level of the organization.
> Type: operational-level information system
> Inputs: transactions and events
> Processing: updating
> Outputs: detailed reports
> Users: operations personnel, supervisors, etc
> Decision-making: highly structured
2
AIS AIS
EXAMPLES: Payroll system, accounts payable system, accounts receivable systems, cash
management, security trading, etc. Note: TPS is a major producer of information for other
systems
Types of Transaction Processing Systems
Sales /Marketing Production/Manufact Finance/ Accounting Human Resources
Systems uring Systems Systems Systems
Major > Sales management > Scheduling > Budgeting > Personnel record
Functions > Market research > Planning > General ledger > Benefits
> Promotion > Shipping/receiving > Billing > Compensation
> Pricing > Engineering > Cost accounting > Labor relations
> New products > Operations > Training
Major > Sales Order IS > Materials Resource > General Ledger System > Payroll System
Applications/ > Market Research Planning systems > Accounts Receivable > Employee Records
System > Purchase Order / Payable System System
Systems > Budgeting System > Benefit systems
> Pricing system Systems
> Engineering Systems > Funds management > Career Path
> Quality Control Systems Systems
systems
2. Office Automation Systems (OAS) Computer system, such as word processing, electronic
mail system, and scheduling system, that is designed to increase the productivity of data
workers in the office.
> Type: knowledge-level information system
> Inputs: documents, schedules, etc
> Processing: document management, scheduling, communication
> Outputs: documents; schedules
> Users: clerical workers
EXAMPLES: document imaging system, word processing, electronic calendar, etc
3. Knowledge Work Systems (KWS) Information system that aids knowledge workers in the
creation and integration of new knowledge in the organization.
> Type: knowledge-level
> Inputs: design specifications
> Processing: modeling
> Outputs: designs, graphics
> Users: technical staff; professionals
EXAMPLES: Engineering workstations, graphic workstations, managerial workstations
4. Decision Support Systems (DSS) Information system at the management level of an
organization that combines data and sophisticated analytical models or data analysis tools to
support semi-structured and unstructured decision making. A DSS is designed for specific
types of decisions for specific users. It is directed at serving specific non-routine information
requests by mangers. A familiar example is the use of spreadsheet software to perform what if
analysis of operating or budgeted data such as sales forecasts by marketing personnel.
> Type: management-level system
> Inputs: low volume data
> Processing: simulations, analysis
> Outputs: decision analysis
> Users: professionals, staff managers
> Decision-making: semi-structured
3
AIS AIS
EXAMPLES: regional sales analysis, production scheduling, cost analysis, pricing/profitability

analysis, and contract analysis
Characteristics of Decision-Support Systems
> DSS offers users flexibility, adaptability, and a quick response
> DSS operates with little or no assistance from professional programmers
> DSS provides support for decisions and problems whose solutions cannot be specified
in advance
> DSS uses sophisticated data analysis and modeling tools
5. Management Information Systems (MIS) Information system at the management level of

an organization that serves the functions of planning, controlling, and decision making by
providing routine summary and exception reports. MIS provides a wide variety of information
beyond that which is associated with data processing in organizations. It recognizes that
managers within organizations use and require information in decision- making, and that
computer based information systems can assist in providing information to managers.
> Type: management-level system
> Inputs: high volume data
> Processing: simple models
> Outputs: summary reports
> Users: middle managers
> Decision-making: structured to semi-structured
EXAMPLES: annual budgeting, sales management, inventory control, capital investment
analysis, relocation analysis
Characteristics of Management information Systems
> MIS support structured decisions at the operational and management control levels.
However, they are also useful for planning purposes of senior management staff.
> MIS are generally reporting and control oriented. They are designed to report on
existing operations and therefore to help provide day-to-day control of operations.
> MIS rely on an existing corporate data and data flows
> MIS have little analytical capability.
> MIS generally aid in decision making using past and present data.
> MIS are relatively inflexible.
> MIS have an internal rather than an external orientation.
6. Executive Support Systems (ESS)

Information system at the strategic level of an organization that addresses unstructured decision
making through advanced graphics and communications. ESS is a system tailored to the strategic
information needs of top-level management. Much of the information used by top-level
management comes from sources other than an organizations information systems. Examples are
meetings, memos, television, periodicals, and social activities. But some information must be
processed by the organizations information systems. An ESS provides top-level management with
easy access to selective information that has been processed by the organizations information
systems. This selective information concerns the key success factors that top-level management
has identified as being critical to the organizations success. Actual versus projected market share
for product groups and budget versus actual profit and loss data for divisions might be key success
factors for top-level executive.
> Type: strategic level system
4
AIS AIS
> Inputs: aggregate data; internal and external

> Processing: interactive
> Outputs: projections
> Users: senior managers
> Decision-making: highly unstructured
EXAMPLES: 5 year operating plan, 5-year budget forecasting, 5-year sales trend forecasting, 5-
year profit planning, 5-year manpower planning
Classification of Information Systems by Functional Areas

> The marketing information system - Systems that help the firm identify customers for
the firms products or services, develop products and services to meet customers
needs, promote products and services, sell the products and services, and provide
ongoing customer support.
> The manufacturing (operations, production) information system - systems that deal with
the planning, development, and production of products and services and with
controlling the flow of production
> The human resources information system Systems that maintain employee records;
Track employee skills, job performance, and training; and support planning for
employee compensation and career development.
> The accounting information system it will be discussed here under.
What Is an AIS?
Being an information system, an accounting information system (AIS) must have a target system.
The target system is the accounting-aspects of business operations when broadly defined. Other
non-accounting aspects of business operations are covered by information systems such as
Decision Support System, Management Information System, Executive Support System, and so
on. The target system for an accounting system is aspects of business operations that are concerned
with accountability for and control of the assets and liabilities of the enterprise, determination of
the results of operations that ultimately leads to the computation of comprehensive income, and
the financial reporting of business operations. AISs are computer- based systems designed to
transform accounting data into information. AIS is used broadly to include many transaction
processing systems, the use of information technology and the development of information
systems.
An AIS is a system that collects, records, stores, and processes data to produce information for
decision makers. It can use advanced technology; or be a simple paper-and-pencil system; or be
something in between. Technology is simply a tool to create, maintain, or improve a system. That
is, an Accounting Information System is a unified structure that employs physical resources and
components to transform economic data into accounting information for external and internal
users. It is a collection of resources such as people and equipment designed to transform financial
data into financial information.
Components of AIS
AISs consist of five components:
1. People persons who operate the system and perform various functions.
2. Procedures both manual and automated methods used in collecting, processing, and
storing data about organizations activities
3. Data - are raw facts and figures that are processed to produce information.
5
AIS AIS
4. Software computer programs that assists in processing the organizations data

5. Information Technology Infrastructure includes computers, input devices, output
devices, and data communication devices, data bases, data modeling concepts, computer
networks such LAN, WAN, etc
Functions of AIS
The five components together enable AIS to fulfill three important functions. These functions of
AIS are:
> To collect and store data about events, resources, and agents.
> To transform that data into information that management can use to make decisions about
events, resources, and agents.
> To provide adequate controls to safeguard the organizations assets including its data, to
ensure that the data are available when needed and are accurate and reliable.
1.2) Why do we study an AIS? (Reasons for Studying AIS)

An AIS is an important topic to study because of the following reasons:
1. AIS is fundamental to accounting
Accounting is an information providing activity, so accountants need to understand:
> how the system that provides that information is designed, implemented and used.
> how financial information is reported
> how information is used to make decisions
Other accounting courses focus on how the information is provided and used. An AIS course
places greater emphasis on:
> how the data is collected and transformed
> how the availability, reliability, and accuracy of the data is ensured
2. AIS skills are critical to career success
> Auditors need to evaluate the accuracy and reliability of information produced by the AIS
> Tax accountants must understand the clients AIS adequately to be confident that it is
providing complete and accurate information for tax planning and compliance work.
> In private industry and not-for-profits, systems work is considered the most important
activity performed by accountants (system analysts)
> In management consulting, the design, selection, and implementation of accounting
systems is a rapid growth area (management consultants)
Effective AIS is essential to the organizations long run success:
> It enables monitoring the events that occur and how well an organization works.
> It also tracks the effect of various events on the resources that the organization controls.
> Information about the agents who participate in the events is used to assign responsibility
for actions taken.
3. AIS skills are critical to career development those who want to pursue education in
information system at Master or PhD level must have understanding of AIS
4. AIS is complementary to other systems courses
There are many other systems courses focus on design and implementation of information systems,
and which help you develop specialized skills in such areas as databases, expert systems, and
telecommunications. The AIS course differs from these other information systems courses in its
focus on accountability and control. These issues are important because in most large
organizations, the managers are not owners. Instead, the owners have entrusted the
6
AIS AIS
management with assets (including data and information) and hold them accountable for their
proper use. Hence, the AIS course complements the other systems course.
5. An AIS topic is part of international certificates and examinations (E.g. ACCA, CPA)
> Makes up about 25% of the Business Environment & Concepts section of the CPA exam.
6. To understand the interaction of AIS in general, Information technology in particular with
corporate strategy and organization culture
Factors influencing the design of AIS
AIS design is affected by information technology, the organizations strategy, and the
organizations culture.
Culture
AIS
Information technology affects the companys choice of business strategy. IT is profoundly

changing the way that accounting and many other business activities are performed. It is also
essential to know the costs and benefits of new IT developments. This requires developing basic
understanding of business strategies and how IT can be used to implement those strategies as well
as how new developments in IT create an opportunity to modify those strategies.
While culture affects the design of the AIS, its also true that the AIS affects culture by altering
the dispersion and availability of information. Because the AIS functions within an organization,
it should be designed to reflect the values of that organizational culture. The design of AIS also
influences the organizational culture by controlling the flow of information within the
organization. For example, an AIS that makes information easily accessible and widely available
is likely to increase pressures for more decentralized and autonomy.
Studying AIS will increase understanding of how Information Technology (IT) is applied to
different accounting systems such as financial accounting, managerial accounting, auditing,
taxation, etc. Study of AIS is also useful for understanding business processes, computerized
software, and information flows that are all part of AIS.
1.3) Role of the AIS in the Value Chain

The objective of most organizations is to provide value to their customers. One may ask what value
is. While value is a commonly used buzzword, in its genuine sense, it means making the value
of the finished component greater than the sum of its parts. It may mean:
7
AIS AIS
> Making it faster

> Making it more reliable
> Providing better service or advice
> Providing something in limited supply
> Providing enhanced features
> Customizing it
Value Chain is the sequential set of primary and support activities that an enterprise performs to
turn inputs into valuable outputs for its customers. That is, Value is provided by performing a
series of activities referred to as the value chain. An organizations value chain consists of five
primary activities that directly provide value to its customers. The "primary activities" include:
inbound logistics, operations (production), outbound logistics, marketing and sales, and after-sale
services (maintenances). The "support activities" include: firm infrastructure, human resources,
technology, and procurement.
The Primary Activities are:
1. Inbound Logistics- consists of receiving, storing, and distributing raw materials that
are used as inputs by a firm to create salable services and products.
2. Operations- activities that transform inputs into final products or services.
3. Outbound Logistics- are the activities involved in distributing finished products or
services to customers.
4. Marketing and Sales- refers to the activities involved in helping customers to buy
the organizations products or services.
5. Post-sale Services- activities that provide post sale support to customers. Examples are
repairs and maintenance services.
2. Operations
Logistics Logistics and Sales Services
Firm Infrastructure
Human Resources
Technology
Purchasing
Figure 1.2: Value Chain of a Firm
The Support Activities
Organizations also perform a number of other support activities that enable the five primary
activities to be performed efficiently and effectively. Those support activities can be grouped into
four categories:
1. Firm Infrastructure- refers to the accounting, finance, legal support, and general
administrative activities that are necessary for any organization to function. The AIS is
part of the firm infrastructure.
2. Human Resources- activities that include recruiting, hiring, training, and providing
employee benefits and compensation.
8
AIS AIS
3. Technology- activities that improve a product or service. Examples include research and
development, improvements in information technology, web site development, and product
design.
4. Purchasing- includes all the activities involving in procuring raw materials, supplies,
machinery, and the buildings used to carry out the primary activities.
It shall be recalled that systems are often composed of subsystems. Thus, each step in an
organizations value chain is itself a system consisting of a set of activities. For example, the sales
and marketing step includes such activities as market research, calling on customers, order
processing, and credit approval. In addition, an organizations value chain is itself a part of a larger
system. Organizations interact with suppliers, distributors, and customers.
How Can AIS Add Value to an Organization?

The value chain model shows that the AIS is a support activity. Thus, AIS can add value to the
organization by providing accurate and timely information so that the five primary value chain
activities can be performed more effectively and efficiently. A well-designed AIS can do this by:
1. Improving the quality and reducing the cost of products and services- an AIS
for example can monitor machinery so that operators are notified immediately when the
process falls outside acceptable quality limits. This helps not only maintain product quality
but also reduces the amount of wasted materials and the costs of having to rework anything.
2. Improving efficiency- a well designed AIS can help improve the efficiency of
operations by providing more timely information. For example, a just in time
manufacturing approach requires constant, accurate, up to date information about raw
materials inventories and their costs. That means less time and cost are used to produce and
distribute goods and services.
3. Improving decision making- an AIS can improve decision making by providing
accurate information in a timely manner.
4. Sharing of knowledge- a well-designed AIS can make it easier to share knowledge and
expertise, perhaps thereby improving operations and even providing a competitive
advantage.
Supply Chain (Value System)

The linking of these separate value chains creates a larger system known as a supply chain
(Value System). That is, an organizations value chain can be connected with the value chains
of its suppliers, customers, and distributors.
The Supply Chain can be expanded as follows:
9
AIS AIS
Raw Materials Supplier The linking of these separate value chains creates a larger
Inbound Logistics system known as a supply chain (Value System).
Operations
Outbound Logistics
Manufacturer
Marketing & Sales
Inbound Logistics
Post-Sale Service
Operations
Outbound Logistics Customers
Marketing & Sales Inbound Logistics
Post-Sale Service Operations
Outbound Logistics
Example: The outbound logistics of the supplier is linked to inbound Marketing & Sales
logistics of the manufacturer and the outbound logistics of the manufacturer
Post-Sale Service
is linked to the inbound logistics of customers.
Figure 1.4: Expanded Supply Chain
A well designed AIS helps an organization make large profit by improving the efficiency and
effectiveness of its Supply Chain. For example, allowing customers to directly access the
companys inventory and sales order entry systems can reduce the cost of sales and marketing
activities. Moreover, if such access reduces customers costs and time of ordering, both sales and
customer retention rates may increase. Information technology can facilitate synergistic linkages
that improve the performance of each companys value chain.
1.4) Data, Information and Decision Making

The functions of AIS include collecting data and transform that data into information. Data are
facts that are collected, recorded, stored, and processed by an information system. Information is
different from data. Information is data that have been organized and processed to provide
meaning to a user. Usually, more information and better information translates into better
decisions.
Functional Steps in Transforming Data into Information
The steps of transformation are:
1. Data Collection capturing, recording, validating and editing data for completeness and
accuracy
2. Data Processing /Maintenance classifying, sorting, calculating data
3. Data Management and Control - storing, maintaining and retrieving data and then
safeguarding and securing data and ensuring the accuracy and completeness of the data
4. Information Generation interpreting, reporting, and communicating information
One of the roles of AIS is improving decision making by providing useful information. Once data
have been collected, the AIS will transform the facts to information so that they will be used to
make decisions. In the case of AIS, Data are business activities and transactions that are
10
AIS AIS
collected, recorded, stored, and processed by an Accounting Information System. Organizations

collect data about:
Events that occur,
Resources that are affected by those events, and
Agents who participate in the events
Information is data that have been processed and are meaningful and useful to users. In the case
of AIS, information includes financial statements that are useful in making decisions by external
and internal users. The terms meaningful and useful are important terms and usually subsume
other qualities such as relevance, reliability, completeness, timeliness, understandability,
verifiability, accessibility, consistency, comparability, etc. These are characteristics that make
information useful.
> Relevance it reduces uncertainty by helping you predict what will happen or confirm
what already has happened.
> Reliability it is dependable, i.e., free from error or bias and faithfully portrays events
and activities.
> Completeness - it doesnt leave out anything thats important
> Timeliness you get it in time to make your decision
> Understandability it is presented in a manner you can comprehend and use it
> Verifiability it is a consensus notion. The nature of the information is such that
different people would tend to produce the same result.
> Accessibility you can get to it when you need it and in a format you can use
> Consistency and Comparability it is created using the policies and methods so that it
useful for comparisons among companies or within company from year to year
Usually, more information and better information translates into better decisions. However, when
you get more information than you can effectively assimilate, you suffer from Information
Overload. When youve reached the overload point, the quality of decisions declines while the
costs of producing the information increases. Information must be valuable to users. The value
of information is the difference between the benefits of information and cost of producing
information. The benefit may take up one of the following forms: reduction of uncertainty;
improved decisions; and improved ability to plan and schedule activities. Costs may include time
and resources spent on collecting data; processing data; storing data; and distributing information
to users. However, costs and benefits of information are often difficult to quantify, but you need
to try when youre making decisions about whether to provide information.
Information is provided to both external users and internal users. External users primarily use
information that is either mandatory information, which is required by a governmental entity,
such as financial statements and income tax returns; or essential information, which is required
to conduct business with external parties, such as purchase orders. In providing mandatory or
essential information, the focus should be on minimizing costs; meeting regulatory requirements;
and meeting minimum standards of reliability and usefulness. Internal users primarily use
discretionary information. The primary focus in producing this information is ensuring that
benefits exceed costs, i.e., the information has positive value.
Decision Making
There are different models of decision-making and problem solving process. All those models
depict that decision-making as a complex, multi-step activity.
11
AIS AIS
First the problem has to be identified.

Then the decision maker must select a method for solving the problem
Next the decision maker must collect the data needed to execute the decision model and,
Next the decision maker interpret the outputs of the model and evaluate the merits of each
alternative decision model
Finally, the decision maker chooses and executes the preferred solution.
The AIS can provide assistance in all phases of decision-making. Different decision models and
analytical tools can be provided to users. Query languages can facilitate the gathering of relevant
data upon which to make the decision. Various tools such as graphical interfaces can help the
decision maker interpret the results of a decision model and evaluate and choose among alternative
course of action. Finally the AIS can provide feedback on the results of actions.
The degree to which AIS can support decision-making depends, however, on the type of decision
being made. Decisions may be categorized either in terms of the degree of structure or by their
scope.
Decision Structure
There is variation in the degree of structure used to make decisions. Decisions are classified into
three in this regard.
Structured (programmable) decisions- are repetitive, routine, and understood well
enough that they can be delegated to lower level employees in the organization. For
example, the decision about extending credit to established customers require only
knowledge about the customers credit limit and current balance. Structured decisions can
often be automated.
Semi structured decisions- are characterized by incomplete rules for making the
decisions and the need for subjective assessments and judgments to supplement formal
data analysis. Setting a marketing budget for a new product is a typical example. Although
such decisions cant be fully automated, they are often supported by computer based
decision aids.
Unstructured (nonprogrammable) decisions - are nonrecurring and non-routine
decisions. For example, choosing the cover of a magazine, hiring senior management, and
selecting basic research projects to be undertaken. No framework or model exists to solve
such problems. Instead, they require considerable judgment and intuition. Nevertheless,
unstructured decisions can be supported by computer based decision aids that facilitate
gathering information from diverse sources.
Decision Scope
Decisions vary in terms of the scope of their effect. This will include:
Operational Control- concerns the effective and efficient performance of specific tasks.
Decisions relating to inventory management and extending credit are examples of
operational control activities.
Management Control- concerns the effective and efficient resources for accomplishing
organizational objectives. Budgeting, developing human resource practices and deciding
on research projects and product improvements are examples of management control
activities.
12
AIS AIS
Strategic Planning- concerns the establishing of organizational objectives and policies

for accomplishing those objectives. Setting financial and accounting policies, developing
new product lines, and acquiring new businesses are examples of strategic planning
decisions.
There exists a correspondence between a managers level in an organization and his decision
making responsibilities.
> Top management unstructured and semi-structured decisions, involving strategic planning
> Middle managers deal with semi structured decisions, involving management control
> Lower level supervisors and employees face semi structured or unstructured decisions
involving operational control
Value of Information for Decision Making
The information produced by well-designed AIS can improve decision making in several ways:
> First, it identifies situations requiring management action. For example, a cost report with a
large variance might stimulate management to investigate and if necessary take corrective
action.
> Second, by reducing uncertainty, accounting information provides a basis for choosing
among alternative actions. For example, accounting information is often used to set prices
and determine credit policies.
> Third, information about the results of previous decisions provides valuable feedback that
can be used to improve future decisions.
1.5) AIS and Corporate Strategy

Strategies and Strategic Positions
Corporations have unlimited opportunities to invest in technology and limited resources to invest
in technology. Consequently, they must identify the improvements likely to yield the highest
return. This decision requires an understanding of the entitys overall business strategy. Michael
Porter suggests that there are two basic business strategies companies can follow: product-
differentiation strategy or low-cost strategy
1. A Product Differentiation Strategy entails adding some features or services to a product
that are not provided by competitors. Doing so allows a company to charge a premium
price to its customers.
2. A Low Cost Strategy entails striving to be the most efficient producer of a product or a
service. A low-cost strategy involves offering a cheaper product than competitors. The low
cost is made possible by operating more efficiently
Sometimes companies can succeed in both producing a better product than competitors at costs
below its industry average. Usually, however, companies must choose between the two basic
strategies. If they concentrate on being the lowest cost producers, they will have to forego some
value added features that might differentiate their product. If they focus on product differentiation,
they most likely will not have the lowest costs in the industry. Thus a business strategy involves
making choices.
The choice of a business strategy involves the selection of a specific strategic position they shall
adopt. According to Michael Porter, there are three strategic positions.
13
AIS AIS
1. A Variety Based Strategic Position involves producing or providing a subset of the

industrys products or services. EXAMPLE: An insurance company that only offers life
insurance as opposed to life, health, property-casualty, etc.
2. A Needs Based Strategic Position involves trying to serve most or all of the needs of a
particular group of customers. This entails first identifying a target market. EXAMPLE: A
Farm based insurance companies providing a portfolio of insurance and financial services
tailored to the specific needs of farmers.
3. An Access Based Strategic Position involves serving a subset of customers who differ
from other customers in terms of factors such as geographic locations or size, which creates
different requirements for serving those customers. Example: Satellite Internet Services
that are intended primarily for customers in rural areas who cannot get cable services
The three strategic positions are not mutually exclusive and indeed often overlap. For example, a
company may adopt elements of all the three. Choosing a strategic position is important because
it enables the company to focus its efforts; otherwise, it risks trying to be everything to everybody.
EXAMPLE: A radio station that tries to play all types of music will probably fail. Its critical to
design the organizations activities so they reinforce one another in achieving the selected strategic
position. The result is synergy, which is difficult for competitors to imitate.
Information Technology and Strategy

We have seen that IT can affect strategy. In addition to directly affecting the way that organizations
carry out their value chain activities, IT such as the Internet can also affect significantly both
strategy and strategic positioning. For example, it dramatically cuts costs, thereby helping
companies to implement a low cost strategy.
The growth of the Internet has profoundly affected the way value chain activities are performed:
> Inbound and outbound logistics can be streamlined for products that can be digitized, like
books and music.
> The Internet allows companies to cut costs, which impacts strategy and strategic position.
> Because the Internet is available to everyone, intense price competition can result. The
outcome may be that many companies shift from low-cost to product-differentiation
strategies.
> The Internet may impede Access-Based Strategic positions.
Role of the AIS in Business Strategy

AIS plays important role in helping a firm adopt and maintain a strategic position. Achieving a
close fit among activities requires that data be collected about each activity. It is also important
that the information system collect and integrate both financial and non-financial data about the
organizations activities. Traditionally, the AIS was used as transaction processing system because
it was concerned only with financial data. To handle non-financial data, other systems were used
leading to redundancy and problem in updating data.
Enterprise Resource Planning (ERP) Systems are designed to overcome the problems as they
integrate all aspects of a companys operations with its traditional AIS. For example, when a sales
order is entered by the sales force, the effect of the transaction automatically flows to all affected
parts of the company. Inventory is updated, production schedules are adjusted, and
14
AIS AIS
purchase orders of raw materials and supplies are initiated. More over, important non-financial
data such as the time of sales are collected and stored in the same system.
A key feature of ERP systems is the integration of financial with other non-financial operating
data. The value of such integration is to suggest that there may be strategic benefits to more closely
linking traditionally separate functions of information systems and accounting, and many
organizations are beginning to combine these two functions.
End of Chapter Questions

1. What is the meaning of system, data, and information?
2. What is an accounting information system (AIS)?
3. Why is the AIS an important topic to study?
4. What are the roles of the AIS in the value chain?
5. How does the AIS provide information for decision making?
6. What are the basic strategies and strategic positions an organization can pursue?
15
AIS Overview of Business Processes AIS
Chapter Two
Overview of Business Processes
Chapter Outlines
> Business Activities and Information Needs
> Transaction Processing: Documents and Procedures
> Providing Information for Decision Making
Chapter Objectives
After completing this chapter, a student should be able to:
> Explain the three basic functions performed by an accounting information system (AIS)
> Describe the documents and procedures used in AIS to collect and process transaction data.
> Discuss the types of information that can be provided by AIS.
> Describe the basic internal control objectives of AIS and explain how they are
accomplished
2.1) Business Activities and Information Needs

The three basic functions of AIS are discussed in the first chapter. In order to understand how
AIS performs its basic functions, one must understand:
> The basic types of business activities performed by business organizations, the decisions
that must be considered when managing such activities and the information needed to make
such decisions
> How data about business activities will be gathered, processed, and transferred into
information for management
> How adequate internal controls are established
Business activities are a group of related transactions. Business activities of any organization can
be described as pairs of events that involve a GivetoGet exchange. Example: sells of
merchandise to customers is Give merchandise and Get Cash exchange. Businesses engage in a
variety of activities, including:
> Acquiring capital
> Buying buildings and equipment
> Hiring and training employees
> Purchasing inventory
> Doing advertising and marketing
> Selling goods or services
> Collecting payment from customers
> Paying employees
> Paying taxes
> Paying vendors
Each of these activities follows key decisions and requires different types of information for
decision. The types of information needed for decisions are:
> Some is financial
> Some is non-financial
16
> Some comes from internal sources

> Some comes from external sources
Effective AIS needs to be able to integrate information of different types and from different
sources. The AIS interacts with external parties, such as customers, vendors, creditors, and
governmental agencies. The AIS also interacts with internal parties such as employees and
management. The interaction is typically two-way, in that the AIS sends information to and
receives information from these parties (internal parties and external parties).
Overview of Business Activities, Key Decisions, and Information Needs
Business Activities Key Decisions Information Needs
Acquiring Capital > How much? > Cash flow projections
> Invest or borrow? > Pro-forma financial statements
> If borrow, best terms? > Loan amortization schedule
Acquire Building and > Size of building? > Capacity needs
Equipment > Amount of equipment? > Prices
> Rent or buy? > Market study
> Location? > Tax tables and regulations
> How to depreciate?
Acquire Inventory > Which models to carry? > Market analyses
> How much to purchase? > Inventory status reports
> Which vendors? > Vendor performance and
> How to manage and control payment terms
inventory
Business Cycles (Transaction Cycles)

A transaction is an agreement between two entities to exchange goods or services; or any other
event that can be measured in economic terms by an organization. EXAMPLES: Sell goods to
customers, depreciation of equipment, etc.
The basic GivetoGet exchanges that are made by business organizations involve what
historically have been called transaction cycles (business cycle). The transaction cycle is a process
begins with capturing data about a transaction and ends with an information output, such as
financial statements. The basic exchanges can be grouped into five major transaction cycles.
1. Revenue Cycle
2. Expenditure Cycle
3. Production Cycle
4. Human Resources/Payroll Cycle
5. Financing Cycle
Revenue Cycle
The revenue cycle involves interactions with your customers. You give goods or services and get
cash. Thus, it involves the sales and cash receipt events.
Give Goods
Expenditure Cycle
17
The expenditure cycle involves interactions with your suppliers. You buy goods or services and
pay cash
Give Cash
Production Cycle
In the production cycle, raw materials and labor are transformed into finished goods.
Give Raw Get Finished

Materials & Labor Goods
Human Resources/ Payroll Cycle

The human resources cycle involves interactions with your employees. Employees are hired,
trained, paid, evaluated, promoted, and terminated.
Give Cash Get Labor
Financing Cycle
The financing cycle involves interactions with investors and creditors. You raise capital (through
stock or debt), repay the capital, and pay a return on it (interest or dividends).
Give Cash Get Cash

Thousands of transactions can occur within any of these cycles. But there are relatively few types
of transactions in a cycle.
Transactions in the Revenue Cycle
In the Revenue Cycle, the Basic Give-to-Get Transaction is Give goods and Get cash. Other
transactions in the revenue cycle include:
> Handle customer inquiries
> Take customer orders
> Approve credit sales
> Check inventory availability
> Initiate back orders
> Pick and pack orders
> Ship goods
> Bill customers
> Update sales and Accounts Receivables for sales
> Receive customer payments
> Update Accts Rec. for collections
> Handle sales returns, discounts, & bad debts
> Prepare management reports
> Send info to other cycles
Transactions in the Expenditure Cycle
Major Give-to-Get: Give cash; get goods or services
Other Transactions:
> Requisition goods and services
> Process purchase orders to vendors
18
> Receive goods and services

> Store goods
> Receive vendor invoices
> Update accounts payable for purchase
> Approve invoices for payment
> Pay vendors
> Update accounts payable for payment
> Handle purchase returns, discounts, and allowances
Transactions in the HR/Payroll Cycle
Major Give-to-Get: Give cash; get labor
Other Transactions:
> Recruit, hire, and train employees
> Evaluate and promote employees
> Discharge employees
> Update payroll records
> Pay employees process timecard and commission data, and prepare and
distribute payroll
> Calculate and disburse tax and benefit payments
Transactions in the Production Cycle:
Major Give-to-Get: Give labor and raw materials; Get finished goods
Other Transactions:
> Design products
> Forecast, plan, and schedule production
> Requisition raw materials
> Manufacture products
> Store finished goods
> Accumulate costs for products
Transactions in the Financing Cycle:
Major Give-to-Get: Give cash; get cash
Other Transactions:
> Forecast cash needs
> Sell securities to investors
> Borrow money from lenders
> Pay dividends to investors and interest to lenders
> Retire debt
19
These various transaction cycles relate to one another and interface with the general ledger and
reporting system, which is used to generate information for both management and external parties.
Financing Cycle
Get Giv
Cas e
h Cas
Funds h
Funds Funds
Expenditure Cycle
Human Resources Cycle
Giv Get Giv Give

e Labour e Goods
Cas Cas
h h
Data
Data Data
Information for
General Ledger & Reporting Both Internal and
System External users
Data
Raw
Data Materials
Labour
Production Cycle
Give Get
Labour Finishe
d
Goods
Give
Raw
Materials
Finished
Goods
Revenue Cycle
Give Get
Goods Cas
h
Figure 2.1: The AIS and its Subsystems
The Revenue Cycle:

> The revenue cycle interacts with customers.
20
> Gets finished goods from the production cycle
21
> Provides funds to the financing cycle

> Provides data to the General Ledger and Reporting System
The Expenditure Cycle:
> The expenditure cycle interacts with suppliers
> Gets funds from the financing cycle
> Provides raw materials to the production cycle
The Production Cycle:
> In the production cycle, raw materials, labor, and machinery and equipment
time are transformed into finished goods
> Gets raw materials from the expenditure cycle
> Gets labor from the HR/Payroll cycle
> Provides finished goods to the revenue cycle
The HR/Payroll Cycle:
> The human resources cycle involves interactions with employees of the firm
> Gets funds from the financing cycle
> Provides labor to the production cycle
The Financing Cycle:
> The financing cycle involves interactions with investors and creditors
> Gets funds from the revenue cycle
> Provides funds to the expenditure and HR/payroll cycles
The General Ledger and Reporting System:
> Gets data from all of the cycles
> Provides information for internal and external users
In many accounting software packages, the various transaction cycles are implemented as
separate modules because:
> Certain company need not apply all the modules. Not every module is needed in every
organization, e.g., retail companies dont have a production cycle.
> Some companies may need extra modules, e.g. financial institutions have demand-deposit and
installment-loan cycles that relate to transactions involving customer accounts and loans,
respectively.
> The implementation of each transaction cycle can differ significantly across companies.
However the cycles are implemented, it is critical that the AIS be able to accommodate the
information needs of managers and integrate financial and non-financial data]
2.2) Transaction Processing: Documents and Procedures

Accountants play an important role in data processing. They answer questions such as:
> What data should be entered and stored?
> Who should be able to access the data?
> How should the data be organized, updated, stored, accessed, and retrieved?
22
> How can a scheduled and unanticipated information needs be met?

To answer these questions, they must understand data processing concepts. An important
function of the AIS is to efficiently and effectively process the data about a companys
transactions. In manual systems, data is entered into paper journals and ledgers. In computer-
based (automated) systems, the series of operations performed on data is referred to as the data
processing cycle. A data processing cycle consists of four steps:
> Data input
> Data storage
> Data processing and
> Information output
1. Data Input
The first step in data processing is to capture the data. Data input is usually triggered by business
activity. Business activity contains a number of transactions and transaction contains a number of
data. Data must be collected about three facets of each business activity:
1. The events of interest
2. The resources affected by each event
3. The agents who participate in each event
Example: a sale transaction may contain the following data: Data of sale; Time of sale; Employee
who made the sale; Checkout clerk who processed the sale; Checkout Register at which the sale
occurred; total amount of sale; item sold; quantity of each item sold; term of sale; the customer
name; bill to and ship to address; delivery instrument; etc. Some are data about event; some are
data about resources; and some are data about agents.
Each transaction cycle typically processes a large number of individual events, or transactions.
Most of these however, can be categorized into a relatively small number of distinct types.
Actions to improve accuracy and efficiency of data input (data capturing)

A number of actions can be taken to improve the accuracy and efficiency of data input:
> Well-designed source documents and data entry screens
> Using pre-numbered documents or having the system automatically assign sequential
numbers to transactions
> Use turnaround documents
> Source data automation (automate source data)
> Verify transactions
Historically, most businesses used paper source documents to initially collect data about their
business activities and then transferred that data into the computer. Today, however, most data
about business activities are recorded directly through computer data entry screens. Usually the
data entry screen retains the same name as the paper source document it replaced.
Well-designed source documents and data entry screens improve both internal control and
accuracy of capturing data about business activities. Control is improved either by purchasing pre-
numbered source documents or by having the system automatically assign a
sequential number to each new transaction. It used to avoid missing document number in the
sequence. Accuracy is improved by providing instructions or prompts about what data to
collect, grouping logically related pieces of information close together, using check-off boxes or
23
pull down menus to present the available options, and using appropriate shading and boarders to
clearly separate data items.
If paper documents are still to be exchanged with customers or suppliers, data input efficiency and
accuracy can be further improved by using turnaround documents, which are records of
company data sent to an external party and then returned to the company system as input.
Turnaround documents are prepared in machine-readable form to facilitate their subsequent
processing as input records.
Source data automation is yet another means to improve the accuracy and efficiency of data
input. Source data automation devices capture transaction data in machine-readable form at the
time and place of origin. Capture data with minimal human intervention. Examples: ATMs used
by banks, point of sale (POS) scanners in retail stores, and bar code scanners used in warehouses.
2. Data Storage
Information in AIS can be organized for easy and efficient access. The basic data storage concepts
and definitions are seen below for Manual AIS and Automated AIS:
Ledger A ledger is a file used to store cumulative information about resources and agents. We
typically use the word ledger to describe the set of t-accounts. The t-account is where we keep
track of the beginning balance, increases, decreases, and ending balance for each asset, liability,
owners equity, revenue, expense, gain, loss, and dividend account. A ledger can be general ledger
or subsidiary ledger. Following is an example of a general ledger account for accounts receivable:
GENERAL LEDGER
ACCOUNT: Accounts Receivable Account Number: 120
Date Description Post Ref Debit Credit Balance
01/01/05 42,069.00
01/03/05 Sales S03 1,300.00 43,369.00
01/13/05 Cash collections CR09 4,600.00 38,769.00
01/23/05 Sales S04 5,600.00 44,369.00
General ledger the general ledger is the summary level information for all accounts. Detail
information is not kept in this account. Example: Suppose XYZ Co. has three customers. Anthony
Adams owes XYZ $100. Bill Brown owes $200. And Cory Campbell owes XYZ
$300. The balance in accounts receivable in the general ledger will be $600, but you will not be
able to tell how much individual customers owe by looking at that account. The detail isnt there.
Subsidiary ledger the subsidiary ledgers contain the detail accounts associated with the related
general ledger account. The accounts receivable subsidiary ledger will contain three separate t-
accountsone for Anthony Adams, one for Bill Brown, and one for Cory Campbell.
Coding techniques - Coding is a method of systematically assigning numbers or letters to data
items to help classify and organize them. There are many types of codes including: Sequence
Codes; Block Codes; Group Codes. With sequence codes, items (such as checks or invoices) are
numbered consecutively to ensure no gaps in the sequence. The numbering helps ensure that all
items are accounted for and there are no duplicated numbers, which would suggest errors or fraud.
When block codes are used, blocks of numbers within a numerical sequence are reserved
24
for a particular category. When group codes are used, two or more subgroups of digits are used to
code an item.
Group coding schemes are often used in assigning general ledger account numbers. The following
guidelines should be observed:
> The code should be consistent with its intended use, so make sure you know what users
need
> Provide enough digits to allow room for growth
> Keep it simple in order to minimize costs; facilitate memorization; and ensure employee
acceptance
> Make sure its consistent with the companys organization structure, and other divisions of
the organization
Chart of accounts the chart of accounts is a list of all general ledger accounts that an
organization uses. Group coding is often used for these numbers, e.g.:
> The first section identifies the major account categories, such as asset, liability, revenue,
etc.
> The second section identifies the primary sub-account, such as current asset or long-term
investment
> The third section identifies the specific account, such as accounts receivable or inventory
> The fourth section identifies the subsidiary account, e.g., the specific customer code for an
account receivable
The structure of chart of accounts is an important AIS issue, as it must contain sufficient detail to
meet the organizations needs.
Journals in manual systems and some accounting packages, the first place that transactions are
entered is the journal. A general journal is used to record:
> Non-routine transactions, such as loan payments
> Summaries of routine transactions
> Adjusting entries
> Closing entries
A special journal is used to record routine transactions. The most common special journals are:
> Cash receipts (cash receipts journal)
> Cash disbursements (cash disbursements journal)
> Credit sales (sales journal)
> Credit purchases (Purchase journal)
Audit Trail an audit trail exists when there is sufficient documentation to allow the tracing of a
transaction from beginning to end or from the end back to the beginning. The inclusion of posting
references and document numbers enable the tracing of transactions through the journals and
ledgers and therefore facilitate the audit trail
Data Storage Process
When transaction data is captured on a source document, the next step is to record the data in a
journal. A journal entry is made for each transaction showing the accounts and amounts to be
credited.
In most real-world situations, journal entries really work like this. Entries are originally made in
the General Journal only for Non-routine transactions; and Summaries of routine transactions.
25
Routine transactions are originally entered in Special Journals. The most common special
journals are Credit sales; Cash receipts; Credit purchases; and Cash disbursements
Special Journals:
1. On Dec. 1, a sale is made to Lee Co. for $800. Lee Co. was sent Invoice No. 201. The general
ledger account number for accounts receivable is No. 120. Lee Co. was about the 122nd
customer, so their subsidiary account number is 120-122.
2. The next sale on Dec. 1 was made to May Co. for $700
3. The third and final sale on Dec. 1 was made to DLK Co. for $900
Page 5 Sales Journal

Invoice Account Account
Date Number Debited Number Post Ref. Amount
12/01/04 201 Lee Co. 120-122 800.00
12/01/04 202 May Co. 120-033 700.00
12/01/04 203 DLK Co. 120-111 900.00
TOTAL 2,400.00
120/502
General Journal: Then a summary journal entry must be made to the general journal. The sales
for the period are totaled. In this case, they add up to $2,400. The 120/502 that appears beneath
the total indicates that a summary journal entry is made in the general journal with a debit to
accounts receivable (120) and a credit to sales (502).
12/01/04 Accounts receivable 2,400
Sales revenue 2,400
12/01/04 Salaries expense 900

Cash 900
Subsidiary Ledgers and General Ledgers

Suppose the company making these sales posts transactions at the end of each day. Consequently,
at days end, they will post each individual transaction to the accounts receivable subsidiary ledger:
> An $800 increase in accounts receivable (debit) will be posted to Lee Co.s subsidiary
account (120-122)
> A $700 debit will be posted to May Co.s subsidiary account (120-033)
> A $900 debit will be posted to DLK Co.s subsidiary account (120-111)
The entries in the general journal are periodically (or automatically) posted to the general ledger.
The $2,400 debit to accounts receivable will be posted to the accounts receivable control account,
and the $2,400 credit will be posted to the general ledger account for sales.
From time to time, the subsidiary account balances will be added up, and this sum will be compared
to the balance of the control account. If they arent equal, it means that there was error in recording
transaction in a journal or posting to ledger accounts.
In general the data storage processes are as follows:

> When routine transactions occur, they are recorded in special journals
> When non-routine transactions occur, they are recorded in the general journal
26
> Periodically, the transactions in the special journal are totaled, and a summary entry is
made in the general journal.
> The individual line items in the special journal are posted to the subsidiary ledger
accounts.
> The items in the general journal are posted to the general ledger.
> Periodically, the balances in the general ledger control accounts are compared to the
sums of the balances in the related subsidiary accounts.
As transactions occur, they are recorded in journals and then posted to ledgers. At the end of each
accounting period, the process is complete by carrying out the following steps.
> Using the balances in the general ledger, prepare a trial balance
> Prepare the end-of-period adjusting entries: Record in journal and Post to ledger
> Using corrected account balances, make an adjusted trial balance and complete the
Work Sheet
> Prepare: an income statement, Statement of stockholders equity, Balance sheet, and
Statement of cash flows
> Prepare closing entries
Computer-Based Storage Concepts

Storing accounting data in computer files involves organizing the data into a data hierarchy. A
computer-based storage concept includes Entity, Attribute, Record, Data Value, Field, File,
Master File, Transaction File, and Database
Entity - an entity is something about which information is stored. It is an object, person, or event
about which a firm wants to collect and maintain data. Examples of entities include employees,
inventory items, and customers.
Attributes Record
Customer Customer Address Credit Balance

Number Name Limit
1001 XYZ Co. A.A; P.O.Box 123 30,000 24,750
3 Entities 2121 ABC Co. A.A; P.O.Box 752 45,000 12,000 Data Values
4565 QRS Co. A.A; P.O.Box 741 25,000 24,900
Individual Fields
File
Attribute - are characteristics of interest with respect to the entity. Each entity has attributes or
characteristics of interest, which need to be stored. Examples: An employee pay rate and employee
address. Some attributes that an accounts receivable transaction processing system typically stores
about the credit customer entity are: Customer Number, Customer Name,
27
Customer Address, Credit Limit, and Credit Balance. Each attribute stored in the system is has a
Data Element (Data Value). There is usually a one-to-one correspondence between attributes and
data elements. A broadly defined attribute may have several specific attributes and therefore data
elements. e.g., Shipping Address Street, City, State, Zip Code, Country
Field (Data Field) is a physical space where an attribute is stored. Generally, each type of entity
possesses the same set of attributes. It is the intersection of row and column in a file within a
record. The lowest level of information in a file is a binary digit or Bit. Eight bits create a Byte
that represents a character. A Data Field combines several characters or Bytes.
Data Value is the intersection of the row and column. The specific data values for those
attributes, however, will differ among entities. Data values are stored in a Data Field. Data Value
is the content of a Data Field.
Record is the set of attributes stored for a particular instance of an entity. The combination of
attributes stored for entity will form an entitys record. Each row in a file represents a different
record.
A file is a group of related records. For example, all customer receivable records are stored in an
account receivable file.
A master file is a file that stores cumulative information about an organizations entities. It is
conceptually similar to a ledger in a manual AIS in that:
> The file is permanent;
> The file exists across fiscal periods
> Changes are made to the file to reflect the effects of new transactions
A transaction file is a file that contains records of individual transactions (events) that occur
during a fiscal period. It is conceptually similar to a journal in a manual AIS in that:
> The files are temporary
> The files are usually maintained for one fiscal period
A database is a set of interrelated, centrally-coordinated files. For example, the accounts
receivable file might be combined with customer file, sales analysis file, and related files to form
a customer database.
3. Data Processing
Once data about a business activity has been collected and entered into a system, it must be
processed. There are four different types of file processing:
> Updating data to record the occurrence of an event, the resources affected by the event,
and the agents who participated, e.g., recording a sale to a customer
> Changing data, e.g., a customer address
> Adding data, e.g., a new customer
> Deleting data, e.g., removing an old customer that has not purchased anything in 5 years
Updating can be done through several approaches:
> Batch processing
> On-line Batch Processing
> On-line, Real-time Processing
28
Batch Processing:
> Source documents are grouped into batches, and control totals are calculated.
> Periodically, the batches are entered into the computer system, edited, sorted, and stored
in a temporary file.
> The temporary transaction file is run against the master file to update the master file.
> Output is printed or displayed, along with error reports, transaction reports, and control
totals.
On-Line Batch Processing:
> Transactions are entered into a computer system as they occur and stored in a temporary
file.
> Periodically, the temporary transaction file is run against the master file to update the
master file.
> The output is printed or displayed
On-Line, Real-Time Processing (OLRT)
> Transactions are entered into a computer system as they occur.
> The master file is immediately updated with the data from the transaction.
> Output is printed or displayed
Immediate updating as each transaction occurs is referred to as on line, real-time processing.
Batch-processing is to be used for some applications that occur at fixed time intervals. Most
companies are shifting to OLRT processing because:
Online entry is more accurate than batch entry because the system can refuse incomplete
or erroneous entries, and
Real-time processing ensures that stored information is always current, thereby
increasing its usefulness for making decisions.
4. Information output: Providing Information for Decision Making

Providing information is the second function of AIS. The final step in the information processing
is information output. This output can be in the form of Documents, Reports, and Queries.
Documents
Documents are records of transactions or other company data. EXAMPLE: Employee paychecks
or purchase orders for merchandise. Documents generated at the end of the transaction processing
activities are known as operational documents (as opposed to source documents). They can be
printed or stored as electronic images.
Reports
Reports are used by employees to control operational activities and by managers to make
decisions and design strategies. They may be produced:
> On a regular basis
> On an exception basis
> On demand
Organizations should periodically reassess whether each report is needed.
Queries
Queries are user requests for specific pieces of information. They may be requested:
> Periodically
> One time
29
They can be displayed on the monitor, called soft copy and/or on the screen, called hard copy.
Output can serve a variety of purposes. Financial statements can be provided to both external and
internal parties. Some outputs are specifically for internal use:
> For planning purposes this includes budgets, which are an entitys formal expression of
goals in financial terms, and sales forecasts
> For management of day-to-day operations Example: delivery schedules
> For control purposes - performance reports are outputs that are used for control purposes.
These reports compare an organizations standard or expected performance with its actual
outcomes.
> Management by exception is an approach to utilizing performance reports that focuses on
investigating and acting on only those variances that are significant.
> For evaluation purposes - these outputs might include surveys of customer satisfaction
and reports on employee error rates
Behavioral Implications of Managerial Reports
You Get What You Measure. Budgets can cause dysfunctional behavior. EXAMPLE: In order to
stay within budget, the IT Department did not buy a security package for its system. A hacker
broke in and devastated some of their data files. Critical security measures were foregone in order
to meet budgetary goals. The resulting costs far outweighed the savings.
Budgeting can also be dysfunctional in that the focus can be redirected to creating acceptable
numbers instead of achieving organizational objectives. Does this mean organizations shouldnt
budget? The saying goes, Not many people sit around and have a roast goose fall in their lap.
In other words, if you want a roast goose, you have to aim. With financial results, youre also
unlikely to achieve when you dont aim. Just be careful where you aim!
2.3) Internal Control Considerations

The third function of AIS is to provide adequate internal controls to accomplish three basic
objectives:
1. Ensure that the information produced by the system is reliable.
2. Ensure that business activities are performed efficiently and in accordance with
managements objectives while also conforming to any applicable regulatory policies
3. Safeguard organizational assets, including data
Two important methods of accomplishing these objectives are providing adequate documentation
of all business activities and ensuring effective segregation of duties.
Adequate Documentation
Adequate documentation of all business transactions is key to accountability. Documentation
allows management to verify that assigned responsibilities were completed correctly. Well
designed documents and records can help organizations quickly identify potential problems.
Adequate documents and records can also ensure that the organization doesnt make commitments
it cannot keep. Adequately written descriptions of task procedures are also important.
Segregation of Duties
Segregation of duties refers to dividing responsibility for different portions of a transaction
among several people. The objective is to prevent one person from having total control over all
30
aspects of a business transaction. Specially, the functions of authorizing transactions, recording

transactions, and maintaining custody of assets should be performed by different people.
Segregation of these three duties helps to safeguard assets and improve accuracy because each
person can look at and thereby limit the others actions. Effective segregation of duties should
make it difficult for an individual employee to steal cash or other assets successfully.
Segregation of duties is especially important in business activities that involve the receipt or
disbursement of cash because cash can be stolen so easily. In small organizations that do not have
sufficient staff to segregate duties effectively, effective control may be achieved through close
supervision and owner performance of some key business activities such as writing checks on the
companys account.
End of Chapter Questions:

> What are the basic business activities in which an organization engages?
> What decisions must be made to undertake these activities?
> What information is required to make those decisions?
> What role does the data processing cycle play in organizing business activities and
providing information to users?
> What is the role of the information system and enterprise resource planning in modern
organizations?
31
AIS Relational Databases AIS
Chapter Three
Relational Databases
Chapter Outlines
> Database Systems
> The Relational Databases

> Database Systems and Future of Accounting
> Database Design Process
> The REA Data Model
Chapter Objectives
After studying the 3rd chapter, a student should be able to:
> Explain the difference between database and file-based legacy systems
> Describe what a relational database is and how it organizes data
> Explain the difference between logical and physical views of a database
> Create a set of well-structured tables to properly store data in a relational database
3.1) Database Systems

This chapter explains what a database is and how it differs from a file-oriented system. Then, it
also describes the structure of a relational database system. And finally, it concludes by discussing
the basic steps involved in designing an AIS database.
Files versus Databases

To fully appreciate the power of databases, it is important to understand some basic principles
about how data are stored in computer systems. An entity is anything about which the organization
wishes to store data.
Customers
Number Name Limit
1001 XYZ Co. A.A; P.O.Box 123 30,000 24,750
2121 ABC Co. A.A; P.O.Box 752 45,000 12,000
4565 QRS Co. A.A; P.O.Box 741 25,000 24,900
Information about the attributes of an entity (e.g., Customers Number and address) are stored in
fields.
Customers
Number Name Limit
1001 XYZ Co. A.A; P.O.Box 123 30,000 24,750
2121 ABC Co. A.A; P.O.Box 752 45,000 12,000
4565 QRS Co. A.A; P.O.Box 741 25,000 24,900
All the fields containing data about one entity (e.g., one customer) form a record. All the fields
that contain data about the same entity form a record.
32
Customers
Number Name Limit
1001 XYZ Co. A.A; P.O.Box 123 30,000 24,750
2121 ABC Co. A.A; P.O.Box 752 45,000 12,000
4565 QRS Co. A.A; P.O.Box 741 25,000 24,900
A set of related records are grouped to form a file. For example, all customer receivable records
are stored in an account receivable file.
Customers
Number Name Limit
1001 XYZ Co. A.A; P.O.Box 123 30,000 24,750
2121 ABC Co. A.A; P.O.Box 752 45,000 12,000
4565 QRS Co. A.A; P.O.Box 741 25,000 24,900
A set of interrelated, centrally coordinated files is referred to as a database. EXAMPLE:

Accounts Receivable Database is shown below: it is a combination of Customers File; Sales File;
and Cash Receipts File
Record 1: Record 2: Record 3: Record 1000:
Field 1: Field 2: Field 6:

Street City State
Name
Types of Files
Two basic types of files exist. A master file is conceptually similar to a ledger in manual AIS.
Master files sore cumulative information about an organizations resources and the agents with
whom it interacts. For example the inventory and equipment master files store information about
33
important organizational resources. Similarly, the customer, supplier, and employee master files
store information about important agents with whom the organization interacts.
Master files are permanent; they exist across all periods. Individual records within a master file,
however, are frequently changed. The most common type of change made to the records in master
files involves updating the data to reflect the effect of specific transactions. Periodically, new
records may also be added to the master file and sometimes, individual records may even be
deleted.
The second type of file is called a transaction file, which is conceptually similar to a journal in
manual AIS. Transaction files contain records of the individual business transactions (events) that
occur during a specific fiscal period. For example, a file containing records of sales events and
another file containing records of customer payments. Both of them would be used to update
individual customer account balances in the customers master file. Transaction files are not
permanent, but are usually only maintained on-line for one fiscal period.
For many years companies created new files and programs each time an information need arose.
The result was a significant increase in the number of master files that organizations stored. This
proliferation of master files created problems. Often, the same data were stored in two ore more
master files. This made it difficult to effectively integrate data stored in different files and to obtain
an organization-wide view of the data. It also created problems because the specific data values
stored in the different files may not have been consistent. For example, new customer address used
to ship merchandise but the old address may be used for billing.
This proliferation (increased in number) of master files created problems:

Often the same information was stored in multiple master files.
Made it more difficult to effectively integrate data and obtain an organization-wide view of
the data.
Also, the same information may not have been consistent between files.
If a customer changed his phone number, it may have been updated in one master file but not
another.
34
Databases
Database systems were developed to address the problems associated with the proliferation of
master files. A database is a set of interrelated, centrally coordinated files.
The database approach treats data as an organizational resource that should be used by and
managed for the entire organization, not just the originating department or function.
The combination of the database; DBMS; and the application programs that access the database
through the DBMS is referred to as the Database System
A database management system (DBMS) serves as the interface between the database and the
various application programs. The person responsible for the database is referred to as the database
administrator. As technology improves, many large companies are developing very large databases
called data warehouses.
Figure 2.4: Database Approach (Database System)
Database
Fact A, Fact D
Fact B, Fact E
Fact C, Fact F
Fact G, Fact H
Database
Database
System
Management
System
(DBMS)
Sales Shipping Billing

Program Program Program
Importance and Advantages of Database Systems

> Database technology is everywhere
> Most new AISs implement a database approach
> Virtually all mainframe computer sites use database technology
> Use of databases with PCs is growing also
> As an accountant, you are likely to audit or work for companies that use database technology
to store, process, and report accounting transactions
> Many accountants work directly with databases and will enter, process, and query databases
> Some will develop and evaluate internal controls necessary to ensure database integrity
> Others will be involved in the design and management of databases
Database technology provides the following benefits to organizations:
> Data integration - achieved by combining master files into larger pools of data accessible by
many programs
> Data sharing - Its easier to share data integrated data
> Reporting flexibility - reports can be revised easily and generated as needed. The database
can easily be browsed to research problems or obtain detailed information.
35
> Minimal data redundancy and inconsistencies - because data items are usually stored only
once
> Data independence - data items are independent of the programs that use them. Consequently,
a data item can be changed without changing the program and vice versa. This Makes
programming easier and simplifies data management.
> Central management of data - data management is more efficient because the database
administrator is responsible for coordinating, controlling, and managing data.
> Cross-functional analysis relationships can be explicitly defined and used in the preparation
of management reports. EXAMPLE: Relationship between selling costs and promotional
campaigns.
Logical and Physical Views of Data

In file-oriented systems, programmers must know the physical location and layout of records used
by a program. They must reference the location, length, and format of every field they utilize. This
process becomes more complex when data is used from several files.
Database systems overcome this problem by separating the storage and use of data elements by
providing two separate views of the data. That means, Database Systems separate the logical and
physical views of data.
1. The logical view is how the user or programmer conceptually organize and understand the
data. It is the manner in which users conceptually organize, view, and understand the
relationships among data items. Example: a sales manager may conceptualize all
information about customers as being stored in form of a table.
2. The physical view refers to how and where the data are physically arranged and stored.
Example: the way data are physically arranged and stored on disk, tape, CD-ROM, or other
media.
Separating the logical and the physical views of data facilitates developing new applications
because programmers can concentrate on coding the application logic (what the program will do)
and do not need to focus on how and where the various data items are stored or accessed.
The Database Management System Software deals with the links between the way the data are
physically stored and each users logical view of the data. Hence, it controls the database so that
users can access, query, or update it without reference to how or where the data are physically
stored. The user only needs to define the logical data requirements. Separating the logical and the
physical views of data also means that users can change their conceptualization about relationships
among data items (their logical view of the task) without making changes in the way those data
are physically stored. Likewise, the database administrator can change the physical storage of the
data to improve performance, without affecting users or application programs.
36
Figure 3.3: Logical and Physical Views of Data

Logical View User A
Past Due Accounts Regions Amount %

Name Balance Days North 3,500 35%
Jackson 2145 48 South 1,595 16%
Houston 1595 65 West 2,700 27%
East 2,205 22%
The DBMS translates users logical

DBMS views into instructions as to which
data should be retrieved from the
database
The Operating System translates

System DBMS requests into instructions
to physically retrieve data from
various disks.
Schemas
A schema describes the logical structure of a database. The database schema is a map or plan of
the entire database. Any particular user or application program will be interested in only a subset
of the schema, called the subschema. A database schema must be flexible enough to satisfy the
required of use of subschema. There are three levels of schemas:
> The conceptual level schema,
> The external level schema, and
> The internal level schema
The conceptual level schema is the organization-wide view of the entire database i.e., the big
picture. It lists all data elements and the relationships between them. The external level schema
consists of a set of individual user views of portions of the database, each of which is also referred
to as a subschema. The internal level schema provides a low level view of the database. It
describes how the data are actually stored and accessed, including information about pointers,
record layouts, indexes, record lengths, and so forth.
37
Subschema User A Subschema User B Subschema User C

Region % John - - - 245 External Level
Name Balance Days North 35% A set of
Susan - - 378
Jackson 2145 48 South 16%
individual user
West 27% Ryan - - -274
Houston 1595 65 logical views of
East 22%
portions of the
Mapping External-Level views to Conceptual-Level Schema
Inventory Sales Customer Conceptual Level

Enterprise-wide View
of Entire Database
Cash Receipts
Mapping Conceptual-Level Items to internal-level descriptions
Inventory Record Internal Level

Item number integer (5), non-null, index = itemx Details about data
Description character (15) storage, such as
Cost currency (6,2) record layouts,
Sales Record definitions, addresses,
Invoice number - integer (5), non-null, index = salesx
Figure 3.4: The Three Levels of Schemas
The DBMS uses the mappings to translate a request by a user or program for data (expressed in
logical names and relationships) into the indexes and addresses needed to physically access the
data. The bidirectional arrows represent mappings between the schemas. Accountants are
frequently involved in developing the conceptual and the external level schemas. An
employees access to data should be limited to the subschema of data that is relevant to the
performance of his job.
The Data Dictionary

A key component of a DBMS is the data directory, which contains information about the structure
of the database. For each data element stored in the database, such as the customer number, there
is a corresponding record in the data dictionary describing it. Accountants have a very good
understanding of the data elements that exist in a business organization, where they originate,
and where they are used. Consequently, Accountants should participate in the development of the
data dictionary because they have a good understanding of the data elements in a business
organization, as well as where those elements originate and how they are used.
The DBMS usually maintains the data dictionary. In fact, this is often one of the first applications
of a newly implemented database system.
Inputs to the dictionary include:
> Records of new or deleted data elements
38
> Changes in names, descriptions, or uses of existing elements

Outputs include:
> Reports that are useful to programmers, database designers, and IS users in:
> Designing and implementing the system.
> Documenting the system.
> Creating an audit trail.
Sample reports include:
1. A list of all programs in which a data item is used
2. A list of all synonyms for the data elements in a particular file
3. A list of all data elements used by a particular user and
4. A list of all output reports in which a data element used.
These reports are useful in the design and implementation of a database system, provide
documentation of the system, and can become part of the audit trail.
Information provided for each element includes:
> A description or explanation of the element
> The records in which it is contained; and Its source
> The length and type of the field in which it is stored
> The programs in which it is used
> The outputs in which it is contained
> The authorized users of the element
> Other names for the element
Example of a Data Dictionary
Data Records Programs Outputs in Other
Element in which Field Field in which which Authorized Data
Name Description contained Source Length Type used contained users Names
Customer Unique ID of A/R Record, Customer Numeric A/R A/R aging
Number each Customer Name list 10 update, report, No
customer Record, Sales customer customer Restrictions None
Record file update, status report,
sales credit report
update
Credit Maximum Customer Credit Customer Customer R. David
Limit credit that Record, A/R Application 8 Numeric file update, status report, W. Feven CR_Limit
can be Record A/R A/R aging H. Heaton
extended to update, report, credit
customer credit Limit
analysis
DBMS Languages
Every DBMS must provide a means of performing the three basic functions of:
> Creating a database,
> Changing a database, and
> Querying a database
The set of commands used to perform these functions are referred to as the data definition, data
manipulation, and data query languages respectively.
Creating a Database
The set of commands used to create the database is known as data definition language (DDL).
The DDL is used to:
> Build the data dictionary
> Initialize or create the database
39
> Describe the logical views for each individual user or programmer
> Specify any limitations or constraints on security imposed on database records or fields
Changing a database
The set of commands used to change the database is known as data manipulation language (DML).
DML is used for data maintenance, which includes such operations as:
> Updating data
> Inserting data
> Deleting portions of the database
The DML simplifies the writing of programs to accomplish these tasks by requiring references
only to the names of data items, rather than to their physical storage locations.
Querying a database
The set of commands used to query the database is known as data query language (DQL). DQL is
used to interrogate the database, including:
> Retrieving records
> Sorting records
> Ordering records
> Presenting subsets of the database
The DQL usually contains easy-to-use, powerful commands that enable users to satisfy their own
information needs. The DML is used to change the contents of the database, whereas the DQL
merely retrieves, sorts, orders, and presents subsets of the database in response to user queries.
Most DQLs contain fairly powerful, but easy to use, set of commands that enables users to satisfy
many of their own information needs, without the programmer's assistance.
Report Writer
Many DBMSs also include a report writer, which is a language that simplifies report creation.
Typically, users need only specify which data elements they want printed and how the report
should be formatted.
The report writer then:
> Searches the database,
> Extracts the specified data items, and
> Prints them out according to the user specified format
All users generally have access to both the DQL and the Report Writer. Access to the DDL and
DML, however, should be restricted to those employees with administrative and programming
responsibilities. This helps the number of people who have the capability to make changes to the
database.
3.2) Relational Databases

Relational Databases underlie most modern integrated AISs. Relational Databases are the most
popular type of database used for transaction processing. Relational databases are more flexible.
Users can define relationships when the database is created or at later points in time. A DBMS is
characterized by the type of logical data model on which it is based. A data model is an abstract
representation of the contents of the database. The majority of new DBMSs are called relational
databases because they use the relational data model developed by Dr
40
E.F.C odd in 1970. The relational data model represents everything in the database as being stored
in the form of tables. Technically, these tables are called relations (hence relational data model),
but we will use the two words interchangeably. The data model only describes how the data appear
in the conceptual and external level schemas. The data are not actually stored in tables but rather
in the manner described in the internal level schema.
Each row in a relation is called a tuple, contains data about specific occurrence of the type of
entity represented by that table. For example, each row in the inventory table below contains all
the pertinent data about a particular inventory item in the organization. Each column in a table
contains information about one specific attribute about an entity.
Inventory Table
Item Number Description Quantity List price
2014 19" Monitor 32 Br 1,890
2015 21" Monitor 9 Br 2,890
3054 Color Printer 25 Br 3,900
Inventory Table (Relation): Item No. is the Primary Key

Customers Table
Customer # Name Street City State Zip Credit Account
Code Limit Balance
11255 G. Hay 299 Main Street AA AZ 85281 4,000 875
11266 J. Jak HG Street AA AZ 85281 6,000 3,955
Customer Table (Relation): Customer Number is the Primary Key
Sales Table
Invoice No. Date Sales Person ID. Customer # Amount
10001 08-Sep-07 SP101 11255 $8,500
10002 08-Sep-07 SP122 15266 $9,200
10003 08-Sep-07 SP133 13553 $800
10004 08-Sep-07 SP101 13908 $825
Sales Table (Relation): Invoice Number is the Primary Key
Sales-Inventory Line Items Table

Invoice-Item Number Quantity Actual Unit Price
10001-3054 1 399
10002-2015 1 799
10003-2014 1 949
Sales-Inventory Line Items Table (Combination of Invoice Number and Item Number forms
Primary Key)
Types of Attributes (Keys)

Tables in a relational database have three types of attributes:
41
> A Primary Key- is the attribute or combination of attributes that uniquely identifies a specific
row in a table. For example, the primary key for the inventory table previously is item number.
Often, the primary key is a single attribute. In some tables however, two or more attributes
jointly form the primary key. For example, in the sales inventory line items table, the primary
keys are invoice number and item number.
Inventory Table
Primary Key Item Number Description Quantity List price
2014 19" Monitor 32 Br 1,890
2015 21" Monitor 9 Br 2,890
Sales-Inventory Line Items Table

Invoice-Item Number Quantity Actual Unit Price
10001-3054 1 399
10002-2015 1 799
10003-2014 1 949
In some tables, two or more attributes may be joined to form the primary key.
> A Foreign Key- is an attribute appearing in one table that is a primary key in another table.
Foreign keys are used to link tables. Foreign keys enable database records to reference one or
more records in other files. For example, the attributes customer number and salesperson
number are foreign keys in the sales table; both are used to link the data about a particular sales
transaction with information about the sales person and the customer who participated in that
event.
Customers Table
Customer Name Street City State Zip Credit Account
No. Code Limit Balance
11255 G. Hay 299 Main Street AA AZ 85281 4,000 875
11266 J. Jak HG Street AA AZ 85281 6,000 3,955
Foreign Keys are used to link tables together
Sales Table
Invoice No. Date Sales Person ID. Customer # Amount
10001 08-Sep-07 SP101 11255 $8,500
10002 08-Sep-07 SP122 15266 $9,200
10003 08-Sep-07 SP133 11255 $800
10004 08-Sep-07 SP101 13908 $825
> Other Non-Key Attributes- in each table store important information about that entity.
For example, in the inventory table, quantity on hand, description and list price are non-key
attributes.
42
Inventory Table
Item Number Description Quantity List price
2014 19" Monitor 32 Br 1,890
2015 21" Monitor 9 Br 2,890
Alternatives for Storing Data and Its Problems

One possible alternate approach would be to store all data in one uniform table. For example,
instead of separate tables for sales and inventory, we could store all data in one table and have a
separate line for each sales x inventory combination. Using the suggested approach, a customer
buying three inventory types in a single invoice would need three rows in the table.
Customer No. Name Invoice Item No. State Permanent Credit Account
No. Phone No. Limit Balance
11267 H.D 10008 2014 AZ 333-4521 7,000 4,500
11267 H.D 10008 2015 AZ 333-4521 7,000 4,500
11267 H.D 10008 3054 AZ 333-4521 7,000 4,500
11,255 K.D 10009 2014 NJ 355-2135 8,000 6,300
11,255 K.D 10009 3054 NJ 355-2135 8,000 5,500
In this simplified approach, a number of problems arise.
Problems associated with storing all Data in One table

One problem with trying to store all the data in one table is that it creates a great deal of
redundancy. Such redundancy will make file maintenance unnecessarily time consuming and error
prone. Three specific types of problems can occur.
> The first is called update anomaly because updates or changes to data values are not correctly
recorded. For example, changing a customer's address requires searching the entire table and
changing every occurrence of that customer's address. Overlooking even one row would create
inconsistency in the database and multiple rows with different addresses exist for the same
customer. It costs in wrong mailing and error analysis of sales etc.
Customer No. Name Invoice Item No. State Permanent Credit Account
No. Phone No. Limit Balance
11267 H.D 10008 2014 AZ 333-4521 7,000 4,500
11267 H.D 10008 2015 AZ 333-4521 7,000 4,500
11267 H.D 10008 3054 AZ 333-4521 7,000 4,500
11,255 K.D 10009 2014 NJ 355-2135 8,000 6,300
11,255 K.D 10009 3054 NJ 355-2135 8,000 5,500
If customer H.D changes his phone number, you need to make the change in three places. If you
fail to change it in all three places or change it incorrectly in one place, then the records for that
customer will be inconsistent. This problem is referred to as an update anomaly.
> The second one is insert anomaly, because there is no way to store information about
prospective customers until they actually make the purchase. Until then, the sales invoice
43
number column would be blank. But, the invoice number is part of the primary key and it
cannot be blank.
> The third one is delete anomaly, because it involves unintended results that arise when deleting
a row in that table. If a customer has made only one purchase, consisting of a single item,
deleting that row from the table would result in the loss of all information about that customer.
The Solution: A set of tables

The problem associated with trying to store all the data in one table can be avoided by creating a
set of tables in a relational database - one table for each entity of interest. Each entity is stored in
a separate table, and separate tables or foreign keys can be used to link the entities together. This
is because:
> Redundancy is greatly reduced- non-key attributes are stored only once. This avoids update
anomaly problems. If some attributes are repeated, these are foreign keys and referential
integrity rule will ensure update anomaly problems.
> Adding new data to the system is easy- this avoids the insert anomaly
> Improves the deletion of information- deletion of one row will not result in entire loss of
information about a specific entity. This will rectify the problem of delete anomaly.
Basic Requirements of the Relational Data Model

The relational data model imposes several requirements on the structure of tables. These
requirements are used to develop a well-structured (normalized) database. The requirements
include:
1. Every column in a row must be single valued- there shall be one and only one value in
each cell. Thus, each table is a flat table. This requirement is the reason why there is a table
called sales inventory line item. Each sales transaction may involve more than one item
and a single item may be sold to different customers with different invoice numbers.
2. Primary keys can't be null- the primary key is the attribute or a combination of attributes
that uniquely identifies a specific row in a table. For this to be true, the primary key for any
row can't be null or blank, for then there would never be a way to uniquely identify that
row and retrieve data stored there. A non-null value for primary key indicates that a specific
object exists and can be identified by reference to its primary key value. This constraint is
referred to as the entity integrity rule; because it ensures that every row in every relation
must represent data about some specific object in the real world. In general, there should
no duplicate primary keys and no null primary keys.
3. Foreign keys, if null, must have values that correspond to the value of the primary
key in another relation- foreign keys are used to link rows in one table to rows in another
table. This is only possible if the values correspond to their values in the row of the original
table. This constraint is referred to as the referential integrity rule because it ensures the
consistency of the database. But foreign keys can contain null values. For example, some
customers may pay cash to the seller and the want not to be identified. Hence, the customer
number field in the sales table would be blank.
4. All non-key attributes in a table should describe a characteristic about the job
identified by the primary key- most tables contain other attributes in addition to the
primary and foreign keys. These are other important facts about the entity under
consideration.
44
These four constraints produce a well structured (normalized) database in which data are consistent
and redundancy is minimized and controlled. In a normalized database, attributes appear multiple
times only when they function as foreign keys. The referential integrity rule ensures there will be
no update anomaly problem with foreign keys.
An important feature about relational database is that data about various things of interest
(entities) are stored in separate tables. This will have the following benefits:
> Makes it easier to add new data to the system
You add a new student by adding a row to the student table.
You add a new course by adding a row to the course table.
Means you can add a student even if he hasnt signed up for any courses.
And you can add a class even if no students are yet enrolled in it.
> Makes it easy to avoid the insert anomaly
> Space is also used more efficiently than in the other schemes. There should be no blank rows
or attributes.
Approaches to Database Design

There are two basic approaches to design a well structured relational database: Normalization
and Semantic Data Modeling
Normalization
It starts with the assumption that everything is initially stored in one large table. A set of rules is
then followed to decompose that initial table into a set of normalized tables. The objective is to
produce a set of tables what are called Third Normal Form (3NF), because such tables are free
of the types of update, insert and delete anomalies (problems described earlier).
Semantic Data Modeling (Conceptual Data Modeling)

An alternative way to design well structured relational databases involves Semantic Data
Modeling. Under this approach, the database designer uses knowledge about how business
processes typically work and about the information needs associated with transaction processing
to first draw a graphical picture of what should be included in the database. The resulting figure
can then be directly used to create a set of relational tables that are in 3NF. The two data modeling
tools that accountants and business systems professionals can use to design transaction processing
databases are E-R (Entity-Relationship) Diagramming and the REA Data Model.
Semantic data modeling has two significant advantages over simply following the rules of
normalization.
1. Semantic data modeling uses the designers knowledge about business processes and
practices; it therefore facilitates efficient design of transaction processing databases.
2. The resulting graphical model explicitly represents information about the organizations
business processes and policies and facilitates communication with intended users.
3.3) Database Systems and the Future of Accounting

Database systems may profoundly affect the fundamental nature of accounting. Some of these
include:
1. Database systems may lead to the abandonment of the double entry accounting
model. The basic rational for the double entry model is that the redundancy of recording
45
the amount of a transaction twice provides a check on the accuracy of data processing. But
data redundancy is the antithesis of the database concept. If the amounts associated with a
transaction are entered into a database system correctly, then it is necessary to store them
only once, not twice. Computer data processing is sufficiently accurate making checks and
double checks unnecessary.
2. Database systems also have the potential to significantly alter the nature of external
reporting. Considerable time and effort are currently being invested in defining how
companies should summarize and report accounting information for external users. A copy
of the company's financial database may be simply made available to external users in lieu
of the traditional financial statements so that they would be free to manipulate and analyze
the raw data in whatever manner they see fit.
3. The most significant effect of database systems will be in the way that accounting
information is used in decision making. The difficulty of formulating ad hoc queries in
accounting systems based on traditional files or non-relational DBMS meant that
accountants act in effect as information gatekeepers. Financial information was readily
available only in predefined formats and at specified times. Relational databases, however,
provide query languages that are powerful and easy to use. Thus, managers need not get
bogged down in procedural details about how to receive information. Instead, they can
concentrate solely on specifying what they want. As a result, financial reports can be easily
prepared to cover whatever time periods managers want to examine, not just the time
frames accountants traditionally use.
4. Relational DBMSs can also accommodate multiple views of the same underlying phenomenon. For
example, tables storing information about assets can include columns not only for historical cost,
but also for current replacement costs and market values. Thus, managers will no longer be forced
to look at data in ways predefined by accountants.
5. Relational DBMSs provide the capability of integrating financial and operational data. For
example, data about customer satisfaction, collected by surveys or interviews could be stored in the
same table used to store information about current account balances and credit limits. Managers
would thus have access to a richer set of data for making tactical and strategic decisions.
In all these ways, relational DBMSs have the potential to increase the use and value of accounting
information for making the tactical and strategic decisions involved in running an organization.
Accountants, however, must become knowledgeable about database systems so that they can
participate in designing the accounting information systems of the future. Such participation is
important for ensuring that adequate controls are included in those systems to safeguard the data
and ensure the reliability of the information provided.
3.4) Data Modeling and Database Design

A data model is a "description" of both a container for data and a methodology for storing and
retrieving data from that container. Actually, a data model is not a physical thing". Data models
are abstractions, oftentimes mathematical algorithms and concepts. You cannot really touch a data
model. But nevertheless, they are very useful. The analysis and design of data models has been the
cornerstone of the evolution of databases. As models have advanced so has database efficiency.
Design of a database is much more than simply learning the syntax of a how to use a particular
DBMS. Building accurate databases requires a great deal of careful planning and design before
46
even sitting down at the computer. The issues of data modeling will be emphasized next. The REA
accounting model and the Entity Relationship (E-R) Diagramming and how to use these tools to
build a data model of AIS will be seen in the next discussions. Finally, how to implement the
resulting data model in a relational database will be considered.
Database Design Process

Steps in database design include the following:
1. Planning Stage- involves the initial planning to determine the need for and feasibility of
developing the new system. This includes preliminary judgments about the proposals
technological and economic feasibility.
2. Requirements Analysis Stage- involves identifying user information needs, defining the scope of
the proposed new system, and using information about the expected number of users and
transaction volumes to make preliminary decisions about hardware and software requirements.
3. Design Stage- involves developing the different schemas for the new system, at the conceptual,
external, and internal levels. The requirements analysis and design stages are the stages of data
modeling.
4. Coding- involves translating the internal level schema into the actual database structures that will
be implemented in the new system. This is also the stage when new applications are developed.
5. Implementation- this stage includes all activities associated with transferring data from existing
systems to the new database AIS, testing the new system, and training employees how to use it.
6. Operation and Maintenance- involves using and maintaining the system including carefully
monitoring system performance and user satisfaction to determine the need for making system
enhancements and modifications. Eventually, changes in business strategies and practices or
significant new developments in information technology initiate investigation into the feasibility
of developing a new system and the entire process starts again.
Plannin
g
Requirements Analysis
Data Modeling
Occurs Here
Design
Codin
g
Implementation
Operation and Maintenance

Figure 3.5: Data Modeling in the Database Design Process
Accountants can and should participate in all stages of the database design process, although the
level of their participation in each stage is likely to vary.
47
> In the planning stage, accountants both provide some of the information used to evaluate the
feasibility of the proposed project and participate in making that decision.
> In the requirements analysis and design stages, accountants participate in identifying user
information needs, developing the logical schemas, designing the data dictionary, and
specifying controls.
> In coding stage accountants with good AIS skills may participate in coding.
> In implementation stage, accountants can also help test the accuracy of the new database and
the application programs that will use that data.
> Finally, in operation and maintenance stage, accountants use the database system to process
transactions, and sometimes they even help manage it.
Accountants may provide the greatest value to their organizations by taking responsibility for data
modeling. Data modeling is the process of defining a database so that it faithfully represents all
aspects of the organization, including its transactions with the external environment.
Data modeling occurs during both the requirements analysis and design stages of the database
design. Two important tools that accountants can use in data modeling are: Entity
Relationships Diagramming and the REA Data Model.
Entity Relationship Diagrams
An Entity-Relationship (E-R) Diagram is a graphical technique for portraying a database schema.
It graphically depicts a databases contents. ER Diagram shows entities being modeled and the
relationships among them. In an ER Diagram, entities appear as rectangles and relationships
between entities are represented as diamonds. An entity is anything about which the organization
wants to collect and store information. In a relational database, separate tables would be created to
store information about each distinct entity. In an object-oriented database, separate classes
would be created for each distinct entity.
Inventory Sale
s
Relationships Entity
Sometimes the attributes associated with each entity are depicted as named ovals connected to
each rectangle.
E-R Diagram can be used to represent the contents of any kind of databases. E-R Diagram is used
to design databases to support an organizations business activities. E-R diagrams depict the
contents of a database and graphically model those business processes. Thus, the ER diagrams can
be used not only to design databases but also to document and understand existing databases and
to reengineer business processes. E-R diagrams can include many different kinds of entities and
relationships. An important step in database design is deciding which entities need to be modeled.
The REA data model is useful for making that decision.
The REA Data Model

Specifically used for AIS database design, the REA data model is conceptual modeling tool that focuses on
the business semantics underlying an organization's value chain activities. The REA data model
48
provides guidance for database design by identifying what entities should be included in the AIS database
and how to structure relationships among the entities in that database.
REA data models are usually depicted in the form of E-R Diagrams. Therefore, we refer to E-R diagrams
developed with the REA model as REA Diagrams
Types of Entities: Three Basic Types of Entities

The REA model classifies entities into three distinct categories: the resources that the organization acquires
to use, the events (business activities) in which the organization engages, and the agents participating in the
events. Recently, some researchers proposed a fourth type of entity-locations such as stores, warehouses,
etc. But they may be considered as resources, or attributes of the event entity. The REA data model is so
named because it classifies entities into three distinct categories
Resources (R) that the organization acquires and uses they are things that have economic value
to the organization. These include cash, inventories, equipment and machinery, supplies,
warehouses, factories, and land.
Events (E) in which the organization engages - are the various business activities about which
management wants to collect information for planning or control purposes. The REA data model
helps people design databases that support the management of an organization's value chain
activities. Therefore, most of the events in an REA data model fall into one of the two categories:
economic exchanges or commitments.
Economic exchanges- are the value chain activities that directly affect the quantity of
resources. For example, the sales event decreases the quantity of inventory and the cash
receipts event increases the amount of cash.
Commitments- represent promises to engage in future economic exchanges. For example,
customer orders are commitments that lead to future sales. Often such commitments are
necessary precursors to the subsequent economic exchanges. Moreover, management
needs to track commitments for planning purposes. For example, manufacturing firms
often use information from customer orders to plan production.
Agents (A) are people and organizations that participate in the events and about whom
information is desired for planning, control, and evaluation purposes. Examples include
employees, customers, vendors etc.
Salesman
Inventory Sale
s Customers
Customers
Cas Cash Receipts
h
Cashier
Identify the resources, events, and agents in this E-R Diagram
In general, the REA is a tool for designing AIS databases. An AIS captures data about an organizations
resources, events and agents (REA). Resources are an organizations assets. Events are identifiable
activities associated with a business processes. Agents are the people associated with business activities
49
Basic REA Template

The REA data model prescribes a basic pattern for how the three types of entities should relate to
one another.
Rule 1: Each event is linked to at least one resource that it affects
Events such as the sale of merchandise that change the quantity of a resource are linked to that
resource in what is called a stockflow relationship. Other events such as taking a customer order
that represent future commitments are linked to resources in what are called reserve
relationships.
Every event entity must be linked to at least one resource entity. Events must be linked to at least
one resource that they affect. Some events affect the quantity of a resource:
If they increase the quantity of a resource, they are called a get event.
If they decrease the quantity of a resource they are called a give event.
EXAMPLE: If you purchase inventory for cash:
The get event is that you receive inventory
The give event is that you pay cash
Relationships that affect the quantity of a resource are sometimes referred to as stockflow
relationships. Not every event directly alters the quantity of a resource. If a customer orders goods
but has not paid and has not received goods, this activity is called a commitment event.
Organizations track the effects of commitments to provide better service and for planning purposes
Inventory Sales
Cash Cash Receipts
Rule 2: Each event is linked to at least one other event

Each economic exchange event is linked in a give to get duality relationship with another economic
exchange event. These economic duality relationships reflect the basic business principle that organizations
typically engage in activities that use up resources only in hopes of acquiring some other resource in
exchange. Each accounting cycle can be described in terms of give-to-get economic duality relationships.
In revenue cycle, which interacts with customers, for example, the sales event, which requires giving up
(decreasing) inventory is related to the cash receipts event which requires getting (increasing) the amount
of cash. Not every relationship between two events represents a give-to-get economic duality.
Commitment events are linked to other events to reflect sequential cause-effect relationships. Example:
Customer order is a commitment event that leads to deliver of inventory (give event) and cash receipt (get
event).
Inventory Sales
Cash Cash Receipts
Rule 3: Each event is linked to at least two agents
50
For accountability, organizations need to be able to track actions of employees. Also need to
monitor the status of commitments and exchanges with outside parties. Thus, each event is linked
to at least two participating agents: internal agent and external agent.
For events that involve transactions with external parties:
The internal agent is the employee responsible for the affected resource
The external agent is the outside party to the transaction
For internal events, such as transferring raw materials to the production floor:
The internal agent is the employee who responsible for the custody of the resource
The external agent is the one who receives it.
Salesman
Inventory Sales
Customers
Customers
Cash Cash Receipts
Cashier
Figure 3.6: Basic REA Template
Resource A GET
Inflow Participant Internal Agent
Resource A
Participant External Agent
Economic
Duality
Participant External Agent
GIVE
Resource B Outflow Participant Internal Agent
Resource B
Developing REA Diagram for One Transaction Cycle

In REA diagram, entities are drawn as rectangles and the economic duality relationship between
them as a diamond. In drawing REA model, the paper is divided into three columns- one for each
type of entity:
The left column is used for resources
The center column for events, and
51
The right column for agents.

Readability is further enhanced if the events entities are drawn from top to bottom corresponding
to the sequence in which they occur.
To design REA Diagram for entire AIS, one would develop a model for each transaction cycle and
then integrate the separate diagrams into an enterprise-wide model. Developing REA Diagram for
a specific transaction cycle consists of the following three steps:
Step-1: Identify the events about which management wants to collect information
Step-2: Identify the resources affected by each economic exchange event and the agents who
participate in those events.
Step-3: Determine the cardinalities of each relationship
Step-1: Identify the Events

Identify the events about which management wants to collect information. Events can be Economic
Exchange Events or Commitment Events. Identify the pair of economic exchange events that
represent the basic give to get economic duality relationship in that cycle. Then, analyze each
economic exchange event to determine whether it should be decomposed into a combination of
one or more commitment events and an economic exchange event. If necessary, replace the
original economic exchange event with the resulting set of commitment and economic exchange
events.
The basic REA template consists of a pair of events, one that increases some resource and one that
decreases some resource. That is, every REA model must include the two events that represent the
basic give-to-get economic exchange performed in that transaction cycle. The give event reduces
one of the organizations resources. The get event increases a resource. There are also other events
(commitment events) that management is interested in planning, controlling, and monitoring.
These should be included in the model. Example: REA Diagram for Revenue Cycle. Revenue
Cycle includes the following typical activities:
Take customer order - does not involve giving or taking a resource. It is a commitment
event
Fill customer order - involves a reduction in the companys inventory. It is a give event
Bill customer - involves the exchange of information with an external party but does not
affect resources
Collect payment - results in an increase in cash. It is a get event
In Revenue Cycle, the give-to-get is:
> Fill customer order (often referred to as sale); and
> Collect cash (often referred to as cash receipt)
This step is analyzing each economic exchange event to determine whether it can be decomposed
into a combination of one or more commitment and exchange events. It is important for
management to get up-to-date information about various orders to reorder various inventory items.
It is also important to know which orders have been shipped and when. Then, the single economic
exchange event labeled sales may be replaced with a combination of a commitment event which
is labeled customer orders and the economic exchange event that was labeled sales. The cash
receipts economic exchange event will not be decomposed because whether payment is received
immediately or later by mail, what shall be tracked is actual receipts from customers.
52
Billing as an event is not modeled because it is neither an economic exchange nor a commitment.
Printing an invoice and mailing it to the customer doesn't increase or decrease the amount of any
resource. It is simply an information processing event that merely retrieves information from the
database about previous customer orders and sales events. Organizations build databases to collect,
process, and store information about their value chain activities. Printing documents and reports
or querying the database are just different ways of retrieving information about those activities for
use in making decisions. Such information processing activities do not change the contents of the
database and are not modeled as events in an REA diagram.
Take Customer Order
> Taking an order requires that we set resources aside
> That information should be included in our model
Bill Customer
> Printing and mailing invoices does not directly affect an economic resource
> It does not represent a commitment on the part of the company to a future exchange
> It is an information retrieval event and should not alter the contents of the database
> Does not need to be included in the model
Customer Order
Sales
Cash Receipts
Step 2: Identify Resources and Agents

Once the events of interest have been specified, the resources that are affected by those events
need to be identified. Involves determining:
> The resource(s) reduced by the give event.
> The resource(s) increased by the get event.
> The resources that are affected by a commitment event
For example, the sales event is translated to giving inventory to customers and the cash receipts
event is translated to receiving cash from customers. Hence, the inventory and cash entities are
added in the resource column and the stockflow relationship is drawn between those entities and
the events that affected them.
Accounts Receivables
While accounts receivable is an asset in financial reporting, it is not represented as a resource in
an REA model. It represents the difference between total sales to a customer and total cash
collections from the customer. The information to calculate accounts receivable balance is already
there because the sales and cash receipt information is captured. That is, accounts receivable
simply represents sales for which customer payments have not yet been received. Consequently,
if data about both sales and cash collections are already stored in the database, all the information
needed to calculate A/R can be derived from the information stored about those two events. How
to extract this information will be discussed later.
53
The following questions must be answered to identify the events and resources affected by the
events to incorporate them as an entity in REA Diagram.
> What is the give event?
> What resource is reduced by the give event?
> What is the get event?
> What resource is increased by the get event?
> Is there a commitment event?
> What resource is affected by the commitment event?
The agents who participate in each event should also be identified. After specifying the
resources affected by each event, it is necessary to identify the agents who participate in those
events. There will always be at least one internal agent (an employee) and in most cases an external
agent (the customer or vendor) who participate in each event. For example, customers and
salespersons participate in the sale event and customers and cashiers participate in the cash
collection event. Hence, in the REA diagram, these three agent entities shall be added:
salespersons, customers, and cashiers. Relationships shall be included to indicate which agent
participated in which events. Agents can be identified through the following questions for revenue
cycle:
> What agents are involved in the sale?
> What agents are involved in the receipt of cash?
> What agents are involved in taking the order?
It is important to understand that the agents in the REA data model represent functions, not specific
people. For example, the salesperson and the cashier are shown as separate entities but the same
person may take both roles. The REA data model requires that each event be linked to at least one
resource and at least two agents. This information needs to be supplemented by interviews with
management to identify other possible relationships of interest. For example, if the organization
assigns customers to specific salespeople to provide customized service, then a direct relationship
between the two agent entities (salesperson and customer) would be added to the diagram.
Step 3: Determine Cardinalities of Relationships

The final step in REA Diagram for one transaction cycle is to add information about the cardinality
relationship between various entities. Cardinality describes the nature of the relationship between
two entities. Cardinalities indicate how many instances of one entity can be linked to one
specific instance of another entity. That is, the cardinality of a relationship describes the number
of occurrences of one entity that may be associated with a single occurrence of the other entity.
For example, cardinalities indicate how many sales transactions can be linked to each individual
customer and, conversely, how many customers can be linked to each individual sales transaction.
In a relational database, each entity is a table and each instance is a row in that table. Therefore,
in relational databases, cardinalities indicate how many rows in one table can be linked to each
row in another table.
Cardinalities are represented as pairs of numbers next to each entity minimum and maximum
cardinality. There is no universal standard for diagramming cardinalities.
> The symbol for zero cardinality is a zero (0)
54
> The symbol for one cardinality is Arabic number one (1)
> The symbol for many cardinality is an English Alphabet N
Minimum Cardinality
The first number is the minimum cardinality in each cardinality pair. It indicates whether a
row in this table must be linked to at least one row in the table on the opposite side of that
relationship. Minimum cardinalities can be either 0 or 1.
> A minimum cardinality of 0 (Zero) means that a new row can be added to that table without
being linked to any specific rows in the table on the other side of the relationship.
> A minimum cardinality of 1 means that each row in that table must be linked to at least one
row in the other table.
Example 1: Sales and Customers Relationship
Sale (1, 1) Made to (0, N) Customers

s
Minimum Cardinality
> The minimum cardinality of zero in the (0, N) cardinality pair to the left of the customer entity in the
customer-sales relationship indicates that a new customer may be added to the database without
being linked to any sales events.
> The minimum cardinality of 1 in the (1, 1) cardinality pair to the right of the sales entity in the
customer-sales relationship indicates that a new sales transaction CAN ONLY be added if it is
linked to a customer.
Maximum Cardinality
The second number in each cardinality pair is the maximum cardinality. It indicates whether one row in
that table can be linked to more than one row in the other table. Maximum cardinalities can be either 1 or
N.
> A maximum cardinality of N means that each row in that table MAY be linked to more than one row
in the other table.
> A maximum cardinality of 1 means that each row in that table can be linked to at most only one row
in another table.
Example 2: Sales and Customers Relationship

(1, 1) (0, N)
Sale Made to Customers
s
> The maximum cardinality of N in the (0, N) cardinality pair to the left of the customer entity in the
customer-sales relationship indicates that a given customer MAY be linked to many sales events.
> The maximum cardinality of 1 in the (1, 1) cardinality pair to the right of the sales entity in the
customer-sales relationship indicates that a given sales transaction can only be linked to one
customer.
Example 3: Sales and Cash Receipts Relationship
Sales
(0, N)
Leads to
(1, N)
Cash Receipts
55
> The zero minimum for the sales event indicates that credit sales are made
> The N maximum for the sales event means that customers may make installment
payments
> The one minimum for the cash receipts event indicates that cash is not received prior to
delivering the merchandise
> The N maximum for the cash receipts event means that customers may pay for several
sales with one check
Types of Relationships
Cardinalities are not arbitrarily chosen by the database designer. They reflect facts about the
organization being modeled and its business practices obtained during the requirements analysis
stage of the database design process.
Three basic types of relationships between entities are possible depending on the maximum
cardinality associated with each entity. Cardinality of relationships are determined only taking
into account the maximum cardinality on each side of a relationship.
1. A one-to-one (1:1) relationship exists when the maximum cardinality for each entity in that
relationship is one. Example:
Customer Order
(1, 1)
2. A one-to-many (1:N) relationship exists when the maximum cardinality of one entity in that
relationship is 1 and the maximum cardinality of the other entity in that relationship is N
(0, N)
Customers
> The maximum number of customers that can be involved in each sale is one.
> The maximum number of sales that can be associated with any individual customer is
many.
> This is a one-to-many (1:N) relationship
3. Many-to-many (M:N) relationship exists when a maximum cardinality for both entities in
the relationship is N.
(0, N)
Sales
56
> The maximum number of inventory items that can be sold in one sale is many.
> The maximum number of sales that can occur for a particular inventory item is many.
> This is a many-to-many (M:N) relationship
Do not confuse the notation used for minimum and maximum cardinalities (a pair of numbers separated by
a comma) with the notation used to describe the cardinality of a relationship between two entities (a pair of
numbers separated by a colon).
It is not a one size fits all world for relationships and cardinalities. The cardinalities between two entities
can vary based on how the particular company does business. In other words, the choice of cardinalities is
not arbitrary. It reflects facts about the organization that are obtained during the requirements definition
stage of the database design process. For example: see the following carnalities of relationship between
Sales and Cash Receipts:
1. Retail Stores (Cash Sale Only)

Sales > Customers pay for each sale with
(1, 1) a maximum of one payment
> Each cash receipt from a customer
Leads to relates to only one sale.
> The relationship between sales
(0, 1) and cash receipts is 1:1.
Cash Receipts
2. Large Businesses (Installment Sale is made)
Sales > Customers pay for each sale

with a maximum of many
(1, 1) payments (installments).
> Each cash receipt from a
Leads to
customer relates to one (and
(0, N) only one) sale.
> The relationship between sales
Cash Receipts and cash receipts is 1:N.
3. Aggregate Cash Payment for Many Sales
Sales > Customers make only one payment

for a sale.
(1, N)
> Each cash receipt from a
customer can relate to multiple
Leads to
sales (e.g., they pay for all sales
that month in one payment).
(0, 1) > The relationship between sales and
Cash Receipts cash receipts is 1:N.
57
4. Many-to-many Relationship between cash receipts and sales
Sales > Customers may make

multiple payments for a
(1, N) particular sale.
> A cash receipt from a customer
Leads to may relate to more than one
sale.
(0, N) > The relationship between sales
Cash Receipts and cash receipts is M:N.
Complete REA Diagram for Revenue Cycle
Call on Customer Salesperson

(0, 1)
Leads to
(0, N) (0,N)
(0, 1)
(1,N) (1,1) (0,N) Customer
Customer Orders
(0,1) (1,1)
Leads to
(0,N)
Inventory (1,1) (0,N) Salesperson

Sales Sales
Customer
Receipts
(1,1) (0,N)
Cash Cash Receipts Cashier
Rules for Specifying Cardinalities

The database designer doesn't arbitrarily choose cardinalities. Instead, cardinalities reflect facts
about the organization being modeled and its business practices. This information is obtained
during the requirements definition stage of the database design process. Certain general principles
can provide a starting point for developing an REA data model for any organization.
1. Cardinality Rules for Agent-Event Relationship
58
Almost always, the minimum and maximum cardinalities associated with the Event Entity in
every agent-event relationship are both one (1). That is, for each event that occurs, the cardinality
between event and agent is typically (1,1)
> The minimum cardinality associated with the event is 1 because there must be some agent
who participates in that event.
> The maximum cardinality is 1 because the organization wants to be able to hold some
specific agent responsible for that event.
For Example: When a sale occurs:
> There is usually one and only one customer
> There is usually one and only one salesperson. This practice makes it more feasible for the
organization to establish employee accountability for the event.
There is also a general principle concerning cardinalities associated with each Agent Entity in
the agent-event relationship. The cardinalities associated with each agent entity in the agent- event
relationship all have Zero minimums and N maximums. That is, for each agent the cardinality
between agent and event is typically (0,N).
The maximum cardinality associated with internal agent entities is almost always N, because
organizations expect their employees will participate in numerous events. It is also usually N for
external agents, because organizations often engage in repeat transactions with the same suppliers
and customers.
There are two reasons why the minimum cardinality associated with agent entities in the agent-
event relationship is usually zero:
> Organizations want to be able to add information about potential customers and suppliers
even though those agents may not have participated yet in the business transactions
> Event entities are analogous to transaction files, where as agent entities are analogous to
master files. At the end of the fiscal year, the contents of events tables are archived and the
new fiscal year begins with no rows in various event tables. In contrast, information about
agents is permanent in nature and is carried over from one fiscal period to the next.
Therefore, at the beginning of a new fiscal year customers may not be linked to any current
sales.
Example:
For a particular salesperson
> There is typically a minimum of zero sales (allows for inclusion of a new salesperson who
has not yet made any sales)
> A salesperson can have a maximum of many sales
For a particular customer:
> There is typically a minimum of zero sales (to allow for the inclusion of prospective
customers who havent bought anything yet) and a maximum of many sales
2. Cardinality Rules for Resource-Event Relationships

The minimum cardinalities associated with Each Resource in resource-event relationship are
Zero. In the cardinality between event and resource, the maximum is typically many (N). This is
by the same reasoning as the case for cardinalities associated with agents in agent-event
relationship. Reasons:
Minimum cardinality
59
> A company can have an inventory item for which there has never been a sale
> When the companys cash account is new, there has never been a cash receipt deposited
in it
Maximum cardinality
> Most inventory items can be sold many times. (An exception might occur if each
inventory item is one unique item, such as a piece of real estate.)
> The companys cash account can have many cash receipts
One exception to this rule is that the maximum cardinality associated with the inventory resource
is sometimes One (1). This is when organizations track specific physical inventory items such as
original artwork, vehicles, or houses that are identified by a primary key which is some type of
serial number. In such cases, a given row in inventory table could be associated with at most one
sales transaction and would have maximum cardinality of 1 instead of N.
The minimum cardinality associated with Event Entities in resource-event relationship is

usually 1, because an event cant occur without affecting at least one resource. For example, each
sale event must reduce at least one inventory in the inventory table and each Cash Receipt from a
customer must be deposited into some cash account.
The only exception to this general rule arises if an event potentially can be linked to more than one
resource entity. For example, consider a household appliance repair business. Some services may
not require parts whereas others may include labor plus parts. Thus, the sale event for such repair
business could be linked with inventory entity, or to repair service entity or both types of resources.
Consequently, the minimum cardinality for the sales event would be zero in both of those
relationships. (In rare situations, an event might be linked to one of several unique agent entities.
In such cases, the minimum cardinality associated with the event entity again will be 0 instead of
the normal 1.)
There is no general principle concerning the maximum cardinality associated with event
entities in resource-event relationship. Instead, the maximum cardinality depends on the nature of
the resources affected by that event and by the organizations policies. For example, customers may
buy and are encouraged to buy as many products as possible of a company. Hence, customer order
and sales events can be linked to many rows in inventory table.
3. Cardinality Rules for Event-Event Relationships

Almost any kind of cardinality pair is possible for each event entity in event-event relationships.
The organization's business practices and policies must be understood to decide which possibility
is correct. For example, collections from customers may be at once (1:1) or in installments (1: N).
The only general modeling principle that applies to event-event relationships is that for two
temporally ordered events, the minimum cardinality for the first event is 0, because at the time it
occurs, the other event has not yet happened. Often, but not always, the minimum cardinality for
the event that occurs second is 1, indicating that the first event had already occurred.
When events occur in a sequence, the minimum cardinality between the first event and the second
event is always zero, because there is a span of time (although possibly quite short) when the first
event has occurred but there are zero occurrences of the second event. Examples:
60
> When an order is first taken, there have been no deliveries of goods (sale event) to the
customer.
> When goods are delivered to the customer, there is a span of time, however brief, in
which there is no cash receipt from the customer.
The minimum cardinality between the second event and the first event is typically one, because
the second event cant occur without the first event having occurred. An exception could occur if
the first event is not required for the second event to occur. Example: If a sale can be made without
first taking an order, then the minimum cardinality between sale and take order could be zero.
The maximums in the cardinalities between events can be either one or many, and these maximums
vary based on business practices. We have seen this when we looked at the four different
possibilities for the relationships between sales and cash receipts previously.
Uniqueness of REA Diagrams
Each organization will have its own unique REA diagram. Business practices differ across
companies, so cardinalities and relationships will differ. A given organization can change business
practices, leading to a change in its REA diagram:
> A change in practice could cause a change in cardinalities.
> Could even lead to the inclusion of different entities on the diagram
Data modeling can be complex and repetitive. Data modelers must discuss their drafts of models
with intended users to ensure that:
> Key dimensions are not omitted or misunderstood.
> Terminology is consistent
Implementing REA Diagram into a Relational Database

Once the REA diagram has been developed, it can be used to design a well structured relational
database. Implementing an REA diagram in a relational database is a three-step process:
1. Create a table for each distinct entity and for each many to many relationships
2. Assign attributes to appropriate tables
3. Use foreign keys to implement one to one and one to many relationships
Step 1: Create Tables for Each Entity and M:N Relationships

A properly designed relational database has a table for each distinct entity and for each many to
many relationships in an REA diagram. Some of the distinct entities include: Cash, Inventory,
Customer Orders, Sales, Cash Receipts, Employees, and Customers assuming that the
company does make a call to customer to buy inventory. The expected many-to-many relationships
include Customer Order-Inventory, Sales-Inventory, and Sales-Cash Receipts. (10 Tables from
the following REA Diagram)
61
(0,N)
(0,1)
(1,N) (1,1) (0,N) Salesperson
Sales
(0,N)
(1,1)
(0,N)
Cashier
It is good practice to give each table the same name as the entity that it represents. Tables
representing M:N relationships, however, are often titled by hyphenating the names of the two
entities that are linked. For example, Sales-Inventory line table
Step 2: Assign Attributes to Each Table

During the data modeling process, users and management will have identified facts that they want
to collect. For example, for inventory items the attributes may include item number, description,
cost and selling price.
> Assign primary keys- every table in a relational database must have a primary key, consisting
of attributes or a combination of attributes. Companies often create numeric identifiers for
specific resources, events and agents. These numeric identifiers are good candidates for
primary keys. Usually, the primary key of a table representing an entity is a single attribute.
The primary key for M:N relationship tables, however, always consists of two attributes
that represent the primary keys of each entity linked in that relationship. For example, the
primary key of a sales-inventory table consists of both the invoice number (primary key of
the sales entity) and item number (primary key of the inventory entity). Such multiple-
attribute primary keys are called concatenated keys.
> Assign other attributes to appropriate tables- additional attributes besides the primary key
are included in each table to satisfy transaction processing requirements and management's
information needs. Some of the attributes such as the date and amount of
62
each sale are necessary for complete and accurate transaction processing and the production
of financial statements and managerial reports. Other attributes are stored because they
facilitate the effective management of an organization's resources, events and agents.
> Non-key attributes in M:N relationship tables- attributes that help keep the table flat and that
can't be stored in separate tables are listed as attributes in M:N relationship tables. For
example, quantity sold can't be an attribute in the sales table because a single invoice may
have several values. In addition, a single item may be sold in many different sales
transactions. Hence, it may not be an attribute in inventory table. Hence, as it applies to a
specific item included in a specific sales transaction, it belongs in the M:N relationship
table that links these two entities.
Price data- may be stored in both the inventory and sales-inventory tables. The inventory table
lists suggested selling price that remains constant. But the sales inventory table stores actual sales
price which varies during the year in relation to promotions.
Cumulative data- includes such information as quantity on hand (in inventory table) and account
balance (in the customer table). Theoretically, it is unnecessary to store such information
separately in the database because the system can readily compute them when necessary. Explicitly
storing cumulative totals and balances, however, may improve response time to queries.
Step 3: Use Foreign Keys to Implement 1:1 and 1:N Relationships

M:N relationships must be implemented as separate tables to have a well structured relational
database. Although 1:1 and 1:N relationships can be implemented as separate tables, it is usually
more efficient to implement them by means of foreign keys.
One to one Relationships- in a relational database, one to one relationships between entities
can be implemented by including the primary key of one entity as a foreign key in the table
representing the other entity. The choice is arbitrary. Careful analysis of the minimum cardinalities
of the relationship may suggest which approach is likely to be more efficient. For example, in the
1:1 relationship between sales and customer payments,
> the minimum cardinality for the sales event is 0 indicating the existence of credit sales
> the minimum cardinality for the cash receipt event is 1 indicating that customer payments
only occur after a sale has been made (assuming no advance collections are made)
In this case including invoice number as foreign key in cash receipts event may be more efficient
because then only that one table would have to be accessed and updated to process data about each
customer payment. When events are sequential, including the primary key of the event that occurs
first as a foreign key in the event that occurs second may improve internal control.
One to many relationships- As with 1:1 relationships, 1:N relationships also can be
implemented in relational databases with foreign keys. To do this, place the primary key of the
entity with the maximum cardinality of N as a foreign key in the entity that has maximum
cardinality of 1. For example, the primary keys of the salesperson and customer tables are included
as foreign keys in the sales table.
A potential exception to this general rule for implementing 1:N relationships may occur if the
relationship includes two sequential event entities, and the event that occurs first is also the one
63
that participates many times in that relationship. In that case, implementing the relationship as a
separate table might improve internal control.
REA Diagram for Documenting Business Processes

REA diagrams are especially useful for documenting advanced AIS built using databases, because
the cardinalities in REA diagrams provide information about the organization's business practices
and the nature of its economic exchanges.
Correctly interpreting what the cardinalities in an REA diagram mean requires understanding
exactly what the occurrence of each entity represents. This is usually easy for both agent and event
entities.
Understanding what each occurrence of resource entity represents may be difficult. Consider
inventory, for example. An individual occurrence of this entity might represent either a specific
physical object or a class of objects depending on the nature of the inventory. In such cases,
examining the attributes associated with that entity may indicate what it represents. For example,
if there is a column entitled ''quantity on hand'', each row refers to a specific kind of inventory, not
an individual object. In the case of sales-inventory relationship, such column will not exist because
items may be identified by serial number and there could only be one of each item.
Every organization will have its own unique REA diagram at least because business practices and
relationship cardinalities differ across companies. Differences in business practices also result in
differences in entities being modeled.
The cardinalities in REA diagram also provide information about business controls. For instance,
each row in the cash entity represents a specific account. One may be checking account, another
payroll account, another money market investment account etc. Cash-cash receipts relationship
being modeled as 1:N reflects a sound control practice of depositing all cash collections from
customers into the company's checking account.
Extracting Information from the AIS

A completed REA diagram also serves as a useful guide for querying an AIS database. Elements
such as journals, ledgers and information about receivables as well as payables may seem missing
in a database AIS. But they are present though stored in a different format.
Producing journals and ledgers- queries can be used to generate journals and ledgers from
a relational database built on the REA model. The information normally found in a journal is stored
in the tables used to record data about events. For example, a sales journal can be produced by
writing a query that displays the appropriate entries in the sales table for a given period. A query
can be written to display every entry in a sales table, to produce a list of all sales events, both cash
and credit sales. Traditionally, sales journals are used to record all credit sales. Therefore, the query
to produce a credit sales journal would have to include both the sales and cash receipts tables. The
logic on the query is would include restricting the output to display only those sales that are not
linked to a corresponding customer payment event that occurred on the same day as a sale.
The information traditionally contained in ledgers is often stored in a relational database in a
combination of resources and events tables. For example, accounts receivable doesn't appear as a
64
table. Instead, it is derived by calculating the total amount of sales for which customer payments
have not been received.
Situation 1: Extracting Information form AIS (Accounts Receivable)

(0, 1) (1, N)
Sale Cash Receipts
s
> Each sales transaction is paid in full by a cash collection event.
> Each customer payment may be for more than one sale.
> What is the query logic?
> Total accounts receivable is the sum of all sales for which there is no remittance number

(0, N) (1, 1)
Sale Cash Receipts
s
> Each sales transaction can be paid in installments.
> Each customer payment is for just one sale.
> (1) Sum all sales; (2) sum cash collections; then A/R = (1)-(2)

(0, 1) (1, 1)
Sale Cash Receipts
s
> Each sales transaction is paid in full by a cash collection event.
> Each customer payment is for one sale.
> Total accounts receivable is the sum of all sales for which there is no remittance number

(0, N) (1, N)
Sale Cash Receipts
s
> Each sales transaction may be paid for in installments.
> Each customer payment may be for more than one sale.
> (1) Sum all sales; (2) Sum all cash collections; Then A/R = (1)-(2)
Providing other financial statement information- an REA diagram can guide the
writing of queries to produce other information that would be included in financial statements.
Querying a single table can derive many financial statement items. For example, summing the
amount column of the sales table would yield sales for the current period.
Preparing managerial reports- a major advantage of the REA data model is that it integrates
non-financial and financial data in the AIS and makes both types of data easily accessible to
management. For example, information such as time of sale, returns and allowances etc can be
included as attributes in the sales table. New attributes such as credit rating
65
could be added easily. The REA data model can be used to build a database that allows the AIS to
change in response to management's changing information requirements. The REA data model
shows that accounting need not be limited to the traditional double entry model with its journals,
ledgers, and chart of accounts. Instead, the REA data model supports the view that accounting a
process or system of collecting and disseminating information about an organization's business
transactions. Although the mechanics of accounting may change, the need for the results
(managerial reports and financial statements) of accounting remains.
E-R Diagram for Expenditure Cycle based on REA Model
Inventory (0,N) Inventory- (1,N) (1,1) (0,N) Buyer

Purchases Participant
Purchases (Purchasing Agent)
(0,N)
(1,1)
Participant
(0,N)
Purchases-
Cash Vendor
(0,N)
Participant
(1,N) (1,1)
(0,N) (1,1) Cash (1,1) (0,N)

Cash Stockflow Participant Cashier
Disbursement
Number of Tables for REA Diagram:

Inventory, Purchases, Employees, Vendors, Cashier, Cash disbursements, Cash, Purchases-
inventory, Purchases-cash disbursements

> How are databases different than file-based legacy systems?
> Why are databases important and what is their advantage?
> What is the difference between logical and physical views of a database?
> What are the fundamental concepts of database systems such as DBMS, schemas, the data
dictionary, and DBMS languages?
> What is a relational database, and how does it organize data?
> How are tables structured to properly store data in a relational database?
> What steps are followed to design and implement a database system.
> How is the REA data model used to design an AIS database?
> How is an entity-relationship (E-R) diagram of an AIS database drawn?
> How are E-R diagrams read, and what do they reveal about the business activities and
policies of the organization being modeled?
66
AIS The System Development Process AIS
Chapter Four
The System Development Process
Chapter Outlines
> System Development and Documentation Tools and Techniques
Importance of documentation in System Development
Basic Documentation Tools
Data Flow Diagrams (DFDs)
Flowcharts
Differences between DFDs and Flowcharts
> Introduction to Systems Development and Systems Analysis
Overview of the Systems Development Life Cycle
The Key Players in System Development Process
Planning Systems Development
Feasibility Analysis
Behavioral Aspects of Change
Systems Development Life Cycle
> AIS Development Strategies
Purchase Software
Development by In-House Information Systems Department
Outsource the System
Improving and Accelerating the System Development Process: BPR, Prototyping,
CASE) Tools
Chapter Objectives
After studying the 3rd chapter, a student should be able to:
> Prepare and use data flow diagrams to understand, evaluate, and design information
systems.
> Draw flowcharts to understand, evaluate, and design information systems.
> Explain the five phases of the systems development life cycle
> Discuss the people involved in systems development and the roles they play.
> Explain the importance of systems development planning and describe planning techniques
> Discuss the various types of feasibility analysis, and calculate economic feasibility
> Explain why a system change triggers behavioral reactions, what form this resistance to
change takes, and how to avoid or minimize the resulting problems
> Discuss the key issues and steps in systems analysis.
> Discuss the conceptual systems design process and the activities in this phase.
> Discuss the physical systems design process and the activities in this phase.
> Discuss the systems implementation and conversion process and the activities in this phase.
> Discuss the systems operation and maintenance process and the activities in this phase.
> Describe how organizations purchase application software, vendor services, and hardware.
> Explain how information system departments develop custom software.
> Explain how end-users develop, use, and control computer-based information systems.
> Explain why organizations outsource their information systems, and evaluate the benefits
and risks of this strategy.
67
> Explain the principles and challenges of business process reengineering.

> Describe how prototypes are used to develop an AIS, and discuss the advantages and
disadvantages of doing so.
> Explain what computer-aided software engineering is and how it is used in systems
development.
4.1) System Development and Documentation Tools and Techniques

Documentation is a vital part of any AIS. Accountants use many different types of diagrams to
trace the flow of accounting data through an AIS. A wide variety of software is available for
documenting AISs. Documentation includes the following types of tools:
> The narratives (written descriptions),
> Flowcharts,
> Diagrams, and
> Other written material that explain how the system works
This information covers the who, what, when, where, why, and how of data entry, processing,
storage, information output and system controls. One popular means of documenting a system
is to develop diagrams, flowcharts, tables, and other graphical representations of information.
These are then supplemented by a narrative description of the system, which is a written step-by
step explanation of system components and interactions.
The two most common tools of system documentation- dataflow diagrams and flowcharts will be
discussed in this part. These tools save the organization both time and money.
Importance of documentation in System Development

Depending on the job function being performed, documentation tools are important on one or
more of the following levels:
1. At minimum, your must be able to read documentation to determine how the system
works.
2. Internal control documentations are evaluated to identify control strengths and
weaknesses and to recommend improvements.
3. The greatest amount of skill is needed to prepare documentation.
An understanding of documentation tools is required regardless of the type of accounting career
chosen. For example, auditors are required to understand the client's system of internal controls
before conducting an audit. In general, documentation is important as in the following manners:
> It depicts how the system works
Studying and reviewing written descriptions of the inputs, processing steps, and outputs of the
system make the job easier.
> It is used to give training to users
Documentation also includes the user guides, procedure manuals, and other operating
instructions that help people learn how the AIS operate.
> It is used as a framework for designing the new systems
Documentation helps system designers develop new systems in much the same way that
blueprints help architects design buildings.
68
> It is used to control system development and maintenance costs

Good documentation helps system designers develop object-oriented SW, that is, programs that
contain modular, reusable code. This object-orientation helps programmers avoid writing
duplicate programs and facilities changes when programs must be modified later.
> It is a means of standardizing communications with others
Documentation techniques such as flowcharts and data flow diagrams are standard industry
tools, and they are more likely to be interpreted the same way by all parties viewing them.
> It can be used as guideline for Auditing AISs
Documentation helps auditors determine the strengths and weaknesses of a systems controls.
> It is used for documenting business processes
By mapping the business processes, documentation helps managers better understand the ways in
which their businesses operate.
> It is used to establish accountability
Basic Documentation Tools

The two of the most common and basic documentation tools are:
1. Data Flow Diagrams (DFDs) are graphical descriptions of the sources and destinations of
data. They show data flow within an organization i.e. where data comes from and where it
goes, how it flows, the processes performed on it, and how data are stored
2. Flow Charts
Include three types:
> Document Flow Chart a graphical description of the flow of documents and information
between departments or areas of responsibility within an organization. It traces the physical
flow of documents through an organization.
> System Flowchart a graphical description of the relationship among the input, processing,
and output in an information system. It shows the electronic flow of data and processing
steps in an AIS.
> Program Flowchart a graphical description of the sequence of logical operations that a
computer performs as it executes a program.
These tools are used extensively in the System Development Process. Systems development is a
complex process and these tools are used to create order from chaos and complexity. In addition,
the team members who develop information systems projects often change and these
documentation tools help the new team members get up to speed quickly.
Both DFDs and Flowcharts are easy to prepare and revise when one of the recently developed
DFDs or Flowcharting Software packages is used. They are easier to use than most word
processors. Once a few basic commands are mastered, users can quickly and easily prepare, store,
revise, and print presentation-quality DFDs or Flowcharts.
Which method should you use Flowcharts or DFDs?
> 62.5% of IS professionals use DFDs in USA
> 97.6% use flowcharts in USA
> Both can be prepared relatively simply using available software
> Both are tested on professional exams
69
> Conclusion: You need to know them both
Data Flow Diagrams (DFDs)

A data flow diagram (DFD) graphically describes the flow of data within an organization. Data
Flow Diagrams (DFDs) are primarily used in the systems development process as a tool for
analyzing an existing system. It is also used to plan and design new ones. There is no ideal way to
develop a DFD, because different problems call for different methods. However, some general
guidelines for developing DFDs can be used by system analysts.
Guideline for Drawing DFDs
1. Understand the system- involves observing the flow of information through an organization and
interviewing the individuals who use and process the data.
2. Ignore certain aspects of the system- as DFD diagrams the origin, flow, transformation, storage and
destinations of data, all control actions and processes should be ignored.
3. Determine system boundaries- is determining what to include in and exclude form the system. All
relevant data elements shall be included in the DFD because excluded items will not be considered
during systems development. When in doubt about an element's importance, include it until a
definitive decision can be made to discard it.
4. Develop a context diagram- a context diagram is a good way of depicting system boundaries. In the
diagram's center is a circle; inside of it is displayed the system of concern. The outside entities, with
which the system interacts directly, are in boxes on either side, connected by data flows depicting the
data passed between them. DFDs are prepared, in successively more detail, to depict data flows in
the system.
5. Identify data flows- all data flows shall be identified entering or leaving the system's boundary,
including where the data originate and the final destination. Any significant movement of information
is usually a data flow. All data flows come from and go to either a transformation process, a data
store (file), or a data source or destination. As each of this is identified, it should be connected to the
appropriate data flow. Data flows can move in two directions, shown as a line with arrows on both
ends.
6. Group data flows- a data flow consists of one or more pieces of datum. Data elements that always
flow together should be grouped together and shown as one data flow until they are separated. If the
data elements do not always flow together, then they should be shown as two separate data flows.
7. Identify transformation processes- this is by placing a circle wherever work is required to transform
one data flow into another. All transformation processes should have one or more incoming or
outgoing data flows.
8. Group transformation processes- transformation processes that are logically related or occur at the
same time and place should be grouped together. Unrelated items shall never be combined into a
single transformation process. If data are not processed together, or are sometimes processed
differently, then, they shall be separate.
9. Identify all files or data stores- data are stored temporarily or permanently in most systems. Each
data repository, and each data flow into and out of it, should be identified.
10. Identify all data sources and destinations- all sources and destinations of data should be identified
and included on the DFD.
11. Name all DFD elements- except for data flows into or out of data stores (data store is sufficient to
identify the data flow), data elements should be given unique and descriptive names representing
what is known about them. This makes DFD easier to read and understand as it provides the reader
with key information. Naming data flows first forces the developer to concentrate on the all-
important data flows, rather than on the processes or stores. Once data flows have been labeled,
naming the process and data stores is usually easy, because they typically take their names from the
data inflows or outflows. Choosing active and descriptive names such as daily inventory update and
70
validate transaction, rather than input data or update process. Process names should include action
verbs such as update, edit, prepare, and record.
12. Subdivide the DFD- a cluttered DFD is hard to read and understand. If there are more than five to
seven processes on a single page, then, higher level and lower level DFDs shall be used. The context
diagram shall be decomposed into high level processes, and then exploded into successively lower
level processes.
13. Give each process a sequential number- in completed DFD, each process is given a sequential number
that helps readers move back and forth between different DFD levels. Data flows should only go from
lower numbered to higher numbered processes.
14. Repeat the process- DFD developers must work through organization data flows several times. Each
subsequent pass helps refine the diagram and identify the fine points. When refining, the DFD shall
be organized to flow from top to bottom and from left to right.
15. Prepare a final copy- the final copy of the DFD shall be drawn. Data flow lines shall be allowed to
cross over each other, if necessary, a data store or destination may be repeated. The name of the DFD,
the data prepared, and the preparer shall be placed on each page.
Elements in a Data Flow Diagram

A DFD is composed of four basic elements: data sources and destinations, data flows,
transformation processes, and data stores. Each is represented in a DFD by a unique symbol. The
Demarco & Yourdon Symbols are as follows:
Symbol Name Explanation
> Data Source and > The people and organizations that send data to and
Destinations receive data from the system are represented by square
boxes. Data destinations are also referred to as data
sinks.
> Data Flows > The flow data into or out of a process is represented
by curved or straight line with arrows.
> Transformation
> The processes that transform data from inputs to
Processes outputs are represented by oval circles or circle. They
are often referred to as bubbles.
> Data Stores > The storage of data is represented by two Horizontal
lines.
Gane & Sarson Symbols include the following:

> Data Source and > The people and organizations that send data to and receive
Destinations data from the system are represented by square boxes.
Data destinations are also referred to as data
sinks.
> Data Flows > The flow data into or out of a process is represented by
curved or straight line with arrows.
> Transformation
Processes > The processes that transform data from inputs to outputs
are represented by oval circles or circle. They are often
referred to as bubbles.
> Data Stores > The storage of data is represented by two Horizontal lines.
71
These four symbols are combined to show how data are processed. For example, in the diagram
below, the input to Process C is data flow B, which comes form data source A. The outputs of
process C are data flows D and E. Data flow E is sent to data destination J. Process F uses data
flows D and G as input and produces data flows I and G as output. Data flow G comes from and
returns to data store h. Data flow I is sent to data destination K
Data Sources and Destinations

A data source or data destination symbol on the DFD represents an organization or individual
that sends or receives data that they system uses or produces. An entity can be both a source and a
destination. Data sources or destinations are represented by a square.
Data flows
Data flows appear as arrows. A data flow represents the flow of data between processes, data stores
and data sources and destinations. Data that passes between data stores and either a data source or
a destination must go through some form of data processing (transformation process). Data flow
arrows are labeled to indicate the type of data being passed. Thus, the reader knows exactly what
information is flowing; no inferences are required. In the diagram below data flow B is labeled
Customer Payment; Item D (remittance data); E (deposit); G (unlabeled; represents information
entered into or retrieved from an accounts receivable data file), and I (receivable information) A
data flow can consist of one or more pieces of datum. For example, data flow B (customer
payment) in the diagram below consists of two parts: a payment and remittance data. Process
1.0 (process payment) splits these two data elements and sends them in different directions. The
remittance data (D) flows to another process, where it is used to update accounts receivable
records, and the payment (E) is sent to the bank with a deposit slip. Because data flows may consist
of more than one data element, the designer must determine the number of lines to show. The
determining factor is if the data elements always flow together. For example customers may send
inquiries about the processing of their payments with payments or separately.
72
Data flow diagram of Customer Payment Process

Accounts
Receivable (H)
Customer Receivables
Payment (B) 1.0 2.0 Information (I)
Custome Process Data (D) Update Credit Manager
r Payment (C) Receivables (F) (K)
(A)
Deposits (E)
Data
Destination (J)
Transformation Process
A transformation process represents the transformations of data. The diagram above shows
that process payment (C) takes customer payment and splits into the remittance data and the
deposit (which includes the checks and deposit slip created within process payment). The updating
receivables (F) process takes the remittance data (D) and the accounts receivables (H) data,
producing updated receivables record and sending receivables information to the credit manager.
Data Stores
A data store is a temporary or permanent repository of data. DFDs do not show the physical
storage medium such as disks, and paper, used to store data. As with other DFD elements, data
store names should be descriptive. Data stores are represented by horizontal lines, with respective
name recorded inside.
Data Dictionary
A data dictionary contains description of all the elements, stores, and flows in a system. Data
flows and data stores are typically collections of data elements. Typically, a master copy of the
data dictionary is maintained to ensure consistency and accuracy throughout the development
process.
Types of DFDs
> Physical Data Flow Diagrams
A Physical DFD documents the physical structure of an existing system. It answers questions
such as where an entity works, how an entity works, the work is done by whom, etc. Given the
very physical focus of a physical DFD, it changes whenever the entities, technology used to
implement the system, etc. changes. Physical DFDs have no lower levels. Physical DFD focuses
on physical entities as well as the tangible documents, reports, and similar hard-copy inputs and
outputs that flow through the system. Physical DFD lists the job title of one typical employee and
it is simple, more readable, and therefore more easily understood.
73
Sales Order &

Cash register
Customer Clerk tape
1.0
Cashier
Form 66W 2.0
Verified
Sales Book- register tape Deposit slip

information & cash
Keeper
3.0
Blue sales book
Bank
Figure: Physical Data Flow Diagram
> Logical Data Flow Diagrams

Logical Data Flow Diagrams document the processes in an existing or proposed system. It used to
document what tasks the system performs. The logical DFD focuses on the logical flow of data. Because
the logic of a system changes infrequently, relative to its physical nature, a logical DFD will remain
relatively constant over time. Logical Data Flow Diagrams are usually drawn in levels that include
increasing amounts of detail. Logical Data flow diagrams typically have levels below the level-0 diagram
> Context Diagram

A top level (High-Level) Logical DFD that provides an overall picture of an application or system is
called a Context Diagram. A context diagram provides the reader with a summary level view of the system.
It depicts a data processing system and the external entities that are the sources and destinations of the
system's inputs and outputs. It does focus either on the tasks or the physical entities. It shows the overall
picture of the system.
The Hierarchy of Data Flow Diagrams
Context Diagrams
Physical DFD Level0 Logical

No Lower Levels DFD
Lower Levels Possible
Level1 Logical DFD
Level2 Logical DFD, etc
Decomposing (Subdividing) the DFD

Decomposition is the act of exploding data flow diagrams to create more detail. Data Flow
Diagrams are usually drawn in levels that include increasing amounts of detail. A Context Diagram
is then decomposed, or exploded, or broken down into successively lower levels of
74
detail. The Decomposition or Subdivision into successively lower levels is made in order to
provide ever-increasing amounts of detail because few systems can be diagrammed on one sheet
of paper. Physical DFD is not subdivided into lower successive levels. The Logical DFD is
decomposed as required. Logical DFDs typically have levels below the Level-0 Diagram. Level-
0 DFDs may be exploded into successive lower levels of detail. The next level of detail would be
a Level-1 DFDs. The DFDs become linked together in a hierarchy, which would fully document
the system.
For example, the following can be considered as the Context Diagram of Payroll Processing
System for a certain company. It shows that the payroll processing system receives time card data
from different departments and employees' data from the human resource department. When these
data are processed, the system produces:
> Tax reports and payments for governmental agencies
> Employee payments
> A deposit in the payroll account at the bank, and
> Payroll data for management.
The context diagram is decomposed into successively lower levels, each with an increasing amount
of detail. In exploding the Context DFD the number of processing activities involved and the data
inputs and outputs from each processing activity must be identified.
Governmental
Departments Agencies
Employee checks Employees

Payroll
Processing
System
Bank
Human
Resources
Context Diagram for Payroll Processing System Management
For payroll processing system, five data processing activities are identified as follows:
> The first activity is updating the employee/payroll master file
> The second activity is handling employee compensation. This activity can be broken
down into smaller parts
> The third activity is generating management reports
> A fourth activity is paying taxes; and
75
> A fifth activity is posting entries to the general ledger
All data inflows and outflows, and the five activities that forms DFD are summarized as follows
Data Inputs Activities (Processes) Data Outputs
New employee form Update Updated employee/payroll file
Employee change form Employee/Payroll file
Employee/payroll file
Time cards Pay Employees Employee checks
Employee/payroll file Payroll register
Tax rates table Updated employee/payroll file
Payroll check
Payroll cash disbursements vouchers
Employee/payroll file Prepare Reports Payroll report
Employee/payroll file Pay Taxes Tax report
Tax payment
Payroll tax cash disbursements voucher
Update general ledger
Payroll tax cash disbursements voucher Update General Ledger Updated general ledger
Payroll cash disbursement voucher
Exploded DFD for Payroll Processing System (Level-0 Logical DFD)
Departments
Employees
Human
Resources 1.0
Update
2.0
Employee/ Pay
Payroll Employees Payroll check
File
Bank
3.0
5.0
Prepare Employee/ Update
Reports Payroll file General
Ledger
4.0 General
Pay Ledger
Taxes
Management Governmental
Agencies
Some data inputs and outputs have been excluded from the above DFD. For example, in process
2.0, the data inflows and outflows that are not related to an external entity or to another process
are not depicted (tax tables and payroll register in this case), which does not show a greater level
of detail. These data flows are internal to the Pay Employees activity and are shown on the
76
next DFD Level. Suppose Process 2.0 (Pay Employees) can be further exploded in the next level
as follows and the sub-processes would be numbered 2.1, 2.2, etc.
Tax Rates
Table Employees
2.1
Process
Payroll
Payroll Register
Payroll Disb. Voucher
2.2
Prepare Cash Payroll Check
Employee/ Disbursements Bank
Payroll File
Flowcharts
A flowchart is an analytical technique used to describe some aspect of an information system in a
clear, concise, and logical manner. Flowcharts use a standard set of symbols to pictorially describe
transaction processing procedures. The following are general guidelines for preparing flowcharts
that are readable, clear, concise, consistent, and understandable.
1. Understanding a system before flowcharting it by interviewing users, developers, auditors,
and management or having them complete a questionnaire as well as by reading through a
narrative description of the system, or walking through system transactions.
2. Identifying the entities to be flowcharted such s departments, job functions, or external
parties as well as identifying documents and information flows in the system and the
activities or processes performed on the data, for instance drawing a box around the entities,
a circle around the documents and a line around the activities.
3. Dividing the flowchart into columns when several entities such as departments and
functions need to be shown on the flowchart with a label for each followed by flowcharting
the activities of each entity in its respective columns.
4. Flowcharting only the normal flow of operations, ensuring that all procedures and
processes are in proper order and identifying exception procedures by using an annotation
symbol.
5. Designing the flowchart so that flow proceeds from top to bottom and from left to right.
6. Giving the flowchart a clear beginning and ending by designing where the document
originated and showing the final disposition of all documents so there are no loose ends
that leave the reader dangling.
7. Using the standard flowcharting symbols and drawing them with a template or a computer
8. Clearing labeling all symbols by writing a description of the input, process, or output inside
the symbol. If description may not fit, annotation symbol shall be used.
77
9. Placing document numbers in the top right hand corner of the symbol when using multiple
copies of a document. The document numbers should accompany the symbols as it moves
through the system.
10. Having an input and output for each manual processing symbol. Two documents shall not
be connected directly except when moving from one column to another column.
11. Using on page connectors to avoid excess flow lines, which results in a neat looking page
as well as using off-page connectors to move from one flowchart page to another. All
connectors shall be clearly labeled to avoid confusion.
12. Using arrowheads on all flow lines and not assuming that the reader will know the direction
of the flow.
13. Clearly labeling the pages 1 of 3, 2 of 3 etc if a flowchart can not fit into a single page.
14. Showing documents or reports first in the column in which they are created and then
moving to another column for further processing. A manual process is not needed to show
documents being flowcharted.
15. Showing all data entered into or retrieved from a computer file as passing through a
processing operation (a computer program) first.
16. Drawing a line from the document to a file to indicate that it is being filed. A manual
process is not needed to show a document entering a file.
17. Drawing a rough sketch of the flowchart as a first effort. Concern shall be with capturing
content than perfect drawing. Few systems can be flowcharted in a single draft.
18. Redesigning the flowchart to avoid clutter and a large number of crossed lines.
19. Verifying the flowchart's accuracy by reviewing it with the people familiar with the system.
It shall be assured that all uses of flowchart conventions are consistent.
20. Drawing the final copy of the flowchart, placing the name of the flowchart, the date, and
the preparer's name on each page.
Flowchart Symbols
There are various types of symbols used to create flowcharts. Each symbol has a special meaning
that is easily conveyed by its shape. The shape indicates and describes the operation performed
and the input, processing, output, and storage media employed. The symbols are drawn by a
software program or with a flowcharting template.
Flowcharting symbols can be divided into the following four categories:
1. Input/output symbols- represent devices or media that provide input to or record output
from processing operations.
2. Processing symbols- either show what type of device is used to process data or indicate
when processing is completed manually.
3. Storage symbols- represent the device used to store data that the system is not currently
using.
4. Flow and miscellaneous symbols- indicate the flow of data and goods. They also represent
such operations as where flowcharts begin and end, where decisions are made, and when
to add explanatory notes to flowcharts.
78
Flowchart Symbols:
Input/Output Symbols
Document >Represents a document or report that is prepared by
hand or printed by a computer.
1
2
3
Multiple Copies of > Indicates multiple copies of a paper document or report.
One Document > The document copies should be numbered in the upper,
right-hand corner.
> Can represent any input or output on a program
Input/output; flowchart. It also represents accounting journals or
Journal/Ledger ledgers in a document flowchart.
Display > Represents information displayed by an online output

device such as a terminal, monitor, or screen
Online Keying > Represents data entry by an online device such as a
terminal or personal computer
Terminal or Personal > Combines the display and online keying symbols to
Computer represent terminals and personal computers.
Transmittal Tape >Represents manually prepared control totals which are

to be compared to computer totals for control
purposes.
Processing Symbols
Computer Processing >Represents a process performed by a computer, which
usually results in a change in data or information.
Manual Operation >Represents a processing operation that is performed
manually
Auxiliary Operation >Represents a processing operation carried out by a
device other than a computer, e.g., an optical character
scanner.
Off-line Keying >Represents an operation that uses an off-line keying
Operation device, such as a cash register or keying to a disk.
Storage Symbols
Magnetic disk >Represents data stored permanently on a magnetic

disk. Frequently used to represent master files and
databases.
Magnetic Tape >Represents data stored on a magnetic tape.
>Sometimes represents transaction files
Diskette >Represents data stored on a floppy disk or zip disk
Online Storage >Represents data stored in a temporary online file in a

direct-access medium such as a magnetic disk.
79
File >Represents a file of documents that are manually stored

A and retrieved. Letter indicates the ordering sequence: A
= Alphabetic order; D = Date order; and
N = Numeric order
Flow And Miscellaneous Symbols
Document or Processing >Represents the direction of processing or document
Flow flow
>Normal flow is top to bottom and left to right
Data/Information Flow >Represents the direction of data/information flow.
>Often used to show data being copied from one
document to another.
Communication Link >Represents the transmission of data from one location
to another via communication lines.
On-page connector >Connects processing from one location to another on
the same page. Used to avoid crisscrossing lines.
Off-page connector >Connects the processing flow between two different

pages. Signals the exit from one page and the
corresponding entrance on another page.
Terminal >Represents the beginning, end, or a point of
interruption in a process or program.
>Also used to indicate an external party.
Decision >Represents a decision-making step. Used in a program
flowchart to show branching to alternate paths.
Annotation >Provides for the addition of descriptive comments or
explanatory notes as clarification
1) Document Flowcharts
A document flowchart illustrates the flow of documents and information among areas of
responsibility within an organization. Document flowcharts trace a document from its cradle to its
grave. They show:
> Where each a document originates,
> Its distribution,
> The purposes for which it is used,
> Its ultimate disposition, and
> Everything that happens as it flows through the system.
A document flowchart is particularly useful in analyzing the adequacy of control procedures in a
system, such as internal checks and segregation of duties. Flowcharts that describe and evaluate
internal controls are often referred to as internal control flowcharts.
The document flowchart can reveal weaknesses or inefficiencies in a system, such as inadequate
communication flows, unnecessary complexity in document flows, or procedures responsible for
causing wasteful delays. They also can be prepared as part of the system design process and should
be included in the documentation of an information system.
Following is a typical example of how a Document Flowchart can be designed:
Compiled By: Kassahun Boressa 79

2) System Flowcharts
System flowcharts depict the relationship among the input, processing, and output of an AIS. A
system flowchart begins by identifying both the inputs that enter the system and their origins.
These inputs can be:
> New data
> Data stored for future use
> Both

Figure: System Flowchart of Sales Processing

The input is followed by the processing portion of the flowchart. The input is followed by
processing portion of the flowchart that is the steps performed on the data. The logic the computer
uses to perform the processing task is shown on a program flowchart. That is, if the process is
performed by a computer, the logic of the computer program would be depicted in a program
flowchart. The resulting new information is the output component, which can be stored for later
use, displayed on a screen, or printed on paper. In many instances, the output from one process is
an input to another.
System flowcharts are an important systems analysis, design, and evaluation tool. They are
universally employed in systems work and provide an immediate form of communication among
workers. The system flowchart is an excellent vehicle for describing information flows and
procedures within AIS.
A system flowchart depicts the relationship among the inputs, processes, and outputs of an AIS.
> The system flowchart begins by identifying the inputs to the system.
> Each input is followed by a process, i.e., the steps performed on the data.

> The process is followed by outputsthe resulting new information.

> In other words, its the same basic input process output pattern that we saw in the
document flowchart.
See the above System flow Chart of Sales Processing and the Following System Flowchart
for Preparing a Payroll
3) Program Flowcharts
A program flowchart illustrates the sequence of logical operations performed by a computer in
executing a program. It describes the specific logic to perform a process shown on a systems
flowchart. A flow line connects the symbols and indicates the sequence of operations. The
processing symbol represents a data movement or arithmetic calculation. Once designed and
approved, the program flowchart serves as the blueprint for coding the computer program.
> Note that the program flowchart details the logic of processes performed by the computer.
> The input/output symbol represents either reading of input or writing of output.

> The decision symbol represents a comparison of one or more variables and the transfer of
flow to alternative logic paths.
> All points where the flow begins or ends are represented by the terminal symbol.
Differences between DFDs and Flowcharts

> DFDs emphasize the flow of data and what is happening in a system, whereas a
flowchart emphasizes the flow of documents or records containing data.
> A DFD represents the logical flow of data, whereas a flowchart represents the
physical flow of data.
> Flowcharts are used primarily to document existing systems.
> DFDs, in contrast, are primarily used in the design of new systems and do not concern
themselves with the physical devices used to process, store, and transform data.
> DFDs make use of only four symbols.
> Flowcharts use many symbols and thus can show more detail.

4.2) Introduction to Systems Development and Systems Analysis

Because the environment is competitive and ever changing, organizations continually face the need
for new, faster, and more reliable ways of obtaining information. To meet this need, an information
system must continually undergo changes, ranging from minor adjustments to major overhauls.
Occasionally, the changes are so drastic that the old system is scrapped and replaces by an entirely
new one. Change is so constant and frequent that most organizations are involved in some system
improvement or change. This due to one of the following reasons:
1. Changes in user or business needs- increased completion, business growth or
consolidation, merger and divestiture, new regulations, or changes in regional and global
relationships can alter an organization's structure and purpose. To remain responsive, the
system must change as well.
2. Technological change- as technology advances and becomes less costly, an organization
can make use of the new capabilities or existing ones that were previously too expensive.
3. Improved business processes- many companies have inefficient business processes that
require updating.
4. Competitive advantage- Increased quality, quantity and speed of information can result in
an improved product or service and may help lower costs.
5. Productivity gains-computers automate clerical and repetitive tasks and significantly
decrease the performance time of other tasks. Expert systems place specialized knowledge
at the disposal of many others.
6. Growth- companies outgrow their systems and must either upgrade or replace them
entirely.
7. Downsizing- companies often move from centralized mainframes to networked PCs or to
Internet-based systems to take advantage of their price/performance ratios. This places
decision making and its corresponding information as far down the organization chart as
possible.
This Topic Discusses Five Subtopics:

> Systems development life cycle process that organizations follow to obtain and
implement a new AIS
> Planning activities during the systems development life cycle
> Feasibility analysis
> Behavioral aspects of change
> Systems analysis
The Systems Development Life Cycle
Whether systems changes are major or minor, most companies go through a systems development
life cycle. The systems development life cycle (SDLC) is a conceptual model that describes the
stages involved in an information system development project, from an initial feasibility study
through maintenance of the completed application. It is a logical process by which systems
analysts, software engineers, programmers and end-users build information systems and computer
applications to solve business problems and needs.
Systems development methodology can be used as a synonym for the life cycle. Systems
development methodology is a very formal and precise system development process that defines
a set of activities, methods, best practices, deliverables, and automated tools that system

developers and project managers are to use to develop and maintain information systems and
software.
Various SDLC methodologies have been developed to guide the processes involved, including:
> The Waterfall Model (Which Was The Original SDLC Method);
> Rapid Application Development (RAD);
> Joint Application Development (JAD);
> The Fountain Model;
> The Spiral Model;
> Build And Fix; And
> Synchronize-And-Stabilize
Frequently, several models are combined into some sort of hybrid methodology. Documentation
is crucial regardless of the type of model chosen or devised for any application, and is usually done
in parallel with the development process. Some methods work better for specific types of projects,
but in the final analysis, the most important factor for the success of a project may be how closely
the particular plan was followed.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated- deficiencies are identified. This can be done by
interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined- in particular, the deficiencies in the existing
system must be addressed with specific proposals for improvement.
3. The proposed system is designed- plans are laid out concerning the physical construction,
hardware, operating systems, programming, communications, and security issues.
4. The new system is developed- the new components and programs must be obtained and
installed. Users of the system must be trained in its use, and all aspects of performance
must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use-this can be done in various ways. The new system can phased
in, according to application or location, and the old system gradually replaced. In some
cases, it may be more cost-effective to shut down the old system and implement the new
system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated.
Maintenance must be kept up rigorously at all times. Users of the system should be kept
up-to-date concerning the latest modifications and procedures.
The five stages in the systems development life cycle are: (1) Systems analysis; (2) Conceptual
Design; (3) Physical Design; (4) Implementation and Conversion; and (5) Operation and
Maintenance

Systems Analysis
> Do initial investigation
> Do system survey
> Do feasibility study
> Determine information needs and system
requirements
> Deliver systems requirements
Conceptual
Design
> Identify and evaluate design alternatives
> Develop design specifications
>
Physical Design and Decision Points:
> Design output
> Economic Feasibility
> Design database
> Design input > Technical Feasibility
> Develop programs > Legal Feasibility
> Develop procedures
> Design controls > Scheduling Feasibility
> Deliver developed system > Operational Feasibility
Implementation and Conversion

> Develop plan
> Install hardware and software
> Train personnel, test the system
> Complete documentation
> Convert from old to new system Fine-tune and
review
> Deliver operational system

> Operate system
> Modify system
> Do ongoing maintenance
> Deliver improved system
Figure: The Systems Development Life Cycle

In addition to these five phases, the following three activities are preformed throughout the life
cycle Planning Systems Development; Assessing the ongoing Feasibility of the Project; and
Managing Behavioural Reactions to Change

The Key Players in System Development Process

The Players refer to who are the people involved in developing and implementing AIS?
1. Top management
2. Accountants
3. The information systems steering committee
4. The project development team
5. Systems analysts and programmers
6. Computer programmers
7. External players
Top Management
Top managements role in systems development is to:
> Provide support and encouragement and a clear signal that user involvement is
important
> Help align the systems with corporate strategies
> Establish system goals and objectives
> Review IS department performance and leadership
> Establish policies for project selection and organizational structure
> Participate in important systems decisions
User management needs to:
> Determine information requirements for departmental projects
> Assist systems analysts with project cost-benefit estimates
> Assign key staff members to development projects
> Allocate funds
Accountants
Accountants also play an important role in systems development:
> As AIS users, they must determine their information needs and systems requirements
and communicate them to system developers
> As members of project development teams or steering committees, they help
management in the development process.
> They are also active in designing system controls and monitoring and testing these
controls and ensuring the system is easy to audit.
> Controls and auditability need to be built in early to minimize costs and
inefficiencies later.
The Information Systems Steering Committee
The information systems steering committee is an executive-level committee whose duty is to
plan and oversee the IS function. The information systems steering committee:
> Consists of high level management, such as Controller; IS Manager; and User department
managers.
> Sets policies to govern the AIS and assure top-management participation, guidance, and
control.
> Attempts to encourage goal congruence and reduce goal conflict
The Project Development Team

The project development team includes systems specialists, managers, accountants, auditors, and
users whose responsibility is to guide development. Their job is to:
> Plan each project.
> Monitor to ensure timely and cost-effective completion.
> Ensure the human element is considered.
> Communicate project status to top management and steering committee.
> Communicate and meet with users to consider ideas; discuss progress; and eliminate
surprises
The team approach produces more effective results and better user acceptance.
Systems Analysts
> Systems analysts study existing systems, design new ones, and prepare specifications that
are used by programmers.
> They interact with technical personnel and users to bridge the gap.
> They are responsible for ensuring the system meets user needs.
Computer programmers
> Computer programmers write the computer programs, using the specs developed by the
systems analysts
> They also modify and maintaining existing programs
External Players
> External players include Customers, Vendors, Auditors, and Governmental entities
> Their needs must also be met in systems development.
Planning Systems Development

Several activities must be performed at various times throughout the SDLC. One of these activities
is planning. The organization should have plans for the long range, each systems development
project, and each phase of each systems development project. This sub-topic discusses these plans
and a number of techniques to develop them.
Systems development planning is an important step for the following key reasons:
> Consistency with the organizations strategic plan
> Efficiency achieved through coordination of the subsystems
> Cutting edge technology and techniques
> Lower costs due to lack of duplication, wasted effort, time overruns, and cost overruns
> Adaptability for future changes
When a system is poorly planned, a company must often return to a prior phase and correct errors
and design flaws. These returns are costly and result in delays, frustration, and low morale.

System
Systems requirements
Analysis
Blueprint for detailed

Conceptual system design
Change in Scope or Systems Design
requirements
Fully Designed
System
Physical
Inadequate or incorrect Design
design blueprint Operational
System
Implementation
Errors or problems that do and Conversion
not allow implementation
to completed
Operation and
Implementation Maintenance
Incomplete
Two types of systems development plans are needed:

> Individual project plans developed by the project teams (Project Plans)
> A master plan developed by the IS steering committee (Master Plan)
Individual project plans developed by the project teams

Individual project plans contain:
> A cost-benefit analysis.
> Developmental and operational requirements, including human resources, Hardware,
Software, Financial resources
> A schedule of activities to develop and operate the new application
A master plan developed by the IS steering committee

A master plan specifies:
> What the system will consist of
> How it will be developed
> Who will develop it
> How needed resources will be acquired
> Where the AIS is headed
It also provides:
> Status of projects in process
> Prioritization of planned projects and criteria for establishing priorities
> Timetables for development
Projects with highest priority are first to be developed. These decisions are made by top
management.

Planning Techniques
Two techniques for scheduling and monitoring systems development activities are:
> Program Evaluation and Review Technique (PERT)
> Gantt Charts
A) PERT (Program Evaluation and Review Techniques);

A PERT diagram requires that all activities in a project be identified along with the activities that
precede and follow them. That means, PERT requires identifying all activities and the precedent
and subsequent relationships among them. These activities are used to draw a PERT diagram,
which consists of a network of:
> Arrows representing activities that require time and resources.
> Nodes representing completion and initiation of activities.
The Critical Path in a PERT diagram is the path requiring the greatest amount of time. If an
activity on the critical path is delayed, the whole project is delayed. Resources may be shifted to
the critical path to reduce the delay.
Sample PERT Chart
> Building and selling a doghouse
> Each block contains a task and a time estimate (may include best time, worst time, and
average time)
> May indicate who will be responsible for the task
2 4
1 6 7 8
3 5
1. Design doghouse; 2 weeks

2. Buy Wood & Nails; 1 week
3. Buy Paint; 1 week
4. Build Base; 2 weeks
5. Build Roof; 1 week
6. Nail Together; 2 weeks
7. Paint & Decorate; 3 weeks
8. Sell; 2 weeks
B) Gantt Chart
> A Gantt chart is a bar chart with project activities on the left and time across the top.
> For each activity, a bar of expected time is drawn.
> As activities are completed, the bar is filled in
> The Gantt chart makes it easy to eyeball the chart and understand the current status of a
project.
> But the chart does not show the relationship between activities like the PERT chart does

A) = Complete
B) = Testing
C) = In Development
D) = Not yet started
E) = Milestone
Period
1 2 3 4 5 6 7 8 9 10
Organize Implementation Team
Prepare System Support Procedures
Develop Conversion and Testing Plan
Prepare Program Specifications
Revise System Documentation
Perform Programming Tasks
System Test and Install System
Acceptance Test and Conversion
During the systems analysis phase, a feasibility study (also called a business case) is prepared and
is updated during the remaining steps in the SDLC. The extent of the feasibility study depends on
the size and nature of the system. Feasibility team should include Management, Accountants
skilled in controls and auditing, Systems personnel, and Users
The feasibility study and its updates are used by the steering committee as the project proceeds to
decide whether to:
> Terminate the project
> Proceed
> Proceed if specific problems are resolved
The five important aspects need to be considered during a feasibility study are:
1. Technical feasibility
> Is the technology there to do it?
2. Operational feasibility
> Do we have people who can do it, and will it get used?
3. Legal feasibility
> Does it comply with legal, regulatory, and contractual obligations?
4. Scheduling feasibility
> Can it be done in time?
5. Economic feasibility
> Will the benefits exceed the costs?
Calculating Economic Feasibility

Economic feasibility is probably the most important and frequently analyzed aspect. Economic
feasibility requires a careful investigation of costs and benefits of a proposed system. It typically
uses a capital budgeting model that considers:
> Cost savings and other benefits
> Initial outlay costs
> Operating costs

> Other costs

When possible, benefits and costs should be estimated and included even if they are not easily
quantifiable. If some costs and benefits cannot be accurately estimated, they should at least be
listed, along with the likelihood of their occurrence and their expected impact.
Benefits might include:
> Cost savings
> Improved customer service, productivity, decision making, or data processing.
> Better management control
> Increased job satisfaction and employee morale
Costs might include:

> Equipment costs initial outlay plus ongoing operating costs
> Software costs costs of acquiring, maintaining, supporting, and operating
> Human resource costs salaries, as well as costs of hiring, training, and relocating staff
> Site preparation costs
> Installation and conversion costs
> Supplies costs
> Overhead costs
> Financial charges
> Operating costs - the primary operating cost is maintaining the system.
Capital Budgeting
Most organizations use a capital budgeting return on investment technique to evaluate the
economic merits of different system alternatives. There are three commonly used capital budgeting
techniques:
> Payback period - calculates the number of years before the new savings from the project
equal the initial cost of the investment. Select projects with shorter payback periods.
> Net present value (NPV) - calculates and sums the discounted future cash flows of the
costs and benefits. Select projects with higher positive NPV.
> Internal rate of return (IRR) calculates the effective interest rate that would result in
a net present value of zero for the project. Select projects with higher IRRs.
Behavioural Aspects of Change

Individuals involved in systems development are agents of change who are continually confronted
by peoples reaction and resistance to change. The best system will fail without the support of the
people it serves. So the behavioral aspects of change are crucial. You need to be aware of and
sensitive to the types of behavioral problems that can result from change.
Why Behavioral Problems Occur?

Employees will tend to view change as good if they believe it will affect them positively and vice
versa. To minimize adverse behavioral reactions, one must first understand why resistance occurs.
Some of the more important factors include the following:
> Personal characteristics and background
> Manner in which change is introduced
> Experience with prior changes employees who had bad experience are reluctant
> Top management support

> Communication employees are unlikely to support a change unless the reasons behind it
are explained.
> Biases and natural resistance to change
> Disruptive nature of the change process
> Fear fear of the unknown, failure, technology, losing respect or status, and losing their
jobs
How People Resist AIS Changes?
Resistance to change often takes one of three forms:
1. Aggression behavior intended to destroy, cripple, or weaken the systems effectiveness.
Examples: Increased error rates, disruptions, or deliberate sabotage.
2. Projection blaming the new system for any and every unpleasant occurrence, i.e., the system
becomes a scapegoat. To preserve the integrity of the system, these criticisms must be
controlled or answered.
3. Avoidance - If I dont use this thing, maybe it will go away!
Overcoming behavioral problems to changes
Reactions to change can be improved by observing the following guidelines:
> Meet users needs with respect to the form, content, and volume of system output.
> Keep communication lines open. Managers and users should be fully informed about: What
changes are being made; why the change is made; how it will benefit them; and who to
contact with questions
> Maintain a safe and open atmosphere
> Obtain management support
> Alleviate fears to the extent possible, reassure employees that no major job losses or
responsibility shifts will occur. If employees are terminated, severance pay and
outplacement services should be provided.
> Solicit user participation - users who participate will be more committed to using the
system
> Make sure users understand the system dont underestimate the training needs
> Provide honest feedback explain which suggestions are and are not being used and why.
> Humanize the system employees shouldnt feel the computer is controlling them or has
usurped their positions
> Describe New Challenges And Opportunities the system can provide greater job
satisfaction and increased opportunities
> Reexamine performance evaluation Are performance standards and criteria realistic in
light of the change?
> Test the systems integrity it is important to minimize bad impressions
> Avoid emotionalism
> Present the system in the proper context
> Control the users expectations - dont oversell, and be realistic
> Keep the system simple - avoid complex systems that cause radical changes.
Systems Development Life Cycle

Phase-1: Systems Analysis
As organizations grow and change, management and employees recognize the need for more or
better information and request a new or improved information system. The first step in systems

development is systems analysis. During systems analysis, the information needed to purchase or
develop a new system is gathered. Requests for systems development are prioritized to maximize
the use of limited development resources. If a project passes the initial screening, the current
system is surveyed to define the nature and scope of the project and to identify its strength and
weaknesses. Then an in-depth study of the proposed system is conducted to determine its
feasibility. If the proposed system is feasible, the information needs of system users and managers
are identified and documented. This is the most important part of systems analysis, as these needs
are used to select or develop a new system. To summarize the work done during systems analysis,
a report is prepared and submitted to the information systems steering committee.
Since System analysis is too costly (in terms of time, effort, money, etc), it is mostly started after
the project is approved and green light is obtained from the management. When a new or improved
system is needed, a written request for systems development is prepared. The request describes the
current systems problems, why the change is needed, and the proposed systems goals and
objectives. It also describes the anticipated benefits and costs. When a new or improved system is
needed, a written request for systems development is prepared. That request describes the current
systems problems; the reasons for the proposed changes; the goals and objectives of a proposed
system; and the anticipated benefits and costs. In general, system analysis is the stage of studying
the current business system; understanding how the existing system works; determining the
weakness and strength of the existing system; and defining the business needs and requirements
(user requirement determination and system requirement determination independent of technology
issues), etc
There are five steps in the system analysis phase:
> Initial Investigation
> Systems Survey
> Feasibility Study
> Information Needs and Systems Requirements
> Systems Analysis Report
Initial Systems Feasibility Information Needs and System Analysis

Investigation Survey Study Systems Requirement Report
Physical Systems Conceptual Systems Design

Design
Systems Analysis
1. Initial investigation- is conducted to screen projects. It involves gathering the information

needed to buy or develop a new system and determining whether it is a priority
> Gaining a clear picture of the problem or need sometimes what is thought to be the
cause of the problem is not the real source

> Determining the project's viability and expected costs and payoffs
> Evaluating the project's scope and the nature of the new AIS, and
> Recommending whether to continue the development project as proposed or modified or
abandon.
At this stage the exact nature of the problems under review must be determined. If the project is
approved:
> A proposal to conduct systems analysis is prepared
> The project is assigned a priority and added to the master plan
> The development team begins a survey of the existing AIS
> The proposal will be modified as more information becomes available
2. Systems survey- at this stage, an extensive study of the current AIS is undertaken. It may take
weeks or months depending on the complexity and the scope of the system. The objectives of
a system survey include:
> Gain a thorough understanding of the company operations, policies, and procedures; data
and information flows; AIS strengths and weaknesses; and available hardware, software,
and personnel.
> Make preliminary assessment of current and future processing needs, and determine the
extent and nature of the changes needed.
> Develop working relationships with users and build support for the AIS
> Collect data that identify user needs, conduct a feasibility analysis and make
recommendations to management.
Data can be gathered from:
> Employees
> Documentation such as organization charts and procedure manuals
> External sources such as Consultants, Customers, Suppliers, Industry associations, and
Government agencies
Traditional Methods of Collecting Data are:
> Interviews is a tool that helps to collect data which is answers to why questions: why is
there a problem? Why does the AIS work this way? Why is this information important?
> Questionnaires questionnaires can be used when the amount of information to be gathered
is small and well defined.; the information is to be obtained from many people or from those
who are remotely located; and the information is intended to verify data from other sources
> Observation is used to verify information gathered using other approaches and to determine
how a system actually works, rather than how it should work.
> System Documentation describes how the AIS is intended to work. Throughout the systems
survey, the project team should be alert to differences between intended and actual systems
operation.
Modern Methods of Collecting Data are:
> Joint Application Design (JAD) - sstarted in late 1970s at IBM. It brings together key users,
managers and systems analysts involved in the analysis of the current system. Its structure of
roles and its agenda differentiates it from group interview. The purpose is to collect system
requirements simultaneously from key people. It should be conducted off- site away from
the normal work place for the people involvedto minimize distraction

> Prototyping
Repetitive process involving analysts and users
Rudimentary version of system is built and rebuilt based on feedbacks
Replaces or augments SDLC
Goal: to develop concrete specifications for ultimate system
Quickly converts requirements to working version of desired system
Once the user sees requirements converted to physical system, they ask for modifications
or generate additional requests
Most useful when:
User requests are not clear
Few users are involved in the system
Designs are complex and require concrete form
History of communication problems between analysts and users
Tools are readily available to build prototype
Drawbacks
Tendency to avoid formal documentation
Difficult to adapt to more general user audience
Sharing data with other systems is often not considered
Systems Development Life Cycle (SDLC) checks are often bypassed
> Radical Method
Mostly when the traditional methods are used to determine requirements, they result in
automation of the existing system with some modification
Analysts focus on the problems and opportunities of the current system
This has a direct on the future system
The work on the identification and implementation of radical change on business processes
to achieve major improvements is possible through Business Process Reengineering
(BPR)
Goals of BBR
Recognize complete flow data in major sections of an organization
Eliminate unnecessary steps
Combine steps
Become more responsive to future changes
Document findings and model the existing system
Finally, the information gathered (the findings) during the analysis phase must be documented and
modelled so that it can be used throughout the systems development project. Documentation
consists of questionnaire copies, interview notes, memos, and document copies. Another way of
documenting a system is to model it.
System modeling:
Physical models illustrate how a system functions by describing:
> Flow of documents
> Computer processes performed and the people doing them
> Equipment used
> Any other physical elements
Logical models illustrate what is being done regardless of how the flow is accomplished.

Analyze the existing system

Once data gathering is complete, the survey team should:
> Evaluate the AISs strengths and weaknesses to develop ideas for designing and
structuring the new AIS. Try to retain strengths and correct weaknesses.
> Sometimes, revolutionary rather than evolutionary change is needed, called re-
engineering.
The system survey culminates with a system survey report. The report is supported by
documentation such as memos, interview and observation notes, etc.
3. Feasibility study- a more thorough feasibility analysis is conducted to determine the project's
viability. Especially important is economic feasibility. The feasibility analysis is updated as
the project proceeds and costs and benefits become clearer.
4. Information needs and systems requirements- once a project is deemed to be feasible, the
company identifies the information needs of the AIS users and documents system
requirements, which include:
> Processes describes what is to be done and by whom.
> Data elements describes name, size, format, source, and significance of necessary
data elements
> Data structure A preliminary structure showing how the data elements will be
organized into logical records
> Outputs layouts of system outputs and a description of their purpose, frequency, and
distribution
> Inputs a copy of system inputs and a description of their contents, source, and who is
responsible for them
> Constraints a description of deadlines, schedules, security requirements, staffing
limitations, and legal requirements
> Controls controls that are needed to ensure accuracy and reliability
> Reorganizations changes in staffing, job functions, etc., that would be necessary.
Determining information needs can be a challenging process due to the sheer quantity and variety
of information needs that must be specified, even for relatively simple AIS. In addition, it may be
difficult for employees to articulate their information needs or they may identify them incorrectly.
Thus, systems requirements must be determined accurately.
Systems Objectives and Constraints
Many entities take a systems approach to determining information needs and systems
requirements; Problems and alternatives are viewed from the standpoint of the entire
organizationas opposed to a single department. Systems objectives must be identified, so
analysts and users can focus on those elements most vital to success of the AIS. These objectives
may include:
> Usefulness information produced by the system should help management and users in
decision making
> Economy the benefits of the system should exceed the cost
> Reliability the system should process data accurately and completely
> Availability users should be able to access it when they need it.
> Timeliness More critical information is provided first.
> Customer service - Efficient and courteous customer service should be provided

> Capacity system should be capable to handle peak period operations

> Ease of use it should be user-friendly
> Flexibility should accommodate reasonable changes
> Tractability should be eeasily understood and facilitates problem solving and future
development.
> Auditability it should be auditable
> Security only authorized users should be granted access to it
Success often depends on the project teams ability to cope with organizational constraints,
including:
> Requirements of governmental agencies
> Managerial policies and guidelines
> Lack of sufficient, qualified staff
> Capabilities and attitudes of users
> Available technology
> Limited financial resources
Strategies for Determining Requirements:

One or more of the following four strategies are used to determine AIS requirements:
A) Ask users what they need
> This is the simplest and fastest strategy.
> But many people dont realize or understand their true needs.
> Its sometimes better to ask them what decisions they make and what processes they are
involved in.
> Users also need to think beyond their current information needs.
B) Analyze existing systems
> Internal and external systems should be analyzed to avoid reinventing the wheel
C) Examine existing system use
D) Create a prototype
> Entails roughing out a system for users to critique.
> When they see something on a screen, its easier to identify what they like and dont
like.
> Goes through iterations of improving and reviewing with users until users agree on
their needs.
Documentation and Approval of User Requirements
Detailed requirements for the new AIS should be created and documented.
> How to produce the required features is determined during the design phases of the
SDLC
> The requirements list should be supported by sample input and output forms and charts
that make it easier to conceptualize
5. Systems analysis report- is the conclusion of the system analysis phase. It is used to
summarize and document the analysis activities and serve as a repository of data from which
system designers can draw. The outlines include:
> Goals and objectives of the new system.
> Scope of the project.
> How the new system fits into the companys master plan.
> User processing requirements and information needs.

> Feasibility analysis.

> Recommendations for the new system.
A go-no-go decision is generally made three times during system analysis:
> During the initial investigation- to determine whether to conduct a feasibility survey
> At the end of the feasibility study- whether to proceed to the information requirements
phase
> Upon completion of the analysis phase- to decide whether to proceed to the next phase.
Requirements determination tries to collect information on what system should do from many
sources like users, reports, forms, etc. Characteristics for gathering requirements are:
1. Impertinence question everything
2. Impartiality find the best organizational solution and dont try to justify the
importance of your suggestions at any cost.
3. Relaxation of constraints--assume that any thing is possible
4. Attention to detaildue consideration should be given to facts (information)
5. Reframinganalysis is a creative process. Try to address situations in a new way.
Dont jump to conclusions thinking you have done the same thing before
Deliverables of system analysis include:
Information collected from users
> Interview results
> Questionnaire summaries
> Notes from observations, etc.
Existing documents and files
> Mission and strategy statements
> Forms and reports
> Procedure manuals
> Job descriptions, etc
Understanding of organizational components
> Business objectives
> Information needs
> Rules of data processing
> Key events
Phase-2: Conceptual System Design

During conceptual design, the company decides how to meet user needs. The first task it to identify
and evaluate appropriate design alternatives. There are many different ways to obtain a new
system, including buying software, developing it in-house, or out-sourcing the system to someone
else. Detailed specifications outlining what the system is to accomplish and how it is to be
controlled must be developed. This phase is complete when conceptual design requirements are
communicated to the information systems steering committee.
In the conceptual systems design phase, a general framework is developed for implementing user
requirements and solving problems identified in the analysis phase. What are the three steps in
conceptual design?
> Identify and Evaluate design alternatives
> Develop design specifications

> Deliver conceptual Prepare conceptual systems design report
The system analysis phase is related to the conceptual design phase based on the diagram shown
below:
Systems
Conceptual
Systems Analysis
Design
Evaluate Design Prepare Design Prepare

Alternatives Specifications Conceptual Systems Design
Physical Design
Implementation and
Conversion
1. Evaluate design alternatives

There are many design decisions that must be made. For example:
> Should a document be hard-copy or sent by EDI?
> Should the company use a large centralized mainframe or some form of distributed
processing?
> What form should data entry take, e.g., keyboard, optical character recognition, POS
devices?
There are many ways to approach the systems development process:
> Packaged software
> In-house development
> End-user development
> Outsourcing
The company also chooses between:
> Modifying or enhancing existing software
> Replacing existing software
> Reengineering its business processes
The design team should identify and evaluate design alternatives using the following criteria:
> How well it meets organizational and system objectives
> How well it meets users needs
> Whether it is economically feasible
> Its advantages and disadvantages
Design considerations and alternatives:

> How should the communications channel be configured?
> What type of communications channel should be used?

0
> What type of communications network should be used?

> What type of storage media should be used for data? Diskette, Hard drive, and CD, and Paper
> What type of data storage structure should be used? Files or Database
> How should files be organized and accessed? Random, Sequential, or Indexed-Sequential
> What media should be used to input data? Keying, OCR, MICR, POS, EDI, and Voice
> What format will the input take? Source documents, Turnaround documents, and/or Screen
> How will the system be operated? In-house and/or Outsourcing
> How frequently will outputs be produced? Instantly, Hourly, Daily, Weekly, and/or Monthly
> What media will be used for output? Paper, Screen, Voice, Diskette, CD, and/or Microfilm
> How will output be scheduled? On demand and/or at predetermined times
> What format will the output take? Narrative, Table, Graph, and/or Electronic file
> What processing mode will be used? Manual, Batch, and/or Real time
> What type of processor will be utilized? PC, Minicomputer, and/or Mainframe
2. Prepare design specifications
Once a design alternative has been selected, the team develops the conceptual design
specifications for the following elements:
> Output since the system is designed to meet users information needs, output
specifications must be prepared first. The following must be decided at this step:
How often to produce a report? What the report should contain? What the report
will look like? And what format of the report users require?
> Data storage this involves determining which data elements must be stored to
produce a report.
> Input involves determining which data elements to capture and enter into the system
> Processing procedures and operations involves designing how to process the input
and stored data in order to produce different reports
3. Prepare conceptual systems design report
At the end of the conceptual design, a conceptual systems design report is developed and
submitted:
> To guide physical systems design activities
> To communicate how management and user information needs will be met
> To help assess systems feasibility
The main component is a description of one or more recommended system designs. This
description contains:
> The contents of each output, database, and input
> Processing flows and the relationships among programs, files, inputs, and outputs
> Hardware, software, and resource requirements
> Audit, control, and security processes and procedures
> A discussion of assumptions or unresolved problems that might affect the final
design
Phase-3: Physical Systems Design

During the physical systems design phase, the company determines how the conceptual AIS design
is to be implemented. Physical design translates the broad, user-oriented requirements of the
conceptual design into detailed specifications that are used to code and test the computer

1
programs. Input and output documents are designed, computer programs are written, files and
databases are created, procedures are developed, and controls are built into the new system. This
phase is complete when physical system design results are communicated to the information
systems steering committee.
System design is the evaluation of alternative solutions and the specification and construction of a
detailed computer based solution. It is also called physical design as it deals with implementation
issues. Systems analysis depends more on the logical aspect and implementation-independent
aspects of a system. Systems design concentrates on the physical or implementation-dependent
aspects of a system (the systems technical specifications). The above activities will come as a
series of steps as shown by the diagram below:
Systems Analysis
Physical Systems Conceptual Systems Design

Design
Output File and Input Programs Procedures Controls Design

Design Database Design Design Design Design Report
Design
1. Output Design
The objective of output design is to determine the characteristics of reports, documents, and
screen displays. It requires cooperation between users and designers.
Important output design considerations include:
> Use of the output - Who will use it and why? When is it needed? What decisions will it
facilitate?
> Output medium Paper, Screen, Voice response, Diskette, Microfilm, Other
> Output format - the format that clearly conveys the most important information should
selected (E.g. it could be Table, Narrative, and Graphic)
> Pre-printed Should paper output be on preprinted form? Should turnaround document
be used?
> Location Where should AIS output be sent?
> Access - Who should have access to hard-copy and screen output?
> Detail Length of the output, executive summary, a table of contents, headings and
legends, highlight of important items, detailed information, appendix, etc
> Timeliness How often should the output be produced?
Output fits into one of four categories:

2
> Scheduled reports - have pre-specified content and format. They are prepared on a
regular basis. Examples: Weekly sales analysis, and Monthly financial statements
> Special-purpose analysis No pre-specified content and format. Typically prepared in
response to a management request
> Triggered exception reports have pre-specified content and format. They are
prepared only in response to abnormal conditions, i.e., the trigger.
> Demand reports Have pre-specified content and format and they are prepared only
on request.
AIS developers prepare sample outputs and users evaluate them to ensure they are complete,
relevant, and useful. Modifications are made as needed to ensure acceptability. Many organizations
require users to sign off on these documents before proceeding through the SDLC.
2. File and Database Design
Various company segments need to store data in compatible formats so that data can be shared
across units. Important file and database design considerations include:
> Storage medium Hard drive, Disk, Diskette, CD, Tape, Paper
> Processing mode Manual, Batch, Real time
> Maintenance procedures needed to effectively maintain the data
> Size How many records and how big are they? How fast are they expected to
grow?
> Activity level portion of records added or deleted or updated each year
3. Input Design
Systems designers must identify the different types of data input and optimal input methods.
There are two principal types of data input:
Forms
Computer screens
Considerations in input design include:
> Input medium Keyboard, OCR, MICR, POS terminal, EDI, Voice input
> Input source - data may originate from computer, customer, and remote location
> Input format turnaround document, screen, and source data automation
> Input type - the nature of the data
> Volume how much data are to be entered
> Personnel functions and expertise of the data entry operators
> Frequency - how often is data to be entered?
> Cost How can costs be minimized without adversely affecting efficiency and accuracy?
> Error detection and correction What errors are possible? How can they be detected and
corrected?
Forms Design
Although input is evolving toward source data automation, forms design is still important.
Following are important principles for designing new forms and evaluating existing ones:
General considerations in Forms Design
> Preprint as much data as possible.
> Use appropriate weight and grade of paper.
> Use bold type, double-thick lines, and shading to highlight different parts of the form.

3
> Use a standard size and one that is consistent with requirements for filing, binding, or
mailing.
> If mailed to external parties, position the address for placement in a window envelope.
> Have copies of the form printed in different colors to facilitate accurate distribution.
> Include clear instructions for completing the form.
Introductory section of Forms
> Place the form name at the top in bold type.
> Have the forms pre-numbered consecutively.
> If distributed to external parties, have company name and address pre-printed on the form
Main body of Forms
> Group together logically related information (e.g., info about the customer, info about the
product)
> Provide sufficient room to record each item.
> Order the data items consistent with the sequence in which the data is likely to be
gathered.
> Use codes and check-offs in places where standardized explanations are likely.
Conclusion section of Forms
> Provide space for recording final disposition of the form; approval signatures; dates of
approval and final disposition; and a dollar or numeric total.
> Clearly indicate the distribution of each form.
Designing Computer Screens
It is more efficient to enter data directly into the computer than to record it on paper for subsequent
entry. Therefore, its important to design computer screens for input as well as output.
Computer screens are most effective when the following principles are used:
> Organize the screen for quick, accurate, and complete entry of the data.
> Enter data in the same order it appears on the document.
> Complete the screen from left to right and top to bottom, grouping logically related data
together.
> Design the screen so users can jump from one data entry location to another or use a
single key to go directly to screen locations.
> Make it easy to correct mistakes.
> Avoid clutter by restricting the amount of data on one screen.
4. Program Design
Program development is one of the most time-consuming activities in the SDLC. A structured
programming process should be followed:
> With structured programming, programs should be subdivided into small, well-defined
modules to reduce complexity and enhance reliability and modifiability.
> Modules should interact with a control module rather than with each other.
> To facilitate testing and modification, each module should have only one entry and exit
point.
To improve software quality, organizations should develop programming standards (rules for
writing programs).

4
> Contributes to consistency among programs.

> Makes them easier to read and maintain.
Doing structured program walk-throughs to find incorrect logic, errors, omissions, or other
problems is essential. Program preparation time may range from a few days to a few years,
depending on complexity. Though accountants need not be programmers, they should understand
how software is created.
The eight steps for developing software and where these steps take place in the SDLC.
> Step One: determine user needs. It occurs during the systems analysis stage of the SDLC.
> Step Two: develop and document a plan. It occurs during the conceptual system design
phase and the beginning of physical system design.
> Step Three: write the program code. It begun during physical systems design and completed
during systems implementation and conversion
> Step Four: Test the program code. Debugging and Desk checking. It occurs during physical
systems design and systems implementation and conversion
> Step Five: Document the program. Documentation explains how programs work and helps
correct and resolve errors. Includes flowcharts, record layouts, E-R diagrams, REA data
models, narrative descriptions of the system, etc., organized in a manual. It mostly occurs
during system implementation and conversion.
> Step Six: Train program users. It occurs during system implementation and conversion
> Step Seven: Install the system. It occurs during system implementation and conversion
> Step Eight: Use and modify the system
5. Procedures Design
Individuals who interact with a newly-designed AIS should follow procedures that answer the
who, what, where, and how questions related to all AIS activities. Procedures design cover:
> Input preparation
> Transaction processing
> Error detection and corrections
> Controls
> Reconciliation of balances
> Database access
> Output preparation and distribution
> Computer operator instructions
Procedures may take the form of:
> System manuals
> User instruction classes
> Training materials
> Online help screens
The procedures may be written by development teams; Users; or teams representing both groups
6. Control Design
> Improperly controlled input, processing, and database functions produce information of
questionable value. Controls must be built into AIS to ensure its effectiveness, efficiency,
and accuracy.
> These controls should minimize errors and detect and correct errors when they do occur

5
> Accountants play a vital role in this area
Important control design concerns that must be addressed include:

> Validity Are all interactions valid?
> Authorization Are input, processing, storage, and output activities authorized by the
appropriate managers?
> Accuracy Is input verified to ensure accuracy? What controls ensure that data is not lost
when passing between processing activities?
> Security Is the system protected against unauthorized physical and logical access to prevent
improper use, alteration, destruction, or disclosure of information and software? Is the system
protected against theft of system resources?
> Numerical Control Are documents pre-numbered to prevent errors or intentional misuse
and to detect when documents are missing or stolen?
> Availability Is the system available as set forth in agreements? Can users enter, update,
and retrieve data during those times?
> Maintainability Can the system be modified without affecting system availability,
security, and integrity?
> Integrity Is processing complete, accurate, timely, and authorized? Is it free from
unauthorized or inadvertent manipulations?
> Audit Trial Can data be traced from source to output and vice versa?
7. Physical Systems Design Report
At the end of the physical system design phase, the team prepares a physical systems design report.
This report becomes the basis for managements decision whether to proceed to the
implementation phase.
Phase-4: Implementation and Conversion

The implementation and conversion phase is the capstone phase during which all the elements and
activities of the system come together. Because of this phases complexity and importance, an
implementation and conversion plan is developed and followed. As part of implementation, any
new hardware or software is installed and tested. New employees may need to be hired and trained,
or existing employees relocated. New processing procedures must be tested and perhaps modified.
Standards and controls for the new system must be established and system documentation
completed. The organization must convert to the new system and dismantle the old one. After the
system is up and running, any fine-tuning adjustments needed are made and a post implementation
review is conducted to detect and correct any design deficiencies. The final step in this phase is to
deliver the operational system to the organization, at which time the development of the new
system is complete. A final report is prepared and sent to the information systems steering
committee.
Systems implementation is the process of installing hardware and software and getting the AIS up
and running. Implementation and Conversion includes the following activities.
> Develop Implementation plan
> Prepare site and Install hardware and software
> Select and Train personnel, test the system
> Complete documentation
> Convert from old to new system Fine-tune and review

6
> Deliver operational system

The relationship of the items in this phase and the conversion process will be as shown below in
a series of activities.
Systems Analysis
Conceptual Systems Design
Implementation
and Conversion Physical Systems Design
Prepare Site; Install Complete

and Test SW & HW Documentation
Implementation Conversion
Planning
Select and Train Test System
Ppersoannel
1. Implementation Planning
> An implementation plan consists of implementation tasks, expected completion dates,
cost estimates, and the person or persons responsible for each task.
> The plan specifies when the project should be complete and operational.
> The implementation team should identify risk factors that decrease the likelihood of
successful implementation, and the plan should contain a strategy for coping with each of
the risks.
> AIS changes may require adjustments to the companys organizational structure, including:
Creation of new departments; Elimination or downsizing of existing departments; and
Changes even in the data processing department.
2. Prepare Site and Install and Test Software & Hardware
Site Preparation
Site preparation is a lengthy process and should begin well ahead of the installation date. A PC
requires little site preparation. A large computer may require changes such as:
> New electrical outlets
> Data communications facilities
> Raised floors
> Humidity controls
> Special lighting
> Air-conditioning
> Security measures, such as Fire protection and Emergency power supply
> Space for equipment, storage, and offices
Develop and Test Software Programs

7
Seven steps are followed when developing and testing software programs.
> Determine user needs
> Develop a plan.
> Write program instructions (code)
> Test the program.
> Document the program.
> Train program users.
> Install and use the system.
3. Select and Train Personnel
> Employees can be hired from outside the company or transferred internally
> Effective AIS training should include employees orientation to new policies and
operations
> Training should occur before systems testing and conversion
> When training is insufficient, the company will not achieve the expected return on
investment
> The hidden cost is that users will turn to their coworkers who have mastered the
system for help. Results in Less productive coworkers; and Increased costs
> Effective training includes: hardware and software skills, and orientation to new
policies and operations
Types of training include technical training from vendors; Self-study manuals; Computer-aided
instruction; Videotape presentations; Role-playing; Case studies; and Experimenting with the AIS
under the guidance of experienced users
4. Complete Documentation
Three types of documentation must be prepared for new systems.
> Development documentation it describes the AIS and includes a system
description; Copies of output, input, file, and database layouts; Program flowcharts;
Test results; and User acceptance forms
> Operations documentation includes operating schedules; files and databases
accessed; and equipment, security, and file retention requirements
> User documentation this teaches users how to operate the AIS and includes a
procedures manual and training materials.
5. Test the System
Inadequate system testing has contributed to the failure of systems. All of the following should be
given a trial run in realistic circumstances documents and reports, user input, operating and control
procedures, processing procedures, and computer programs. Capacity limits and Backup and
recovery procedures should also be tested. There are three common forms of testing.
A) Walk-throughs is step-by-step reviews of procedures or program logic. It focuses on
organizations input, files, outputs, data flows. Subsequently walk-throughs are made by
programmers addressing logical and structural aspects of program code.
B) Processing of test transactions determines whether the program operates as designed. It
requires both valid and erroneous data. The correct response for each test should be specified
in advance.
C) Acceptance tests uses copies of real transactions and files rather than hypothetical ones.
Users develop acceptance criteria and then make final decision whether to accept or not.

8
Even software purchased from an outside vendor must be tested thoroughly before
installation.
6. Systems Conversion
Conversion is the process of changing from the old AIS to the new. Many elements must be
converted, including hardware, software, data files, and procedures. The process is complete when
the new AIS has become a routine, ongoing part of the system.
System Conversion
Four conversion approaches are used to change from an old to a new system:
> Direct conversion
> Parallel conversion
> Phase-in conversion
> Pilot conversion
A) Direct Conversion Method

Immediately terminates the old AIS when the new one is introduced. Appropriate when the old
AIS has no value; or the new AIS is so different that comparisons between the two are meaningless.
Old System
New System
Advantage direct conversion is inexpensive
Disadvantage It provides no backup AIS. There is a high risk of failure unless the new system
has been very carefully developed and tested.
B) Parallel Conversion Method
This method operates the old and new systems simultaneously for a period of time. You can
process transactions with both systems, compare output, reconcile differences, and make
corrections to the new AIS.
Old System New System
> Advantage it protects the company from errors

> Disadvantage It is costly and stressful for employees to process all transactions twice.
> Because companies often experience problems during conversion, parallel processing has
gained widespread popularity.
C) Phase-in Conversion Method
Gradually replaces elements of the old AIS with the new one. The new system is often phased in
a module at a time.
> Advantage data processing resources can be acquired over time.
> Disadvantages Costs of creating temporary interfaces between old and new AIS. Large
time required to make the complete conversion.
Old System New system
D) Pilot
Conversion Method

9
This method implements a system in just one part of the organization, e.g., a branch office or a
single store. When problems with the system are resolved, the new system could be implemented
at the remaining locations.
> Advantages localizes conversion problems and allows training in a live environment.
> Disadvantages long conversion time and need for interfaces between old and new systems.
1 2 3 1 2 3
Old Old Old Old Old New
1 2 3 1 2 3
Old New New New New New
Data Conversion
> Data conversion can be time-consuming, tedious, and expensive
> The difficulty and magnitude can be easily underestimated.
> Data files may need to be modified in three ways:
Files may be moved to a different storage medium (e.g., tape to disk).
Data content may be changed (e.g., fields added or deleted).
A file or database format may be changed.
Steps in the data conversion process:
> Decide which data files need to be converted.
> Check files for completeness and data inaccuracies, and remove any inconsistencies.
> Do the actual data conversion.
> Validate the new files to ensure data were not lost during conversion.
> If the file conversion is lengthy, update the new files with transactions that occurred during
data conversion.
> After conversion and testing, monitor the system to make sure it runs smoothly and
accurately.
> Document the conversion activities
Phase-5: Operations and maintenance

The last step in the SDLC is to operate and maintain the new system. During its life, the system is
periodically reviewed. Modifications are made as problem arise or as new needs become evident,
and the organization uses the improved system. This process is referred to as the operations and
maintenance phase. Eventually a major modification or system replacement is necessary and the
SDLC begins again.
What are some factors to consider during the post implementation review?
> Goals and objectives Does the system help the organization meet its goals, objectives,
and overall mission?
> Satisfaction Are users satisfied? Do they want changes or improvements?
> Benefits Were the expected benefits achieved?
> Costs Are actual costs in line with expected costs?
> Reliability Has the system failed, and if so, why?
> Documentation Is documentation complete and accurate?
> Timeliness Does the system produce timely information?

0
> Controls and security Are there safeguards against unintentional errors, fraud, and
intrusion?
> Errors Are there adequate error-handling procedures?
> Training Are systems personnel and users adequately trained?
> Communications Is the communications system adequate?
> Organizational changes Are structural changes that resulted from the system beneficial or
harmful? If harmful, how can they be resolved?
> Accuracy Does the system produce accurate and complete data?
> Compatibility Are hardware, software, data, and procedures compatible with existing
systems?
Any problems discovered during the review should be brought to managements attention, and
adjustments should be made. When the review is complete, a post-implementation review report
is prepared. User acceptance of that report is the final activity in systems development. Control of
the AIS is then passed to the data processing department.
4.3) AIS Development Strategies

Companies can experience a number of difficulties in developing an AIS, including:
> Projects are backlogged for years because of the high demand for resources.
> The newly designed system doesnt meet user needs.
> The process takes so long that by the time its complete, its obsolete.
> Users cant adequately specify their needs.
> Changes to the AIS are often difficult to make after requirements have been written into
the specifications.
A new accounting information system can be obtained by:
> Purchasing prewritten software;
> Developing software in-house; or
> Outsourcing
The system development process can be hastened or improved through:

> Business process reengineering
> Prototyping
> Computer-aided software engineering (CASE) tools
1) Purchase Software
In the early days of computers, companies were rarely able to buy software that could meet their
needs. But commercially available packages are now outpacing custom-developed software as the
software industry is becoming matured.
Canned software is sold on the open market to a broad range of users with similar requirements.
Some companies sell hardware and software together as a package. These systems are called
turnkey systems, because the vendor installs the entire system and the user needs only to turn
the key. Many turnkey systems are written by vendors who specialize in a particular industry.
A major problem with canned software:
> It often does not meet all of a companys information needs.
> Unauthorized modifications may render the program unreliable and unstable.

1
The Internet has given companies a new way to acquire software. Companies can also acquire
software from Application Service Providers (ASPs) who host web-based software on their
computers and deliver the software to their clients over the internet.
Advantages of ASPs:
> Reduction of software costs and administrative overhead
> Automated software upgrades
> Scalability as the business grows
> Global access to information
> Access to skilled IT personnel
> Ability to focus on core financial competencies rather than IT
Purchasing Software and the SDLC

Companies that buy rather than develop software still follow the SDLC process, including:
1. Systems analysis companies must conduct an initial investigation, systems survey, and
feasibility study and they must also determining AIS requirements.
2. Conceptual design An important aspect is determining whether software that meets AIS
requirements is already available. If so, a make-or-buy decision must be made.
3. Physical design - if software is purchased, program design and coding can be omitted. But
software modifications may be needed. Companies also may design inputs, outputs, files,
and control procedures.
4. Implementation and conversion these activities must still take place: selecting and
training personnel, installing and testing hardware and software, documenting procedures,
and converting from old to new AIS. However, the software modules do not have to be
developed and tested. And the computer programs do not need to be documented.
5. Operation and maintenance The AIS is operated like any other software. The vendor
usually maintains the software.
The Systems Acquisition Process
Yes

2
Selecting a Vendor
Deciding whether to make or buy software can be made independently of the decision to acquire
hardware, service, maintenance, and other AIS resources. And the preceding resources can be
bought independently of the software. But hardware and vendor decisions may depend on the
software decisions.
Acquiring Hardware and Software
Once AIS requirements have been defined, the organization can buy software and hardware.
Companies needing only a PC and some office software can usually complete their own research
and make a selection. When buying large or complex systems, a request for proposal (RFP)
should be prepared:
> The RFP is an invitation to bidders to propose a system by a specific date.
> Each proposal is evaluated
> Finalists are investigated in depth.
The formal approach to acquiring system resources, such as an RFP, is important for
several reasons:
> Saves time
> Simplifies the decision-making process
> Reduces errors
> Avoids potential for disagreement
Evaluating Proposals and Selecting a System

Eliminate any proposals that are missing important information; fail to meet minimum
requirements; and are ambiguous. Those that pass the preliminary screening should be compared
with the proposed AIS requirements to determine if they meet all mandatory requirements; and
how many desirable requirements they meet. Finalists can be invited to demo their system using
company-supplied data. In reviewing the proposals, you need to evaluate: (1) Hardware, (2)
Software, (3) Vendors
Criteria to evaluate Hardware include:
Cost; Ability to run required software; Processing speed and capabilities; Secondary storage
capability; Input and output speeds; Communication capabilities; Expandability; Recency of
technology; Availability; Compatibility with existing hardware, software, and peripherals;
Performance compared to competitors; Cost and availability of support and maintenance;
Warrantees and guarantees; Financing arrangements; & Ability to meet mandatory requirements
Criteria to evaluate Software include:
Conformity with specifications; Need for modification; Performance (speed, accuracy, reliability);
Use by other companies; Satisfaction of other users; Documentation; Compatibility with existing
software; User-friendliness; Ability to be demonstrated and test-driven; Warranties; Flexibility and
maintainability; Capability for online inquiry of files and records; & Vendor upgrades
Criteria to evaluate Vendors include:
Size; Financial stability and security; Experience; Quality of support and warranties; Regularity of
updates; Ability to provide financing; Willingness to sign contract; Willingness to provide
references; Reputation for reliability and dependability; Hardware and software support and
maintenance; Implementation and installation support; Quality and responsiveness of personnel;
Willingness to provide training; and Responsiveness and timeliness of support

3
Approaches to comparing system performance:

> Benchmarking The AIS with the lowest time is judged most efficient after performing
a data processing task with input, processing, and output jobs.
> Point Scoring a weight is assigned to each criterion used to evaluate the system, based
on the relative importance of that criterion.
> Requirements Costing estimates cost of purchasing or developing features that are not
included in a particular AIS. The total cost is cost of system with all required features.
2) Development by In-House Information Systems Department

Despite the availability of good canned software, many organizations develop their own custom
software because their requirements are unique; or their size and complexity necessitates a custom
package. Developing custom software is difficult and error prone and consumes much time and
resources.
The most difficult hurdles are lack of time; complexity of desired system; poor requirements and
systems planning; inadequate communication and cooperation between departments and users;
lack of qualified staff; poor senior executive support; custom
Custom software is usually developed and written in-house. Alternately, organizations may
engage an outside company to develop a package or assemble one from their inventory of
modules. These modules are adapted, combined, and organized to form a customized product that
meets specific requirements. When contracting with an outside organization, a company should
maintain control over the development process. The following guidelines are recommended:
> Carefully select a developer
> Sign a contract to clearly define responsibilities
> Plan and monitor each step
> Maintain effective and frequent communication
> Control all costs
Information systems consultants suggest that clients develop their own software only if it provides
a significant competitive advantage. If there is no significant competitive advantage, buy software
from an outside supplier. There is no pat answer to the make-or-buy decision.
End-User-Developed Software
End-user computing (EUC) is the hands-on development, use, and control of computer-based
information systems by users. With EUC, individuals use IT to meet their own IS needs rather than
rely on systems professionals. Factors contributing to EUC are increased computer literacy; easier-
to-use programming languages; inexpensive PCs; and a variety of powerful and inexpensive
software packages. Consequently, users have began developing their own systems to create and
store data, access and download company data, and share data and computer resources in networks.
EUC has altered the role of the IS staff.
End user development (EUD) happens when information users (e.g., managers, accountants,
auditors) develop their own applications using computer specialists as advisors. EUD is
inappropriate for complex systems, such as those that process a large number of transactions or
update database records. Therefore, it is not used for large-scale processing, such as payroll,
receivables, payables, general ledger, or inventory.

4
End user development may be most appropriate for:

> Retrieving information from company databases to produce simple reports or to answer
one-time queries
> Performing what if sensitivity or statistical analyses
> Developing applications using prewritten software (spreadsheet or database system)
> Preparing schedules and lists, such as depreciation schedules, accounts receivable aging,
and loan amortizations
Benefits of End-User Computing

> User creation, control, and implementation
> Systems that meet user needs
> Timeliness it took less resources and time to complete
> Freeing up Information System resources
> Versatility and ease of use
> Versatility and ease of use easy to understand and use
Risks of End-User Computing
> Logic and development errors
> Inadequately tested applications
> Inefficient systems
> Poorly controlled and documented systems
> System incompatibilities
> Duplication of systems and data and wasted resources
> Increased costs
To achieve proper balance between maximizing the benefits of end user systems and minimizing
the risks systems analysts can act as advisers and require user-created systems to be reviewed
and documented prior to use. Users can be trained in systems analysis so they can identify and
adequately meet their needs, as well as reviewing the work of others.
Managing and Controlling End-User Computing
Organizations use several different approaches to mange and control end-user computing (EUC).
For example, a help desk can encourage, support, coordinate and control end-user activities.
What are some duties of the help desk?
> Providing hot-line assistance to help resolve problems
> Serving as a clearinghouse for information, coordination, and assistance training end
users, and providing corresponding technical maintenance and support
> Evaluating new end-user hardware and software products
> Assisting with application development
> Developing and implementing standards for hardware and software purchases;
documentation and application testing; and overseeing security
> Controlling corporate data
3) Outsource the System

Outsourcing is hiring an outside company to handle all or part of an organizations data processing
activities. In a mainframe outsourcing agreement, the outsourcers buy their clients computers and
hire all or most of the clients employees. Then operate and manage the entire system on the
clients site or migrate it to the outsourcers computers. Many of these contracts

5
have terms of 10 or more years and cost from hundreds of thousands to millions of dollars a year.
In a client/server or PC outsourcing agreement, an organization outsources a particular service, a
segment of its business, a particular function, or PC support. Examples of outsourced activities
include Installation, Training, Maintenance, Help desk, Technical support, etc
The Growth in Outsourcing Applications
Outsourcing was initially used for standardized applications such as payroll, accounting, and
purchasing. Also used by companies that were struggling to survive and wanted a quick cash
infusion from selling their hardware. Most companies that outsource use several different
companies rather than a single source in order to increase flexibility, foster competition, and reduce
costs. Most companies do not outsource strategic management of their IT environment; business
process management; and IT architecture
Benefits of Outsourcing
> A business and information solution allows companies to concentrate on their core
competencies.
> Asset utilization it improves cash position and reduce expenses by selling their
computers to an outsourcer.
> Access to greater expertise and more advanced technology
> Lower costs Outsourcing can reduce IS costs
> Improved development time
> Elimination of peaks and valleys usage
> Facilitation of downsizing
Risks of Outsourcing
> Inflexibility contract is difficult and/or costly to break
> Loss of control of system and/or data the company may lose control of its system and
data and confidential data may be shared with others
> Reduced competitive advantage
> Locked-in system it is expensive and difficult to reverse outsourcing
> Unfulfilled goals outsourcing goals and benefits are never realized
> Possibility of poor service - poor service from their outsourcers
Improving and Accelerating the System Development Process

System Development Process can be hastened or improved through:
> Business Process Reengineering
> Prototyping
> Computer-Aided Software Engineering (CASE) Tools
1) Business Processes Reengineering (BPR)

Business process reengineering (BPR) is the analysis and redesign of business processes and
information systems to achieve significant performance improvements. It is the thorough analysis
and complete redesign of business process and information systems to achieve performance
improvements. It is a process that challenges traditional organizational values and cultures
associated with underperformance.
> BPR reduces a company to its essential business processes and focuses on why they are
done rather than on the details of how they are done.

6
> It completely reshapes organizational work practices and information flows to take
advantage of technological advancements.
> BPR simplifies the system; Makes it more effective; improves a companys quality and
service. BPR software has been developed to help automate many BPR tasks
The Principles of Reengineering
Michael Hammer has set forth several principles that help organizations successfully reengineer
business processes
1. Organize around outcomes, not tasks.
2. Require those who use the output to perform the process.
3. Require those who produce information to process it.
4. Centralize and disperse data.
5. Integrate parallel activities.
6. Empower workers, use built-in controls, and flatten the organization chart.
7. Capture data onceat its source.
Underlying reengineering is the efficient and effective use of the latest information
technology, e.g.:
> Radio- and satellite-based communications
> Powerful handheld computers
> Image processing that lets multiple users handle a document simultaneously.
> Active documents
Challenges Faced by Reengineering Efforts
What are some of the obstacles to reengineering efforts?
Tradition Success requires changes in culture and beliefs
Resistance change is always met with resistance and requires continual reassurance,
persuasion, and support.
> Time requirements two or more years are required to complete BPR
> Cost it is costly to thoroughly examine business processes
> Lack of management support managers are nervous about the big propaganda and
publicity few results syndrome.
> Risk risk of losing jobs for information system professionals if it is not successful
> Skepticism BPR is sometimes viewed as just the same picture in a different frame
> Retraining The necessary retraining costs time and dollars.
> Controls Cannot skip the inclusion of controls to ensure reliability and integrity
2) Prototyping
Prototyping is an approach to systems design in which a simplified working model of a system is
developed. The prototype (first draft) is built quickly at low cost and provided to users for
experimentation. Playing with the prototype allows users to determine what they do and do not
like. Developers modify the system in response to user comments and re-present it to them. The
iterative process continues until users are satisfied that the system meets their needs.
The basic premise is that its easier for people to express what they like or dislike than to imagine
what they want in a system. In another words, it helps to have a straw man to aim at. Even a simple
system that is not fully functional demonstrates features far better than graphics

7
and verbiage. Developers who use prototyping still go through the systems development life cycle.
But prototyping allows them to expedite some analysis and design. For example, prototyping
captures user needs and helps developers and users make many conceptual and physical design
decisions. Current practice leans heavily toward prototyping so that projects can be completed
quickly.
Steps in Developing a Prototype
Four steps are involved in developing a prototype:
> Step One: identify basic systems requirements
> Step Two: develop an initial prototype that meets the agreed upon requirements
> Step Three: repeated iterations users identify changes, developers make changes, and
the system is turned over to the user
> Step Four: Use the system approved by the users
An approved prototype is typically used in one of two ways. Half of the prototypes are turned into
fully functional systems referred to as operational prototypes. To make them operational, the
developer must add needed controls; improve operational efficiency; provide backup and recovery;
and integrate the prototype with the systems with which it interfaces. When its not practical to
modify the prototype to make a fully functional system, non-operational or throwaway prototypes
the SDLC is followed to develop the system, and the prototype is used a model.
When to Use Prototyping

Prototyping supports rather than replaces the SDLC. It is appropriate when:
> Users dont fully understand their needs, or the needs change rapidly
> System requirements are difficult to define
> System inputs and outputs are not known
> The task to be performed is unstructured or semi-structured
> Designers are uncertain about what technology to use
> The system is crucial and needed quickly
> The risk of developing the wrong system is high
> The users reactions to the new system are important development considerations
> Many design strategies must be tested
> The design staff has little experience developing this type of system or application
> The system will be used infrequently so that processing efficiency is not crucial
Good candidates for prototyping include:
> Decision support systems
> Executive information systems
> Expert systems
> Information retrieval systems
> Systems that involve experimentation and trial-and-error development
> Systems in which requirements evolve as the system is used
Advantages of Prototyping
> Better definition of user needs because of intensive end-user involvement.
> Higher user involvement and satisfaction
> Faster development time it may take days or weeks to get a prototype up

8
> Fewer errors errors are detected early because the users experiment with each version
> More opportunity for changes
> Less costly - Some of the cost of traditional systems can be reduced
Disadvantages of Prototyping
> Significant user time
> Less efficient use of system resources
> Incomplete systems development
> Inadequately tested and documented systems
> Negative behavioral reactions
> Never ending development
3) Computer-Aided Software Engineering (CASE) Tools
Computer-Aided Software Engineering (CASE) tools are an integrated package of computer-
based tools that automate important aspects of the software development process. CASE tools are
used to plan, analyze, design, program, and maintain an information system. They are also used to
enhance efforts of managers, users, and programmers in understanding information needs. CASE
tools do not replace skilled designers, but provide developers with effective support for all SDLC
phases. CASE software typically includes tools for strategic planning; project and system
management; database design; screen and report layout; and automatic code generation
Advantages of CASE Technology

> Improved productivity can generate bug-free code from system specifications.
> Improved program quality can simplify enforcement of structured development
standards
> Cost savings cost savings of up to 80-90% are possible
> Improved control procedures
> Simplified documentation
Problems with CASE technology

> Incompatibility some tools dont interact effectively with some systems
> Cost - some packages very expensive to acquire
> Unmet expectations expected benefits may not be achieved

> What is the purpose of documentation?
> Why do accountants need to understand documentation?
> What documentation techniques are used in accounting systems?
> What are data flow diagrams and flowcharts?
> How are they alike and different?
> How are they prepared?
> What are the phases in the systems development life cycle?
> Who are the individuals involved in systems development?
> What techniques are used to plan the development of a system?
> How do you determine whether a particular system is feasible?

9
> How do people respond to systems changes, and how can dysfunctional behavior be
minimized?
> What are the activities that take place in the conceptual design phase of the systems
development life cycle (SDLC)?
> What activities take place in the physical systems design phase?
> What happens during the systems implementation and conversion process?
> What activities occur in the systems operation and maintenance process?
> How do organizations buy software, hardware, and vendor services?
> How do information systems departments develop custom software?
> How do end users develop, use and control computer-based information systems?
> Why do organizations outsource their information systems, and what are the benefits and
risks of doing so?
> How are prototypes used to develop an AIS, and what are the advantages and
disadvantages?
> What is computer-aided software engineering, and how is it used in systems
development?
Text Book:
Romney, Marshall B. and Paul, John Steinbart (2003), Accounting Information Systems, 9th
Edition, Prentice Hall, Inc., USA
References:
Nancy A. Bagranoff, Mark G. Simkin, and Carolyn N. Strand (2008), Core Concepts of
Accounting Information Systems, 10th Edition; John Wiley & Sons Publishers, Inc, USA
Wilkinson, Cerullo, Raval and Wong-On-Wing (2000), Accounting Information Systems, 4th
ED., John Wiley & Sons Publishers, Inc, USA
C. Janie Chang & Laura R. Ingraham (2007), Modeling and Designing Accounting Systems:
Using Access to Build a Database, 2nd Ed., John Wiley & Sons Publishers, Inc, USA

0

AIS Best Teaching Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AIS Best Teaching Material

Uploaded by

Copyright:

Available Formats

AIS AIS

Accounting Information System: An Overview

1.1) What Is an Accounting Information System?

What is Information System?

Major Types of Information Systems

EXAMPLES: regional sales analysis, production scheduling, cost analysis, pricing/profitability

5. Management Information Systems (MIS) Information system at the management level of

6. Executive Support Systems (ESS)

> Inputs: aggregate data; internal and external

Classification of Information Systems by Functional Areas

4. Software computer programs that assists in processing the organizations data

1.2) Why do we study an AIS? (Reasons for Studying AIS)

Information technology affects the companys choice of business strategy. IT is profoundly

1.3) Role of the AIS in the Value Chain

> Making it faster

How Can AIS Add Value to an Organization?

Supply Chain (Value System)

The Supply Chain can be expanded as follows:

Figure 1.4: Expanded Supply Chain

1.4) Data, Information and Decision Making

collected, recorded, stored, and processed by an Accounting Information System. Organizations

First the problem has to be identified.

Strategic Planning- concerns the establishing of organizational objectives and policies

1.5) AIS and Corporate Strategy

1. A Variety Based Strategic Position involves producing or providing a subset of the

Information Technology and Strategy

Role of the AIS in Business Strategy

End of Chapter Questions

2.1) Business Activities and Information Needs

> Some comes from internal sources

Business Cycles (Transaction Cycles)

Give Raw Get Finished

Human Resources/ Payroll Cycle

Give Cash Get Labor

Give Cash Get Cash

> Receive goods and services

Giv Get Giv Give

Figure 2.1: The AIS and its Subsystems

The Revenue Cycle:

> Provides funds to the financing cycle

2.2) Transaction Processing: Documents and Procedures

> How can a scheduled and unanticipated information needs be met?

Actions to improve accuracy and efficiency of data input (data capturing)

Page 5 Sales Journal

12/01/04 Salaries expense 900

Subsidiary Ledgers and General Ledgers

In general the data storage processes are as follows:

Computer-Based Storage Concepts

Customer Customer Address Credit Balance

4565 QRS Co. A.A; P.O.Box 741 25,000 24,900

4. Information output: Providing Information for Decision Making

2.3) Internal Control Considerations

aspects of a business transaction. Specially, the functions of authorizing transactions, recording

End of Chapter Questions:

> The Relational Databases

3.1) Database Systems

Files versus Databases

A set of interrelated, centrally coordinated files is referred to as a database. EXAMPLE:

Record 1: Record 2: Record 3: Record 1000:

Field 1: Field 2: Field 6:

This proliferation (increased in number) of master files created problems:

Sales Shipping Billing

Importance and Advantages of Database Systems

Logical and Physical Views of Data