CASE STUDY
MIS360 System Analysis
Chapter 6: Structuring System Requirements: Process Modeling
Learning Objectives
Explain process modeling
Discuss data-flow diagramming mechanics, definitions, and rules
Discuss balancing data-flow diagrams
Discuss the use of data-flow diagrams as analysis tools
Examine decision tables used to represent process logic
Process Modeling for Structured Analysis
Process Modeling
• Graphically represents 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
Process Modeling (continued)
• Modeling a System’s Process • Utilize information gathered during requirements
determination
• Structure of the data is also modeled in addition to the processes
• Deliverables and Outcomes • Set of coherent, interrelated data-flow diagrams
Process Modeling (continued)
Deliverables and Outcomes: pg.184
Set of coherent, interrelated data-flow diagrams • Context data-flow diagram (DFD): Scope of system. • Level-O Diagram: Major system’s processes, data
flows, and data stores at a higher level of detail. • Level-1 diagram: results from decomposition of Level-
0 diagram. • Level-n diagram: it is a DFD diagram that is the result
of n nested decompositions from a process on a level- 0 diagram.
Process Modeling (continued)
Deliverables and Outcomes
DFDs of current system • Enable analysts to understand current system
DFDs of new logical system • Technology independent
• Show data flows, structure and functional requirements of new system
Process Modeling (continued)
• Deliverables and Outcomes (continued) • Context data-flow diagram (DFD)
• Scope of system
• DFDs of current system • Enable analysts to understand current system
• DFDs of new logical system • Technology independent
• Show data flows, structure and functional requirements of new system
Process Modeling (continued)
• Data-flow Diagramming Mechanics • Represent both physical and logical information systems,
manual or computer based.
• Four symbols are used • See Figure 6-3
• Developed by Gane and Sarson
Definitions and Symbols
Definitions and Symbols
Comparison of DeMarco
and Yourdon
and Gane and Sarson
DFD symbol sets
Definitions and Symbols (Cont.)
• Process: works or actions performed on data (inside the system)
• Data store: data at rest (inside the system)
• Source/sink: external entity that is the origin or destination of data (outside the system)
• Data flow: arrows depicting movement of data
Data-Flow Diagramming Mechanics
Data Flow • Depicts data that are in motion and moving as a unit
from one place to another in the system
• Drawn as an arrow
• Select a meaningful name to represent the data
Data-Flow Diagramming Mechanics (continued) Data Store
• Depicts data at rest
• May represent data in • File folder
• Computer-based file
• Notebook
• Drawn as a rectangle with the right vertical line missing
• Label includes name of the store as well as the number
Data-Flow Diagramming Mechanics (continued) Process
• Depicts work or actions performed on data so that they are transformed, stored, or distributed
• Drawn as a rectangle with rounded corners
• Number of process as well as names are recorded
Data-Flow Diagramming Mechanics (continued) Source/Sink
• Depicts the origin (Source) and/or destination (Sink) 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.
Developing DFDs
Context Diagram • A data-flow diagram 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.
Note: only one process symbol, and no data stores shown
Developing DFDs: An Example
• Hoosier Burger’s Automated Food Ordering System
Context Diagram (Figure 6-5)
contains no data stores
Developing DFDs (continued)
Level-O Diagram • A data-flow diagram that represents a system’s major
processes, data flows, and data stores at a higher level of detail.
• Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs.
Developing DFDs: An Example (continued)
– Next step is to expand the context diagram to show the breakdown of processes (Figure 6-6)
Data-Flow Diagramming Rules
Basic rules that apply to all DFDs:
• Inputs to a process are always different than outputs. – Processes purpose: is to transform inputs into
outputs.
• Objects always have a unique name – Every process has a unique name.
• In order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram
Data-Flow Diagramming Rules (continued)
Process A. No process
can have only outputs (a miracle)
B. No process can have only inputs (black hole)
C. A process has a verb phrase label
Data Store D. Data cannot be
moved from one store to another
E. Data cannot move from an outside source to a data store
F. Data cannot move directly from a data store to a data sink
G. Data store has a noun phrase label
Source/Sink H. Data cannot move
directly from a source to a sink
I. A source/sink has a noun phrase label
Data-Flow Diagramming Rules (continued)
Data Flow J. A data flow has only one direction of flow between symbols K. A fork means that exactly the same data go from a common
location to two or more processes, data stores, or sources/sinks
L. A join means that exactly the same data come from any two or more different processes, data stores or sources/sinks to a common location
M. A data flow cannot go directly back to the same process it leaves N. A data flow to a data store means update O. A data flow from a data store means retrieve or use P. A data flow has a noun phrase label
Data Flow Diagramming Rules (Cont.)
Figure 7-6 Incorrect and correct ways to draw DFDs
Decomposition of DFDs
Functional decomposition • An iterative process of breaking a system
description down into finer and finer detail.
• Creates a set of charts in which one process on a given chart is explained in greater detail on another chart.
• Continues until no subprocess can logically be broken down any further.
Decomposition of DFDs (Cont.)
Level-1 diagram results from decomposition of Level-0 diagram.
Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a level-0 diagram.
Primitive DFD is the lowest level of a DFD.
Level-1 DFD
Processes are labeled 4.1, 4.2, etc.
These can be further decomposed
in more primitive (lower-level)
DFDs if necessary.
Level-1 diagram showing the
decomposition of Process 4.0
from the level-0 diagram for
Hoosier Burger’s food-ordering
system
Level-1 DFD shows
the sub-processes
of one of the
processes in the
Level-0 DFD.
This is a Level-1
DFD for Process
4.0.
Level-n DFD
Processes are labeled 4.3.1, 4.3.2, etc. If this is the
lowest level of the hierarchy, it is called a primitive DFD.
Level-2 diagram showing the decomposition of
Process 4.3 from the level-1 diagram for Process
4.0 for Hoosier Burger’s food-ordering system Level-n DFD
shows the sub-
processes of one of the processes
in the Level n-1
DFD.
This is a Level-2
DFD for Process
4.3.
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 6-5, notice that there is
• One input to the system:
• the customer order • Three outputs:
• Customer receipt
• Food order
• Management reports
Balancing DFDs (continued)
• Example (Continued)
• Notice Figure 6-6.
• 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
Balancing DFDs: An Unbalanced Example
• In context diagram, we have one input to the system, A and one output, B
• Level-0 diagram has one additional data flow, C
• Therefore. these DFDs are not balanced
Balancing DFDs
• We can split a data flow into separate data flows on a lower level diagram
Balancing DFDs: Four Additional Advanced Rules
Guidelines for Drawing DFDs
1. Completeness • DFD must include all components necessary for the
system • Each component must be fully described in the
project dictionary or CASE repository
2. Consistency • The extent to which information contained on one
level of a set of nested DFDs is also included on other levels
Guidelines for Drawing DFDs (continued)
3. Timing • Time is not represented well on DFDs • Best to draw DFDs as if the system has never started
and will never stop
4. Iterative Development • Analyst should expect to redraw diagram several
times before reaching the closest approximation to the system being modeled
5. Primitive DFDs • Lowest logical level of decomposition • Decision has to be made when to stop
decomposition
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
Using DFDs in Business Process Reengineering
• Example: IBM Credit
• Credit approval process is required six days before Business Process Reengineering (see Fig 6- 13)
Using DFDs in Business Process Reengineering (continued)
After Business Reprocess Engineering, IBM was
able to process 100 times the number of
transactions in the same amount of time
Summary
• Data-flow Diagrams (DFD) • Symbols
• Rules for creating
• Decomposition
• Balancing
• DFDs for Analysis
• DFDs for Business Process Reengineering (BPR)