The document discusses structured analysis and structured design (SASD) techniques including modeling system requirements using data flow diagrams, entity relationship diagrams, and structure charts. It also covers the history and goals of SASD, which aims to improve system quality by decomposing large problems and establishing clear documentation of functional requirements.
2. Agenda
• Introduction
• SASD Tools and Exercises
• Pros and Cons
• Comparisons with Other Techniques
• Conclusion
• References
3/15/2012 s.k.chakravarti 2
3. 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
4. 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
5. 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
6. 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
7. 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
8. 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
9. SASD Approach to Development Cycle
Existing or Install and Operate
Foreseen
Requirements Conditions
Definition Analysis
Functional Design
Architecture
System Build
Architecture
Operational
System
3/15/2012 s.k.chakravarti 9
10. 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
11. 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
12. Elements of Structured Analysis and
Design
Essential Model
Environmental Behavioural
Model Model
Implementation Model
3/15/2012 s.k.chakravarti 12
13. 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
3/15/2012 s.k.chakravarti 13
14. 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
3/15/2012 s.k.chakravarti 14
15. 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
3/15/2012 s.k.chakravarti 15
16. 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
3/15/2012 s.k.chakravarti 16
17. 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
3/15/2012 s.k.chakravarti 17
18. 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
19. 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
20. 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
21. Context Diagram - Notation
Process - Represents the proposed system
Terminator - Represents the external entities
Flow - Represents the in and out data flows
3/15/2012 s.k.chakravarti 21
22. 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
3/15/2012 s.k.chakravarti 22
23. 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
24. 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
25. 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
26. 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
27. Data Flow Diagram - Notation
Represents functions in the system
Represents the external entities
Represents data flows
Represents data stores
3/15/2012 s.k.chakravarti 27
28. 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
3/15/2012 s.k.chakravarti 28
29. 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
3/15/2012 s.k.chakravarti 29
30. Data Flow Diagram – Validation
Black Hole
Spontaneous
3/15/2012 s.k.chakravarti 30
35. Data Dictionary - Purpose
• Defines data elements to avoid different
interpretations.
3/15/2012 s.k.chakravarti 35
36. 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
37. 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
38. 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
39. Data Dictionary - Exercise
Build data dictionary items for the vendor name and vendor
address
3/15/2012 group 3: SASD 39
40. 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
41. 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
42. Entity Relationship Diagram - Notation
Data Element
Relationship
Associated Object
Cardinality – Exactly one
Cardinality – Zero or one
Cardinality – Mandatory Many
Cardinality – Optional Many
3/15/2012 s.k.chakravarti 42
43. Entity Relationship Diagram - Example
Payments
receive Bills
are made
generate
Accounts of
Transactions
contains
pay for include
Cards
Transaction_
products
3/15/2012 s.k.chakravarti 43
44. Entity Relationship Diagram - Exercise
Create an ERD for the Warm Boot Manufacturing System
3/15/2012 s.k.chakravarti 44
45. 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
46. Structure Charts - Purpose
• Functional Decomposition (Divide and
conquer)
• Information hiding
• Modularity
• Low coupling
• High internal cohesion
3/15/2012 s.k.chakravarti 46
47. 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
3/15/2012 s.k.chakravarti 47
48. Structure Charts
Input Process Output
(Afferent Flow) Central Transform) (Efferent Flow)
Control
Input Process Output
3/15/2012 s.k.chakravarti 48
49. Structure Charts - Notation
Modules
Library modules
Module call
Data
Flag
3/15/2012 s.k.chakravarti 49
50. 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
51. 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
52. 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
53. 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
54. 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
3/15/2012 s.k.chakravarti 54
55. 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
56. 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
3/15/2012 s.k.chakravarti 56
57. State Transition Diagram - Purpose
• Shows the time ordering between processes
3/15/2012 s.k.chakravarti 57
59. 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
3/15/2012 s.k.chakravarti 59
60. 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
61. 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
62. Pros of SASD
• Flexible
• Provides a means of requirements validation
• Relatively simple and easy to read
3/15/2012 s.k.chakravarti 62
63. 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
64. 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
65. 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
66. 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
67. Cons of SASD
• Doesn’t address stakeholders’ needs
• Doesn’t work well with Object-Oriented
programming languages
3/15/2012 s.k.chakravarti 67
68. 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
69. 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
70. 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
71. 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
72. 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
73. 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
74. SASD vs. Agile Methods
similarities:
facilitate stakeholder communication
3/15/2012 s.k.chakravarti 74
75. 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
76. 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
77. 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
3/15/2012 s.k.chakravarti 77
78. 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
79. SASD vs. QFD
Similarities:
Both involve analysts and system designers
Both used in requirements analysis
3/15/2012 s.k.chakravarti 79
80. 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
81. 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
82. SASD vs. JAD
Similarities:
• Both support customer-analyst communication and requirements
documentation
Both need user support
3/15/2012 s.k.chakravarti 82
83. 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
84. SASD vs. SSM
Similarities:
• Both focus on communication with stakeholders
• Both have consideration of organizational/user impact
• Both have the ability to model requirements
3/15/2012 s.k.chakravarti 84
85. 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)
3/15/2012 s.k.chakravarti 85
86. 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
87. 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
88. 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
89. 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