I S 6 3 0 : A c c o u nti ng I n f orm a tion 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 6 3 0 / I S 6 3 0 _ F 1 2 . 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 630 : Lecture 3

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

IS 630 : Lecture 3

Standard Flowcharting Symbols

IS 630 : Lecture 3

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 630 : Lecture 3

Common System Flowcharting Routines

User queries the computer

IS 630 : Lecture 3

Common System Flowcharting Routines . . .

Update sequential data store

IS 630 : Lecture 3

Common System Flowcharting Routines . . .

Preparation and then manual reconciliation of control totals.

IS 630 : Lecture 3

Common System Flowcharting Routines . . .

Key and rekey to verify inputs

IS 630 : Lecture 3

Common System Flowcharting Routines . . .

Enter document into computer using a scanner

IS 630 : Lecture 3

10

Common System Flowcharting Routines . . .

Enter document into computer using scanner and then manual keying

IS 630 : 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 630 : 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 630 : Lecture 3

13

Preparing Systems Flowcharts . . .

7. Documents or reports printed in a computer facility should be shown in that facilitys 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 630 : 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 630 : 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 630 : Lecture 3

16

Preparing Systems Flowcharts . . .

All documents must have an origin and termination:

each copy of the document must flow to

Make sure progress of a document is clear.

Diagram a document

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 before and after each process entering or leaving a file entering or leaving a page or area of responsibility
IS 630 : Lecture 3 17

Suprina Systems Flowchart

IS 630 : 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 630 : Lecture 3

19

Suprina Systems Flowchart

with an Enterprise Database

IS 630 : 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 630 : 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 630 : Lecture 3

22

Data Flow Diagrams Symbols

DE MARCO & YOURDON

External Entity

Data Flow
Process

Data Store
IS 630 : Lecture 3 23

Data Flow Diagrams Symbols

GANE & SARSON NOTATIONS

External Entity

Data Flow
3

Process

Pay Bill AP Clerk

Data Store
IS 630 : 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 630 : 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 630 : 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. requirements in cases one is too preoccupied with technical results (premature technical solutions). end-users in nontechnical or less technical languages (charts, diagrams).
IS 630 : Lecture 3

Logical models reduce the risk of missing business Logical models allow the communication with

27

Process Modeling with DFD Process Modeling is a technique for organizing

and documenting the structure and flow of data through a systems processes, and the logic, policies, and procedures to be implemented by a systems 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 630 : 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 630 : Lecture 3

29

Systems & Subsystems

INPUT OUTPUT

IS 630 : 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 630 : Lecture 3

31

Decomposition Diagram

IS 630 : Lecture 3

32

Functional Decomposition Diagram

IS 630 : Lecture 3

33

Event Decomposition Diagram

IS 630 : 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 630 : 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 630 : 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 systems end-users or managers IS 630 : 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 630 : 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 630 : 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 630 : 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 630 : 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 630 : 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 630 : Lecture 3

43

M
0

P N

Context Diagram

M
1

D1 3

Level-0 Diagram
P

Level-1 Diagram

IS 630 : Lecture 3

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 630 : 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 DFDs Sub-processes (activities or tasks) of Level-0 processes (system
functions)

IS 630 : 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 630 : Lecture 3

47

Rules in DFD Building . . .

Rule 3 : Must be one process associated with each

data flow

IS 630 : Lecture 3

48

Rules in DFD Building . . .

Rule 3 : Must be one process associated with each

data flow

IS 630 : Lecture 3

49

Rules in DFD Building . . .

Rule 3 : Must be one process associated with each

data flow.

IS 630 : 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

D3 Accounts Receivable

CUSTOMER

3.0

D3

Accounts Receivable

IS 630 : Lecture 3

51

Rules in DFD Building . . .

Rule 5 : No process without output data flow (black hole !!!)

IS 630 : Lecture 3

52

Rules in DFD Building . . .

Rule 6 : No process without input data flow (miracle !!!)

IS 630 : 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 630 : 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 630 : Lecture 3

55

Balance Check
M P N

Context Diagram

M 1 2 P

Level-0 Diagram
IS 630 : Lecture 3 56

Rules in DFD Building . . . Rule 9 : Data flows cannot split by themselves

IS 630 : Lecture 3

57

Rules in DFD Building . . . Rule 9 : Data flows cannot split

IS 630 : 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 630 : 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 630 : Lecture 3

60

Rules in DFD Building ... Rule 12 : Data flow can NOT go backward in Level-0
Notes: Show any branching decision / loop in Level-1

(Todays output cant go back to yesterdays work !!!)

IS 630 : 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 630 : 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 630 : Lecture 3

63

Data to Process Matrix

IS 630 : Lecture 3

64

Architecture Blueprints

Street Location
N

Context Diagram

0
E1 E2

2010 D.Nguyen @ CSUN

IS 630 : Lecture 3

65

Architecture Blueprints . . .
Building Plan Level-0 DFD
1.0

E1

F3 F2 F1
3.0 2.0

E2

The building has 3 floors

2010 D. Nguyen @ CSUN

The system has 3 functions 66

IS 630 : Lecture 3

Architecture Blueprints . . .
Floor Plan for F1 Level-1 DFD for 1.0

1.0

Floor 1 has a big space for parking No need for detail blueprint

Function 1 has a single task No need for Level-1 (can get from Level-0) 67

2010 D. Nguyen @ CSUN

IS 630 : Lecture 3

Architecture Blueprints . . .
Floor Plan for F2 Level-1 DFD for 2.0
(1.0)
2.1

2.3

2.2
2.1

2.2

2.3

Floor 2 has 3 suites

(3.0)

Function 2 has 3 activities

2010 D. Nguyen @ CSUN

IS 630 : 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

Activity 2.1 has 2 tasks 69

IS 630 : Lecture 3

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 70

IS 630 : Lecture 3

Conditional Branching
1.1

(EXTRA STEP)

2.1

(CONDITIONAL EXIT)

IF (Condition) DO 1.2
1.2 2.2

IF (Condition) DO 2.2 ELSE DO 2.3

1.3

2.3

(2.0)

(3.0)

Note: Show conditional branching in Level-1 DFDs or lower.

IS 630 : Lecture 3

71

DFD Deliverables

Current System Context Diagram Logical Level-0 DFD Logical Level-1 DFDs (multi-task functions) Physical Level-0 DFD [for AUDITING] Physical Level-1 DFDs (multi-task functions)[for AUDITING] Proposed System Context Diagram Logical Level-0 DFD Logical Level-1 DFDs (multi-task functions) Physical Level-0 DFD [for implementation] Physical Level-1 DFDs (multi-task functions)[for implementation]
IS 630 : Lecture 3 72