Dataflow Diagrams Documentation Guide
General Rules:
Professional Teams developing systems produce details and complete
document in all areas covered.
The period involved in SAD means that you may not be able to document in
the details required. In particular the detail required for the data
dictionary. It is important to convey all the important datastores and
process descriptors.
Try to provide the important parts of the DFD components.
View the different styles portrayed in the guides and samples.
out areas that enhance your report.
Try and pick
Ultimately it takes several years to produce a sufficient DFD library which
can be utilized whenever building new systems.
Technical or bulky material should be moved to the appendix.
Web based or small scale systems may not need the level of details in the
data dictionary section.
Larger systems - most of the detailed material should be moved to the
appendix so as not to divert the reader from the general theme of your
system report.
Make a professional judgment.
Documenting in details helps maintain standards and procedures
particularly when there are a number of people working on developing the
system.
Section indicated in red need to be added.
Example: A Toy Sales Order Entry & Processing
System
Below is the typical documentation (requirements specifications) for a toy sales order
entry processing system and are not based this toy system on any real-world
accounting system. The specification provided is only a sub-section of a complete
system and therefore are incomplete. They are given as illustrations only. They
consist of:
Context diagram
Levelled logical dataflow diagrams
Relation specifications for a Relational Database
Specifications for the dataflows
Process descriptions in raw prolog code. (Prolog is a relational language. The
code is given here, since prolog code is generally easily grasped). The code
given here, with very minor changes, should be executable.
We are talking about a very small firm that considers orders from customers for one
item. You should be able to add a lot more to the model provided as you wish. The
situation considered is rather unrealistic, but it makes important points about
specifications for an accounting system and its documentation.
NOTE :
Sample Style Content Page
Section
Description
Dataflow Diagrams:
1.1
Context Diagram: (Sales Order Entry & Processing System)
1.2
Events List: (Sales Order Entry & Processing System)
1.3
Level 0 Logical Dataflow Diagram:
1.3.1
Sales Order Entry & Processing System
1.4
Level 1 Logical Dataflow Diagram:
1.4.1
Sales Order Entry Sub-system
1.4.2
Sales Order Processing Sub-system
2.
DATA DICTIONARY
2.1
Datastore List:
2.2
Dataflow Specifications
2.3
Process Specifications:
2.4
Example of Mini Spec (related code).
Page
Dataflow Diagrams:
<Introduce the reader to DFD modelling>
1.1 Context Diagram: (Sales Order Entry & Processing
System)
<text describing context diagram>
Figure: Context Diagram
1.2 Events List: (Sales Order Entry & Processing
System)
<Event List>
1.3
Level 0 Logical Dataflow Diagram:
1.3.1 Sales Order Entry & Processing System
<text describing level 0>
Figure: Level 0 Dataflow Diagram
1.4
Level 1 Logical Dataflow Diagram:
1.4.1 Sales Order Entry Sub-system
<text describing level 1>
Figure: Level 1 Dataflow Diagram (Sales Order Entry Subsystem)
1.4.2 Sales Order Processing Sub-system
<text describing level 1>
Figure: Level 1 Dataflow Diagram (Sales Order Processing Subsystem)
2.
DATA DICTIONARY (part 1)
<Introduction to data dictionary>
2.1
Datastore List:
<Introduction to datastore specification>
Syntax: tableName(attribute1, attribute2,......)
2.1.1
salesorder(CustomerName, CustomerAddress, Item, Quantity, .)
<Follow suit with remaining datastores>
priceList(Item, Price)
customerMaster(CustomerName, CustomerAddress, Balance,
CreditLimit)
inventoryMaster(Item, QuantityOnHand)
salesOrderMaster(CustomerName, Item, Quantity, OrderPrice)
billOfLading(CustomerName, Item, Quantity)
openInvoices(CustomerName, Item, Quantity, OrderPrice)
customer(CustomerName, CustomerAddress)
Optional - Datastore Specifications found in Appendix X1:
NOTE :
Datastores are used to develop the table requirements of the
system. Each datastore may generate several related tables.
2.2
Dataflow Specifications
<Introduction to dataflow specification>
Syntax: dataflowName(attribute1, attribute2,.....)
2.2.1
order(CustomerName, CustomerAddress, Item, Quantity)
<Follow suit with remaining dataflows>
pricedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
weDontSell(CustomerName, CustomerAddress, Item)
sorryBadCredit(CustomerName, CustomerAddress)
approvedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
sorryNotInStock(CustomerName, CustomerAddress, Item)
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
salesOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
billOfLading(CustomerName, CustomerAddress, Item, Quantity)
invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
Optional - Dataflow Specifications found in Appendix X2:
NOTE :
Dataflows are used to develop the data entry forms and output forms
required by the system. Each dataflow will require its own form view.
2.3
Process Specifications:
<Introduction to process specification>
2.3.1
<Follow suit with remaining processes>
Process Specifications found in Appendix X3:
NOTE :
Process descriptions are used to develop validation rules,
macros, functions or code required by the system.
Each process will require its own description.
2.4
Data Structure and Elements:
Example of Mini Spec (related code).
MINI SPEC PRICE ORDER
2.3.1
priceOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
/* Orders are priced by multiplying the quantity ordered by the price for the
item on the price list */
if
order(CustomerName, CustomerAddress, Item, Quantity),
priceList(Item, Price),
orderPrice is Price * Quantity.
/* We don't sell the item ordered by the customer if such item is not on the
price list */
weDontSell(CustomerName, CustomerAddress, Item)
if
order(CustomerName, CustomerAddress, Item, Quantity),
not priceList(Item, - ).
/* A customer order for an item is approved if the order is priced and the
account balance after the order is less than the credit limit */
approvedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
if
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
NewBalance is Balance + OrderPrice,
NewBalance < CreditLimit.
/* A customer order is rejected on account of bad credit if the order is priced
and the account balance after the order exceeds the credit limit for the
customer */
sorryBadCredit(CustomerName, CustomerAddress)
if
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
NewBalance is Balance + OrderPrice,
NewBalance >= CreditLimit.
/* A customer order is accepted if it is approved and the quantity on hand of
the item ordered is at least as much as the quantity ordered */
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)
if
approvedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice),
inventoryMaster(Item, QuantityOnHand),
QuantityOnHand >= Quantity.
/* A sales order is prepared if a customer order is accepted */
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
if
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice),
/* A bill of lading is prepared if a sales order is prepared */
billOfLading(CustomerName, CustomerAddress, Item, Quantity)
if
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice).
/* An open invoice is prepared if a bill of lading is prepared */
openInvoices(CustomerName, Item, Quantity, OrderPrice)
if
billOfLading(CustomerName, CustomerAddress, Item, Quantity).
/* A customer's account is updated by adding the order price to the current
balance in the account if open invoice is prepared */
updateCustomerAccountsForInvoices
if
openInvoices(CustomerName, Item, Quantity, OrderPrice),
retract(customerMaster(CustomerName, CustomerAddress, Balance,
CreditLimit)),
NewBalance is Balance + OrderPrice,
assert(customerMaster(CustomerName, CustomerAddress, NewBalance,
CreditLimit)).
DOCUMENTING DATA DICTIONARY (part 2)
When documenting the Data Dictionary Structures and Elements try to utilize some of
the following style.
1. DATA DICTIONARY
Provide an overview or a lookup table for datastore, dataflow and process
descriptors.
1.1.
Data Store Descriptors
1.1.1. orders
2
Content:
ORDERS =
{ORDER}
Description:
**the orders for books placed by customers
Inputs:
1.1 Log Order
Outputs:
1.2 Check Stock
Read:
Live / daily / weekly / monthly
Write:
Live / daily / weekly / monthly
status:
Disk / Paper ledger / Written Report
1.1.2. stocks
3
Content:
STOCKS =
Description:
Read:
**the books the company retails
1.2 Check Stock
1.4 Update Stock
1.2 Check Stock
1.5 Check Pending Orders
Live / daily / weekly / monthly
Write:
Live / daily / weekly / monthly
status:
Disk / Paper ledger / Written Report
Inputs:
Outputs:
{STOCK}
Follow suit with all remaining datastores. Hyperlink the data store
structures to the entry in 1.3 Data Structures for the list of data attributes.
1.2.
Data Flow Descriptors
1.2.1. order
Name:
Content:
date+@order#+CUSTOMERDETAIL+1{OITEM}
Description:
Source:
an order placed by a customer
Data Store
Process
1 Orders
1.1 Log Order
Destination:
Process
1.2 Check Stock
Read:
Live / daily / weekly / monthly
Write:
Live / daily / weekly / monthly
status:
Disk / Paper ledger / Written Report
Data Store
1 Orders
1.2.2. stock
Name:
Content:
Description:
Source:
Destination:
@isbn+title+AUTHOR+cost+sale+SUPPLIER+level
Process
Data Store
incomplete
incomplete
Process
Data Store
incomplete
incomplete
Read:
Live / daily / weekly / monthly
Write:
Live / daily / weekly / monthly
status:
Disk / Paper ledger / Written Report
1.2.3. customer
Name:
Content:
Description:
Source:
@customer#+CUSTOMERDETAIL+creditlevel
Destination:
Process
Data Store
Incomplete
incomplete
Process
Data Store
incomplete
incomplete
Read:
Live / daily / weekly / monthly
Write:
Live / daily / weekly / monthly
status:
Disk / Paper ledger / Written Report
Follow suit with
1.3.
all remaining dataflows.
Data Structures:
Data Structures: General
Description
ADDRESS
AUTHOR
CUSTOMERDETAIL
OITEM
SUPPLIER
house#+street+town+county+postcode
fname+sname
nametitle+sname+fname+ADDRESS+tel+fax+email
title+qty
sname+ADDRESS
Follow suit with
1.4.
all remaining data structures.
Data Elements
Data Elements:
Cost
currency
County
1{char}20
Cate
date
Fname
1{char}20
usually from [A..Z|a..z|0..9| ,-]
dd/mm/yy
house#
1{char}3
usually numeric but can from from subset [0..9|A..Z|a..z]
Isbn
level
Nametitle
order#
Postcode
Qty
10{char}10
integer
2{char}4
1{char}4
7{char}7
integer
format #-######-##-# where each # = [0..9]
minimum value 0
[Mr|Mrs|Ms|Miss|Dr|Prof]
numeric characters each [0...9]
format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9]
minimum value 1
sale
Sname
Street
Title
Town
currency
1{char}30
1{char}20
1{char}20
1{char}20
Follow suit with
all remaining data elements.
1.5.
usually from [A..Z|a..z|0..9| ,-]
usually from [A..Z|a..z|0..9| ,-]
usually from [A..Z|a..z|0..9| ,-]
Process Descriptors
Provide all process descriptors as follows.
DATA DICTIONARY: PROCESS DESCRIPTORS
2.1 match stock and order item
Name:
Description:
validating that order lines can be met from present stock
Data Inputs:
dataflow new order from data store 1. new orders.
dataflow stock order from data store 2. stocks.
Data Outputs:
dataflow complete order to process 2.2 record sale
dataflow noofitems to process 2.3 deduct stock
dataflow incompleteorder to process 2.4 create pending order
dataflow itemdetails to process 2.5 create purchase order
Variables:
Mini-Spec:
REPEAT
GET next ORDERITEM
IF MATCH [Link] with any [Link]
IF [Link] <[Link]
DO create purchase order
DO create pending order
ELSE ([Link] >=[Link])
DO deduct stock
DO record sale
ENDIF
ELSE (NO MATCH [Link] with any [Link])
**continue
ENDIF
UNTIL no more ORDERITEM
