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