Structured analysis and design

Structured analysis and design

3.1 Purpose

“Structured Analysis and Design” is divided into two components: structured analysis as defined by DeMarco² and structured design as defined by Yourdon and Constantine⁴. Structured analysis is a front-end methodology that allows users and/or systems analysts to convert a real-world problem into a pictorial diagram or other logical representation that can subsequently be used by the systems developers and/or programmers to design an information system. Structured design is concerned with physical design based on the results of structured analysis. More generally, structured analysis transforms the abstract problem into a feasible logical design, while structured design concentrates on converting the logical design into a physical information system.

3.2 Strengths, weaknesses, and limitations

Structured analysis and design may be the best known analysis and design methodology. It features a top-down, hierarchical approach that tends to generate well-organized systems. Its step-by-step approach (parallel to the system development life cycle described in Chapter 1) simplifies project management, risk management, and resource management. Additionally, this methodology’s tools and techniques can all be used to support other methodologies.

Managing and/or controlling the amount of data created by the structured analysis and design methodology can be time-consuming. Maintaining, updating, and documenting a complete set of data flow diagrams and a complete data dictionary are significant data management tasks in their own right. The step-by-step design philosophy makes this methodology inflexible. System and data requirements must be frozen at the beginning of the life cycle, so the actual systems developed may not reflect the current data and system requirements. Compared with other methodologies, structured analysis and design is not very user-friendly.

3.3 Inputs and related ideas

The structured analysis and design methodology can be viewed as a special case of the system development life cycle introduced in Chapter 1. Relevant tools include data flow diagrams (Chapter 24), data dictionaries (Chapter 25), decision trees (Chapter 57), decision tables (Chapter 58), structured English (Chapter 60), and structure charts (Chapter 63). Structured program design (Chapter 62) discusses the structured design process.

3.4 Concepts

Structured analysis and design is divided into two components: structured analysis as defined by DeMarco and structured design as defined by Yourdon and Constantine.

3.4.1 Structured analysis

The major steps in structured analysis are outlined in Figure 3.1.

3.4.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.

3.4.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 (Chapter 24), a data dictionary (Chapter 25), and other models as appropriate.

3.4.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.

3.4.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.

3.4.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.

3.4.1.6 Select the best design

The best alternative is selected using the tools described in Part V.

3.4.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.

3.4.2 Structured design

The major steps in structured design are outlined in Figure 3.2. See structured program design (Chapter 62) for additional depth on many of the topics overviewed in this section.

Figure 3.1  The major steps in the structured analysis process.

Figure 3.2  The major steps in the structured design process.

3.4.2.1 Construct a structure chart

As the name implies, the purpose of this step is to construct a structure chart (Chapter 63) that shows the hierarchical relationship and structure of all the data flows identified during structured analysis. In addition, control flows are added to the model to facilitate subsequent systems development.

3.4.2.2 Examine the coupling (interdependency) relationships

A key objective of structured design is to define loosely coupled, independent modules. Generally, a module’s degree of independence is inversely proportional to the number of data elements (or composites) that flow between the module and the rest of the system. Consequently, the focus of this step is to increase module independence by identifying and restructuring modules with excessive data flows.

3.4.2.3 Examine module cohesion

A second objective of structured design is to define cohesive modules that perform a single, complete function. The focus of this step is on combining modules that perform common functions, consolidating functions to reduce the number of interfaces, and relocating modules to increase system efficiency.

3.4.2.4 Refine the structure chart

Using the results of the previous two steps, a final version of the structure chart is prepared.

3.4.2.5 Perform transform analysis

The purpose of transform analysis is to group together the modules (or processes) that manipulate a particular set of data or a particular data structure. For example, the processes that accept inventory transaction data, modify inventory levels, and update the master inventory data are probably related. The afferent (input), efferent (output), transform (data modification), and coordinate (controlling) modules are identified first. Grouping the modules to form a control structure might involve designating one module as the master (promoting a boss) or creating a new master (hiring a new boss). The subordinate modules are called slaves.

3.4.2.6 Perform transaction analysis

The purpose of transaction analysis is to group all modules (or processes) triggered by the same transaction to form a transaction center. For example, all the tasks performed in response to the arrival of an order from a supplier are related. Often, the control center serves as a control module.

3.4.2.7 Create module specifications

The primitives defined in the data flow diagram are defined in terms of logical sequence, selection, and repetition blocks.

3.4.2.8 Package the physical modules

The key purpose of this step is to ensure that the parent-child relationships between the modules are preserved when the procedures are grouped to form physical load modules for efficient execution on a computer. Often, a procedural analysis is performed to determine which procedures must be grouped within the same load module to avoid severe execution and/or testing errors.

3.5 Key terms

Cohesion —

A measure of a module’s completeness.

Control flow —

The transfer of control into or out from a module.

Coupling —

A measure of a module ’s independence; fewer parameters flowing into or out from a module imply looser coupling.

Data dictionary —

A collection of data about a system’s data.

Data flow —

Data in motion; the transfer of data into or out from a module.

Data flow diagram —

A logical model of the flow of data through a system.

Load module —

The unit of program logic that is physically loaded and executed on a computer.

Logical model —

A model that exists on paper or in an analyst’s mind; logical models are easily manipulated; contrast with physical.

Module —

A portion of a larger program that performs a specific task.

Physical —

Real; actual, operational hardware, software, or data; contrast with logical.

Primitive —

A process (or transform) that requires no further decomposition.

Process —

An activity that changes, moves, or manipulates data.

Requirement —

An element (process, data, etc.) that must be part of a system.

Structure chart —

A hierarchy chart on which the data flows and control flows between modules are traced.

Structured analysis —

A set of tools and techniques intended to transform an abstract problem into a feasible logical design.

Structured design —

A set of tools and techniques intended to convert a logical design into a concrete information system.

Transaction —

Typically, one occurrence of a business activity; for example, a single customer order or a single shipment from a supplier; an event.

Transaction analysis —

The act of grouping all modules (or processes) triggered by the same transaction to form a transaction center.

Transform analysis —

The act of grouping together the modules (or processes) that manipulate a particular set of data or a particular data structure.

3.6 Software

Not applicable.

3.7 References

1.  Aktas, A. Z., Structured Analysis and Design of Information Systems, Prentice-Hall, Englewood Cliffs, NJ, 1987.

2.  DeMarco, T., Structured Analysis and System Specification, Prentice-Hall, Englewood Cliffs, NJ, 1979.

3.  Martin, J. and McClure, C., Structured Techniques: The Basis for CASE, Prentice-Hall, Englewood Cliffs, NJ, 1988.

4.  Yourdon, E. and Constantine, L. L., Structured Design. Fundamentals of a Discipline of Computer Program and Systems Design, Prentice-Hall, Englewood Cliffs, NJ, 1979.

5.  Yourdon E., Modern Structured Analysis, Prentice-Hall, Englewood Cliffs, NJ, 1989.

6.  Yourdon, E., Techniques of Program Structure and Design, Prentice-Hall, Englewood Cliffs, NJ, 1989.