You are on page 1of 11

Structured Analysis and Design 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. Structured systems analysis and design separates process and data. The emphasis is on the procedural aspects of a system. The design is top-down, modular, hierarchical. A separate model is built to represent each of these two views: • A process model • A data model This is the fundamental difference between the Object Oriented and Structured paradigms. History of Structured Analysis and Systems Design • 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”. • The availability of CASE tools in the 1990s enabled analysts to develop and modify the graphical SASD models. 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. • The purpose of Structured analysis and Design is to develop a useful, high quality information system that will meet the needs of the end user. Goals of Structured Analysis and Design • 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 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 behavior. • Easy to understand by user.

automated. Context diagram. Minimizes the cost of development and maintenance • Determines which functions should be manual vs. and others who are not directly involved in the system Example of Statement of Purpose – The purpose of the credit card system is to provide a means for the company to extend credit to the customer. transaction capture. and Event List Behavioral Model • Model of the internal behavior and data entities of the system • Models the functional requirements • Composed of Data Dictionary. credit management.Elements of Structured Analysis and Design Essential Model Environmental Model Behavioral 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 behavioral 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. billing. remittance. The system will handle details of credit application. Can be used to discuss the cost-benefits of functionality with the users/stakeholders • Defines the Human-Computer interface • Defines non-functional requirements • Tools: Structure Charts 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 State Transition Diagram Implementation Model • Maps the functional requirements to the hardware and software. Entity Relationship Diagram. and management reporting. Data Flow Diagram. Process Specification. Information about transactions should be available to the corporate accounting system.

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 Event List – Purpose • A list of the events/stimuli outside of the system to which it must respond .Analysis and Design Process Context Diagram – Purpose • Highlights the boundary between the system and the outside world • Highlights the people. organizations.

(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 – Leveling .• 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.

Data Flow Diagram – Example Data Flow Diagram – Validation Black Hole - Spontaneous Data Flow Diagram – Validation Data Dictionary – Purpose • Defines data elements to avoid different interpretations .

Data Dictionary – Notation ‘ = ‘ Is composed of ‘ + ‘ And ‘ ( ) ‘ Element is optional ‘ { } ‘ Interation ‘ [ ] ‘ Select one of a list of elements ‘ | ‘ Separates 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 • SP = “ “ Space • LD = {0-9} Legal Digits • Range = 5191 0000 0000 0000 to 5191 9999 9999 9999 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 .

Structure Charts – Purpose • Functional Decomposition (Divide and Conquer) • Information hiding • Modularity • Low coupling • High internal cohesion Structure Charts Structure Charts – Notation Modules Library Modules Module Call .

This is unavoidable in traditional batch processing • Common – Modules access data through global variables • Content – One module changes the data of another module .Data Flag Structure Charts – Example Structure Charts – Cohesion • Function – 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 • 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 • External – Two or more modules reference the same piece of external data.

Transitions State Transition Diagram – Example Pros of Structure Analysis and Design • It has distinct milestones. which are implied but not shown in a Data Flow Diagram • Specifies the input.Process Specifications – Purpose • Shows process details. 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 . and algorithm of a module in the DFD • Normally written using pseudo-code Process Specification – Example Apply Payment • For all payments o 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 . output.

user-analyst interaction • Doesn’t provide a communication process with users • Hard to decide when to stop decomposing • Doesn’t address stakeholders’ needs • Doesn’t work well with Object-Oriented programming languages Context Diagram • Does not provide a specific means to determine the scope of the system .• A mature technique • Process-oriented approach is a natural way of thinking • Flexible • Provides a means of requirements validation • Relatively simple and easy to read 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 Data Dictionary • Simplifies data requirements • Used at high or low level analysis ERD • Commonly used. 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 Process specifications • Express the process specifications in a form that can be verified State transition diagrams • Models real time behavior Structure charts • Modularity improves system maintainability • Provides a means for transition from analysis to design • Provides a synchronous hierarchy of modules Cons of Structure Analysis and Design • It ignores non-functional requirements • Minimal management involvement • Non-iterative. well understood • Graphical tool.

Event List • Does not define all functionality (example. formal notation • Complex in large Structure charts • Does not work well for asynchronous processes such as networks • Could be too large to be effectively understood with large programs 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 Structure Analysis and Design • In well know 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 Structure Analysis and Design (SAD) vs. Object Oriented Analysis Design (OOAD) Similarities • Both SAD 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 Differences • SAD is Process-oriented • OOAD is Data-oriented • Another difference is that OOAD encapsulates as much of the systems’ data and processes into objects . 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 Data Dictionary • No functional details • Formal language is confusing to users ERD • May be confusing for users.