SASD Analysis and Design

Structured Analysis and Structured
Design

Presented by:-
Sanjay kumar chakravarti
Roll:-RK2R13A28
Reg.-11006964

3/15/2012 s.k.chakravarti 1

Agenda
• Introduction
• SASD Tools and Exercises
• Pros and Cons
• Comparisons with Other Techniques
• Conclusion
• References


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


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


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.


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.

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]


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


SASD Approach to Development Cycle

Existing or Install and Operate
Foreseen
Requirements Conditions
Definition Analysis
Functional Design
Architecture
System Build
Architecture
Operational
System


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


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.


Elements of Structured Analysis and
Design

Essential Model

Environmental Behavioural
Model Model

Implementation Model


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

Essential Model

Model Model


Environmental 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. Essential Model

Model Model


Behavioural 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. Essential Model

Model 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 Essential Model

requirements. Environmental
Model
Behavioural
Model
•Tool: Structure Charts

Analysis & Design Process
Environmental Model

Statement of
Behavioural Model
Purpose
Implementation
Activity

Context Diagram
Event List Data Dictionary Model
ERD
DFD
Process Specification
State Transition
Diagram
Structure Charts

Time

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.


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


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.


Context Diagram - Notation

Process - Represents the proposed system

Terminator - Represents the external entities

Flow - Represents the in and out data flows


Context Diagram - Example

Customer Service
Application
Customer Credit
Bills
Payment Credit Card Overdue Collection
Processing Accounts Company
Corporate
Accounting Account Transaction
System Summary
Payment Store


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

• Similar to “use-cases”


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


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.


Data Flow Diagram - Purpose
• Provides a means for functional
decomposition.
• Primary tool in analysis to model data
transformation in the system.


Data Flow Diagram - Notation

Represents functions in the system

Represents the external entities

Represents data flows

Represents data stores


Data Flow Diagram - Example
New
Transaction
Customer
Customer* 1.0 2.0
Store
Card Transaction
Process
Number Open to Capture Authorization
Application
Cards Buy
Account
Details
Transaction
Account
3.0
Transaction Total
Transaction
Bill
Transactions
Customer

Cheque
Amount Credit Terms
Status

Overdue
5.0 Customer
Amount
Service
4.0
Determine Overdue Account
Overdue
Process
Accounts
Payment Cheque
Customer*
Collection
Company

Data Flow Diagram - Leveling
cheque

cheque 4.1 4.2
4.4
Read Check
Payment Status Update
4 Account

Process
Payment 4.3

Process

amount,
Payment

account
amount,
Account account

Data Flow Diagram – Validation

Black Hole

Spontaneous


Data Flow Diagram – Validation


Context diagram - Exercise
• System context diagram

Cash
invoice requirements-report
Pay-
Vendor invoice management
Payment
payment authorization

Cash-requirement
report

accounting

[Kendall 1996]

Data Flow Diagram - Exercise
• Build a level 0 DFD


Data Flow Diagram-level 0
Solution

2.
1. Valid invoice details
Check Invoice
invoice Check valid
Payment Cash requirements report
Invoice
authorization

Purchase order
Packing slip item details
details
vendors
Purchase
orders
Pending
Packing slip
invoices
item details
Payment authorization

3.
payment authorization
(Manual) Produce
payment
Payment


Data Dictionary - Purpose
• Defines data elements to avoid different
interpretations.


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?”


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)


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


Data Dictionary - Exercise

Build data dictionary items for the vendor name and vendor
address

3/15/2012 group 3: SASD 39

Data dictionary - Solution

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


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.


Entity Relationship Diagram - Notation

Data Element

Relationship

Associated Object
Cardinality – Exactly one
Cardinality – Zero or one
Cardinality – Mandatory Many
Cardinality – Optional Many

Entity Relationship Diagram - Example

Payments
receive Bills
are made
generate
Accounts of

Transactions
contains
pay for include

Cards
Transaction_
products

Entity Relationship Diagram - Exercise
Create an ERD for the Warm Boot Manufacturing System


Entity-Relationship diagram - Solution

PACKING-SLIP-
INVENTORY-ITEMS receives ITEM-DETAILS

orders itemizes

PURCHASE-ORDER
ITEM-DETAILS
includes PACKING-SLIP-
DETAILS

itemizes

Purchases VENDORS
PURCHASE-ORDERS from

Bills for PENDING-INVOICES Owed
to


Structure Charts - Purpose
• Functional Decomposition (Divide and
conquer)
• Information hiding
• Modularity
• Low coupling
• High internal cohesion


Transform Analysis
Central 4.6 payment
Customer Transform Insert
4.3 Payment
cheque, Process Payments
bill stub Payment account, 4.5
4.1
amount Update
Read
Payment account, Open To
amount Buy
payment 4.4
edited Update
payment Balance account,
4.2 amount
Edit account,
Payment
Afferent amount
Efferent Accounts
Flow Flow

Structure Charts

Input Process Output
(Afferent Flow) Central Transform) (Efferent Flow)

Control

Input Process Output


Structure Charts - Notation

Modules

Library modules

Module call

Data
Flag


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.


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


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.

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.


Structure Charts - Example

Payment Process Payment Control
Error Payment
Payment
Payment Process
Get Payment Today Write Payment
Process Payment

Payment
Raw Payment Payment
Payment Error
Raw
Payment
Update Insert
Payment
Account Payment
Read Edit
Event
Record Record

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.


Process Specifications - Example

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


State Transition Diagram - Purpose
• Shows the time ordering between processes


State Transition Diagram – Notation

Objects

Transitions


State Transition Diagram – Example
Customer
Customer Active pays bills
makes purchase Account.
Account Balance Customer
application makes purchase
Customer
Create request to
New Account. close account & Customer
No Balance pays balance does not
pay bills

Closed Bad Debt
Account. Account.
No Balance Balance


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


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


Pros of SASD
• Flexible
• Provides a means of requirements validation
• Relatively simple and easy to read


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


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


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


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


Cons of SASD
• Doesn’t address stakeholders’ needs
• Doesn’t work well with Object-Oriented
programming languages


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


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.


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


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


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


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


SASD vs. Agile Methods

similarities:
 facilitate stakeholder communication


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


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


SASD vs. Cleanroom

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


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.


SASD vs. QFD

Similarities:
 Both involve analysts and system designers
 Both used in requirements analysis


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.


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


SASD vs. JAD

Similarities:
• Both support customer-analyst communication and requirements
documentation
 Both need user support


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


SASD vs. SSM

Similarities:

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


SASD vs. SSM

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)


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?


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


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


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


SASD Analysis and Design

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SASD Analysis and Design

Similar a SASD Analysis and Design (20)

Más de Sanjay Kumar Chakravarti

Más de Sanjay Kumar Chakravarti (8)

SASD Analysis and Design