Demarco's Systems Analysis Method
Essay by review • February 23, 2011 • Research Paper • 2,204 Words (9 Pages) • 1,760 Views
Outline the structured specification produced by DeMarco’s systems analysis method.
What do you think are the main advantages of specifying a computer-based system by means of such a structured specification?
How adequately, do you think, does this method deal with the human aspects of information systems changes?
According to DeMarco’s structured analysis, it is a study of a problem leading to the specification of a new system prior to implementation of that system. DeMarco also makes it very clear in his book (The Structured Analysis and System Specification вЂ" a Yourdon Book) that the most important product of the analysis phase of the life cycle is the specification document. Different organizations are using different terms for this document: Functional Specification, Design Specification, Memo of Rationale, Requirements Document, etc. But DeMarco introduced a new term called the Target Document. The analyst is the third person or the middleman between the user and the development team. The user decides what has to be done and the development team makes it possible. With the Target Document, the analyst will bridge the gap between the user and the development team. The process of putting this document together and getting it accepted by all parties is called specification. Whether the whole specification process leads to a successful result or not will depend on its product which is the target document. As planned, if the Target Document is capable of performing its task, to serve as a model of the new system, that shows the success of the specification process.
The Structured Specification has several components:
1. Data Flow Diagram (DFD): Depicts processes and the flow of data between them. DFD doesn’t depict conditional logic or flow of control between modules.
2. Data Dictionary: A repository of definitions for data elements, files, and processes.
3. Transform Descriptions: Use Structured English, Decision Tables, and Decision Trees to document the internals of the DFD in a detailed manner.
Structured English is a specification language. It uses a limited vocabulary and a limited syntax.
The vocabulary consist only of
- imperative English language verbs
- terms defined in the Data Dictionary
- certain reserved words for logic formulation
The syntax of a Structured English is limited to
- simple declarative sentence
- closed-end decision construct
- closed-end repetition construct
Decision Table is a table of entries that are actions and policies.
Decision Tree is a graphic presentation of a Decision Table.
The qualities of DeMarco’s Structured Specification can be summarized in 7 steps:
1. It should be graphic: An easy to understand presentation of the subject matter is depicted by Data Flow Diagrams. DFDs give a meaningful picture of what is being specified.
2. It should be partitioned: The system is decomposed into processes. The processes are the basic elements on the Data Flow Diagram.
3. It should be rigorous: A highly detailed documentation of the interfaces is provided by the Data Dictionary.
4. It should be maintainable: The process of changing the Structured Specification can be controlled. Redundancy is minimized and controlled.
5. It should be Iterative: Some parts of the Structured Specification can be taken into consideration separately. The working documents which the users deal with are actual components of the Structured Specification. These components can be moved to users and the development team until a final approval is met. Then they will appear unchanged in the Structured Specification.
6. It should be logical: The Structure Specification doesn’t encourage a physical thinking. It eliminates the elements that depend on hardware, vendor etc.
7. It should be precise, concise and highly readable.
The Structured Analysis and System Specification (SASS) methodology was originally proposed and developed by DeMarco and Yourdon in the mid 70’s. DeMarco’s approach to structured analysis is a top-down approach. In this approach, the analyst maps the current physical system onto the current logical data flow model. The SASS can be summarized in four steps.
The Structured Analysis and System Specification Methodology
1. Study current environment
- Draw a Data Flow Diagram (DFD) to show how data flows through current organization
- Label bubbles with names of organizational units or individuals
2. Derive logical equivalents
- Replace names with action verbs
- Merge bubbles that show the same logical function
- Delete bubbles that don’t transform data
3. Model new logical system
- Modify current logical DFD to show how information will flow once the new system is in place
- Don’t distinguish (only for the time being) which components will be automated
4. Define a number of automation alternatives
- Document each as a physical DFD
-
...
...