Chapter Three

Systems Development and Documentation Techniques

Introduction
Documentation encompasses the narratives (written descriptions), flowcharts, diagrams, and other written
materials that explain how a system works. This information covers who, what, when, where, why, and how
of data entry, processing, storage, information output, and system controls.
Popular means of documenting a system include diagrams, flowcharts, tables, and other graphical
representations of information. These are supplemented by a narrative description of the system, a written
step-by-step explanation of system components and interactions.
• How do accountants use documentation?
– At a minimum, they have to read documentation to understand how a system works.
– They may need to evaluate the strengths and weaknesses of an entity’s internal controls.
• Requires heavy reliance on documentation.
– They may peruse documentation to determine if a proposed system meets the needs of its users.
– They may prepare documentation to:
• Demonstrate how a proposed system would work
• Demonstrate their understanding of a system of internal controls
In this chapter, we discuss two of the most common documentation tools:
1. Data flow diagrams (DFD), a graphical description of the sources and destinations of data that shows
data flow within an organization, the processes performed on the data, and how data are stored. They
show:
– Where data comes from
– How it flows
– The processes performed on it
– Where it goes
2. Flowcharts: which is a graphical description of a system. There are several types of flow charts,
It include three types:
a. Document flowchart, a graphical description of the flow of documents and information between
departments or areas of responsibility within an organization.
b. System flowchart, a graphical description of the relationship among the input, processing, and
output in an information system.
c. Program flowchart, a graphical description of the sequence of logical operations that a computer
performs as it executes a program.
Documentation techniques are necessary tools for accountants:
 Statements on Auditing Standards (SAS) 94, “The effect of information technology on the
auditor`s consideration of internal control in a financial statement audit,” requires that independent
auditors understand the automated and manual internal control procedures an entity uses. This
understanding can be gleaned through documenting the internal control system a process that
effectively exposes strengths and weaknesses of the system.
 SOX (2002) effectively requires that publicly-traded corporations and their auditors document and
test the company’s internal controls.
 Auditing Standard No. 2 promulgated by the Public Company Accounting Oversight Board
(PCAOB) requires that the external auditor express an opinion on the client’s system of internal
controls.

Page 1 of 22
Documentation tools help accountants by:
 Organizing very complicated systems into a form that can be more readily understood
 Helping new team members understand a pre-existing system
DATA FLOW DIAGRAMS
A data flow diagram (DFD) graphically describes the flow of data within an organization. It is used to
document existing systems and to plan and design new ones. There is no black-and-white approach to
developing a DFD. i.e., there is no ideal way to develop a DFD, because different problems call for different
methods.
Elements in a Data Flow Diagram
A data flow diagram composed of four basic elements:
– Data sources and destinations
– Data flows
– Transformation processes and
– Data stores
Each is represented on a DFD by one of the symbols:
Symbol Name Explanation
Data sources 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 of data between sources and destinations, processes,
and data stores is represented by curved or straight lines with
arrows.
Transformation The processes that transform data from inputs to outputs are
processes represented by circles. They are often referred to as bubbles.
Data stores The storage of data is represented by two horizontal lines.

These four symbols are combined to show how data are processed.
1. Data sources and destinations
A source or destination symbol on the DFD represents an organization or individual that sends or receives
data that the system uses or produces. Data sources and data destinations are represented by squares.
An entity/item can be both a source and a destination
2. Data flows
– Appear as arrows
– Represent the flow of data between sources and destinations, processes, and data stores.
3. Processes
 Appear as circles
 Represent the transformation of data
4. Data stores
 Appear as two horizontal lines
 Represent a temporary or permanent repository of data. DFDs do not show the physical storage
medium (such as disks and paper) used to store the data. As with the other DFDs elements, data
store names should be descriptive.
Page 2 of 22
Data dictionary:
– Data flows and data stores are typically collections of data elements.
– EXAMPLE: A data flow labeled student information might contain elements such as student name, date
of birth, ID number, address, phone number, and major.
– The data dictionary contains a description of all data elements, data stores, and data flows in a system.
Subdividing the DFD
DFDs are subdivided into successively lower levels to provide increasing amounts of detail, because few
systems can be fully diagrammed on one sheet of paper. Users have needs, so a variety of levels can better
satisfy these requirements.
The highest level DFD 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.
Guidelines for Drawing a DFD
• RULE 1: Understand the system: To understand how the system works, observe the flow of
information through an organization and interview the individuals who use and process the data.
• RULE 2: Ignore control processes and control actions (e.g., error corrections). Only very critical error
paths should be included.
• RULE 3: Determine the system boundaries—where it starts and stops. If you’re not sure about a
process, include it for the time being.
• RULE 4: Draw the context diagram first, and then draw successively greater levels of detail.
• RULE 5: Identify and label all data flows. The only ones that do not have to be labeled are those that
go into or come out of data stores.
• RULE 6: Data flows that always flow together should be grouped together. Those that do not flow
together should be shown on separate lines.
• RULE 7: Show a process (circle) wherever a data flow is converted from one form to another. Likewise,
every process should have at least one incoming data flow and at least one outgoing data flow.
• RULE 8: Transformation processes that are logically related or occur simultaneously can be grouped
in one bubble.
• RULE 9: Number each process sequentially. A process labeled 5.0 would be exploded at the next level
into processes numbered 5.1, 5.2, etc. A process labeled 5.2 would be exploded into 5.21, 5.22, etc.
• RULE 10: Process names should include action verbs, such as update, prepare, etc.
• RULE 11: Identify all files and 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.
• RULE 12: Identify and label all sources and destinations. An entity can be both a source and destination.
You may wish to include such items twice on the diagram, if needed, to avoid excessive or crossing
lines.
• RULE 13: As much as possible, organize the flow from top to bottom and left to right.
• RULE 14: You’re not likely to get it beautiful the first time, so plan to go through several iterations of
refinements.
• RULE 15: Prepare a final copy: Draw a final copy of the DFD. Do not allow data flow lines to cross
over each other; if necessary, repeat a data store or destination. Place the name of the DFD, the date
prepared, and the preparer’s name on each page.

Page 3 of 22
FLOWCHARTS
A flowchart is an analytical technique that describes some aspect of an information system in a clear, concise,
and logical manner.
A flowchart is a graphical representation of a system that describes the physical relationships between its
key entities. Flowcharts can be used to represent manual activities, computer processing activities, or both.
Flowcharts use a set of standard symbols to depict processing procedures and the flow of data.
Flowchart Symbols
Every shape on a flowchart depicts a unique operation, input, processing activity, or storage medium.
In the days of yore, flowcharts were commonly drawn with flowcharting template, a piece of hard, flexible
plastic on which the shapes of symbols have been die cut. Most flowcharts are now drawn using a software
program such as Visio, a drawing package based on the green plastic flowchart templates. Flowcharts can
also be drawn using Microsoft Word, Excel, and Power Point. The software uses pre-drawn shapes, and the
developer drags the shapes into the drawing.
There are four types of flowcharting symbols:
(1) Input/output symbols: represent devices or media that provide input to or records output from a
processing operations.
Symbol Name Explanation
Input/output symbols
Document Represents a document or report that is prepared by
hand or printed by a computer.
Multiple Copies of Indicates multiple copies of a paper document or
One Document report.
The document copies should be numbered in the
upper, right-hand corner.

Input/Output; Can represent any input or output function on a

Journal/Ledger program flowchart. Also used to represents
accounting journals or ledgers in a document
flowchart.
Represents information displayed by an online
Display output device such as a terminal, monitor, or screen.
Represents data entry by an online device such as a
Online keying terminal or personal computer.
Terminal or Combines the display and online keying symbols to
personal computer represent terminals and personal computers.

Page 4 of 22
(2) Processing symbols: either show what type of device is used to process data or indicate when processing
is performed manually.

Symbol Name Explanation

Processing Symbols
Computer Represents a computer-performed processing function;
processing usually results in a change in data or information.

Manual Represents a processing operation performed manually.

operation

Auxiliary Represents a processing function performed by a device

operation other than a computer, e.g., an optical character
scanner.
Represent an operation utilizing an off-line key
Off-line keying operation device (e.g., key to disk, cash register)

(3) Storage symbols: represent the device used to store data that the system is not currently using.
Symbol Name Explanation
Storage Symbols
Represents data stored permanently on a magnetic
Magnetic disk/drive. Frequently used to represent master files
disk/drive 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.

Represents data stored in a temporary online file in a

Online storage direct-access medium such as a magnetic disk.
File Represent file of documents manually stored and
retrieved; inscribed letter indicates file-ordering
N sequence N= numerically, A = alphabetically, D = by
date

(4) Flow and miscellaneous symbols: indicate the flow of data and goods. They also represent such
operations as where flowcharts begin or end, where decisions are made, and when to add explanatory
note to flowcharts.
Page 5 of 22
 Symbol Name Explanation
Flow and Miscellaneous Symbols
Document or Represents the direction of processing or
processing flow document flow; normal flow is top to bottom and
left to right.
Data/information Represents the direction of data/information flow;
flow often used to show data copied from one document
to another.

Communication Represents the transmission of data from one

link location to another via communication lines.

On-page connector Connects the processing flow on the same page; its
usage avoids crisscrossing a page.

Off-page Connects the processing flow between two

connector different pages. Signals the exit from one page and
the corresponding entrance on another page.
Represents the beginning, end, or point of
Terminal interruption in a process or program; also used to
indicate an external party.
Represents a decision-making step; used in a
Decision program flowchart to show branching to
alternative paths.

DOCUMENT FLOWCHARTS
A document flowchart illustrates the flow of documents and information among areas of responsibility
within an organization. A document flowchart is used to depict the elements of a manual system, including
accounting records (documents, journals, ledgers, and files), organizational departments involved in the
process, and activities (both clerical and physical) that are performed in the departments. Document
flowcharts trace a document from its cradle to its grave. They show where each document originates, its
distribution, the purpose for which it is used, its ultimate disposition, and everything that happens as it flows
through the system.
• Internal control flowcharts are document flowcharts used to evaluate the adequacy of internal
controls, such as segregation of duties or internal checks.
• They can reveal weaknesses or inefficiencies such as:
– Inadequate communication flows
– Unnecessarily complex document flows
– Procedures that cause wasteful delays
• Document flowcharts are also prepared in the system design process.

Page 6 of 22
GUIDELINES FOR PREPARING FLOWCHARTS
• Let’s step through some guidelines for preparing flowcharts:
1. Understand a system before flowcharting it. Interview users, developers, auditors, and management, or
have them complete a questionnaire. Read through a narrative description of the system, or walk through
systems transactions.
2. Identify the entities to be flowcharted, such as departments, job functions, or external parties (the parties
who “do” things in the story). Identify documents or information flows in the system, as well as the
activities or processes performed on the data. (For example, when reading a description of the system,
the preparer could draw a box around the entities, a circle around the documents, and a line under the
activities.)
3. Use separate columns for the activity of each entity.
• Example: If there are three different departments or functions that “do” things in the narrative,
there would be three columns on the flowchart.
4. Flowchart only the normal course of operations, and identify exceptions with annotations.
5. As much as possible, the flow should go from top to bottom and left to right.
6. Use the standard flowcharting symbols, and draw them with a template or a computer.
7. Clearly label all symbols. Write a description of the input, process, or output inside the symbol. If the
description will not fit, use the annotation symbol. Print neatly, rather than writing in cursive.
Use annotations if necessary to provide adequate explanation.
– Give the flowchart a clear beginning and ending.
– Show where each document originated and its final disposition.
– One approach you can use is to read through the narrative and for each step define:
– What was (were) the input(s)
– What process was carried out
– What was (were) the output(s)
– Note on the next slide that the flow sequence is input -- process – output.
– Every manual process should have at least one input and at least one output.
8. Show all data entered into or retrieved from a computer file as passing through a processing operation (a
computer program) first.
– Do not show process symbols for:
1. Forwarding a document to another entity
2. Filing a document
– Do not connect two documents except when forwarding to another column.
• When a document is forwarded, show it in both locations.
– When using multiple copies of a document, place document numbers in the upper, right-hand corner.
– Show on-page connectors and label them clearly to avoid excess flow lines.
– Use off-page connectors if the flow goes to another page.
– If a flowchart takes more than one page, label the pages as 1 of 5, 2 of 5, 3 of 5, etc.
– Show documents or reports first in the column where they are created.
Start with a rough draft; then Redesign the flowchart to avoid clutter and a large number of crossed lines.
Verify the flowchart`s accuracy by reviewing it with the people familiar with the system. Be sure all uses of
flowcharting conventions are consistent.
Draw a final copy of the flowchart. Place the name of the flowchart, the date, and the preparer’s name on
each page of the final copy.

Page 7 of 22
SYSTEM FLOWCHARTS
System flowchart depicts the relationship among the inputs, processes, and outputs of an AIS. System
flowcharts portray the computer aspects of a system. They depict the relationships between input (source)
data, transaction files, computer programs, master files, and output reports produced by the system. System
flowcharts also describe the type of media being used in the system, such as magnetic tape, magnetic disks,
and terminals.
A system flowchart begins by identifying the inputs that enter the system and their origins. The input can be
new data entering the system, data stored for future use, or both. The input is followed by the processing
portion of the flowchart, i.e., the steps performed on the data. The logic the computer use(s) to perform the
processing task is shown 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. In other words, it’s the same basic input – process – output pattern that we saw
in the document flowchart.

System flowcharts are an important system 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.

Figure Below Shown System Flowchart

Page 8 of 22
PROGRAM FLOWCHARTS
Program flowcharts illustrate the sequence of logical operations performed by a computer in executing a
program. A program flowchart describes the specific logic to perform a process shown on a system flowchart.
They also follow an input – process – output pattern. Once designed and approved, the program flowchart
serves as the blueprint for coding the computer program.
FLOWCHARTS versus DFDs
• Now that we’ve examined both flowcharts and DFDs, it may be useful to discuss the differences
again.
• DFDs place a heavy emphasis on the logical aspects of a system. Flowcharts place more emphasis
on the physical characteristics of the system.
• An example may be useful.
Page 9 of 22
For example, the registrar’s office of a small college receives paper enrollment forms from students. They
sort these records alphabetically and then update the student record file to show the new classes. They also
prepare class lists from the same data. The sorted enrollment forms are forwarded to the bursar’s office for
billing purposes. Class lists are mailed to faculty members.

Here’s a DFD that goes with the story.

Students
Enrollment
Forms

1.0 Update Student

Student Records
Records Enrollment
Forms
2.0 Prepare Bursar
Class Lists
Enrollment
Class Forms
Faculty Lists

Here’s a flowchart that goes with the story

Registrar’s Office

Enrollment Sort
Students Forms Forms

A Update Sorted
Student Enrollment
Forms
Records

Sorted
Prepare
Enrollment
Forms Class
Lists

Class Sorted
Lists Enrollment
Forms

Faculty Bursar

Page 10 of 22
Introduction to Systems Development and Systems Analysis
Because we live in a highly competitive and ever-changing world, 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
needed changes are so drastic that the old system is scrapped and replaced by an entirely new one.
Companies change their systems for one of the following reasons:
Changes in user or business needs: Increased competition, business growth or consolidation, mergers
and divestitures, new regulations, or changes in regional and global relationships can alter an
organization`s structure and purpose. To remain responsive to company needs, the system must change
as well.
Technology changes (i.e., to take advantage of or respond to technology changes): As technology
advances and becomes less costly, an organization can make use of the new capabilities or existing ones
that were previously too expensive.
Improved business processes (i.e., to accommodate improvements in their business process): Many
companies have inefficient business processes that require updating.
Competitive advantage (i.e., to gain a competitive advantage and/or lower costs): Increased quality,
quantity, and speed of information can result in an improved product or service and may help lower costs.
Productivity gains (i.e., to increase productivity): Computers automate clerical and repetitive tasks and
significantly decrease the performance time of other tasks. Information systems can also place specialized
knowledge at the disposal of many company employees.
To accommodate growth (Growth): Companies outgrow their systems and must either upgrade or
replace them entirely.
Downsizing (i.e., to accommodate downsizing or distribute decision making): Companies often move
from centralized mainframes to net-worked PCs or to Internet-based systems to place decision making
and its corresponding information as far down the organizational chart as possible.
Systems integration (i.e., to integrate incompatible systems): Organizations often have many adequate
and serviceable systems that are incompatible—that is, they do not communicate well with each other
because they were developed over many years using different technologies and data formats. These
systems often are rewritten to remove the incompatibilities and consolidate databases.
Systems age and need to be replaced (i.e., to replace a system that is aged and unstable): As systems
age and are repaired numerous times, they become less stable and eventually need to be replaced.
Developing quality, error-free software is a difficult, expensive, and time-consuming task. In fact, it is almost
always the case that software development projects deliver less than one expects and take more time and
money to develop than one expects. To make matters worse, most companies that want to implement a new
system want it immediately. As developers feel the pressure to perform system miracles, they begin skipping
systems development steps and just start writing code. Omitting basic systems development steps only leads
to disaster, as developers create well-structured systems that fail to meet user needs or solve any of their
business problems.
For example, a KPMG survey found that 35% of all major information systems projects were classified as
runaways hopelessly incomplete and over budget.
– Major cause of runaways: Skipping or skimping on systems development processes. Runaways can
consume a great deal of time and money and in the end produce no usable results.

Page 11 of 22
Systems Development
Whether systems changes are major or minor, most companies go through a systems development life cycle.
The steps in that cycle and the people involved in systems development are discussed in this section.
The Systems Development Life Cycle (SDLC)
The five stages in the systems development life cycle are:
1) System Analysis
2) Conceptual Design
3) Physical Design
4) Implementation and Conversation
5) Operations and Maintenance

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. When a new or improved system is needed, a written request for systems development is
prepared. The request describes:
 The current system’s problems.
 The reasons for the proposed changes.
 The proposed systems goals and objectives, as well as its anticipated benefits and costs.
The project development team conducts the analysis. The five steps in system analysis phases include:
(1) Initial investigation: Involves gathering the information needed to buy/purchase or develop a new
system and determining whether it is a priority. An initial investigation is conducted to screen projects.
The person conducting an initial investigation must:
 Gain a clear picture of the problem or need
 Determine the projects viability and expected costs and payoffs
 Evaluate the project`s scope and nature of the new AIS
 Recommend whether the development project should be initiated as proposed, modified, or
abandoned.
During the initial investigation, the exact nature of the problem(s) under review must be determined. In
some instances, what is thought to the cause of the problem is not the real source. For example, a government
accountant once asked a consultant to develop an AIS to produce the information he needed to fund
expenditures and available funds. Further investigation showed that the agency`s system already provided
the information. The accountant simply did not understand the reports he was receiving.
The project`s scope (what it should and should not seek to accomplish) also must be determined. A new
AIS is useful when problems are a result of lack of information, inaccessibility of data, and inefficient data
processing. However, a new AIS is not the answer to organizational problems, such as the controller
managing too many employees. Likewise, if a manager lacks organizational skills or if a failure to enforce
existing procedures causes control problems, a new AIS is not the answer.
If a project is approved, a proposal to conduct system analysis is prepared. It is assigned a priority and added
to the master plan, and the development team begins the survey of the existing AIS. As the investigation
progresses, the proposal will be modified as more information becomes available.
(2) Systems survey: During the systems survey, an extensive study of the current AIS is undertaken. This
survey may take weeks or months, depending on the complexity and scope of the system. The objectives
of a systems survey are as follows:

Page 12 of 22
  Gain a thorough understanding of company operations, policies, and procedures; data and
information flow; AIS strengths and weaknesses; and available hardware, software, and personnel.
 Make preliminary assessments of current and future processing needs, and determine the extent
and nature of 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 about the current AIS can be gathered internally from employees, as well as from documentation such
as organizational charts and procedures manuals. External sources include consultants, customers and
suppliers, industry associations, and government agencies.
Four common methods of gathering data are:
– Interviews
– Questionnaires
– Observation
– System documentation
(3) Feasibility study: Involves an in-depth study of the proposed system to determine whether it’s feasible.
At this point in systems analysis, a more thorough feasibility analysis is conducted to determine the
project`s viability. The feasibility analysis is updated regularly as the project proceeds and costs and
benefits become clearer.
A feasibility study (also called a business case) is prepared during the systems analysis and updated as
necessary during the remaining steps in the SDLC. The extent of these studies varies, depending on the size
and nature of the system. For example, the study for a large-scale system is generally quite extensive, whereas
one for a desktop system might be conducted informally. The feasibility team should include management,
accountants skilled in controls and auditing, systems personnel, and users.
At major decision points, the steering committee uses the study to decide whether to terminate a project,
proceed unconditionally, or proceed if specific problems are resolved. Although a project can be terminated
at any time, the early go/no-go decisions are particularly important as each subsequent SDLC step requires
more time and monetary commitments. As the project proceeds, the study is updated and the project`s
viability is reassessed. The further along a development project is, the less likely it is to be canceled if a
project feasibility study has been prepared and updated.
Five important aspects to be considered during a feasibility study are as follows:
1) Economic feasibility: Will system benefits justify the time, money, and other resources required to
implement it? (i.e., Will the benefits exceed the costs?)
2) Technical feasibility: Can the planned system be developed and implemented using existing
technology? (i.e., Is the technology there to do it?)
3) Legal feasibility: Does the system comply with all applicable federal and state laws and statutes,
administrative agency regulations, and the company`s contractual obligations?
4) Scheduling feasibility: Can the system be developed and implemented in the time allotted? If not, it
will have to be modified, postponed, or replaced by an alternative selection.
5) Operational feasibility: Do the organization have access to people who can design, implement, and
operate the proposed system? Can people use the system, and will they use it?
Economic feasibility is the most important and frequently analyzed of the five aspects.

Page 13 of 22
(4) Information Needs and Systems Requirements
Once a project is deemed feasible, the company identifies the information needs of AIS users and documents
systems requirements.
Systems objectives and constraints
Many organizations take a systems approach to determining information needs and systems requirements.
Problems and alternatives are viewed from the standpoint of the entire organization, rather than from any
single department or interest group.
It is important to determine system objectives so that analysts and users can focus on those elements most
vital to the AIS`s success, however, it is difficult for a system to satisfy every objective. For example,
designing adequate internal controls must be viewed as a trade-off between the objectives of economy and
reliability. Similarly, cutting clerical costs must balance the objectives of capacity, flexibility, and customer
service.
A system`s success often depends on the project team’s ability to cope with constraints the organization
faces. Common constraints include governmental agency requirements, managerial policies and guidelines,
lack of sufficiently qualified staff, the capabilities and attitudes of system users, available technology, and
limited financial resources.
To maximize system performance, the effects of these constraints on system design must be minimized.

Strategies for Determining Requirements:

One or more of the following four strategies are used to determine AIS requirements:
1. Ask users what they need: Though this is the simplest and fastest strategy, many people do not realize
or understand their true needs. Although they may know how to do their jobs, they may not be able to
break them down into the individual information elements they use. It is sometimes better to ask users
questions pertaining to what decisions they make and what processes they are involved in and then help
them design systems to address their answers. Users must think beyond their current information needs
so that new systems do not simply replicate the current information in new and improved formats.
2. Analyze existing systems: Both internal and external systems should be analyzed. A partial solution may
already exist, thus eliminating the problem of reinventing the wheel.
3. Examine existing system use: This strategy differs from the previous one by taking into account that
certain modules may not be used as intended, may be augmented by manual tasks, or may be avoided
altogether. This approach helps determine if a system can be modified or must be replaced.
4. Create a model: When it is difficult to identify a usable set of requirements, a developer can quickly
rough out a system for users to critique. Once users see something on the screen, they can begin to identify
what they like and dislike and request changes. This iterative process of looking at what is developed and
then improving it continues until users agree on their needs.
Documentation and approval of user requirements
Detailed requirements for the new AIS that explain exactly what the system must produce 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, as well as charts, to make it
easier for readers to conceptualize the system. A nontechnical summary that captures important user
requirements and development efforts to date is often prepared for management.
When user requirements have been determined and documented, the project team meets with users, explains
the requirements, and obtains their agreement and approval. When an agreement is reached, user
management should sign the appropriate system requirements documents to indicate approval.

Page 14 of 22
(5) Systems Analysis Report
System analysis is concluded by preparing a systems analysis report to summarize and document the
analysis activities and serve as a repository of data from which designers can draw. The reports show the
new system`s goals and objectives, the scope of the project and the new system, how the new system fits
into the company’s master plan, the user`s processing requirements and information needs, the
feasibility analysis, and recommendations for the new system. The project development team is
responsible for preparing a systems analysis report.
A go/no-go decision may be made up to three times during systems analysis:
 During the initial investigation, to determine whether to conduct a systems survey.
 At the end of the feasibility study, to determine whether to proceed to the information
requirements phase; and
 At the completions of the analysis phase, to decide whether to proceed to the next phase
(conceptual design).
After systems analysis is completed, the projects developed using the SDLC approach move to the conceptual
design phase and then to physical design, implementation and conversion, and operation and maintenance.

2) Conceptual design
During conceptual design, the company decides how to meet user needs. The first task is 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 outsourcing system development 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.
3) Physical 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 AIS requirements of conceptual design into
detailed specifications that are used by programmers to code and test the computer 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.
i. Output design: The objective of output design is to determine the nature, format, content, and timing
of printed reports, documents, and screen displays. Tailoring the output to user needs requires
cooperation between users and designers.
Outputs usually fit into one of the following four categories:
Scheduled reports: Have a pre-specified content and format and are prepared on a regular basis.
Examples include monthly performance reports, weekly sales analyses, and annual financial
statements.
Special-purpose analysis reports: Have no pre-specified content and format and are not on a regular
schedule. They are prepared in response to a management request to evaluate an issue, such as which
of three new products would provide the highest profits. Example: Analysis of impact of a
government mandate on profitability
Triggered exception reports: Have pre-specified content and format but are prepared only in
response to abnormal conditions. Excessive absenteeism, cost overruns, inventory shortages, and
situations requiring immediate corrective action trigger such reports.

Page 15 of 22
 Demand reports: Have a pre-specified content and format but are prepared only on request. Both
triggered exception reports and demand reports can be used effectively to facilitate the management
process.

ii. File and database design

iii. Input design
iv. Program design
v. Procedures design
vi. Controls design
4) Implementation and conversion
System implementation is the process of installing hardware and software and getting the AIS up and
running. This process generally consists of developing a plan, preparing the site, installing and testing
hardware and software, selecting and training personnel, completing the documentation, and testing the
system. Conversion is the process of changing from the old to the new AIS. Many elements must be
converted: hardware, software, data files, and procedures. The process is complete when the new AIS has
become a routine, ongoing part of the system.
Conversion Approaches
Four conversion approaches are used to change from an old to a new system:
• Direct conversion
• Parallel conversion
• Phase-in conversion
• Pilot conversion
Direct conversion immediately terminates the old AIS when the new one is introduced. Direct conversation
is appropriate when the old AIS has no value or the new one is so different that comparisons between the
two are meaningless. The approach is inexpensive, but it provides no backup AIS. Unless a system has been
carefully developed and tested, therefore, direct conversation carries a high risk of failure.

Parallel conversion 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.
Parallel processing protects the company from errors, but it is costly and stressful for employees to process
all transactions twice. However, because companies often experience problems during conversion, parallel
processing has gained widespread popularity.
Phase-in conversion gradually replaces elements of the old AIS with the new one.
– The new system is often phased in a module at a time.
These gradual changes mean that data processing resources can be acquired over time. The disadvantages
are the cost of creating the temporary interfaces between the old and the new AIS and the time required to
make the gradual changeover (complete conversion).
Pilot conversion implements a system in just one part of the organization, such as a branch office or a single
store. When problems with the system are resolved, the new system could be implemented at the remaining
locations. This approach localizes conversion problems and allows training in a live environment. The
disadvantages are the long conversion time and the need for interfaces between the old and the new systems,
which coexist until all locations have been converted.

Page 16 of 22
Implementation and conversation constitute the capstone phase during which all the elements and activities
of the system come together. Because of the complexity and importance of this phase, an implementation
and conversion plan is developed and followed. As part of implementation, any new hardware and 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.
5) Operation and maintenance
The final step in the SDLC is to operate and maintain the new system. Once the system is up and running,
operations and monitoring continue.
• Tasks include:
– Fine-tune/adjust and do post-implementation review.
– Operate the system.
– Periodically, review and modify the system.
– Do ongoing maintenance.
– Deliver improved system.
Eventually, a major modification or system replacement is necessary and the SDLC begins again.
In addition to these five phases, three activities (planning, managing the behavioral reactions to change,
and assessing the ongoing feasibility of the project) are performed throughout the life cycle.
THE PLAYERS
Many people are involved in developing and successfully implementing an AIS, including:
a) Top management: One of the most effective ways to generate systems development support is a clear
signal from top management that user involvement is important. With respect to systems development,
top management’s most important roles are:
 Providing support and encouragement for development projects and aligning information
systems with corporate strategies.
 Establishing system goals and objectives.
 Reviewing the performance and leadership of the information system department.
 Establishing policies for project selection and organizational structure.
 Participating in important system decisions.
• The principal roles of user management are:
 To determine information requirements for departmental projects.
 To assist systems analysts with project cost and benefit estimates.
 To assign key staff members to development projects.
 To allocate appropriate funds to support systems development and operation.
b) Accountants
Accountants may play three roles during systems design:
– First, as AIS users, they must determine their information needs and system requirements and
communicate them to system developers.
– Second, as members of a project development teams or information systems steering committee, they
help manage systems development.

Page 17 of 22
 – Third, accountants should take an active role in designing system controls and periodically monitoring
and testing the system to verify that the controls are implemented and functioning properly. All
systems should contain sufficient controls to ensure the accurate and complete processing of data. The
system also should be easy to audit. If addressed at the start of development, auditability and control
concerns can be minimized. Trying to achieve them after a system has been designed is inefficient,
time-consuming, and costly.
c) Information systems steering committee
Because AIS development spans functional and divisional boundaries, organizations usually establish an
executive-level information systems steering committee to plan and oversee the information system function.
The committee often consists of high-level management people, such as the controller and the systems and
user-department management. The steering committee sets policies that govern the AIS and ensures top-
management participation, guidance, and control. The steering committee also facilitates the coordination
and integration of information systems activities to increase goal congruence and reduce goal conflict.
d) Project development team
Each development project has a team of systems specialists, managers, accountants and auditors, and users
that guides development. Team members plan each project, monitor it to ensure timely and cost-effective
completion, make sure proper consideration is given to human element, and communicate project status to
top management and the steering committee. They should communicate frequently with users and hold
regular meetings to consider ideas and discuss progress so there are no surprises upon project completion. A
team approach usually produces more effective results and facilitates user acceptance of the implemented
system.
e) Systems analysts
Systems analysts study existing systems, design new ones, and prepare specifications that are used by
computer programmers. Analysts interact with information technology and systems employees throughout
the organization to successfully bridge the gap between the user and technology. Analysts are responsible
for ensuring that the system meets user needs.
f) Computer programmers
Computer programmers write the computer programs, using the specifications developed by the systems
analysts. They also modify and maintaining existing computer programs.
g) External players
Many people outside an organization play a role in systems development, including 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 such activity is planning.
The organization must have a long range plan. Each systems development project requires a plan, and each
phase of each systems development project must also be planned. This section discusses these plans and a
number of techniques to develop them.
Systems development planning is an important step for the following key reasons:
Consistency: Planning enables the system`s goals and objectives to correspond to the organization’s
overall strategic plan.
Efficiency: Systems are more efficient, subsystems are coordinated, and there is a sound basis for
selecting new applications for development.
Cutting edge: The company remains abreast of the ever preset-changes in information technology.

Page 18 of 22
 Lower costs: Duplication, wasted effort, and cost and time overruns are avoided. The system is less
costly and easier to maintain.
Adaptability: Management is better prepared for future resource needs, and employees are better
prepared for the changes that will occur.
When development efforts are poorly planned, a company must often return to a prior phase and correct
errors and design flaws. Such a process is costly and result in delays, frustration, and low morale.
Two types of systems development plans are needed: individual project plans developed by the project
teams and a master plan developed by the information systems steering committee.
1. Project development plan: The basic building block of information systems planning is the project
development plan. Each project development plan contains a cost-benefit analysis, developmental and
operational requirements (including human resources, hardware, software, and financial resources
requirements), and a schedule of the activities required to develop and operate the new application.
2. The master plan: A master plan a long-range planning document that specifies what the system will
consist of, how it will be developed, who will develop it, how needed resources will be acquired, and
where the AIS is headed. The master plan also should describe the status of projects in process, prioritize
planned projects, describe the criteria used for prioritization, and provide timetables for development.
The projects with the highest priority should be the first to be developed. The importance of this
decisions dictates that it be made by top management and not by computer specialists. A planning
horizon of approximately three years is reasonable, and the plan should be updated at least two to three
times a year. Many companies, because of the rapid and constant changes in IT, update the plan quarterly
or monthly.
It is important for the person fulfilling the role of the chief information officer to gauge how soon new
technologies will become widely used, whether the company should be an early or late adopter of the
technology, and to keep an eye out for business opportunities that arise from new technologies.

Planning Techniques
Two techniques for scheduling and monitoring systems development activities are:
 Program Evaluation and Review Technique (PERT) and
 The Gantt Chart
a. Program Evaluation and Review Technique (PERT)
A PERT diagram requires that all activities in a project be identified along with the activities that precede
and follow them. These activities and relationships are used to draw a PERT diagram, which consists of a
network of:
 Arrows—representing project activities that require an expenditure of time and resources.
 Nodes—representing completion and initiation of activities.
Completion time estimates are made, and the critical path—the path requiring the greatest amount of time—
is determined. If an activity on the critical path is delayed, then the whole project is delayed. If possible,
resources are shifted to critical path activities to reduce project completion time.
b. Gantt Charts
A Gantt chart is a bar chart with project activities listed on the left-hand side and units of time (days or
weeks) across the top. For each activity, a bar of expected time is drawn from the scheduled starting date to
the ending date, there by defining expected project completion time. As activities are completed, they are
recorded on the Gantt chart by filling in the bar; thus, at any time it is possible to determine quickly which
activities are on schedule and which are behind. The capacity to show, in graphical form, the entire schedule

Page 19 of 22
for a large, complex project, including progress to date and current status, is the primary advantage of the
Gantt chart. The charts do not show, however, the relationships among various project activities.
BEHAVIORAL ASPECTS OF CHANGE
Individuals participating in systems development are agents of change who are continually confronted by
people`s reactions and resistance to change. The behavioral aspects of change are crucial, because the best
system will fail without the support of the people it serves. Organizations must be sensitive to and consider
the feeling and reactions of persons affected by changes. They also should be aware of the type of behavioral
problems that can result from changes.
Why Behavioral Problems Occur
Individuals` views of change as good or bad will usually depend on how they are personally affected by it.
For example, management views change positively if it increases profits or performance or reduces costs.
Employees, on the other hand, will view the same change as bad if their jobs are terminated or adversely
affected.
– The Department of Defense with 3.3 million employees has faced tremendous resistance to change
in the course of over 20 years of system integration attempts.
– A more transparent system would likely expose personal agendas and a “project protection”
mindset.
To minimize adverse behavioral reactions, one must first understand why resistance occurs/ takes place.
Some of the more important factors include the following:
Personal characteristics and background: Generally speaking, the younger and more highly educated
people are, the more likely they are to accept change. Likewise, the more comfortable people are with
technology, the less likely they are to oppose changes in an AIS.
Manner in which change is introduced: Resistance is often a reaction to the methods of instituting
change rather than to the change itself. For example, the rationale used to sell the system to top
management may not be appropriate for lower-level employees. The elimination of mental tasks and the
ability to advance and grow are often more important to users than are increasing profits and reducing
costs.
Experience with prior changes: Employees who had a bad experience with prior changes are more
reluctant to cooperate when future changes occur.
Top management support: Employees who sense a lack of top-management support for a change wonder
why they themselves should endorse it.
Communication: Employees are unlikely to support a change unless the reasons behind it are explained.
Biases and natural resistance to change: People with emotional attachments to their duties or co-
workers may not want to change if those elements are affected.
Disruptive nature of the change process: Requests for information and interviews are distracting and
place additional burdens on people. These disturbances can create negative feelings toward the change
that prompted them to occur.
Fear: Many people fear the unknown and the uncertainty accompanying change. They also fear losing
their jobs, losing respect or status, failure, technology, and automation.
How people resist AIS changes
Behavioral problems may begin as soon as people find out that a system change is being considered. Initial
resistance is often subtle, manifested by tardiness, subpar performance, or failure to provide developers with
information. Major behavioral problems often occur after the new system has been implemented and the
change has become a reality.

Page 20 of 22
Major resistance often takes one of three forms: aggression, projection, or avoidance.
1. Aggression: Aggression is a behavior that is usually intended to destroy, cripple, or weaken the
system’s effectiveness. It may take the form of increased error rates, disruptions, or deliberate sabotage.
One organization introduced an online AIS only to discover soon thereafter that the data input devices
were inoperable; some had honey poured into them, others had been mysteriously run over by forklifts,
and still others had paper clips inserted in them. Employees had also entered erroneous data into the
system. More subtle forms of aggression can also undermine the system`s intended use. In other
organization, disgruntled workers used the new system to gang up on an unpopular foreman. Instead of
clocking in and out as they moved from one station to another, they punched in at the foreman`s
department for the entire day and proceeded to work in different areas. This adversely affected the
foreman`s performance evaluation, as he was charged for hours that did not belong to his operation.
2. Projection: Projection involves blaming the new system for any and every unpleasant occurrence. For
example, a new system is blamed for missing and incorrect data until the actual cause is determined. In
essence, the system becomes the scapegoat for all real and imagined problems and errors. If these
criticisms are not controlled or answered, the integrity of the system can be damaged or destroyed.
3. Avoidance: Dealing with problems through avoidance is a common human trait. For example, a person
who cannot decide between two job offers may delay a decision until one company withdraws its offer
and the decision is made for him. Likewise, one way for employees to deal with a new AIS is to avoid
using it in the hope that the problem (the system) can be ignored or that it will eventually go away.

Preventing Behavioral Problems

The human element is often thought to be the most significant problem a company encounters in designing,
developing, and implementing a system. Although there is no one best way to overcome behavioral problems,
people’s reactions can be improved by observing the following guidelines:
Meet user’s needs: It is essential that the form, content, and volume of system output be designed to
satisfy user needs.
Keep communication lines open: Managers and users should be fully informed of systems changes as
soon as possible. They should be told what changes are being made and why, they should be shown how
the new system will benefit them. The objective is to help employees identify with the company`s efforts
to improve the system. This helps ensure that employees feel they are key players in the company`s future
goals and plans. Open communication also helps prevent damaging and inaccurate rumors and
misunderstanding. Employees should be told who they can contact if they have questions or concerns.
Maintain a safe and open atmosphere: It is vital that everyone affected by systems development have
an attitude of trust and cooperation. If employees become hostile, it will be difficult to change their
attitude or to implement the system successfully.
Obtain management support: When possible, a powerful champion, who can provide resources for the
system and motivate others to assist and cooperate with systems development, should be appointed.
Allay fears: The organization should provide assurances (to the extent possible) that no major job losses
or responsibility shifts will occur. These goals can be achieved through relocation, attrition, and early
retirement. If employees are terminated, severance pay and outplacement services should be provided.
Solicit user participation: Those who will use or be affected by the system should participate in its
development by providing data, making suggestions, and helping make decisions. Participation is ego
enhancing, challenging, and intrinsically satisfying. Users who participate in development are more
knowledgeable, better trained, and more committed to using the system.

Page 21 of 22
 Provide honest feedback: To avoid misunderstandings, users should be told which suggestions are being
used and how, which suggestions are not being used and why, and which ones will be incorporated at
later date.
Make sure users understand the system: Effective use or support cannot be obtained if users are
confused about or do not understand the system. Generally, those who have a working knowledge of
computers often underestimate user training needs.
Humanize the system: System acceptance is unlikely if individuals believe the computer is controlling
them or has usurped their positions.
Describe new challenges and opportunities: System developers should emphasize important and
challenging tasks that can be performed with the new system. That the system may provide greater job
satisfaction and increased opportunities for advancement also should be emphasized.
Reexamine performance evaluation: Users` performance standards and criteria should be reevaluated
to ensure that they are satisfactory in view of changes brought on by the new system.
Test the system’s integrity: The system should be properly tested prior to implementation to minimize
initial bad impressions.
Avoid emotionalism: When logic vies with emotion, it rarely stands a chance. Emotional issues related
to change should be allowed to cool, handled in a non-confrontational manner, or sidestepped.
Present the system in the proper context: Users are vitally interested in how system changes affect them
personally. Relevant expectations should be presented that address their concerns, rather than the
concerns of managers or developers.
Control user’s expectations: A system is sold too well if users have unrealistic expectations of its
capabilities and performance. Be realistic when describing the merits of the system.
Keep the system simple: Avoid complex systems that cause radical changes. Make the change seem as
simple as possible by conforming to existing organizational procedures.
Observing these guidelines is time-consuming and expensive, and workers may skip difficult steps to speed
systems development and installation. However, the problems caused by not following these guidelines are
usually more expensive and time-consuming to fix than preventing behavioral problems in the first place.
“End of Chapter Three”

Page 22 of 22