Chapter Five

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 – The processes performed on it
– How it flows – Where it goes
2. Flowcharts
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 require that publicly-traded corporations and their auditors document and
test the company’s internal controls.
✓ Auditing Standard No. 2 promulgated by the PCAOB requires that the external auditor express
an opinion on the clients system of internal controls.
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

Accounting Information System | Lecturer: Rukiya T. 1

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 data
destinations from the system are represented by square boxes. Data
destinations are also referred to as data sinks.
Data flows The flow of the data into or out of a process 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.
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

Accounting Information System | Lecturer: Rukiya T. 2

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

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:

Accounting Information System | Lecturer: Rukiya T. 3

(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
One Document document or report.
The document copies should be numbered
in the upper, right-hand corner.

Input/Output; Can represent any input or output function

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

(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 processing function; usually results in a
change in data or information.

Manual operation Represents a processing operation

performed manually.

Auxiliary operation Represents a processing function performed

by a device other than a computer, e.g., an
optical character scanner.

Accounting Information System | Lecturer: Rukiya T. 4

 Represent an operation utilizing an off-line
Off-line keying key 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 disk/drive magnetic disk/drive. 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.

Represents data stored in a temporary online

Online storage file in a direct-access medium such as a
magnetic disk.

File Represent file of documents manually stored

and retrieved; inscribed letter indicates file-
N ordering 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.

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.

Accounting Information System | Lecturer: Rukiya T. 5

 Communication link Represents the transmission of data from
one 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 connector Connects the processing flow between two

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

Decision a program flowchart to show branching to
alternative paths.

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

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

Accounting Information System | Lecturer: Rukiya T. 6

 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.
2. Use the standard flowcharting symbols, and draw them with a template or a computer.
3. 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.
15. 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
18. Redesign the flowchart to avoid clutter and a large number of crossed lines.
19. Verify the flowchart`s accuracy by reviewing it with the people familiar with the system. Be sure
all uses of flowcharting conventions are consistent.
20. 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.

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

Accounting Information System | Lecturer: Rukiya T. 7

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

Here’s a flowchart that goes with the story

Accounting Information System | Lecturer: Rukiya T. 8

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.

Accounting Information System | Lecturer: Rukiya T. 9

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

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 4) Implementation and Conversation
2) Conceptual Design 5) Operations and Maintenance
3) Physical Design

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.

Accounting Information System | Lecturer: Rukiya T. 10

 ✓ 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, 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, 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:
✓ 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

Accounting Information System | Lecturer: Rukiya T. 11

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

Accounting Information System | Lecturer: Rukiya T. 12

 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.

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

Accounting Information System | Lecturer: Rukiya T. 13

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

Accounting Information System | Lecturer: Rukiya T. 14

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.

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
Accounting Information System | Lecturer: Rukiya T. 15
Many people are involved in developing and successfully implementing 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.
– 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

Accounting Information System | Lecturer: Rukiya T. 16

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.

Accounting Information System | Lecturer: Rukiya T. 17

Accounting Information System | Lecturer: Rukiya T. 18
Accounting Information System | Lecturer: Rukiya T. 19
Accounting Information System | Lecturer: Rukiya T. 20
Accounting Information System | Lecturer: Rukiya T. 21