Business and Economics

ACW2851 Accounting Information Systems and Financial Modelling

Lecture 6

Documenting Accounting Information Systems

Adapted from:
Simkin, Rose, & Norman (2012) Core Concepts of Accounting Information Systems (12th ed.) and
Gelinas & Dull (2008) Accounting information systems (7th ed.)
 Learning Objectives
 Appreciate the need for systems and program
documentation, including for end-user developed systems
 Be able to read and evaluate a range of systems and
program documentation, including:
– Document, system, and program flowcharts
– data flow diagrams
 Link to textbook
 Simkin (13th edition) AIS. Chp 5.

Presentation title 28th February 2011 3

Link to other topics.
 Important
• International student attendance
 What is documentation?

28th February 2011 Presentation title 6

 What is documentation?

• Documentation are the flowcharts, narratives and

other written communication that describe the
inputs, processing, and outputs of an AIS.

• We will cover only a few basic diagrams

– Flowcharts
– Data Flow Diagrams
 Why documentation is important
 Depict how the system works (trace the flow of data
and/or depict business processes)
 Train users
 Design new systems
 Control system development & maintenance costs
 Standardise communications with others
 Audit AIS
 Document business processes
 Comply with the SOX
 Establish accountability
What are flowcharts?

Presentation title 28th February 2011 9

 Types of Flowcharts

 Document flowcharts
Trace the physical flow of documents
through an organisation
 System flowcharts
Depict the electronic flow of data and
processing steps in an AIS
 Program flowcharts
Outline the processing logic and indicate the order of
processing steps in a program
 Document Flowcharts

 Traces the physical flow of documents through an

organisation.
 Construction begins by identifying the different
departments or groups that handle the documents of a
particular system (we identify these at top of each section)
 Auditors and accountants often use
document flowcharts when
analysing a current system for
weaknesses in controls and reports
 Common Document
Flowcharting Symbols
 Common Document
Flowcharting Symbols
A Simple Document Flowchart
A Document Flowchart
Document Flowcharting Guidelines
 Identify all departments involved
 Classify documents and activities by department
 Identify documents by numbers or color-coding
 Account for the distribution of every copy of a document
 Use on-page and off-page connectors
and connect by using same letter or number
 Annotate unclear activities for clarity
 Consider sequencing whenever important
 Avoid acronyms that could cause confusion
 Consider using automated flowchart tools
 System Flowcharts
 Present a comprehensive picture of the
 management,

 operations,

 information systems, and

 process controls

embedded in business processes

 Each processing phase usually involves preparing one or
more control reports
 These flowcharts depict an electronic stream of data
through processing phases of an AIS, and therefore
illustrate audit trails
Common System Flowchart Symbols
Common System Flowchart Symbols
System Flowchart –
Payroll Processing
System Flowchart Example
System Flowchart Example (continued)
 Enter document into
computer via keyboard,
edit input, record input
 Preparation and later
reconciliation of control
totals
 Systems Flowcharting Guidelines
 Arrange to read from top to bottom and left to right
 Use appropriate, standard symbols
 Always use a process symbol between an input and an
output symbol. This is called
the sandwich rule
 Use connectors to avoid crossed
lines and cluttered flowcharts
 Sketch a flowchart before designing the final draft
 Use annotated descriptions and comments in flowcharts
for clarification
 Program Flowcharts
 Outline the processing logic, and indicate the order of
processing steps, for computer programs
 Present the steps in a structured walk-through which
helps the reviewers formally
 assess the soundness of the logic,
 detect and correct design flaws, and
 make improvements.

 Macro program flowcharts serve as an

overview of the data processing logic
 Lower-level flowcharts indicate logic
necessary to carry out specific tasks
Program Flowcharts
What are data flow diagrams?

Presentation title 28th February 2011 28

 Data Flow Diagrams
 Data flow diagrams (DFDs) portray a business processes’
 activities,

 stores of data, and

 flows of data among those elements

DFDs are a means to describe the physical and logical

elements of any type of process or system, and
particularly the “flow of data”
DFDs do not show controls
Data Flow Diagram Symbols
 Types of DFDs
 Context Diagrams
 Overview of the system

 High-level

 Physical Data Flow Diagrams

 Focuses on the physical entities of the organisation

 Logical Data Flow Diagrams

 Emphasises tasks of participants
 Context Diagrams
 DFDs are usually drawn in levels that include
increasing amounts of detail.
 A top level (or highest-level) DFD that provides
an overall picture of an application or system is
called a context diagram.
 A context diagram is then decomposed,
or exploded, into successively lower
levels of detail.
 Only has 1 bubble
 Context diagram
The top level DFD – provides an overview of the system
 Physical Data Flow Diagrams
 Specify where, how, and by whom a system’s processes
are accomplished (but not what is being accomplished)
 Focus on physical entities as well as the tangible
documents, reports, and similar hard-copy inputs and
outputs that flow through the system
 List the job titles of typical employees
 Are simple, more readable, and therefore fairly easily
understood
 Bubble (circle) is a NOUN (Who!)
Physical Data Flow Diagrams
 Logical Data Flow Diagrams
 Shows the system’s processes (as bubbles), data stores,
and the flows of data into and out of the processes and
data stores
 Represents the logical nature of a system – concentrates
on what tasks the system is doing (without specifying the
how, where and by whom the tasks are accomplished)
 A logical DFD portrays a system’s activities, whereas a
physical DFD depicts a system’s infrastructure
 Top level logical DFD is called a level-0 DFD
 Bubble is a VERB (what task)
 Logical Data Flow Diagrams
 Decompose logical DFDs into successive levels
(decomposing or exploding each bubble into increasing
levels of detail – ideally to a maximum of 5 - 7 bubbles per
logical DFD)
 Each bubble contains a verb that indicates a task the system
performs
 Logical DFDs help designers decide
 what system resources to acquire,

 what activities employees must perform to run these

systems, and
 how to protect and control these systems after installation.
Logical Data Flow Diagrams (level 0)
 Decomposition
(of Bubble 3.0 into a level 1 logical DFD)
 Guidelines for drawing DFDs
 Avoid detail in high level DFDs
 Give different data flows different names
 All data stores should have data flows both into them and
out of them
 Include even temporary files in a DFD
 Classify most of the final recipients of system information
as external entities
 Display only normal processing routines in
high-level DFDs
How do you draw these diagrams?

Presentation title 28th February 2011 41

 Documentation Tools
Software tools for graphical documentation and SOX
compliance
 Microsoft Word, Excel, and PowerPoint
(use AutoShapes” for graphic symbols and logic diagrams)
 CASE Tools (computer-assisted software engineering) to
automate costly, inefficient, slow documentation tasks.
CASE tools can reduce the time and cost to produce high-
quality documentation for new systems, thus supporting
rapid application development (RAD). For example, Visio,
SmartDraw and iGrafx
What is end-user computing?
And what is end-user
documentation?

Presentation title 28th February 2011 43

 End-User Computing
 Refers to the ability of non-IT employees to create their
own computer applications
 It is important for end-users to document applications they
develop. Your should recall this from our spreadsheet
model design principles (in week 1 and 2). We identified
four categories of spreadsheet model documentation:
1. Introduction
2. Instructions
3. Assumptions
 Importance of End-User
Documentation
 End-users require complete, easy-to-follow training
manuals, tutorials, and reference guides
 Documentation is important for learning how to
accomplish things or undo mistakes
 Documentation is also important for end users as time is
wasted when other employees need to alter/update a
system but lack the basic documentation to accomplish
this task
 Peterson

 NPV>0, invest
 No cash generating flows during Year 0. Only cash
outflow for payment to buy equipment.
 Cash flows generation only happens when there is
equipment. When equipment is sold, no more asset
balance in the books, no more cash generation from
equipment etc
 Further reading
Nikzad, Manteghi and Shohrehosadat, Karimi Jahromi
(2012) “Designing accounting ınformation system using
SSADM1 Case Study: South Fars Power Generation
Management Company (S.F.P.G.M.C)”
http://www.sciencedirect.com/science/article/pii/S221201
7312000667

Note: This paper shows you how documentation is

performed in 1 organisation.

Presentation title 28th February 2011 47

 Conclusion
 Understand why documentation is important
 Able to narrate document and system flowcharts
 Able to narrate context diagram, physical and
logical DFDs
 Know importance of CASE tool and end-user
documentation

Presentation title 28th February 2011 48