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

Agenda • Introduction • SASD Tools and Exercises • Pros and Cons • Comparisons with Other Techniques • Conclusion • References 3/15/2012 s.k.chakravarti 2

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

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

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

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

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

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

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

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

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

Elements of Structured Analysis and Design Essential Model Environmental Behavioural Model Model Implementation Model 3/15/2012 s.k.chakravarti 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Data Flow Diagram – Validation Black Hole Spontaneous 3/15/2012 s.k.chakravarti 30

Data Flow Diagram – Validation 3/15/2012 s.k.chakravarti 31

Context diagram - Exercise • System context diagram Cash invoice requirements-report Pay- Vendor invoice management Payment payment authorization Cash-requirement report accounting [Kendall 1996] 3/15/2012 s.k.chakravarti 32

Data Flow Diagram - Exercise • Build a level 0 DFD 3/15/2012 s.k.chakravarti 33

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

Data Dictionary - Purpose • Defines data elements to avoid different interpretations. 3/15/2012 s.k.chakravarti 35

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

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

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

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

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

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

Entity Relationship Diagram - Exercise Create an ERD for the Warm Boot Manufacturing System 3/15/2012 s.k.chakravarti 44

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

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

Structure Charts Input Process Output (Afferent Flow) Central Transform) (Efferent Flow) Control Input Process Output 3/15/2012 s.k.chakravarti 48

Structure Charts - Notation Modules Library modules Module call Data Flag 3/15/2012 s.k.chakravarti 49

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

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

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

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

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

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

State Transition Diagram - Purpose • Shows the time ordering between processes 3/15/2012 s.k.chakravarti 57

State Transition Diagram – Notation Objects Transitions 3/15/2012 s.k.chakravarti 58

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

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

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

Pros of SASD • Flexible • Provides a means of requirements validation • Relatively simple and easy to read 3/15/2012 s.k.chakravarti 62

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

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

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

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

Cons of SASD • Doesn’t address stakeholders’ needs • Doesn’t work well with Object-Oriented programming languages 3/15/2012 s.k.chakravarti 67

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

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

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

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

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

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

SASD vs. Agile Methods similarities:  facilitate stakeholder communication 3/15/2012 s.k.chakravarti 74

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

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

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

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

SASD vs. QFD Similarities:  Both involve analysts and system designers  Both used in requirements analysis 3/15/2012 s.k.chakravarti 79

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

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

SASD vs. JAD Similarities: • Both support customer-analyst communication and requirements documentation  Both need user support 3/15/2012 s.k.chakravarti 82

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

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

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

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

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

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

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

Structured Analysis and Structured Design

More Related Content

What's hot

Similar to Structured Analysis and Structured Design

More from Sanjay Kumar Chakravarti

Structured Analysis and Structured Design