requirements analysis2

41
Structured Analysis

Upload: api-26872269

Post on 10-Apr-2015

453 views

Category:

Documents


8 download

TRANSCRIPT

Page 1: Requirements Analysis2

Structured Analysis

Page 2: Requirements Analysis2

Structured Analysis

• Introduced by DeMarco (1978)• Derived from the ideas of structured

programming• Tools

– Data flow diagrams– Data dictionaries– Structured English

Page 3: Requirements Analysis2

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

Page 4: Requirements Analysis2

DFD for a Customer Order Receipt

Customer Clerk Verifies Order

Customer Order File

Verified Order

Acknowledgement

Customer Order

Page 5: Requirements Analysis2

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.

Page 6: Requirements Analysis2

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

Page 7: Requirements Analysis2

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.

Page 8: Requirements Analysis2

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.

Page 9: Requirements Analysis2

Accounts Payable Vendor

Vendor Invoice

Check

Accounts payable

Vendor Data

Context-Level DFD of anAccounts Payable System

Mailing Address

Page 10: Requirements Analysis2

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

Page 11: Requirements Analysis2

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

Page 12: Requirements Analysis2

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

Page 13: Requirements Analysis2

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

Page 14: Requirements Analysis2

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

Page 15: Requirements Analysis2

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

Page 16: Requirements Analysis2

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

Page 17: Requirements Analysis2

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

°

Page 18: Requirements Analysis2

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

Page 19: Requirements Analysis2

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.

Page 20: Requirements Analysis2

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.

Page 21: Requirements Analysis2

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

Page 22: Requirements Analysis2

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

Page 23: Requirements Analysis2

• 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.

Page 24: Requirements Analysis2

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

Page 25: Requirements Analysis2

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)

Page 26: Requirements Analysis2

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)

Page 27: Requirements Analysis2

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)

Page 28: Requirements Analysis2

Weaknesses of DFDs

• Lack precise meaning• Do not define control aspects• Cannot test whether the specifications

reflect a user’s expectations

Page 29: Requirements Analysis2

Data Dictionary

Page 30: Requirements Analysis2

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.

Page 31: Requirements Analysis2

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

Page 32: Requirements Analysis2

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*

Page 33: Requirements Analysis2

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

Page 34: Requirements Analysis2

Example of Customer Order Receipt

CustomerVerify Order

Customer order fileCustomer Order

Acknowledgement

Verified Orders

Page 35: Requirements Analysis2

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

Page 36: Requirements Analysis2

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

Page 37: Requirements Analysis2

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

Page 38: Requirements Analysis2

Structured English

Page 39: Requirements Analysis2

Structured English

• Natural English written in a structured programming fashion– Sequence– Selection – Iteration

Page 40: Requirements Analysis2

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

Page 41: Requirements Analysis2

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