Structured Analysis and Structured Design

90
Structured Analysis and Structured Design Presented by:- Sanjay kumar chakravarti Roll:-RK2R13A28 Reg.-11006964 3/15/2012 s.k.chakravarti 1

Transcript of Structured Analysis and Structured Design

Page 1: Structured Analysis and Structured Design

Structured Analysis and Structured Design

Presented by:-

Sanjay kumar chakravarti

Roll:-RK2R13A28

Reg.-11006964

3/15/2012

s.k.chakravarti

1

Page 2: Structured Analysis and Structured Design

Agenda

• Introduction

• SASD Tools and Exercises

• Pros and Cons

• Comparisons with Other Techniques

• Conclusion

• References

3/15/2012 s.k.chakravarti 2

Page 3: Structured Analysis and Structured Design

Definition of Structured analysis

• “Structured analysis is a set of techniques and graphical tools that allow the analyst to develop a new kind of system specification that are easily understandable to the user. Analysts work primarily with their wits, pencil and paper.”

3/15/2012 s.k.chakravarti 3

Page 4: Structured Analysis and Structured Design

History of SASD

• Developed in the late 1970s by DeMarco, Yourdon, and Constantine after the emergence of structured programming.

• IBM incorporated SASD into their development cycle in the late 1970s and early 1980s.

• Classical SASD was modified due to its inability to represent real-time systems.

• In 1989, Yourdon published “Modern Structured Analysis”.

3/15/2012 s.k.chakravarti 4

Page 5: Structured Analysis and Structured Design

History of SASD

• The availability of CASE tools in the 1990s enabled analysts to develop and modify the graphical SASD models.

Interesting Quote:

“There is no reason for any individual to have a computer in his home.” Kenneth H. Olson, Digital Equipment Corp. 1977.

3/15/2012 s.k.chakravarti 5

Page 6: Structured Analysis and Structured Design

Philosophy of structured analysis and design

• Analysts attempt to divide large, complex problems into smaller, more easily handled ones. “Divide and Conquer”

• Top-Down approach (Classical SA), or Middle-Out (Modern SA)

• Functional view of the problem. “Form follows function”

• Analysts use graphics to illustrate their ideas whenever possible.

• Analysts must keep a written record.

3/15/2012 s.k.chakravarti 6

Page 7: Structured Analysis and Structured Design

Philosophy of structured analysis and design

• “[The purpose of SASD] is to develop a useful, high quality information system that will meet the needs of the end user.”

[Yourdon, 1989]

3/15/2012 s.k.chakravarti 7

Page 8: Structured Analysis and Structured Design

Goals of SASD

• Improve Quality and reduce the risk of system failure

• Establish concrete requirements specifications and complete requirements documentation

• Focus on Reliability, Flexibility, and Maintainability of system

3/15/2012 s.k.chakravarti 8

Page 9: Structured Analysis and Structured Design

SASD Approach to Development Cycle

3/15/2012 s.k.chakravarti 9

Functional Architecture

System Architecture

Operational System

Existing or Foreseen Conditions

Analysis

Design

Build

Install and Operate

Requirements Definition

Page 10: Structured Analysis and Structured Design

Drivers Behind SASD Creation

• Prior to SASD, requirements were documented through text rather than graphically.

• Large problem decomposition.

• Reduces redundancies.

“If the automobile followed the same development as

the computer, a Rolls-Royce would today cost $100,

get a million miles per gallon, and explode once a year

killing everyone inside.” Robert Cringley

3/15/2012 s.k.chakravarti 10

Page 11: Structured Analysis and Structured Design

Characteristics of a Good Analysis Method

• Graphical with supporting text.

• Allow system to be viewed in a top-down and partitioned fashion.

• Minimum redundancies.

• Reader should be able to predict system behaviour.

• Easy to understand by user.

3/15/2012 s.k.chakravarti 11

Page 12: Structured Analysis and Structured Design

Elements of Structured Analysis and Design

3/15/2012 s.k.chakravarti 12

Essential Model

Environmental Model

Behavioural Model

Implementation Model

Page 13: Structured Analysis and Structured Design

Essential Model

3/15/2012 s.k.chakravarti 13

Essential Model

Environmental Model

Behavioural Model

Implementation Model

Model of what the system must do. Does not define how the system will accomplish its purpose. Is a combination of the environmental and behavioural model.

Page 14: Structured Analysis and Structured Design

Environmental Model

3/15/2012 s.k.chakravarti 14

Essential Model

Environmental Model

Behavioural Model

Implementation Model

Defines the scope of the proposed system. Defines the boundary and interaction between the system and the outside world. Composed of: Statement of Purpose, Context Diagram, and Event List.

Page 15: Structured Analysis and Structured Design

Behavioural Model

3/15/2012 s.k.chakravarti 15

Essential Model

Environmental Model

Behavioural Model

Implementation Model

Model of the internal behaviour and data entities of the system. Models the functional requirements. Composed of Data Dictionary, Data Flow Diagram, Entity Relationship Diagram, Process Specification, and State Transition Diagram.

Page 16: Structured Analysis and Structured Design

Implementation Model

3/15/2012 s.k.chakravarti 16

Essential Model

Environmental Model

Behavioural Model

Implementation Model

Maps the functional requirements to the hardware and software. Minimizes the cost of development and maintenance. Determines which functions should be manual vs. automated. Can be used to discuss the costs-benefits of functionality with the users/stakeholders. Defines the Human-Computer Interface. Defines non-functional requirements. •Tool: Structure Charts

Page 17: Structured Analysis and Structured Design

Analysis & Design Process

3/15/2012 s.k.chakravarti 17

Time

Activ

ity

Statement of Purpose

Context Diagram

Event List

DFD

ERD

Data Dictionary

State Transition Diagram

Structure Charts

Environmental Model

Behavioural Model

Implementation Model

Process Specification

Page 18: Structured Analysis and Structured Design

Statement of Purpose

• A clear and concise textual description of the purpose for the system.

• It is deliberately vague.

• It is intended for top level management, user management, and others who are not directly involved in the system.

3/15/2012 s.k.chakravarti 18

Page 19: Structured Analysis and Structured Design

Statement of Purpose - Example

• “The purpose of the credit card system is to provide a means for the company to extend credit to the customer. The system will handle details of credit application, credit management, billing, transaction capture, remittance, and management reporting. Information about transactions should be available to the corporate accounting system.”

3/15/2012 s.k.chakravarti 19

Page 20: Structured Analysis and Structured Design

Context Diagram - Purpose

• Highlights the boundary between the system and the outside world.

• Highlights the people, organizations, and outside systems that interact with the system under development.

• Special case of the data flow diagram.

3/15/2012 s.k.chakravarti 20

Page 21: Structured Analysis and Structured Design

Context Diagram - Notation

3/15/2012 s.k.chakravarti 21

Process - Represents the proposed system

Terminator - Represents the external entities

Flow - Represents the in and out data flows

Page 22: Structured Analysis and Structured Design

Context Diagram - Example

3/15/2012 s.k.chakravarti 22

Credit Card Processing

Customer

Collection Company

Corporate Accounting

System Store

Customer Service Application

Bills

Payment

Transaction

Payment

Overdue Accounts

Credit

Account Summary

Page 23: Structured Analysis and Structured Design

Event List - Purpose

• A list of the events/stimuli outside of the system to which it must respond.

• Similar to “use-cases”

3/15/2012 s.k.chakravarti 23

Page 24: Structured Analysis and Structured Design

Event List - Types

• Flow Oriented Event. (Process is triggered by incoming data).

• Temporal Event. (Process is triggered by internal clock).

• Control Event. (Process is triggered by an external unpredictable event).

3/15/2012 s.k.chakravarti 24

Page 25: Structured Analysis and Structured Design

Event List - Example

• Customer applies for a credit card.

• Customer makes a transaction at a store.

• Customer pays a bill.

• Customer disputes charges.

• Customer Service changes credit terms.

3/15/2012 s.k.chakravarti 25

Page 26: Structured Analysis and Structured Design

Data Flow Diagram - Purpose

• Provides a means for functional decomposition.

• Primary tool in analysis to model data transformation in the system.

3/15/2012 s.k.chakravarti 26

Page 27: Structured Analysis and Structured Design

Data Flow Diagram - Notation

3/15/2012 s.k.chakravarti 27

Represents the external entities

Represents data flows

Represents functions in the system

Represents data stores

Page 28: Structured Analysis and Structured Design

Data Flow Diagram - Example

3/15/2012 s.k.chakravarti 28

1.0 Customer* Store

2.0

3.0

4.0

New Customer

Account

Transactions

Process Application

Bill Customer

Process Payment

Transaction Capture

5.0

Determine Overdue Accounts

Collection Company

Customer Service

Cards

Transaction

Transaction

Transaction

Overdue Account

Credit Terms

Card Number

Account Details

Open to Buy

Customer* Cheque

Authorization

Transaction Total

Cheque Amount

Status

Overdue Amount

Page 29: Structured Analysis and Structured Design

Data Flow Diagram - Leveling

3/15/2012 s.k.chakravarti 29

4

Process Payment

cheque

amount, account

4.1

Read Payment

4.3

Process Payment

4.4

Update Account

Account

4.2

Check Status

cheque

amount, account

Page 30: Structured Analysis and Structured Design

Data Flow Diagram – Validation

3/15/2012 s.k.chakravarti 30

Black Hole

Spontaneous

Page 31: Structured Analysis and Structured Design

Data Flow Diagram – Validation

3/15/2012 s.k.chakravarti 31

Page 32: Structured Analysis and Structured Design

Context diagram - Exercise

• System context diagram

3/15/2012 s.k.chakravarti 32

Pay- invoice Vendor

accounting

management

invoice

payment

Cash requirements-report

Payment authorization

Cash-requirement report

[Kendall 1996]

Page 33: Structured Analysis and Structured Design

Data Flow Diagram - Exercise

• Build a level 0 DFD

3/15/2012 s.k.chakravarti 33

Page 34: Structured Analysis and Structured Design

Data Flow Diagram-level 0 Solution

3/15/2012 s.k.chakravarti 34

vendors Purchase orders

Packing slip item details

Packing slip details

Pending invoices

Purchase order item details

invoice Valid invoice details

Cash requirements report

payment

Payment authorization

payment authorization (Manual)

Check valid Invoice

1. Check Invoice

Payment authorization

2.

Produce Payment

3.

Page 35: Structured Analysis and Structured Design

Data Dictionary - Purpose

• Defines data elements to avoid different interpretations.

3/15/2012 s.k.chakravarti 35

Page 36: Structured Analysis and Structured Design

Data Dictionary - Purpose

• Example: – Alien: “What’s a name?”

– Person: “Well, you know, it’s just a name. It’s what we call each other.”

– Alien: “Does that mean you can call them something different when you are angry or happy?”

– Person: “No, of course not. A name is the same all the time.”

– Alien: “Now I understand. My name is 3.141592653”.

– Person: “Oh your name is PI…But that’s a number, not a name. But what about your first and last name. Or is your first name 3, and your last name 141592653?”

3/15/2012 s.k.chakravarti 36

Page 37: Structured Analysis and Structured Design

Data Dictionary – Notation

• = is composed of

• + and

• () element is optional

• {} iteration

• [] select one of a list of elements

• | seperates choices of elements

• ** comments

• @ identifier for a store (unique id)

3/15/2012 s.k.chakravarti 37

Page 38: Structured Analysis and Structured Design

Data Dictionary - Examples

• Element Name = Card Number

• Definition = *Uniquely identifies a card*

• Alias = None

• Format = LD+LD+LD+LD+SP+ LD+LD+LD+LD+SP+

LD+LD+LD+LD+SP+

LD+LD+LD+LD

• SP = “ “ *Space*

• LD = {0-9} *Legal Digits*

• Range = 5191 0000 0000 0000 to 5191 9999 9999 9999

3/15/2012 s.k.chakravarti 38

Page 39: Structured Analysis and Structured Design

Data Dictionary - Exercise

3/15/2012 group 3: SASD 39

Build data dictionary items for the vendor name and vendor address

Page 40: Structured Analysis and Structured Design

Data dictionary - Solution

3/15/2012 s.k.chakravarti 40

Element Name = Vendor Name Alias = none Format = 30 characters Element Name = Vendor Address Alias = none Format =Vendor street + Vendor city + Vendor Province + Vendor Postal Code + Vendor Country

Page 41: Structured Analysis and Structured Design

Entity Relationship Diagram (ERD) - Purpose

• A graphical representation of the data layout of a system at a high level of abstraction.

• Defines data elements and their inter-relationships in the system.

3/15/2012 s.k.chakravarti 41

Page 42: Structured Analysis and Structured Design

Entity Relationship Diagram - Notation

3/15/2012 s.k.chakravarti 42

Data Element

Relationship

Associated Object

Cardinality – Exactly one

Cardinality – Zero or one

Cardinality – Mandatory Many

Cardinality – Optional Many

Page 43: Structured Analysis and Structured Design

Entity Relationship Diagram - Example

3/15/2012 s.k.chakravarti 43

Accounts

Cards

Transactions

Transaction_ products

Bills Payments

receive

are made of

pay for include

contains

generate

Page 44: Structured Analysis and Structured Design

Entity Relationship Diagram - Exercise

Create an ERD for the Warm Boot Manufacturing System

3/15/2012 s.k.chakravarti 44

Page 45: Structured Analysis and Structured Design

Entity-Relationship diagram - Solution

3/15/2012 s.k.chakravarti 45

INVENTORY-ITEMS

orders

PURCHASE-ORDER ITEM-DETAILS

itemizes

PURCHASE-ORDERS

Bills for PENDING-INVOICES

includes PACKING-SLIP- DETAILS

VENDORS

itemizes

receives PACKING-SLIP- ITEM-DETAILS

Owed

to

Purchases from

Page 46: Structured Analysis and Structured Design

Structure Charts - Purpose

• Functional Decomposition (Divide and conquer)

• Information hiding

• Modularity

• Low coupling

• High internal cohesion

3/15/2012 s.k.chakravarti 46

Page 47: Structured Analysis and Structured Design

Transform Analysis

3/15/2012 s.k.chakravarti 47

Customer

4.1

Read Payment

4.2

Edit Payment

4.3

Process Payment

4.4

Update Balance

4.5

Update Open To

Buy

cheque, bill stub

edited payment

payment

Accounts

4.6

Insert Payment

Payments

payment

account, amount

account, amount

account, amount

account, amount

Afferent Flow

Efferent Flow

Central Transform

Page 48: Structured Analysis and Structured Design

Structure Charts

3/15/2012 s.k.chakravarti 48

Input (Afferent Flow)

Process Central Transform)

Output (Efferent Flow)

Input Process Output

Control

Page 49: Structured Analysis and Structured Design

Structure Charts - Notation

3/15/2012 s.k.chakravarti 49

Modules

Library modules

Module call

Data

Flag

Page 50: Structured Analysis and Structured Design

Structure Charts - Cohesion

Functional Elements are combined to complete one specific function.

Sequential Elements are combined because data flows from one step to

another.

• Communicational Elements are combined because they all act on one data store.

Procedural Elements are combined because control flows from one step to

another.

3/15/2012 s.k.chakravarti 50

Page 51: Structured Analysis and Structured Design

Structure Charts - Cohesion

Temporal Statements are together because they occur at the same time.

Logical Elements are together because of their type of function such as all edits.

Coincidental Elements are grouped together randomly

3/15/2012 s.k.chakravarti 51

Page 52: Structured Analysis and Structured Design

Structure Charts - Coupling

Indirect relationship Modules are independent and there is no way to communicate.

Data Only necessary data is passed between two modules.

Stamp A data structure is passed to a module but the module only needs a

portion of the data in the data structure.

Control Flags are passed between modules.

3/15/2012 s.k.chakravarti 52

Page 53: Structured Analysis and Structured Design

Structure Charts - Coupling

External Two or more modules reference the same piece of external data . This is

unavoidable in traditional batch processing.

Common Modules access data through global variables.

Content One module changes the data of another module.

3/15/2012 s.k.chakravarti 53

Page 54: Structured Analysis and Structured Design

Structure Charts - Example

3/15/2012 s.k.chakravarti 54

Process Payment Control

Get Payment Process Payment

Write Payment

Read Record

Edit Record

Update Account

Insert Payment

Event

Raw Payment

Raw Payment

Payment

Payment Error

Payment

Payment Error

Payment Process Today

Payment

Payment

Payment

Page 55: Structured Analysis and Structured Design

Process Specifications - Purpose

• Shows process details which are implied but not shown in a DFD.

• Specifies the input, output, and algorithm of a module in the DFD.

• Normally written using pseudo-code.

3/15/2012 s.k.chakravarti 55

Page 56: Structured Analysis and Structured Design

Process Specifications - Example

3/15/2012 s.k.chakravarti 56

Apply Payment For all payments If payment is to be applied today or earlier And has not yet been applied Read account Read amount Add amount to account’s open to buy Add amount to account’s balance Update payment as applied

Page 57: Structured Analysis and Structured Design

State Transition Diagram - Purpose

• Shows the time ordering between processes

3/15/2012 s.k.chakravarti 57

Page 58: Structured Analysis and Structured Design

State Transition Diagram – Notation

3/15/2012 s.k.chakravarti 58

Objects

Transitions

Page 59: Structured Analysis and Structured Design

State Transition Diagram – Example

3/15/2012 s.k.chakravarti 59

Create New Account. No Balance

Account application

Active Account. Balance

Customer makes purchase

Customer makes purchase

Customer pays bills

Bad Debt Account. Balance

Customer request to

close account & pays balance

Closed Account.

No Balance

Customer does not pay bills

Page 60: Structured Analysis and Structured Design

Following steps

• Draw structure chart for each function

• Document process description for each module(Detailed Design)

• Document data dictionary(add flags and

the files’ structures into analysis dictionary)

• Report, screen and source Document Design

3/15/2012 s.k.chakravarti 60

Page 61: Structured Analysis and Structured Design

Pros of SASD

• It has distinct milestones, which allows for easier project management tracking

• Very visual – easier for users/programmers to understand

• Makes good use of graphical tools

• Well known in industry

• A mature technique

• Process-oriented approach is a natural way of thinking

3/15/2012 s.k.chakravarti 61

Page 62: Structured Analysis and Structured Design

Pros of SASD

• Flexible

• Provides a means of requirements validation

• Relatively simple and easy to read

3/15/2012 s.k.chakravarti 62

Page 63: Structured Analysis and Structured Design

Pros of SASD

Context Diagram: • Provides a black box overview of the system and the environment

Event List: • Provides guidance for functionality

• Provides a list of system inputs and outputs

• Means of requirements summarization

• Can be used to define test cases

DFD: • Ability to represent data flows

• Functional decomposition- divide and conquer

3/15/2012 s.k.chakravarti 63

Page 64: Structured Analysis and Structured Design

Pros of SASD

Data Dictionary: • Simplifies data requirements

• Used at high or low level analysis

ERD: • Commonly used; well understood

• Graphical tool; easy to read by analysts

• Data objects and relationships are portrayed independently from the processes

• Can be used to design database architecture

• Effective tool to communicate with DBAs

3/15/2012 s.k.chakravarti 64

Page 65: Structured Analysis and Structured Design

Pros of SASD

Process Specifications: • Expresses the process specifications in a form that can be verified.

State Transition Diagrams: • Models real time behaviour

Structure Charts: • Modularity improves system maintainability

• Provides a means for transition from analysis to design

• Provides a synchronous hierarchy of modules

3/15/2012 s.k.chakravarti 65

Page 66: Structured Analysis and Structured Design

Cons of SASD

• It ignores non-functional requirements

• Minimal management involvement

• Non-iterative; waterfall approach

• Not enough user-analyst interaction

• Doesn’t provide a communication process with users

• Hard to decide when to stop decomposing

3/15/2012 s.k.chakravarti 66

Page 67: Structured Analysis and Structured Design

Cons of SASD

• Doesn’t address stakeholders’ needs

• Doesn’t work well with Object-Oriented programming languages

3/15/2012 s.k.chakravarti 67

Page 68: Structured Analysis and Structured Design

Cons of SASD

Context Diagram: • Does not provide a specific means to determine the scope of the system.

Event List: • Does not define all functionality (ex. Edits)

• Does not define specific mechanism for interaction.

DFD: • Weak display of input/output detail

• Users find it confusing initially

• Do not represent time

• No implied sequencing

• Assign data stores early in the analysis with little deliberation

3/15/2012 s.k.chakravarti 68

Page 69: Structured Analysis and Structured Design

Cons of SASD

Data Dictionary: • No functional details

• Formal language is confusing to users

ERD: • May be confusing for users; formal notation

• Complex in large systems

Structure Charts: • Does not work well for asynchronous processes such as networks

• Could be too large to be effectively understood with large programs.

3/15/2012 s.k.chakravarti 69

Page 70: Structured Analysis and Structured Design

Cons of SASD

Process Specifications: • They may be too technical for the users

• Difficult to stay away from the current “How”

State Transition Diagrams: • Explains what action causes a state change but not when or how often

3/15/2012 s.k.chakravarti 70

Page 71: Structured Analysis and Structured Design

Where to use SASD?

• In well known problem domains

• With contract projects where SRS is specified

• In both real-time systems and transaction processing systems

• Not appropriate when time to market is short

3/15/2012 s.k.chakravarti 71

Page 72: Structured Analysis and Structured Design

SASD vs. OOAD

Similarities • Both SASD and OOAD had started off from programming techniques

• Both techniques use graphical design and graphical tools to analyze and model the requirements.

• Both techniques provide a systematic step-by-step process for developers

• Both techniques focus on documentation of the requirements

3/15/2012 s.k.chakravarti 72

Page 73: Structured Analysis and Structured Design

SASD vs. OOAD

Differences • SASD is Process-Oriented

• OOAD is Data-Oriented

• Another difference is that OOAD encapsulates as much of the systems' data and processes into objects

• while SASD separates between them

3/15/2012 s.k.chakravarti 73

Page 74: Structured Analysis and Structured Design

SASD vs. Agile Methods

3/15/2012 s.k.chakravarti 74

similarities:

facilitate stakeholder communication

Page 75: Structured Analysis and Structured Design

SASD vs. Agile Methods (1)

Differences SASD emphasizes requirement documentation

Agile supports a process of requirements elicitation SASD uses top-down process from analysis to design Agile uses incremental process from requirement elicitation to final system integration and delivery SASD uses formal analysis and design tools for each step, such as data flow diagram. Agile Methods have solid technique for requirement analysis and design, Agile Methods use pair programming, test first and customer onsite techniques. SASD is performed by analysts, users and designers Agile Methods team involve project manager, customers and programmers

3/15/2012 s.k.chakravarti 75

Page 76: Structured Analysis and Structured Design

SASD vs. Agile Methods (2)

Differences • SASD focuses on building a design model

• Agile methods don't allow for too much planning

• Agile methods use prototyping with short iterative life cycles

• SASD requires longer life cycles because of the analysis and design involved

• SASD is good for long term planning

• Agile Methods is good for short term quick software releases

• Agile methods require frequent user interaction

• SASD doesn't require too much user interaction

3/15/2012 s.k.chakravarti 76

Page 77: Structured Analysis and Structured Design

SASD vs. Cleanroom

3/15/2012 s.k.chakravarti 77

Similarities: • Both use top-down development process

Both use decomposition to analyze the system Both use diagrams to demonstrate different components of the system: - Context Diagram VS. Black Box - State Transition Diagram VS. State Box - Data Flow Diagram VS. Clear Box

Page 78: Structured Analysis and Structured Design

SASD vs. Cleanroom

Differences:

• SASD emphasizes on requirement documentation and facilitate human communication

Cleanroom doesn’t support requirement elicitation SASD is non-iterative in both analysis and design phases Cleanroom uses incremental development and go through requirement analysis, design,

coding and verification

SASD uses system modeling techniques from different system perspectives and uses modularity design techniques with tool support

• Cleanroom uses usage model, box structure design, formal specification and statistical certification techniques

SASD is performed by analysts, users and designers • Cleanroom needs cooperation of different teams in different development

phases.

3/15/2012 s.k.chakravarti 78

Page 79: Structured Analysis and Structured Design

SASD vs. QFD

3/15/2012 s.k.chakravarti 79

Similarities: Both involve analysts and system designers

Both used in requirements analysis

Page 80: Structured Analysis and Structured Design

SASD vs. QFD

Differences: SASD supports human communication and requirement documentation

QFD prioritizes customer requirements for requirement analysis SASD uses top-down decomposition process from requirements analysis to system design QFD uses prioritizing and comparison of customer requirements and techniques from analysis to design

SASD uses system modeling techniques and tools aided by system specification QFD uses HOQ matrix for prioritizing and comparisons SASD is performed mainly by development team and discussed with users if it is

necessary QFD involves development team, customer, market analysts and system analysts. It emphasize on customer consideration.

3/15/2012 s.k.chakravarti 80

Page 81: Structured Analysis and Structured Design

SASD vs. QFD

Differences:

• SASD takes us a step further than QFD into building an implementation model

• QFD is used mostly for competitor analysis for generic products

• SASD is used to build user-specific systems

3/15/2012 s.k.chakravarti 81

Page 82: Structured Analysis and Structured Design

SASD vs. JAD

3/15/2012 s.k.chakravarti 82

Similarities: • Both support customer-analyst communication and requirements

documentation Both need user support

Page 83: Structured Analysis and Structured Design

SASD vs. JAD

Differences:

SASD uses top-down decomposition process for requirements analysis and system design JAD uses knowledge sharing and decision making by defined group session steps at the beginning of requirement elicitation and system design SASD uses system modeling with tools support JAD uses group session to share information from users and make decision jointly SASD is performed by mainly system analysts and designers JAD needs a session leader, executive sponsor, a specialist, one analyst. JAD requires good communication between users and analysts SASD focuses more on analysis and design without much interaction with users JAD focuses on Customer satisfaction SASD focuses on quality design

3/15/2012 s.k.chakravarti 83

Page 84: Structured Analysis and Structured Design

SASD vs. SSM

3/15/2012 s.k.chakravarti 84

Similarities: • Both focus on communication with stakeholders • Both have consideration of organizational/user impact • Both have the ability to model requirements

Page 85: Structured Analysis and Structured Design

SASD vs. SSM

3/15/2012 s.k.chakravarti 85

Differences: SSM uses Rich Pictures to record the systems analysis SASD uses DFD’s to record the requirements analysis SSM is goal-driven to a desirable future system SASD starts with current situation and tries to improve it SASD has a limited boundary to build or improve a system SSM considers a broad view of the environment (world view)

Page 86: Structured Analysis and Structured Design

Class Discussion of SASD

• Have you ever used SASD?

• Does it reduce maintainability costs?

• Is it Useful?

• Is it efficient?

• Is it appropriate for E-commerce development?

3/15/2012 s.k.chakravarti 86

Page 87: Structured Analysis and Structured Design

Conclusion(1)

• SASD is a process-driven software analysis technique

• It has a long history in the industry and it is mature

• It provides a good documentation for requirements

3/15/2012 s.k.chakravarti 87

Page 88: Structured Analysis and Structured Design

Conclusion (2)

• The Environmental Model: - Statement of Purpose

- Context Diagram

- Event List

• The Behavioural Model: - Data Flow Diagram

- Process Specification

- Data Dictionary

- Entity-Relationship Diagram

• The Implementation Model:

- Structure Diagram

3/15/2012 s.k.chakravarti 88

Page 89: Structured Analysis and Structured Design

References

• “Introduction to System Analysis and Design:a Structured Approach”, Penny A. Kendall, Northern Illinois University.

• “Systems Analysis And Design”, elias M. Awad, Mclntire school of Commerce, University of Virginia.

• “Structured Analysis for Requirements Definition”, Ross, Douglas T., Schoman, Kenneth E. JR., IEEE Transactions on Software Engineering, January 1977, Pg 6-15.

• “Structured Analysis/Structured Design”, Englehart, Kevin,

http://www.ee.unb/kengleha/courses/CMPE3213/Sasd.html

3/15/2012 s.k.chakravarti 89

Page 90: Structured Analysis and Structured Design

THANKS