Structured analysis Structured Analysis (SA) in software engineering and its allied technique, Structured Design (SD), are methods for analyzing and converting business requirements into specifications and ultimately, computer programs, hardware configurations and related manual procedures. Structured analysis and design techniques are fundamental tools of systems analysis, and developed from classical systems analysis of the 1960s and 1970s. Objectives of Structured Analysis • Structured Analysis became popular in the 1980s and is still used by many. • The analysis consists of interpreting the system concept (or real world) into data and control terminology, that is into data flow diagrams. The flow of data and control from bubble to data store to bubble can be very hard to track and the number of bubbles can get to be extremely large. • One approach is to first define events from the outside world that require the system to react, then assign a bubble to that event, bubbles that need to interact are then connected until the system is defined. This can be rather overwhelming and so the bubbles are usually grouped into higher level bubbles. • Data Dictionaries are needed to describe the data and command flows and a process specification is needed to capture the transaction/transformation information.[3] SA and SD were accompanied by notational methods including structure charts, data flow diagrams and data model diagrams, of which there were many variations, including those developed by Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed Yourdon, Steven Ward, Peter Chen, and others. These techniques were combined in various published System Development Methodologies, including Structured Systems Analysis and Design Method, Profitable Information by Design (PRIDE), Nastec Structured Analysis & Design, SDM/70 and the Spectrum Structured system development methodology. Structured analysis The major steps in structured analysis are 1.1 Study the current business environment The purpose of the first step is to study the old system, perform a market analysis to analyze the current business environment, perform a functional end-user analysis to determine the new data requirements, and perform a needs analysis to determine if a new system is necessary. Many of the tools and techniques described in Part II are used. 1.2 Model the old logical system The objective of this step is to construct a logical model that captures the essence of the current environment by eliminating operational and physical details. Typically, the logical model consists of a data flow diagram (# 24), a data dictionary (# 25), and other models as appropriate. 1.3 Model the new logical system Based on the old system model, a new, improved logical model is created. New user requirements are added, redundant requirements are eliminated and consolidated, and existing data requirements are updated. Complex primitives are decomposed into simpler primitives and/or more thoroughly documented. Finally, the data flows are verified. 1.4 Model the new physical environment In this step, the necessary physical details are added back to the new logical design created in the previous steps. As appropriate, design options (hardware, software, platform, and interface) are identified for each of the primitives. 1.5 Evaluate alternatives During this step, a cost estimate, a schedule, an estimate of resource requirements, a cost/benefit analysis, and similar parameters are prepared for each design option using the tools described in Part V. 1.6 Select the best design The best alternative is selected using the tools described in Part V. 1.7 Create the structured specification The purpose of the step is to prepare a recommendation for management’s approval and to provide documentation for structured design.
Posted on: Sun, 30 Jun 2013 23:29:15 +0000
Trending Topics
Recently Viewed Topics
© 2015