I S 5 3 0 : A c c o u nti ng I n f orm at ion S y s t em s
h t t p : / / w w w. c s u n . e d u / ~ d n 5 8 4 1 2 / I S 5 3 0 / I S 5 3 0 _ F 1 5 . h t m
Systems Documentation:
Systems Flowchart &
Data Flow Diagram
Lecture 3
System Documentation
 System Flowcharts present a comprehensive picture
of the management, operations, information
systems, and process controls embodied in business
processes.
 Data Flow diagrams (DFD) portray a business
process activities, stores of data, and flows of data
among those elements.
IS 530 : Lecture 3
2
Systems Flowcharts
 Systems Flowchart: a graphical representation of a
business process, including information processes
(inputs, data processing, data storage, and
outputs), as well as the related operations processes
(people, equipment, organization, and work
activities).
 ( Also known as “process flowcharts” and “business
process flowcharts”, “document flowcharts”)
IS 530 : Lecture 3
3
Standard Flowcharting Symbols
IS 530 : Lecture 3
4
Common System Flowcharting Routines
Enter document into
computer via keyboard,
edit input, record input.
(Note that columns are
set up to communicate
the flow of activities
between processing
entities.)
IS 530 : Lecture 3
5
Common System Flowcharting Routines …
User queries the
computer
IS 530 : Lecture 3
6
Common System Flowcharting Routines . . .
Update sequential data
store
IS 530 : Lecture 3
7
Common System Flowcharting Routines . . .
Preparation and then
manual reconciliation of
control totals.
IS 530 : Lecture 3
8
Common System Flowcharting Routines . . .
Key and rekey to verify
inputs
IS 530 : Lecture 3
9
Common System Flowcharting Routines . . .
Enter document into
computer using a
scanner
IS 530 : Lecture 3
10
Common System Flowcharting Routines . . .
Enter document into
computer using
scanner and then
manual keying
IS 530 : Lecture 3
11
Preparing Systems Flowcharts
1. Divide the flowchart into columns (areas of
responsibilities): one column for each internal
entity and one for each external entity. Label
each column.
2. Flowchart columns should be laid out so that the
flowchart activities flow from left to right. But,
minimize crossed lines and connectors.
3. Flowchart logic should flow from top to bottom
and from left to right. For clarity, put arrows on all
flow lines.
IS 530 : Lecture 3
12
Preparing Systems Flowcharts . . .
4. Keep the flowchart on one page, if possible. With
multiple pages use off-page connectors.
5. Within each column, there must be at least one
manual process, keying operation, or data store
between documents. Do not directly connect
documents within the same column.
6. When crossing organizational lines (one column to
another), show a document at both ends of the
flow line unless the connection is so short that the
intent is unambiguous.
IS 530 : Lecture 3
13
Preparing Systems Flowcharts . . .
7. Documents or reports printed in a computer facility
should be shown in that facility’s column first. Then
show the document or report going to the
destination unit.
8. Documents or reports printed by a centralized
computer facility on equipment located in
another organizational unit should not be shown
within the computer facility.
IS 530 : Lecture 3
14
Preparing Systems Flowcharts . . .
9. Processing within an organizational unit on devices
such as a PC, laptop, or computerized cash
register should be shown within the unit or as a
separate column next to that unit, but not in the
central computer facility column.
10. Sequential processing steps (computerized or
manual) with no delay between them (and
resulting from the same input) can be shown as
one process or as a sequence of processes.
IS 530 : Lecture 3
15
Preparing Systems Flowcharts . . .
11. The only way to get data into or out of a computer
data storage unit is through a computer
processing rectangle or offline process square.
12. Manual process is not needed to show the sending
of a document; sending should be apparent from
the movement of the document.
13. Do not use manual processes to file documents;
show documents going into files.
IS 530 : Lecture 3
16
Preparing Systems Flowcharts . . .
 All documents must have an origin and termination:
each copy of the document must flow to
• a permanent file symbol
• a symbol denoting an exit from the system, or
• an off-page connector
• a document destruction symbol (small black box)
• “cradle to grave” documentation
 Make sure progress of a document is clear.
Diagram a document
• before and after each process
• entering or leaving a file
• entering or leaving a page or area of responsibility
IS 530 : Lecture 3
17
Suprina Systems Flowchart
IS 530 : Lecture 3
18
Documenting Enterprise Systems
 Moving from a file-based system to an enterprise
database changes the systems flowchart.
• An enterprise database replaces transaction and master
•
data.
Other flows may change depending on the system
implementation.
IS 530 : Lecture 3
19
Suprina Systems Flowchart
with an Enterprise Database
IS 530 : Lecture 3
20
Flowchart Summary
• The flowchart is one of the easier types of
documentation for information customers and
management to understand.
• Often, auditors use system, document, and procedure
flowcharts to understand business and systems controls
in an environment
• The primary weakness of the flowchart is that it is tied to
physical information flows and system characteristics
that hide the procedural essence of the system.
• Some flowcharts are full of data and processing
artifacts because they are tied to an outdated
information technology.
IS 530 : Lecture 3
21
Process Modeling / Documentation
Logical vs. Physical Models
System and Process Concepts
Data Flow Diagrams (DFD)
Elements of a DFD
Rules and Procedures in DFD
IS 530 : Lecture 3
22
Data Flow Diagrams Symbols
DE MARCO & YOURDON
External Entity
Data Flow
Process
Data Store
IS 530 : Lecture 3
23
Data Flow Diagrams Symbols
GANE & SARSON NOTATIONS
External Entity
Data Flow
3
Process
Pay Bill
AP Clerk
Data Store
IS 530 : Lecture 3
24
Why System Modeling
 To better understand the system: opportunities for
simplification, optimization (BPR)
 To communicate the desired structure and
behavior of the system (business requirements:
data/information & functions/processes)
 To visualize and control the system architecture
(blueprint)
 To manage risks in development process
IS 530 : Lecture 3
25
Logical Vs. Physical Models
Logical models show WHAT a system is or does. They
are independent of any technical implementation.
Physical models show not only what a system is or does,
but also HOW the system is (to be) physically and
technically implemented. They reflect technology choices.
IS 530 : Lecture 3
26
Why Logical Models
 Logical models remove (political, emotional)
biases resulted from the way the system is currently
implemented, or the way that any one person
thinks the system might be implemented.
 Logical models reduce the risk of missing business
requirements in cases one is too preoccupied with
technical results (premature technical solutions).
 Logical models allow the communication with
end-users in nontechnical or less technical
languages (charts, diagrams).
IS 530 : Lecture 3
27
Process Modeling with DFD
 Process Modeling is a technique for organizing
and documenting the structure and flow of data
through a system’s processes, and the logic,
policies, and procedures to be implemented by a
system’s processes.
 Data Flow Diagram (DFD) is a graphical tool to
depict the flow of data through a system and the
work or processing performed by that system.
 Language description (memo) is subject to
interpretation, it may omit crucial info.
 DFD is Graphical description the flows of data
within an organization
IS 530 : Lecture 3
28
System Concept
 A system exits by taking input from the
environment, transforming (processing) this input,
and release an output
 A system may be decomposed (exploded) into
subsystems
 A subsystem has its own input and output
 Output of one subsystem may become the input
of other subsystems (throughput)
IS 530 : Lecture 3
29
Systems & Subsystems
INPUT
OUTPUT
IS 530 : Lecture 3
30
Systems & Processes
 A system is a process. It addresses a business


function.
A process is work / action performed on, or in
response to, incoming data flows or conditions.
A process (function) can be decomposed into
sub-processes (sub-functions, tasks)
IS 530 : Lecture 3
31
Decomposition Diagram
IS 530 : Lecture 3
32
Functional Decomposition Diagram
IS 530 : Lecture 3
33
Event Decomposition Diagram
IS 530 : Lecture 3
34
Data Flow Diagrams
 DFD documents a business function/activity/task of
a system as a process.
 DFD describes how data is manipulated within and
at the boundaries of the system.
 DFD shows detail of the interdependency among
processes of the system, movements of data or info
among the processes.
IS 530 : Lecture 3
35
External Entities
SUPPLIER
 An External Entity is a provider (source) or receiver
(sink) of data and info of the system.
 An External Entity is NOT part of the system: the
externality depends on how the system is defined.
IS 530 : Lecture 3
36
External Entities . . .
 An external entity (agent) defines a person,
organization unit, or other organization that lies
outside of the scope of the project but that interacts
with the system being studied.
• External agents define the “boundary” or scope of a system
•
•
being modeled.
As scope changes, external agents can become processes,
and vice versa.
Almost always one of the following:
o Office, department, division inside the business but outside the
system scope.
o An external organization or agency.
o Another business or another information system.
o One of system’s end-users or managers
IS 530 : Lecture 3
37
Data Stores
D1
Accounts Receivable
 A Data Store is a storage of data: it contains
information
 Physical storage is immaterial : it can be a filing
cabinet, book, computer file
IS 530 : Lecture 3
38
Data Stores . . .
 A data store is an inventory of data.
• A data store is “data at rest” compared to a data flow
that is “data in motion.”
• Almost always a data store for one of the following:
o
o
o
o
o
Persons (or groups of persons): e.g., customer
Places: e.g, cash register
Objects: e.g., product
Events (about which data is captured): e.g., sales
Concepts (about which data is important): e.g., discount
• One can identify data stores with REAL (Resources-EventsAgents-Locations) framework
• Data stores depicted on a DFD store all instances of data
entities (depicted on an ERD)
IS 530 : Lecture 3
39
Data Flows
DELIVERY SLIP
 A Data Flow represents a movement of data (info)
among processes or data stores
 A Data Flow does NOT represent a document or a
physical good: it represents the exchange of
information in the document or about the good
 A Data Flow represents an input of data to a
process, or the output of data from a process.
• A data flow may also be used to represent the creation,
•
reading, updating, or deletion (CRUD) of data in a file or
database (called a data store).
A composite data flow (packet) is a data flow that consists
of other data flows.
IS 530 : Lecture 3
40
Processes
1
Pay Bill
 A Process is a work or action performed on input
data flow to produce an output data flow
 Use a verb to label the action performed by the
process (not the name of person or department
who does it as in physical DFD)
 A Process must have at least one input data flow
and at least one output data flow.
IS 530 : Lecture 3
41
Types of Processes
 Function: a set of related and ongoing activities of
a business: e.g., sales.
 Activity (Event / Transaction) : a logical unit of work
that must be completed as a whole (as part of a
function): e.g., collect payment.
 Task (Elementary / Primitive Process): a discrete,
detailed activity or task required to respond to an
event. Usually, several such tasks must be
completed to respond to an activity/ event, e.g,
update new info, calculate payment, create
notice…
IS 530 : Lecture 3
42
Context Diagram
 Define the boundary of the system
 Identify the external entities
 No detail on processes and data stores of the
system
IS 530 : Lecture 3
43
M
0
P
Context Diagram
N
M
Level-0 Diagram
D1
1
N
3
2
IS 530 : Lecture 3
P
Level-1 Diagram
44
DFD Building Procedure
 Context Diagram
• Identify the system and its boundaries (the context)
• Identify external entities (providers, receivers of system info)
• Identify external data flows (input, output)
• Note: the whole system itself is a process (it receives input and
transforms it into output) doing a business function
IS 530 : Lecture 3
45
DFD Building Procedure . . .
 Level-0 DFD
• Identify what is being done between each input and its
corresponding output
• Identify the processes (functions of the system)
• Identify external data flows between external entities and
processes
• Identify internal data flows between processes and data stores
 Level-1 DFD’s
• Sub-processes (activities or tasks) of Level-0 processes (system
functions)
IS 530 : Lecture 3
46
Rules in DFD Building
 Rule 1 : Unique label for each symbol to avoid
confusion
 Rule 2 : Use an action VERB to label a process
(because a process is an action !!!)
IS 530 : Lecture 3
47
Rules in DFD Building . . .
 Rule 3 : Must be one process associated with each
data flow …
M
M
IS 530 : Lecture 3
48
Rules in DFD Building . . .
 Rule 3 : Must be one process associated with each
data flow …
M
N
M
N
IS 530 : Lecture 3
49
Rules in DFD Building . . .
 Rule 3 : Must be one process associated with each
data flow.
IS 530 : Lecture 3
50
Rules in DFD Building . . .
 Rule 4 : Shaded corner must appear in ALL occurrences
of a duplicated symbol in a same diagram on the same
page.
CUSTOMER
1.0
CUSTOMER
3.0
D3 Accounts Receivable
D3
Accounts Receivable
IS 530 : Lecture 3
51
Rules in DFD Building . . .
 Rule 5 : No process without output data flow (black hole !!!)
IS 530 : Lecture 3
52
Rules in DFD Building . . .
 Rule 6 : No process without input data flow (miracle !!!)
IS 530 : Lecture 3
53
Rules in DFD Building . . .
 Rule 7 : No need for routing (without transforming) a
data flow with a process (non value-added
activities !!!)
Info A
Info A
IS 530 : Lecture 3
54
Rules in DFD Building . . .
 Rule 8 : Identical input, output data flows for parent
and child processes (but the child processes can
have their own throughputs) . Balance Check.
IS 530 : Lecture 3
55
Balance Check
M
P
Context Diagram
N
M
1
N
2
P
3
Level-0 Diagram
IS 530 : Lecture 3
56
Rules in DFD Building . . .
 Rule 9 : Data flows cannot split by themselves
IS 530 : Lecture 3
57
Rules in DFD Building . . .
 Rule 9 : Data flows cannot split …
IS 530 : Lecture 3
58
Rules in DFD Building . . .
 Rule 10 : A data packet can combine many data
elements being transmitted at the same time to
the same destination (a document carries many
pieces of info)
IS 530 : Lecture 3
59
Rules in DFD Building . . .
 Rule 11 : Double-headed arrows are forbidden [in-
flow (update) and out-flow (extract info) of a data
store carry different information]
IS 530 : Lecture 3
60
Rules in DFD Building ...
 Rule 12 : Data flow can NOT go backward in Level-0
(Today’s output can’t go back to yesterday’s work !!!)
Notes: Show
any branching
decision / loop
in Level-1
IS 530 : Lecture 3
61
Differences Between DFDs and Flowcharts
 Processes on DFDs can operate in parallel (at-thesame-time)
• Processes on flowcharts execute one at a time
 DFDs show the flow of data through a system
• Flowcharts show the flow of control (sequence and transfer
of control)
 Processes on a DFD can have different timing (daily,
weekly, on demand)
• Processes on flowcharts are part of a single program with
consistent timing
IS 530 : Lecture 3
62
Data Conservation
Data conservation – the practice of ensuring that a
data flow contains only data needed by the
receiving process.
• New emphasis on business process redesign to identify and
•
•
•
eliminate inefficiencies.
Simplifies the interface between those processes.
Must precisely define the data composition
(attributes/fields) of each data flow (document), expressed
in the form of data structures (in Data Modeling).
“cradle to grave” documentation
• CRUD Matrix : Create, Read, Update, Delete.
IS 530 : Lecture 3
63
Data to Process Matrix
IS 530 : Lecture 3
64
Architecture Blueprints
Street Location
Context Diagram
N
0
E1
© 2010 D.Nguyen @ CSUN
IS 530 : Lecture 3
E2
65
Architecture Blueprints . . .
Level-0 DFD
Building Plan
1.0
E1
F3
2.0
F2
F1
3.0
E2
The building has 3 floors
© 2010 D. Nguyen @ CSUN
The system has 3 functions
IS 530 : Lecture 3
66
Architecture Blueprints . . .
Floor Plan for F1
Level-1 DFD for 1.0
1.0
Floor 1 has a big space for parking
Function 1 has a single task
No need for detail blueprint
© 2010 D. Nguyen @ CSUN
IS 530 : Lecture 3
No need for Level-1
(can get from Level-0)
67
Architecture Blueprints . . .
Floor Plan for F2
Level-1 DFD for 2.0
(1.0)
2.1
2.3
2.2
2.2
2.1
2.3
Floor 2 has 3 suites
(3.0)
Function 2 has 3 activities
© 2010 D. Nguyen @ CSUN
IS 530 : Lecture 3
68
Architecture Blueprints . . .
Suite Plan for 2.1
Level-2 DFD for 2.1
(1.0)
2.1.1
2.1.2
2.1.1
2.1.2
(2.2)
Suite 2.1 has 2 rooms
© 2010 D. Nguyen @ CSUN
IS 530 : Lecture 3
Activity 2.1 has 2 tasks
69
Linked Processes
1.0
1.0
D1
2.0
2.0
1.0 sends data to 2.0
1.0 and 2.0 share the
same data store D1
IS 530 : Lecture 3
70
Conditional Branching
1.1
(EXTRA STEP)
2.1
IF (Condition)
IF (Condition)
DO “1.2”
1.2
(CONDITIONAL EXIT)
DO “2.2”
2.2
ELSE
DO “2.3”
1.3
2.3
(2.0)
(3.0)
Note: Show conditional branching in Level-1 DFD’s or lower.
IS 530 : Lecture 3
71
DFD Deliverables
 Current System
• Context Diagram
• Logical Level-0 DFD
• Logical Level-1 DFD’s (multi-task functions)
• Physical Level-0 DFD [for AUDITING]
• Physical Level-1 DFD’s (multi-task functions)[for AUDITING]
 Proposed System
• Context Diagram
• Logical Level-0 DFD
• Logical Level-1 DFD’s (multi-task functions)
• Physical Level-0 DFD [for implementation]
• Physical Level-1 DFD’s (multi-task functions)[for implementation]
IS 530 : Lecture 3
72