Structured analysis no relation Larry Constantine
Objectives of structured analysis
Structured analysis became popular in the 1980s and is still in use today. Structured analysis consists of interpreting the system concept (or real world situations) into data and control terminology represented by data flow diagrams. The flow of data and control from bubble to the data store to bubble can be difficult to track and the number of bubbles can increase.
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. Bubbles are usually grouped into higher level bubbles to decrease complexity. Data dictionaries are needed to describe the data and command flows, and a process specification is needed to capture the transaction/transformation information.SA and SD are displayed with 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.History
Structured analysis is part of a series of structured methods that represent a collection of analysis, design, and programming techniques that were developed in response to the problems facing the software world from the 1960s to the 1980s. In this timeframe most commercial programming was done in Cobol and Fortran, then C and BASIC. There was little guidance on "good" design and programming techniques, and there were no standard techniques for documenting requirements and designs. Systems were getting larger and more complex, and the information system development became harder and harder to do so."As a way to help manage large and complex software, the following structured methods emerged since the end of the 1960s:
Structured programming in circa 1967 with Edsger Dijkstra - "Go To Statement Considered Harmful"
Niklaus Wirth Stepwise design in 1971
Nassi–Shneiderman diagram in 1972
Warnier/Orr diagram in 1974  - "Logical Construction of Programs"
HIPO in 1974 - IBM Hierarchy input-process-output (though this should really be output-input-process)
Structured design around 1975 with Larry Constantine, Ed Yourdon and Wayne Stevens.
Jackson structured programming in circa 1975 developed by Michael A. Jackson
Structured analysis in circa 1978 with Tom DeMarco, Edward Yourdon, Gane & Sarson, McMenamin & Palmer.
Structured analysis and design technique (SADT) developed by Douglas T. Ross
Yourdon structured method developed by Edward Yourdon.
Structured analysis and system specification published in 1978 by Tom DeMarco.
Structured systems analysis and design method (SSADM) first presented in 1983 developed by the UK Office of Government Commerce.
Essential Systems Analysis, proposed by Stephen M. McMenamin and John F. Palmer
IDEF0 based on SADT, developed by Douglas T. Ross in 1985.
Hatley-Pirbhai modeling, defined in "Strategies for Real-Time System Specification" by Derek J. Hatley and Imtiaz A. Pirbhai in 1988.
Modern Structured Analysis, developed by Edward Yourdon, after Essential System Analysis was published, and published in 1989.
Information technology engineering in circa 1990 with Finkelstein and popularised by James Martin.According to Hay (1999)  "information engineering was a logical extension of the structured techniques that were developed during the 1970s. Structured programming led to structured design, which in turn led to structured systems analysis. These techniques were characterized by their use of diagrams: structure charts for structured design, and data flow diagrams for structured analysis, both to aid in communication between users and developers, and to improve the analyst's and the designer's discipline. During the 1980s, tools began to appear which both automated the drawing of the diagrams, and kept track of the things drawn in a data dictionary". After the example of computer-aided design and computer-aided manufacturing  (CAD/CAM), the use of these tools was named computer-aided software engineering (CASE).Approach
Structured analysis views a system from the perspective of the data flowing through it. The function of the system is described by processes that transform the data flows. Structured analysis takes advantage of information hiding through successive decomposition (or top down) analysis. This allows attention to be focused on pertinent details and avoids confusion from looking at irrelevant details. As the level of detail increases, the breadth of information is reduced. The result of structured analysis is a set of related graphical diagrams, process descriptions, and data definitions. They describe the transformations that need to take place and the data required to meet a system's functional requirements.De Marco's approach consists of the following objects (see figure):
Context diagram
Data flow diagram
Process specifications
Data dictionaryHereby the data flow diagrams (DFDs) are directed graphs. The arcs represent data, and the nodes (circles or bubbles) represent processes that transform the data. A process can be further decomposed to a more detailed DFD which shows the subprocesses and data flows within it. The subprocesses can in turn be decomposed further with another set of DFDs until their functions can be easily understood. Functional primitives are processes which do not need to be decomposed further. Functional primitives are described by a process specification (or mini-spec). The process specification can consist of pseudo-code, flowcharts, or structured English. The DFDs model the structure of the system as a network of interconnected processes composed of functional primitives. The data dictionary is a set of entries (definitions) of data flows, data elements, files, and databases. The data dictionary entries are partitioned in a top-down manner. They can be referenced in other data dictionary entries and in data flow diagrams.Data flow diagrams
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. It differs from the system flowchart as it shows the flow of data through processes instead of computer hardware. Data flow diagrams were invented by Larry Constantine, developer of structured design, based on Martin and Estrin's "data flow graph"  model of computation.It is common practice to draw a system context diagram first which shows the interaction between the system and outside entities. The DFD is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts. This context-level data flow diagram is then "exploded" to show more detail of the system being modeled.
Data flow diagrams (DFDs) are one of the three essential perspectives of structured systems analysis and design method (SSADM). The sponsor of a project and the end users will need to be briefed and consulted throughout all stages of a system's evolution. With a data flow diagram, users are able to visualize how the system will operate, what the system will accomplish, and how the system will be implemented. The old system's data flow diagrams can be drawn up and compared with the new system's data flow diagrams to draw comparisons to implement a more efficient system. Data flow diagrams can be used to provide the end user with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to recook. How any system is developed can be determined through a data flow diagram.
no relation