Information Systems
System Analysis 421
Class Seven
Structuring System Requirements:
Process Modeling
Learning Objectives
 Understand the logical modeling of processes through
studying data flow diagrams
 How to draw data flow diagrams using rules and guidelines
 How to decompose data flow diagrams into lower-level
diagrams
 Balancing of data flow diagrams
8.2
Learning Objectives
 Explain the differences among four types of DFDs:
current physical, current logical, new physical and new
logical
 Discuss the use of data flow diagrams as analysis tools
 Compare and contrast data flow diagrams with Oracle’s
process modeling tool and with functional hierarchy
diagrams
 Discuss process modeling for Internet applications
8.3
Data Modeling
Entity
Relationship
Data Flow
Diagram
Prototypes
System Modeling
• One way to structure unstructured problems is
to draw a model
– A model is a representation of reality - picture worth a
thousand words
– Built to understand the existing system as a way to
document business requirements
– Data modeling is a technique for defining business
requirements
• Data is viewed as a resource to be shared by as many
processes as possible, data must be organized in a way
that is flexible and adaptable to unanticipated business
requirements
System Modeling
• Physical model shows not only what a system does but how
the system is physically and technically implemented depicts technical design
• Logical models depict business requirements illustrates
the essence of the system
– Move biases that are the results of the way the
current system is implemented
– Reduce the risk of missing requirements
– Allow us to communicate with end users
– Help analysts and users understand business
terminology and rules
Process Modeling
• The simplest process model of a system is based
on inputs, outputs, and the system itself –
Viewed a process.
– The process symbol defines the boundary of the
system.
– The system is inside the boundary; the environment is
outside that boundary.
– The system exchanges inputs and outputs with its
environment.
– Process is work performed on, or in response to,
incoming data flows or conditions.
Process Modeling
• Graphically represent the processes that capture,
manipulate, store and distribute data between a system
and its environment and among system components
• Data flow diagrams (DFD)
– Graphically illustrate movement of data between
external entities and the processes and data stores
within a system
• Modeling a system’s process
– Utilize information gathered during requirements
determination
– Structure of the data is also modeled in addition to the
processes
8.8
Process Modeling
• Deliverables and Outcomes
– Set of coherent, interrelated data flow diagrams
– Context data flow diagram (DFD)
• Scope of system
– DFDs of current system
• Enables analysts to understand current system
– DFDs of new logical system
• Technology independent
• Show data flows, structure and functional requirements
of new system
– Project dictionary and CASE repository
8.9
Data Flow Diagrams
• Data modeling is done during the project definition stage
and refined in physical design
• Similar to ERD Data model - DFD also helps the analyst
identify business vocabulary and uncover business
requirements
• Can be used on current system to understand requirements
• Can be fit on several sheets of paper
• The level of data flow diagram can be compared to a
highway and street maps that you might use - National =>
State => City
Data Flow Diagrams
 Tool that depicts the flow of data through a system and the
work or processing performed by that system
Graphical tool used to describe and analyze the movement of
data through a system manual or automated
 Central tool in which other components are developed
A data flow diagram (DFD) is a tool that depicts the flow of
data through a system and the work or processing performed by
that system. Synonyms include bubble chart, transformation
graph, and process model
DFD Symbols
DFD Symbols
• Named vector or arrow
– Called a data flow
new order
– Portrays a data path
• Bubble
– Called a process
– Portrays transformation of data
• Narrow open rectangle
Verify
Credit
3.2
3.2
Verify
Credit
– Called a data store
– Portrays a file or data base
Customer Master File
• Box
– Called a source or sink
– Portrays an internal or external agent
– Used to define a system’s boundaries
Customer
DFD Symbols
• Data flow - data move in a specific direction
• Processes - people, procedures or device that transforms
data - work to be done
• Source or destination - external source or destination of
data which may be people, program, organization or other
entities - The squares represent external agents – the
boundary of the system.
• Data Store - where data is house
Customer
Good Sold File
2.0
Update
Goods
Sold
DFD Symbols
Customer
External
Entity
1
Orders
Verify
Credit
Data Flow
Credit
History
Customer File
Data Store
Accepted
Orders
2
Ship
Order
Process
DFD Symbols
Data Flow
• A data flow is data in motion.
• The flow of data between a system and its environment, or
between two processes inside a system an relationship
between a system and its environment, or between two
processes is communication.
– A data flow represents an input of data to a process,
or the output of data (or information) from a process.
A data flow is also used to represent the creation,
deletion, or update of data in a file or database (called
a data store on the DFD).
– A data flow is depicted as a solid-line with arrow.
Data Flow
Membership
application
Employee
Bank statement
Existing account
3.1.1
Generate an
employee bank
statement
3.1.2
Create a new
member account
Employee
status
Employee address
Employees
Member Accounts
New account status
3.1.3
Freeze member
account number
Frozen account notification
Accounts
Receivable
Department
Data Flow
• No data flow should ever go completely unnamed.
• Data flow names should describe the data flow without
describing how the flow is or could be implemented.
• All data flows must begin or end at a process, because
data flows are the inputs and outputs of a process.
• Naming Convention - Should be descriptive nouns and noun
phrases that are singular, as opposed to plural.
– Should be unique.
• Use adjectives and adverbs to help to describe how
processing has changed a data flow.
Data Flow
Order
Cancelled Order
Process
Order
Cencel
Order
2
2
New
Order
Order
to be
Deleted
Orders
New
Order
Address
Change
Order
Address
Change of Address
Unfilled
Order
l
1
2
Summarize
Unfilled
Orders
Summary of Orders
Data Flow Packet Concept
• Data is seen as a package of information
Correct use of the
packet concept
Telephone
Service
Provider
Itemized
calls
and
invoice
Incorrect
use of the
packet
concept
Itemized calls
Invoice
Pay
phone
bill
Data Store
• Data Store
– Depicts data at rest
– May represent data in
• File folder
• Computer-based file
• Notebook
– The name of the store as well as the number are
recorded in between lines
8.22
Data Stores
• Most information systems capture data for later use.
• The data is kept in a data store.
– A data store is an ``inventory’’ of data. Synonyms
include file and database (although those terms are too
implementation-oriented for essential process
modeling).
– A data store is represented by the open-end box.
• If data flows are data in motion, think of data stores as
data at rest.
• Data stores should describe ``things’’ about which the
business wants to store data.
• It is permissible to duplicate data stores on a DFD to
avoid crossing data flow lines.
Data Stores
• Data cannot be moved from one data store to another data
stored it must be moved by a process
• Data cannot be moved from an outside source to a data
store it must be moved by a process
• Data Stores should have noun phrase labels
• Data Stores can be labeled
• Data flow to a data store means new/update
• Data flow from a data store means retrieve
A
Good Sold File
DFD Rules - Data Stores
Good Sold File
What’s valid !
Inventory
Students
Customer
Good Sold File
Inventory
3.0
Produce
Mgmt
Reports
Manager
Management Reports
DFD Rules - Data Stores
Good Sold File
What’s valid !
Sold data
Sold data
Inventory
Students
Customer
Good Sold File
Student Data
3.0
Creates
Reports
Inventory Data
Inventory
3.0
Produce
Mgmt
Reports
Manager
Management Reports
Process
• Process names should be descriptive.
1.0
Process
Customer
Food Order
• Processes should have a single Action Verb and a Singular
Object.
• Process numbers strictly used for identification
• All Processes are connected to something.
• All Processes have both Inputs and Outputs.
• No Process has only outputs or only inputs.
• Processes may connect to anything: other processes, data
stores or entities.
• Each Process has a unique name and number.
• A Process number is used only once in a diagram set.
Process
• Black Holes and Miracles
1
1
Process
1
y
Entity
Process
1
Entity
x
x
Data Store
y
Data Store
Process Example
1.0
Process
Customer
Food Order
1.0
Process
Customer
Food Order
1.0
Process
Customer
Food Order
1.0
Process
Customer
Food Order
Which ones are correct and incorrect?
External Entities
• Source/Sink
– Depicts the origin and/or destination of the data
– Sometimes referred to as an external entity
– Drawn as a square symbol
– Name states what the external agent is
– Because they are external, many characteristics are
not of interest to us
8.30
External Entities
• All information systems respond to events and conditions
in the environment.
•
The environment of an information system includes
external entities that form the boundary of the system,
and define places where the system interfaces with its
environment.
• A external entity defines an a person, organization unit,
other system, or other organization that lies outside of
the scope of the project, but which interacts with the
system being studied.
• External agents provide the net inputs into a system, and
receive net outputs from a system.
• Common synonyms include external agents
External Entities
• The term external means “external to the system being
analyzed or designed.”
• An external agent is represented by a square on the data
flow diagram.
• External agents on a logical data flow diagram may include
people, business units, other internal systems with which
your system must interact, and external organizations.
• External agents should be named with descriptive, singular
nouns.
• As a general rule, external agents should be located on the
perimeters of the page, consistent with their definition as
a system boundary.
Data Flow Diagramming Definitions
• Context Diagram
– A data flow diagram (DFD) of the scope of an organizational
system that shows the system boundaries, external entities
that interact with the system and the major information
flows between the entities and the system
• Level-O Diagram
– A data flow diagram (DFD) that represents a system’s major
processes, data flows and data stores at a high level of detail
8.33
Fast Food Restaurant
• Context diagram an overview of an organization
system that shows
– the system boundaries
– sources that interact with the system
– major information flow between the entities
Fast Food Restaurant
• The Context Diagram
– The context diagram contains one and only one process.
– External entities are drawn around the perimeter.
– Data flows define the interactions of your system with
the boundaries and with the external data stores.
– Refer as Level Zero
•
Let’s draw a context diagram
– What does a restaurant do - think McDonalds or
Hoosier
– What are the boundaries
– Who does it interact with
Developing DFDs: An Example
• Hoosier Burger’s automated food ordering
system
• Context Diagram (Figure 8-4) contains no data
stores
• Next step is to expand the context diagram to
show the breakdown of processes (Figure 8-5)
8.36
Figure 8-4
Context diagram of Hoosier Burger’s
food ordering system
8.37
Figure 8-5
Level-0 DFD of Hoosier Burger’s food ordering system
8.38
Data Flow Diagramming Rules
• Source/Sink
– Data cannot move
directly from a source to
a sink
– A source/sink has a noun
phrase label
8.39
•
Data Flow
– A data flow has only one
direction of flow between
symbols
– A fork means that exactly
the same data goes from a
common location to two or
more processes, data stores
or sources/sinks
Data Flow Diagramming Rules
•
Data Flow (Continued)
– A join means that exactly the same data comes from any
two or more different processes, data stores or
sources/sinks to a common location
8.40
–
A data flow cannot go directly back to the same process it
leaves
–
–
–
A data flow to a data store means update
A data flow from a data store means retrieve or use
A data flow has a noun phrase label
Data Flow Example
Incorrect
Correct
DFD Rules -- Data Flow
Incorrect
Correct
Corrected
data
flows
Illegal
data
flows
B1
B1
DS1
DS1
B2
DS1
B1
DS2
B1
a process is
needed to
exchange data
flows between
boundaries
B1
a process is
needed to
update (or
use) a data
store
DS1
a process is
needed to
present data
from a data
store
DS1
a process is
needed to
move data
from one data
store to
another
B1
DS1
B1
DS2
What are the rules
violations?
Dataflow 2
Entity A
Dataflow 5
Dataflow 4
Entity B
Dataflow 2
That’s All
Process
Blue
Dataflow 6
Dataflow 3
Dataflow 7
Dataflow 1
Data Store 1
2.1
2
Process
Green
Dataflow 8
Decomposition of DFDs
• Functional decomposition
– Act of going from one single system to many component
processes
– Repetitive procedure
– Lowest level is called a primitive DFD
• Level-N Diagrams
– A DFD that is the result of n nested decompositions of a
series of subprocesses from a process on a level-0 diagram
8.46
Relationship Among DFD
levels
Level 0 Diagram
• Shows all the processes that comprise the overall system
• Shows how information moves from and to each process
• Adds data stores
Level 1 Diagrams
•
Shows all the processes that comprise a single process on the level 0
diagram
•
Shows how information moves from and to each of these processes
•
Shows in more detail the content of higher level process
•
Level 1 diagrams may not be needed for all level 0 processes
Level 2 Diagrams
•
Shows all processes that comprise a single process on the level 1
diagram
•
Shows how information moves from and to each of these processes
•
Level 2 diagrams may not be needed for all level 1 processes
•
Correctly numbering each process helps the user understand where
the process fits into the overall system
•
The Data Flow Diagram (DFD) is an essential tool for creating formal
descriptions of business processes and data flows.
•
Use cases record the input, transformation, and output of business
processes.
•
Eliciting scenario descriptions and modeling business processes are
critically important skills for the systems analyst to master.
Balancing DFDs
• When decomposing a DFD, you must conserve inputs to and
outputs from a process at the next level of decomposition
• This is called balancing
• Example: Hoosier Burgers
– In Figure 8-4, notice that there is one input to the system,
the customer order
– Three outputs:
• Customer receipt
• Food order
• Management reports
8.51
Balancing DFDs
• Example (Continued)
– Notice Figure 8-5. We have the same inputs and
outputs
– No new inputs or outputs have been introduced
– We can say that the context diagram and level-0 DFD
are balanced
8.52
Figure 8-4
Context diagram of Hoosier Burger’s
food ordering system
8.53
Figure 8-5
Level-0 DFD of Hoosier Burger’s food ordering system
8.54
Balancing DFDs
• An unbalanced example
– Figure 8-10
– In context diagram, we have one input to the system, A
and one output, B
– Level-0 diagram has one additional data flow, C
– These DFDs are not balanced
8.55
Figure 8-10
An unbalanced set of data flow diagrams
(a) Context diagram
(b) Level-0 diagram
8.56
DFD: Balancing and Leveling
• When Zooming In, Do Not forget the Parent!
– Parent Process
– Child Diagram
P1.1
P1.2
P1
P1.3
D1
DFD: Exercise Problem Level 0
DS2
E
1
DF6
DF2
P1
DF1
E
2
P2
DF4
DF3
DF5
P3
DS1
DF3
DFD: Exercise Problem Level 1
DS2
DF6
DF1
P1.1
E
2P1.4
P1.2
DF7
DF9
DF2
DF8
P1.3
DFD: Exercise Problem Level 2
E
2P1.4.3
P1.4.2
DF11
DF12
DF2
DF10
DF8
DF9
P1.4.1
Four Different Types of DFDS
• Current Physical
– Process label includes an identification of the
technology (people or systems) used to process the
data
– Data flows and data stores are labeled with the actual
name of the physical media on which data flow or in
which data are stored
8.61
Four Different Types of DFDS
• Current Logical
– Physical aspects of system are removed as much as possible
– Current system is reduced to data and processes that
transform them
• New Logical
– Includes additional functions
– Obsolete functions are removed
– Inefficient data flows are reorganized
• New Physical
– Represents the physical implementation of the new
system
8.62
Guidelines for Drawing DFDs
• Completeness
– DFD must include all components necessary for system
– Each component must be fully described in the project
dictionary or CASE repository
• Consistency
– The extent to which information contained on one level
of a set of nested DFDs is also included on other levels
• Timing
– Time is not represented well on DFDs
– Best to draw DFDs as if the system has never started
and will never stop.
8.63
Guidelines for Drawing DFDs
• Iterative Development
– Analyst should expect to redraw diagram several times
before reaching the closest approximation to the
system being modeled
• Primitive DFDs
– Lowest logical level of decomposition
– Decision has to be made when to stop decomposition
• Rules for stopping decomposition
– When each process has been reduced to a single
decision, calculation or database operation
– When each data store represents data about a single
entity
8.64
– When the system user does not care to see any more
detail
Using DFDs as Analysis Tools
• Gap Analysis
– The process of discovering discrepancies between two
or more sets of data flow diagrams or discrepancies
within a single DFD
• Inefficiencies in a system can often be
identified through DFDs
8.65
Oracle’s Process Modeler and
Functional Hierarchy Diagrams
• Process Modeler
– Unique to Oracle
– Similar to DFDS but outputs and methods differ in several
ways.
– Table 8-4 illustrates differences
• Functional Hierarchy Diagrams
– Picture of various tasks performed in a business and how they
are related
– Tasks are broken down into their various parts
– Does not include data flows
8.66
Summary
• Data flow diagrams (DFD)
– Symbols
– Rules for creating
– Decomposition
– Balancing
• Four different kinds of DFDs
– Current Physical
– Current Logical
– New Logical
– New Physical
8.67
Summary
• DFDs for Analysis
• DFDs for Business Process Reengineering (BPR)
• Oracle’s Process Modeler
• Functional Hierarchy Diagrams
8.68
Process Decomposition
 What do you do when a complex system is too difficult to
fully understand when viewed as a whole
 We separate a system into its component subsystems,
which in turn are decomposed into smaller subsystems,
until such a time as we have identified manageable subsets
of the overall system.
• This technique is called decomposition.
– Decomposition is the act of breaking a system into its
component subsystems, processes, and subprocesses.
Each lower level reveals more or less detail) about the
overall system
Process Decomposition
• A decomposition diagram is a popular tool to illustrate
system decomposition - also called a hierarchy chart,
shows the top down functional decomposition and
structure of a system.
• A decomposition diagram is essentially a planning tool for
more detailed processes models, namely, data flow
diagrams.
• The decomposition diagram rules:
– Each process in a decomposition diagram is either a parent
process, a child process (of a parent), or both.
– A parent must have two or more children – a single child does
not make sense since that would not reveal any additional
detail about the system.
– In most decomposition diagramming standards, a child may
have only one parent.
– A child of one parent may, of course, be the parent of its own
children.
Process Decomposition
0
The System
2
Another
Function
1
A Function
1.1
Activity of the
Function
1.2
Another Activity
of the Function
2.1
Acivity of this
Function
2.2
Another Activity
of this Function
Task 1.1.1
Task 1.2.1
Task 2.1.1
Task 2.2.1
Task 1.1.2
Task 1.2.2
Task 2.1.2
Task 2.2.2
Task 2.1.3
Task 2.2.3
Task 1.1.3
Task 2.1.4
Process Decomposition
How do you build the hierarchy
• Logical processes are work or actions that must
be performed no matter how you implement the
system.
• Naming conventions for logical processes depend
on where the process is in the decomposition
diagram/data flow diagram and type of process
depicted.
• There are three types of logical processes:
functions, events, and elementary processes
Process Decomposition
• A function is a set of related and on-going
activities of the business. A function has no
start or end – it just continuously performs its
work as needed.
– Each of these functions may consist of dozens, or
hundreds of more discrete processes to do support
specific activities and tasks.
– Functions serve to group the logically related activities
and tasks.
– Functions are named with nouns that reflect the entire
function.
– Think of some functions - Payroll, Order Management,
Travel System
Process Decomposition's
• An event is a logical unit of work that must be
completed as a whole. An event is triggered by a
discrete input, and is completed when the
process has responded with appropriate outputs.
Events are sometimes called transactions.
– Functions consist of processes that respond to events.
– Each of these events has a trigger and response that
can be defined by its inputs and outputs.
– System functions are ultimately decomposed into
business events.
– Each business event is represented by a single process
that will respond to that event.
– Name some events for Payroll, OM and Travel
Process Decomposition's
• An event process can be further decomposed
into elementary processes that illustrate in
detail how the system must respond to an event.
• Elementary processes are discrete, detailed
activities or tasks required to complete the
response to an event. In other words, they are
the lowest level of detail depicted in a process
model. A common synonym is primitive process.
– Elementary processes should be named with a strong
action verb followed by an object clause that describes
what the work is performed on (or for).
DFD: Exercise Problem
Draw both a Context and Level 1 DFD for Order Entry
Department work process at Bebop Records.
Bebop Records is a mail order company that distributes CDs and
tapes at discount prices to record club members. When an order
processing clerk receives an order form, she verifies that the
sender is a club member by checking the MEMBER FILE. If the
sender is not a member, the clerk returns the order along with a
membership application form. If the customer is a member, the
clerk verifies the order item data by checking the ITEM FILE.
Then the clerk enters the order data and saves it to the DAIILY
ORDERS FILE. At the same time the clerk also prints an invoice
and shipping list for each order, which are forwarded to the
ORDER FULFILLMENT DEPARTMENT for processing there.
DFD: Exercise Problem
A. (5 Points) What is wrong with the following DFD?
Customer
Information
From Customer
Customer
Data
Customer
1
Accept
Customer
Information
Customer
Order
Customer
Data
2
Produce
Customer
Invoice
Detail Problem
D.Create a Context DFD and a level zero logical DFD for the following
Order Fulfillment System scenario within the Order Fulfillment
Department:
A CUSTOMER submits a PURCHASE ORDER. The FULFILL ORDER process
acts on the PURCHASE ORDER by either sending an ORDER REJECT
NOTICE back to the CUSTOMER if the CUSTOMER has bad credit, or
sending a FULFILLMENT SLIP to the WAREHOUSE Department.
When a COMPLETED ORDER NOTICE is received from the WAREHOUSE
Department signifying they have shipped the product, the CREATE
INVOICE process generates an INVOICE and outputs it to both the
CUSTOMER (by mail) and the ACCOUNTS RECEIVABLE data store.
When a CUSTOMER makes a PAYMENT it is processed by APPLY PAYMENT.
This requires INVOICE DETAIL input from the ACCOUNTS RECEIVABLE
data store along with PAYMENT DOCUMENTATION (from the customer).
APPLY PAYMENT outputs PAYMENT DETAIL back into the ACCOUNTS
RECEIVABLE store and outputs BANK DEPOSIT SLIP to the BANK, and
CASH RECEIPTS ENTRY to the ACCOUNTING Department.