Structured Analysis and Structured

Design
• 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 An
aly
Functional Design
sis
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
Environmental Behavioural
Model Model

Implementation 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
Environmental Behavioural
Model Model

Implementation 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
Environmental Behavioural
Model Model

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

requirements. Environmental
Model
Behavioural
Model
• Tool: Structure Charts
Implementation Model
 Analysis & Design Process

Environmental Model

Statement of
Behavioural Model
Purpose
Implementation
y
Activit

Co
n
t
Event List Data Dictionary Model
e ERD
x DFD
Process Specification
t
State Transition
D Diagram
i S
a t
g r
Time
r u
a c
m t
 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

Corporate Processing Accounts Company

Accounting Account Transactio
System Summary n
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).
SA/SD

• SA/SD is diagrammatic notation which is design to

help people understand the system.
• The basic goal of SA/SD is to improve quality and
reduce the risk of System failure.
• It establishes concrete management specification
and documentation. It focuses on reliability,
flexibility and maintainability of system.
• In this system it involves 2 phases.
• Analysis Phase: It uses DFD, Data Dictionary,
StateTransition diagram and ER diagram.
• 2) Design Phase: Structure Chart, Pseudo Code
SA/SD

• Analysis Phase:
• Data Flow Diagram: In a DFD model describe how the
data flows through the system.
• Data Dictionary: The content that is missing from DFD is
described in the data dictionary. Data Dictionary defines
the Data store and there relevant meaning.
• State Transition Diagrams is similar to Dynamic model .It
specifies how much time function will take to execute and
data access triggered by events.
• ER Diagram: It specifies the relationship between data
store
SA/SD

• Design Phase: Structure Chart, Pseudo Code

• Structure Chart: It is created by the DFD. Structure Chart specifies how DFD‟s
processes are grouped in to task and allocate to CPU‟s.
• Pseudo Code: Actual implementation of the System.
 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
Credit Terms
Status
Amount

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 Update
4 Status
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 Cash requirements report
Check valid
Payment
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

3/15/2012 s.k.chakravarti 34
 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

3/15/2012 s.k.chakravarti 40
 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
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

3/15/2012 s.k.chakravarti 45
 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,
bill Process
account, Payments
stub Payment
amount 4.5
4.1
Read
account, Update
Payment 4.4 Open
amount To Buy
pay edited Update
m payment Balance account,
4.2 amount
en
Edit account,
t
Payment
Afferent Efferenatmount 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.
3/15/2012 s.k.chakravarti 50
 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 Paymen
Read Edit
t 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

Transition
s
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 pays balance does
Balance not pay
bills
Closed
Account. Bad Debt
No Balance
Account.
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
Jackson Structured Development
(JSD)
• JSD was introduced by Michael Jackson in 1983.
• The fundamental principle of JSD[6] is that it focuses on
describing the real world by the system i.e. its main focus is
to map the progress in the real world rather than specifying
the functions performed by the system i.e its main focus is
to map the progress in the real world.
• JSD consist of three stages:
• 1. Modeling Stage – This Stage comprises of Entity Action and Entity
Structure.
• 2. Network Stage – Initial model step, Function Step, and System
Timing Step.
• 3. Implementation Stage – Implementation Step.
JSD

• In modeling stage the entity structure diagram has

been created and identifies the entities and their
actions.
• In a network phase a set of sequential is expanded
into a process network by addition of process for
handling messages for external environment and
generating system output.
• In Entity Action the entities perform actions in time.
The action is atomic and cannot be decomposed
further.
• Entity Structure Step partially sequences the order of
action with respect to time.
JSD

• In initial model step we concentrate on state vector and data stream

communication. A data stream is an unbounded queue where read
operator extracts the next record from the queue, if there are no records
when the process executing the read operation waits until the record is
available whereas in write operation data stream places the next record
in the queue. In state vector we are present all the possible states of an
entity.
• Function step consist of pseudo code to the output of action generated
from states. In this step the developer requires a complete specification
of the system.
• System Timing Step relates with the performance constraints of the
system.
• The implementation step focuses on process scheduling and allocates
the number of processors required. The process may be different form
the processors
 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