Structured Analysis
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
orA Data Flow
A Process or Data Transformation
A Data Store
An External Entity
DFD for a Customer Order Receipt
Customer Clerk Verifies Order
Customer Order File
Verified Order
Acknowledgement
Customer 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 SystemNational 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.
Accounts Payable Vendor
Vendor Invoice
Check
Accounts payable
Vendor Data
Context-Level DFD of anAccounts Payable System
Mailing Address
Overview Diagram (Zero-Level DFD)
1.0Invoice
Approval
Purchase Orders
Vendor
Vendor Invoice Check
Payable Invoice
Payment Voucher
Batched Invoice
Vendor accounts
Accounts Payable
Checking Accounts
Vendor
Accounts Due
Check Amount
Account Balance
Account Balance
Payable Balance
2.0Revised Balance
Due
3.0Write
Vendor Checks
Purchase Orders Details
Vendor DataMailing Address
Process Hierarchy ChartA/Cs
Payable
Revise balance
due
Revise Vendor
Paymt info
Log account Payable
info
Approve Invoice
Accept Invoice
Verify Purchase
Verify invoice
Verify Price
Write Checks
Prepare check
approval summary
Log Checks
Prepare vendor
payment
Approve checks
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
Ginny Verifies
SignatureVendor
Vendor Invoice
Purchase Orders
Ginny Verifies Merchandise
Ginny Accepts Invoice
Illegal Invoices
Invoices folder
Invoice Invoice
Purchase Department
PO DetailsVerification
Approved invoices
Vendor Ledger
Payable invoices
Invoice Details
Payment Vouchers
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
Received Invoices
1.2Verify
acceptance of merchandise
1.3Verify
merchandise ordered
1.4Receive purchase
authorization
1.5Price Invoice
1.6Accept Invoice
1.5Price Invoice
1.1Verify Signed
Invoice
Approved Invoices
Purchase Order
Invoice
Unsigned Invoice
Signed Invoice
Signed Invoice
Invoice Details
Invoice Log
Payable Invoices
Invoice Package
Unverified Invoice
Purchase Order Details
Invoice Package
Pricing Details
Audited Invoice
Acceptance
Details
Payment vouchers
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
Master File
Transaction Record
Master Record
Updated Master
Record
*
Transaction
Update Master
Check for
error
⊕Valid Transaction
Invalid Transaction
Inquiry Process Inquiry
Online Response
Printed Responce
°
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 DFDs1. Exclusion of Flowchart Symbols
MarksTabulate
Marks
Pass List
Fail List
(Splitting Data flows) Actual No. of Defects
Maximum Desired No.of
Defects
Actual > desired
Check Quality
Actual < desired
(Control signal from a process)
Common Mistakes in Drawing DFDs1. Exclusion of Flowchart Symbols
Get master Record
Master Record
Request for master Record
Process Transaction
Transaction log
Transaction
(Loop)
Master Record
End of Month
Inventory Master Record
Prepare Status Record
Status Record
(Input signal to activate the process)
Common Mistakes in Drawing DFDs2. Conservation of data
Update Inventory
Master
Sales Transaction Record
Inventory Master Record
Invoice
Update Inventory Master
(Data input not used in a process)
Update Inventory
Master
Sales Transaction Record
Inventory Master Record Update Inventory Master
Payment to Salesman
(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
Separates alternativesSeparators|
AnnotationComments**
Optionaliterations that occurs only zero / one times
Optional()
Iterationrepetition of a component
Iterations of{}SelectionAlternative ComponentsEither/Or[]SequencialConcatenationAnd+
EquivalenceAliasIs equivalent to=
Type of Relationship
ExplanationMeaningSymbol
Example1. All the fields are mandatoryName = First_Name + Middle_name+ Last_Name
2. Middle name is not mandatoryName = First_Name + (Middle_name)+ Last_Name
3. First name consists of one to 20 alphabetsFirst_Name = 1 {Alphabetic Characters}20
4. Payment can be either in cash / cheque / draftPayment = [cash|Cheque|Draft] *Post dated cheque is not permited*
Standards Maintained while Recording DataDefining data flows
Data flow nameDescriptionFrom ProcessesTo ProcessesData structure
Defining data stores
Data store name DescriptionInbound data flowsOutbound data flowsData structureVolumeAccessDefining processes
Process nameDescriptionInputOutputLogic summary
Example of Customer Order Receipt
CustomerVerify Order
Customer order fileCustomer Order
Acknowledgement
Verified Orders
Name: Customer Order
Description: It is a form that gives various details aboutthe 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 Data Flow
Process: 1Description: 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 OrderOutput: Acknowledgement and ‘Verified Order’Logic Summary:
Check the content of the ‘Customer Order’Write DATE OF RECEIPT of the order on the order itselfIF some information is missing or incompleteTHEN prepare a list of missing information
send ‘acknowledgement’ asking for these missing information.
ELSE send ‘acknowledgement’ thanking the customerENDIF
Data Dictionary Entry for a Process
Data store: Customer Order File
Description: It stores details about the customer order.
Inbound Data flows: Verified Orderoutbound 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
Data Dictionary Entry for a Data Store
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