System Analysis & Design
Dr. Md. Rakibul Hoque
University of Dhaka
Structuring System Process
Requirements
Systems Development Life Cycle with
the Analysis Phase
Process models
Process modeling – graphically representing functions or
processes that capture, manipulate, store, and distribute data
between a system and components within a system.
Process model
A formal way of representing how a business system operates
Illustrates the activities that are performed and how data
moves among them
Process models are diagrams that map the movement of data
between processes. It is used to organize and document a
system’s processes.
Flow of data through processes
Logic
Policies
Procedures
Deliverables for Process Modeling
A common technique for creating process models is known
as Data Flow Diagram (DFD)
Context DFD
Scope of the system
DFD of the system
Which processes move and transform data
Thorough descriptions of each DFD component
Allows analysts to understand the current system
Abstract this system to show how new system should
meet users requirements
Data Flow Diagrams (DFDs)
Data flow diagram (DFD) is the picture of the
movement of data between external entities and the
processes and data stores within a system.
DFDs are concerned with where and what data flows
into, within, and out of the system, but more particularly
with how it is processed along the way
Data flow diagram (DFD) – a process model used to
depict the flow of data through a system and the work
or processing performed by the system. Synonyms are
bubble chart, transformation graph, and process model.
The DFD has also become a popular tool for business
process redesign.
Data Flow Diagrams (DFDs)
Graphically characterize data processes and flows in a business system
Depict:
System inputs
Processes
Outputs
Represent both physical and logical systems
Useful for depicting purely logical information flows
D F Ds that detail physical systems differ from system flowcharts
which depict details of physical computing equipment
Only four symbols are used
Definitions and Symbols of DFD
Data flow – shows movement of data from one point to another. Described as data in
motion.
Data store – data at rest, which may take the form of many different physical
representations
Process – work or actions performed on data so that they are transformed, stored,
or distributed
Source/sink – origin and/or destination of data; sometimes referred to as external
entities and may consist of:
Another organization or unit that sends/receives data to system being analyzed
A person supported by the system being analyzed
Another IS that is exchanging information with the system being analyzed
Comparison of DeMarco and Yourdon with
Gane and Sarson DFD Symbol Sets
Definitions and Symbols of DFD
• Processes are numbered and named; the name
should be an action (i.e. a verb or, more usually, a
verb phrase)
• Data stores are numbered and named, with an
appropriately descriptive noun or noun phrase
• Data flows are not numbered but are named to
indicate what data is flowing (using a noun or noun
phrase)
• Sources/Sinks are not numbered but are named with
a noun or noun phrase
Definitions and Symbols of DFD
Definitions and Symbols of DFD
Rules Governing Data Flow
Diagramming
Rules Governing Data Flow Diagramming
Process:
A. No process can have only outputs. It would be making data from nothing (a
miracle). If an object has only outputs, then it must be a source.
B. No process can have only inputs (a black hole). If an object has only inputs, then it
must be a sink.
C. A process has a verb phrase label.
Data Store:
D. Data cannot move directly from one data store to another data store. Data must be
moved by a process.
E. Data cannot move directly from an outside source to a data store. Data must be
moved by a process that receives data from the source and places the data into the
data store.
F. Data cannot move directly to an outside sink from a data store. Data must be
moved by a process.
G. A data store has a noun phrase label.
Rules Governing Data Flow
Diagramming
Rules Governing Data Flow Diagramming
Source/Sink:
H. Data cannot move directly from a source to a sink. It must be moved by a
process if the data are of any concern to our system. Otherwise, the data flow
is not shown on the D F D.
I. A source/sink has a noun phrase label.
Rules Governing Data Flow
Diagramming
Rules Governing Data Flow Diagramming
Data Flow:
J. A data flow has only one direction of flow between symbols. It may flow in both directions
between a process and a data store to show a read before an update. The latter is usually
indicated, however, by two separate arrows because these happen at different times.
K. A fork in a data flow means that exactly the same data goes from a common location to two
or more different processes, data stores, or sources/sinks (this usually indicates different
copies of the same data going to different locations).
L. A join in a data flow means that exactly the same data come from any of 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. There must be at least
one other process that handles the data flow, produces some other data flow, and returns the
original data flow to the beginning process.
N. A data flow to a data store means update (delete or change).
O. A data flow from a data store means retrieve or use.
P. A data flow has a noun phrase label. More than one data flow noun phrase can appear on a
single arrow as long as all of the flows on the same arrow move together as one package.
Incorrect and Correct Ways to
Draw DFDs
Differences Between Sources/Sinks and
Processes (An Improperly Drawn DFD
Showing a Process as a Source/Sink)
Differences Between Sources/Sinks and
Processes (A DFD Showing Proper Use of a
Process)
Developing DFDs
Make a list of business activities and use it to determine various
External entities
Data flows
Processes
Data stores
DFDs start with the use cases and requirements definition
Generally, the DFDs integrate the use cases
Names of use cases become processes
Inputs and outputs become data flows
“Small” data inputs and outputs are combined into a single flow
Developing DFDs
Create a context diagram that shows external entities and
data flows to and from the system. Do not show any
detailed processes or data stores.
Create a child diagram for each of the processes in
Diagram 0.
Draw Diagram 0, the next level. Show processes, but keep
them general. Show data stores at this level.
Decompose level 0 processes into level 1 diagrams as
needed; decompose level 1 processes into level 2
diagrams as needed; etc.
Validate DFDs with user to ensure completeness and
correctness
Developing DFDs
Check for errors and make sure the labels you assign to
each process and data flow are meaningful.
Develop a physical data flow diagram from the logical data
flow diagram. Distinguish between manual and automated
processes, describe actual files and reports by name, and
add controls to indicate when processes are complete or
errors occur.
Partition the physical data flow diagram by separating or
grouping parts of the diagram in order to facilitate
programming and implementation.
Developing DFDs
(Context Diagram)
Context diagram – overview 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.
It shows the context into which the business process fits
Context diagram is the first DFD in every business
process
The highest level in a data flow diagram
Developing DFDs
(Context Diagram)
Shows the overall business process as just one process (process 0)
It shows what sources & sinks interact with the system, and what data
they exchange with it
Shows all the external entities that receive information from or contribute
information to the system
The system is represented as a whole as a single process – a “black box”
Contains only one process, representing the entire system
Developing DFDs
(Context Diagram)
All external entities, as well as major data flows are shown
External entities should not be connected to one another
A data store must be connected to at least one process
Data stores never appear on context diagrams; they are internal to the system
The process is given the number 0
The “0” process/system must have at least one input and at least one output
Sources/sinks must have at least one data flow connecting them to the “0” process/system
Sources/sinks are never connected to each other by data flows, only to the “0”
process/system
Developing DFDs
(Context Diagram)
• Source/sinks should always be named in the
singular since they represent types of thing
that can interact with the system (e.g.
“customer” rather than “customers”)
• Similarly, data store names should also be
singular (e.g. “member details” or “member
file” rather than “members details” or
“members file”)
Context Diagram of Food-Ordering
System
Developing DFDs
(Level-0 diagram)
The context diagram tells us nothing about the
internals of the system, just about its interaction
with its environment.
Level-0 diagram – DFD that represents a system’s
major processes, data flows, and data stores at a
high level of detail
DF D Rules
The inputs to a process are different from the
outputs of that process
Objects on a D FD have unique names
Level 0 Diagram
The explosion of the context diagram
Shows all the major processes that comprise the
overall system – the internal components of process 0
Shows how the major processes are interrelated by
data flows
Shows external entities and the major processes with
which they interact
Adds data stores
Level-0 DFD of Food-Ordering
System
Data Flow Diagram
Two important concepts related to data flow
diagrams:
Decomposition
Balancing
Decomposition of DFDs
(Level-1 Diagram)
Functional decomposition – iterative process of breaking
the description of a system down into finer and finer detail,
which creates a set of charts in which one process on a
given chart is explained in greater detail on another chart
Example: We could break down Process 1.0 into the
following tasks:
1. Receive customer order
2. Transform order into meaningful form for kitchen
3. Transform order into a printed receipt for the
customer
4. Transform order into goods sold data
5. Transform order into inventory data
Decomposition of DFDs
(Level-1 Diagram)
Generally, level 1 diagram is created for every major process on
the level 0 diagram
Level-1 diagram – result of decomposition of a Level-0 diagram
Process 1 on the level 1 DFD may be expanded into
(sub)processes 1.1, 1.2 … and data stores D1.1, D1.2 … etc
Rule of thumb—No D F D should have more than about seven
processes
Result makes the D F D crowded and difficult to understand
Level-1 Diagram Showing the Decomposition
of Process 1.0 from the level-0 Diagram for
Food-Ordering System
Level-1 Diagram Showing the Decomposition
of Process 4.0 from the level-0 Diagram for
Food-Ordering System
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
Level-2 Diagram Showing the Decomposition
of Process 4.3 from the Level-1 Diagram for
Process 4.0 for Food-Ordering System
Developing DFDs
IBM Credit Corporation’s Primary
Work Process Before BPR
IBM Credit Corporation’s
Primary Work Process After BPR
Electronic Commerce Application: Process
Modeling Using Data Flow Diagrams
Process modeling for Pine Valley Furniture’s
WebStore:
Completed J AD session
Began translating the WebStore structure into
data flow diagrams
Identified six high-level processes
System Structure of the WebStore and
Corresponding Level-0 Processes
WebStore System Processes
• Main Page Information Display (minor/ no processes)
– Product Line (Catalog) 1.0 Browse Catalog
2.0 Select Item for Purchase
Desks 3.0 Display Shopping Cart
Chairs 4.0 Check Out Process Order
Tables 5.0 Add/Modify Account Profile
6.0 Order Status Request
File Cabinets Information Display (minor/no processes)
– Shopping Cart
– Checkout
– Account Profile
– Order Status/History
– Customer Comments
• Company Information Blank
• Feedback Blank
• Contact Information Blank
Level-0 for the WebStore
An Example
• Suppose we are developing a process
model for a taxi allocation system
• First things first: what is the system
purpose and boundary?
– The system purpose is to accept requests
from customers and allocate taxis to service
those requests, issuing the relevant pickup
details to the appropriate taxi drivers
An Example
The boundary:
– From the description of the system
purpose it seems reasonably clear that
customers and taxi drivers are outside
the system
– Other actors (e.g. staff who accept
customer requests) are inside the system
Taxi Allocation System:
Context Diagram
Taxi Allocation System:
Level 0 DFD
Taxi Allocation System –
Problem?
• Can you see any problem(s) with the previous
model?
• One might be:
– How do we know when a pickup has been
completed? Currently there is no way in the
system to record this fact
• An appropriately modified model might look like
this …
Taxi Allocation System:
Level 0 DFD
Taxi Allocation System:
Level 1 DFD
Typical Errors That Can Occur in a
Data Flow Diagram
An Event Response Table for an
Internet Storefront
Event Source Trigger Activity Response Destination
Customer logs Customer Customer Find customer record and verify Welcome Customer
on number and password. web page
password Send Welcome web page
Customer Customer Item Find item price and quantity Item Customer
browses items information available. Response
at Web Send Item Response web page. web page
storefront
Customer Customer Item purchase Store data on Order Detail Record. Items Customer
places item into (item number Calculate shipping cost using Purchased
shopping and quantity) shipping tables. Update customer web page
basket at Web total. Update item quantity on hand.
storefront
Customer Customer Clicks “Check Display Customer Verification Blank
checks out Out” button on Order web page. web page
web page
Obtain customer Customer Credit card Verify credit card amount with Credit card Credit card
Payment information credit card company. Send. data company
Customer Customer
feedback
Send customer Blank Temporal, Send customer an email confirming Blank Customer
email hourly shipment.
Data Flow Diagrams for the First Three Rows
of the Internet Storefront Event Response Table
Thank
You
