Requirements Analysis2

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 Flow

A Process or Data Transformation

or

An External Entity

A Data Store

DFD for a Customer Order Receipt Customer Order File

Verified Order

Customer Order

Customer Acknowledgement

Clerk Verifies 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 Accounts Payable

Vendor

Mailing Address

Check

Vendor Data

Overview Diagram (Zero-Level DFD) Purchase Orders Purchase Orders Details Vendor Invoice

Vendor accounts Account Balance

2.0 Revised Balance Due

1.0 Invoice Approval

Accounts Payable Payable Balance Accounts Due

Vendor Data Mailing Address

3.0 Write Vendor Checks

Vendor

Check

Vendor Payment Voucher

Batched Invoice

Payable Invoice

Check Amount

Account Balance Checking Accounts

Process Hierarchy Chart A/Cs Payable

Approve Invoice

Verify Purchase

Verify invoice

Write Checks

Revise balance due

Revise Vendor Paymt info

Verify Price

Accept Invoice

Log account Payable info

Log Checks

Prepare vendor payment

Approve checks

Prepare check 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 Department

Purchase Orders

Vendor Ledger

Verification

PO Details

Invoice Details Vendor Invoice

Vendor

Ginny Verifies Signature

Ginny Accepts Invoice

Ginny Verifies Merchandise

Payment Vouchers Illegal Invoices

Invoice

Invoice Payable invoices

Invoices folder

Approved 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 Invoice

1.1 Verify Signed Invoice

Unsigned Invoice

1.2 Verify acceptance of merchandise

Signed Invoice

1.3 Verify merchandise ordered Invoice Invoice Package Details

Received Invoices Signed Invoice

Approved Invoices

Unverified Invoice

Invoice Package

1.4 Receive purchase authorization

1.5 Price Invoice Pricing Details Invoice Log Audited Invoice

Accept ance Details

1.6 Accept Invoice 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 Master

*

te Mas

Master File

ord c e rR

te r s a M ted rd a d Up Reco

tion c a ans r T d Vali

Transaction

ine Onl

Inquiry

Process Inquiry

°

Check for error

e ons p s Re

Prin ted R espo nce

⊕ Inva lid

Tran sact ion

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 nonplural 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 Marks Tabulate Marks

Pass List Fail List

(Splitting Data flows)

Actual No. of Defects

Actual < desired

Check Quality Maximum Desired No.of Defects

Actual > desired

(Control signal from a process)

Common Mistakes in Drawing DFDs 1. Exclusion of Flowchart Symbols Master Record Get master Record

Transaction log Process Transaction

Transaction

Request for master Record (Loop) End of Month Inventory Master Record

Prepare Status Record

Status Record

(Input signal to activate the process)

Common Mistakes in Drawing DFDs 2. Conservation of data Sales Transaction Record

Update Inventory Master

Inventory Master Record

Invoice

Update Inventory Master

(Data input not used in a process)

Sales Transaction Record Inventory Master Record

Payment to Salesman

Update Inventory 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 Either/Or Iterations of

Sequencial Selection Iteration

()

Optional

**

Comments

Concatenation Alternative Components repetition of a component iterations that occurs only zero / one times Annotation

|

Separators

Separates alternatives

Optional

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 Description From Processes To Processes Data structure

Data store name Description Inbound data flows Outbound data flows Data structure Volume Access

Defining processes Process name Description Input Output Logic summary

Example of Customer Order Receipt Customer order file Customer Order Customer Acknowledgement

Verify Order

Verified Orders

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