WHAT IS STRUCTURED ANALYSIS?
Structured Analysis is primarily concerned with a new kind of Functional Specification: the Structured Specification. The difference between the two is that the Functional Specification describes automated procedures by a text narrative, whereas a Structured Specification is graphical. The text narrative always tends to plunge immediately into the details while the structured variant tries to present the big picture first, with the intention of working smoothly from abstract to detail.
However, the purpose of this document is not to provide guidelines for creating a Structured Specification. We are merely using the tools and technique of Structured Analysis to assist Business Analysts and Team Leads in creating a set of functional requirements.
The Business Analysts and Team Leads will need:
DATA FLOW DIAGRAMS
One of our key goals is to come up with a useful partitioning of the business area to be specified. The intent is to write an integrated set of “mini specs” rather than a monolithic Victorian novel specification.
A Data Flow Diagram is a network presentation of a system or a process. The Data Flow Diagram portrays a system or a process in terms of its component pieces, with all interfaces among the components indicated. See Figure 1 below for an example of a DFD for an Accounts Receivables Process.
The above example makes apparent the most significant characteristics of Data Flow Diagrams. DFDs are:
The use of DFDs also causes us to present a situation from the viewpoint of the data instead of from the viewpoint of any person or organization. In classical analysis, we first try to see operations from the viewpoint of the Users, i.e. we interview them and try to learn from them how things work. Then we spend the rest of our time trying to code the working of the modified operations from the system’s viewpoint.
The inversion of viewpoints through Structured Analysis is that we now present the workings of a system as seen by the data, not as seen by the data processors. The advantage of this approach is that the data sees the big picture, while the various people and machines and organizations that work on the data see only a portion of what happens. As the Business Analysts and Team Leads go about doing a Structured Analysis, they will find themselves more and more frequently attaching themselves to the data and following it through the operation. I think of this as “interviewing the data”.
Data Flow Diagram Conventions
Data Flow Diagram Elements
Data Flow Diagrams are made up of only four basic elements:
1. data flows – represented by named vectors (arrows) “X, Y, Z “
2. processes – represented by circles or “bubbles” “P”
3. files – represented by straight lines “F”
4. data sources – represented by boxes (squares) “S”
Consistent with our philosophy of concentrating primarily on data flow, Figure 2 is read as follows:
X data arrives from the source S and is transformed into Y by the process P1 (which requires access to the file F to do its work). The Y data is subsequently transformed into Z data by the process P2.