Structured Analysis

Structured Analysis
• Introduced by DeMarco (1978)
• Derived from the ideas of structured
programming
• Tools
– Data flow diagrams
– Data dictionaries
– Structured English
 Data Flow Diagrams
• A graphical technique to understand the data
flow, data transformation and data stores in an
information system
or

A Data Store
A Data Flow or

A Process or Data
Transformation
An External Entity
 DFD for a Customer Order Receipt

Customer
Order File

Verified Order
Customer Order
Customer Clerk
Verifies
Acknowledgement
Order
 Hierarchical Organization of DFD
• Context Level Diagram
– Identifies external entities, major data flow across the
boundary separating system from external entities,
and thus defines the context in which the system
operates.
– Normally has only one process bearing the name of
the task done by the system.
• Overview Diagram (Level-Zero/ Zero-Level
Diagram)
– Explosion of the context level DFD
– Gives overview of the major functions of the system
– Shows major data stores used in the system
• Exploded Bottom-Level Diagram
– Depending on the need a higher level DFD can
explode to many lower level one.
 Area of
Investigation

More details of the area of investigation

More details for a lower level area

Still more details for one second level area

 An Accounts Payable System
National Merchandise receives invoices from its vendors
by mail. Every morning the mail room manager, Ross
Manning, delivers all invoices and all mail addressed to
the accounts payable department to Ginny Anderson,
the accounts payable clerk, who accumulates invoices
through out the week in an accordion folder. On
Thursday, she reviews them and adds amount due and
invoice number to the vendor ledger card – a manual
record of all accounting transactions for the particular
vendor. The invoices themselves are stored
alphabetically in a filing cabinet.
Checks for payments to vendors are written and signed each
Friday. Harry Demming, manager of the accounts payable
department, reviews all accounts and outstanding invoices, and
determines which ones should be paid. He writes the check and
at the same time enters the amount of the check, name of the
vendor and the number of invoices paid in the checkbook. The
same information is entered on the ledger card of the vendor.

The checks are sent in one batch, with appropriate invoices, to

the controller Ann Williams, who reviews and signs each check.
In some cases, she disapproves the payment and returns the
checks back to Harry unsigned.

The signed checks are placed in individual envelopes and taken

to mail room for mailing to the vendors.
 Context-Level DFD of an
Accounts Payable System

Accounts
payable

Vendor
Invoice
Mailing Address
Accounts
Vendor
Payable
Check

Vendor Data
 Overview Diagram
(Zero-Level DFD)
Purchase Vendor Accounts
Orders accounts Payable Vendor Data
Purchase Mailing
Account Payable Address
Orders Details Balance Balance

Vendor 2.0 Accounts 3.0

Invoice 1.0 Due Check
Invoice Revised Write
Approval Balance Vendor
Due Checks
Vendor Vendor
Payment Batched
Voucher Invoice

Payable Invoice Check Account

Amount Balance

Checking
Accounts
 Process Hierarchy Chart
A/Cs
Payable

Approve Revise Write

Invoice balance Checks
due

Verify Revise Log Log Approve

Verify
Purchase Vendor account Checks checks
Price
Paymt info Payable
info

Accept Prepare Prepare

Verify
Invoice vendor check
invoice
payment approval
summary
 Physical and Logical DFDs
• Physical DFD
– An implementation view of the system
– Identifies physical entities in the system
• Names of persons, forms and document names and
numbers, name of the departments, master and transaction
files, equipment and devices used, locations, names of
procedures
• Logical DFD
– An implementation independent view of the system
– Does not identify physical entities in the system
– Unnecessary processes are removed
 Physical DFD of
Invoice Approval Process
Purchase Purchase
Orders Department
Vendor
Verification Ledger
PO Details
Invoice Details
Vendor
Ginny Ginny
Invoice Ginny Verifies
Verifies Accepts
Merchandise Invoice
Vendor Signature
Payment
Vouchers
Illegal Invoice Invoice
Invoices Payable
invoices
Invoices Approved
folder invoices
 Stages of Data Flow Analysis
• Physical DFD of the current system
• Logical DFD of the current system
• Logical DFD of the proposed system
• Physical DFD of the proposed system
 Purchase
Order
Purchase
Order Details
Signed 1.3
1.1 Invoice Verify
Invoice 1.5
Verify Signed merchandise Price Invoice
Invoice ordered
Invoice
Invoice Package Pricing
Details Details
Unsigned Invoice Log
Received Approved
Invoice Invoices Unverified Invoices
Invoice Audited Accept
Signed Invoice ance
Invoice
Invoice Package Details
1.2 1.4
Verify Receive 1.6
acceptance of purchase Accept Invoice
merchandise authorization

Payment
vouchers

Payable
Invoices
 Logical Association Among
Data Flows
• Multiple data inflows or outflows to or from
a process may have some logical
operational association among them
• Symbols used for this are
–* AND Connection
–° Inclusive OR
–⊕ Exclusive OR
 Tra
nsa
Rec ction
ord

* Update
ec ord Master
te rR
Mas
as te r
Master File M
dated rd
Up Reco
ac tion
Tr ans
d
Vali

Transaction
Check ⊕
for
error Inva
lid Tran
sact
ion

e
s pons
Re
ine
Onl

°
Process
Inquiry
Inquiry
Prin
ted R
espo
nce
 General Guidelines for drawing
DFDs
• Identify all inputs and outputs
• Work your way from inputs to outputs
• Label all the data flows carefully and descriptively
• Label all transforms (processes) by means of a specific transitive
verb of non-plural object.
• Classify the association of data streams to a transform in detailed
DFDs by indicating the appropriate logical connection.
• Ignore initialization and termination
• Omit the details of the error paths in the generalized levels of
DFD
• Do not show control logic such as control loop and associated
decision making.
• Do not show the flows of copies of document to various
departments
• Use levels of DFD if required
 Guideline for creating
Multilevel DFDs
• Number each process within the overview DFD.
• Identify if any process requires more detailed breakdown
of function.
• Draw lower level DFD, number it.
• Make sure inputs and outputs are matched between
parent and associated child diagrams, except for the
error path that may be present in child but absent in
parent diagram
• Repeat the procedure for every process in the DFD.
Guideline for Deriving Logical DFD
from Physical DFD
• Show the actual data in a process, not the documents
that contain them
• Remove routing information (Show the flow between
procedures not between people, offices, or locations)
• Remove tools and devices (File cabinets, folders)
• Consolidate redundant data stores.
• Remove unnecessary processes that do not change the
data or data flows or are device- dependent data
preparation or data entry activities, or duplicate other
processes.
Guideline for Drawing Logical DFD
• Only data needed to perform the process
should be input to the process.
• Any data leaving a process must be based
on data inputted to the process
 Guidelines for Explosion
• The process explosion may proceed to an extent
that ensures that a process in the lowest level
DFD has only one outflow.
• Maintain consistency between processes. New
inputs or outputs that were not identified in a
higher level may be introduced at lower level.
• Data stores and data flow that are relevant only
to inside a process are concealed until the
process is exploded into a greater detail.
• Add control on lower level diagrams only:
– Handling errors and exceptions should be done in
lower level diagrams only
– Avoid document copy description
– Avoid time description of logic or control description
– Avoid procedure control descriptions
• Assign meaningful labels
– Dataflow naming
• Name should reflect the data not the document.
• Outbound data flow should be named differently
from the inbound one
– Process Naming
• Names should contain transitive verbs and non-
plural objects
• Names should fully describe a process
• Should explain the linkage between inflows and
out flows
• Avoid vague names
• Lower processes should be much more specific
and descriptive than the higher level ones.
• Must be unique to the activities they describe.
Evaluating DFD for Correctness
• Unnamed Components
• Processes without input / output
• Processes with multiple inputs / outputs (should
be exploded)
• Adequacy/ inadequacy of input dataflow for
performing a process
• Unreferenced data source
• Unnecessary storage of data
• Presence of aliases
• Independence of a process from other
processes and dependence only on data
Common Mistakes in Drawing DFDs
1. Exclusion of Flowchart Symbols

Pass
Marks
List
Tabulate
Marks Fail
List
(Splitting Data flows) Actual No.
of Defects Actual < desired

Check
Quality
Maximum Actual > desired
Desired No.of
Defects
(Control signal from a process)
Common Mistakes in Drawing DFDs
1. Exclusion of Flowchart Symbols
Master Transaction
Record log
Get master Process
Record Transaction Transaction
Request for
master Record
(Loop)

End of
Month Status
Prepare Record
Status
Inventory Record
Master
Record
(Input signal to activate the process)
Common Mistakes in Drawing DFDs
2. Conservation of data
Sales Transaction
Record

Inventory Update Update Inventory Master

Master Record Inventory
Master

Invoice (Data input not used in a process)

Sales Transaction
Record Payment to Salesman
Update
Inventory Inventory
Master Record Master
Update Inventory Master

(Data output not justified by the input)

 Weaknesses of DFDs
• Lack precise meaning
• Do not define control aspects
• Cannot test whether the specifications
reflect a user’s expectations
Data Dictionary
 Data Dictionary – The Data about
the Data (Meta data)
Serves multiple purposes

• Documents the details about the system

components
– Data flows, data stores, and processes.
• Gives meaning to each system
component.
• Helps identifying errors omissions in the
system.
 Data Dictionary Symbols and Meaning
Symbol Meaning Explanation Type of
Relationship
= Is equivalent to Alias Equivalence

+ And Concatenation Sequencial

[] Either/Or Alternative Components Selection
{} Iterations of repetition of a Iteration
component
() Optional iterations that occurs Optional
only zero / one times
** Comments Annotation

| Separators Separates alternatives

Example
1. All the fields are mandatory
Name = First_Name + Middle_name+ Last_Name

2. Middle name is not mandatory

Name = First_Name + (Middle_name)+ Last_Name

3. First name consists of one to 20 alphabets

First_Name = 1 {Alphabetic Characters}20

4. Payment can be either in cash / cheque / draft

Payment = [cash|Cheque|Draft] *Post dated cheque is not permited*
Standards Maintained while Recording Data
Defining data flows Defining data stores
Data flow name Data store name
Description Description
From Processes Inbound data flows
To Processes Outbound data flows
Data structure Data structure
Volume
Defining processes
Access
Process name
Description
Input
Output
Logic summary
Example of Customer Order Receipt

Customer order file

Customer Order
Verify Verified
Customer Order Orders
Acknowledgement
Data Dictionary Entry for a Data Flow
Name: Customer Order

Description: It is a form that gives various details about

the customer, and the products he want,
and their specifications.

From: The External entity Customer

To: Process 1

Data Structure: Customer_Order = Customer_Order_No+

Date+ Cust_Name + Cust_Address +
1{Prod_Name+ Prod_Specification}n +
(Delivery Condition)
 Data Dictionary Entry for a Process
Process: 1
Description: The customer order is verified for its
completeness and the date of its receipt is
written on the top of the order. Further an
acknowledgement is sent to the customer.
Input: Customer Order
Output: Acknowledgement and ‘Verified Order’
Logic Summary:
Check the content of the ‘Customer Order’
Write DATE OF RECEIPT of the order on the order itself
IF some information is missing or incomplete
THEN prepare a list of missing information
send ‘acknowledgement’ asking for these missing
information.
ELSE send ‘acknowledgement’ thanking the customer
ENDIF
Data Dictionary Entry for a Data Store
Data store: Customer Order File

Description: It stores details about the customer order.

Inbound Data flows: Verified Order

outbound Data flows: None

Data Structure:
Cust_Order_Record = Customer_Order_No+
Date+ Cust_Name + Cust_Address +
1{Prod_Name+ Prod_Specification}n +
Ackn_Date+ Comments_by_Clerk

Volume: Nearly 100 are received daily and growing

10% annually.

Access: As and when necessary for processing

Structured English
 Structured English
• Natural English written in a structured
programming fashion
– Sequence
– Selection
– Iteration
Guidelines for Writing Process logic
in Structured English
• Mostly imperative statements
• Do not use unclear verbs (operate or handle)
• Do not use adjectives without precise meaning
(Some / few)
• Data flows in lower case letters within quote
• Data Store names in capital letters
• Arithmetic and Boolean symbols can be used
• Keyword in capital letter (ex. DO, WHILE, IF …)
• Keywords BEGIN and END to represent logic
blocks (Sequence)
• IF-THEN-ELSE : Selection
• WHILE-DO, REPEAT-UNTIL, FOR repetition
 Advantages of Using
Structured English
• Easily understood by the manager
– Can be used to explain the procedures and
decision situations in problem domain
• Easily understood by the developers
– Easily converted to program codes in solution
domain