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. Try and pick out areas that enhance your report.
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.

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 .
1.2
1.3
1.3.1
1.4
1.4.1
1.4.2
2.
2.1
2.2
NOTE :
Section Description
1
1.1
Sample Style Content Page
Dataflow Diagrams:
Context Diagram: (Sales Order Entry & Processing System)
Events List: (Sales Order Entry & Processing System)
Level 0 Logical Dataflow Diagram:
Sales Order Entry & Processing System
Level 1 Logical Dataflow Diagram:
Sales Order Entry Sub-system
Sales Order Processing Sub-system
DATA DICTIONARY
Datastore List:
Dataflow Specifications
2.3 Process Specifications:
2.4 Example of Mini Spec (related code).
Page

<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)

(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 X 1 :
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 X 2 :
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
NOTE :
<Follow suit with remaining processes>
Process Specifications found in Appendix X 3 :
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)).

When documenting the Data Dictionary Structures and Elements try to utilize some of the following style.
Provide an overview or a lookup table for datastore, dataflow and process descriptors.
1.1. Data Store Descriptors
1.1.1. orders
2
ORDERS = { ORDER }
Content:
Description: **the orders for books placed by customers
Inputs:
Outputs:
1.1 Log Order
1.2 Check Stock
Read:
Write:
Live / daily / weekly / monthly
Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report
1.1.2. stocks
3
Content:
STOCKS = { STOCK }
Description: **the books the company retails
Inputs:
Outputs:
Read:
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

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: an order placed by a customer
Source: Process Data Store
1.1 Log Order
1 Orders
Destination: Process
Data Store
1.2 Check Stock
1 Orders
Read:
Write: status:
Live / daily / weekly / monthly
Live / daily / weekly / monthly
Disk / Paper ledger / Written Report
1.2.2. stock
Name:
Content:
Description:
@isbn+title+AUTHOR+cost+sale+SUPPLIER+level
Source: Process incomplete
Data Store incomplete
Destination: Process incomplete
Read:
Write: status:
Live / daily / weekly / monthly
Live / daily / weekly / monthly
Data Store incomplete
Disk / Paper ledger / Written Report

1.2.3. customer
Name:
Content:
Description:
@customer#+CUSTOMERDETAIL+creditlevel
Source: Process
Incomplete
Data Store incomplete
Destination:
Read:
Write:
Process incomplete
Live
Live
/ daily / weekly / monthly
/ daily / weekly / monthly
Data Store incomplete status: Disk / Paper ledger / Written Report
Follow suit with all remaining data flows.
1.3. Data Structures:
Data Structures: General Description
ADDRESS
AUTHOR house#+street+town+county+postcode fname+sname
CUSTOMERDETAIL
OITEM
SUPPLIER nametitle+sname+fname+ADDRESS+tel+fax+email title+qty sname+ADDRESS
Follow suit with all remaining data structures.
1.4. Data Elements
Data Elements:
Cost
County currency
1{char}20
Cate
Fname house#
Isbn level
£ usually from [A..Z|a..z|0..9| ,-] date
1{char}20 dd/mm/yy
1{char}3 usually numeric but can from from subset [0..9|A..Z|a..z]
10{char}10 format #-######-##-# where each # = [0..9]
integer minimum value 0
Nametitle order#
Postcode
2{char}4
1{char}4
7{char}7
[Mr|Mrs|Ms|Miss|Dr|Prof] numeric characters each [0...9] format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9]

Qty sale
Sname
Street
Title
Town integer currency
1{char}30
1{char}20
1{char}20
1{char}20 minimum value 1
£ usually from [A..Z|a..z|0..9| ,-]
usually from [A..Z|a..z|0..9| ,-] usually from [A..Z|a..z|0..9| ,-]
Follow suit with all remaining data elements.
1.5. Process Descriptors
Provide all process descriptors as follows.
DATA DICTIONARY: PROCESS DESCRIPTORS
2.1 match stock and order item
Name:
Description:
Data Inputs:
Data Outputs:
Variables:
Mini-Spec: validating that order lines can be met from present stock dataflow new order from data store 1. new orders. dataflow stock order from data store 2. stocks. 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
REPEAT
GET next ORDERITEM
IF MATCH ORDERITEM.title with any STOCKCARD.title
ENDIF
IF STOCKCARD.level <ORDERITEM.qty
DO ‘create purchase order’
DO ‘create pending order’
ELSE (STOCKCARD.level >=ORDERITEM.qty)
DO ‘deduct stock’
DO ‘record sale’
ENDIF
ELSE (NO MATCH ORDERITEM.title with any STOCKCARD.title)
**continue
UNTIL no more ORDERITEM