Structured Design

Section 0: Module Objectives or Competencies

Course Objective or Competency	Module Objectives or Competency
The student will be able to employ appropriate systems design tools such as structure charts, process specifications, and dialog flow designers to design a system and its user interface.	The student will be able to apply structured design as a methodology for designing and modularizing systems.

Section 1: Definition

Structured design is the art of designing the components of a system and the interrelationship between those components in the best possible way.

It is a methodology in which a problem (goal/task/system) is divided into smaller sub problems, each of which is then analyzed until a solution is obtained to solve the sub problem. The solutions of the sub problems are then combined to solve the overall problem.

Sub problems are then arranged into a hierarchy that forms a sequence of procedures.

Section 2: Background

Often structured analysis is used alongside structured design as part of an integrated structured system development technique.

The technique begins with structured analysis in which a model of the system is built using data flow diagrams (DFD).
- The DFDs are derived from the actual processes in the existing system that are iteratively refined and decomposed to a final logical solution.
- The DFDs should be checked for consistency and data conservation (the practice of ensuring that a data flow contains only data needed by the receiving process) through each iteration.
A data dictionary should then be built in a logical form specifying the content of the data, the data flows, and all the data forms in the DFDs.
- The data dictionary must be well correlated to the DFDs including the handling of aliases, definition of data structures, and the implementation of the data dictionary.
Next, the processes or operations in the DFDs have to be defined by analyzing the process logic and then depicting them in process specifications.
Finally, a logical, hierarchical design (structure chart) needs to be derived from the DFDs.
- Design begins with an evaluation of the higher level DFDs, the type of information flow is identified, and the flow boundaries that separate the transform or transaction centers are defined.
- The transforms are then mapped to the program structure as modules.

Major Steps in Structured Analysis

Click each step above for these details.

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.

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, a data dictionary, and other models as appropriate.

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.

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.

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.

Select the best design

The best alternative is selected.

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.

Major Steps in Structured Design

Click each step above for these details.

Construct a structure chart

The purpose of this step is to construct a structure chart 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.

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.
You will see more on coupling shortly.

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.

Refine the structure chart

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

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.

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.

Create module specifications

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

Section 3: Pros and Cons

Why use structured design?

It features a top-down, hierarchical approach that tends to generate well-organized systems.
- A top-down approach moves from the general to the specific.
- Top-down design allows the systems analyst to determine overall organizational objectives first, and then to divide the system into subsystems and their requirements.
Modules are easier to understand because they are self-contained subsystems.
- A modular approach involves breaking the system into logical, manageable portions, or modules.
- Modules are easier to write and debug because they are virtually self-contained.
- Modules are easier to maintain – scope of modifications is limited.
Its step-by-step approach simplifies project management, risk management, and resource management.
- Risk management is the process of identifying, analyzing and responding to risk factors throughout the life of a project and in the best interests of its objectives.
- Resource management comprises the acquisition and deployment of the internal and external resources required to deliver the project.
Its tools and techniques can all be used to support other methodologies.
When it is used with other tools such as the data dictionary, structure charts, decision trees, and structured English, it provides the primary building block on which system design can be based.
This technique is well-established and documented.

Why use anything else?

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.
If the designer is not adaptable, the step-by-step design philosophy makes this methodology inflexible.
- When based on the unmodified waterfall approach, 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.