Overview Of Structured Systems Analysis

Published Date: 02 Nov 2017

Introduction

In this lecture we presented the structured systems analysis and design methodology and approach that are used in software systems development. We first presented an overview of the methodology. We defined it, listed its objectives, advantages and disadvantages. Then we presented the activities of the structured systems analysis and design methodology including logical data modeling, data flow modeling and entity event modeling. Later, we presented the elements of the essential model of the structured analysis and design methodology which are the environmental model, the behavioral model and the implementation model. After that, we presented the structured analysis and design tools and techniques including the Structured Query Language (SQL), the Structure Chart (SC), the Data Dictionary, the Context Diagram (CD), the Entity Relationship Diagram (ERD), and the State Transition Diagram (STD). Finally, a comparison between structure analysis and design approach and object oriented analysis and design approach was presented.

Learning Outcomes

Be familiar with the objectives, elements, advantages, and disadvantages of structured systems analysis & Design.

12.0 Introduction

Structured Analysis (SA) and Structured Design (SD) are software engineering techniques and methods used to identify and transform business requirements into software/product specifications. They are also used in the implementing stage of the development life cycle. Structured analysis and design techniques, used since the 1960s, are an integral part of software engineering.

In this lecture we introduce and present structured analysis and design techniques and show how they are used in the software systems development.

12.1 Overview of Structured Systems Analysis & Design Methodology

Structured Systems Analysis and Design Methodology (SSADM) is a set of techniques and graphical tools that are used by the system analyst to develop system specification requirements that could then be easily understandable by the user.

Structured systems analysis and design methodology was developed in the late 1970s by Yourdon DeMarco after the emergence of structured programming. When CASE tools were developed and became available in the 1990s they were used by system analysts who used structured systems analysis and design methodology to develop and modify the graphical structured systems analysis and design methodology models.

SSADM is a methodology used in the analysis and design stages of information systems development. SSADM only considers the analysis and design phases of the software development life cycle and does not cover the coding, implementation, or testing phases of software system development.

Structured systems analysis and design technique separates process and data. It emphasizes on the procedural aspects of a system. The design is top-down, structural, modular, and hierarchical. By using structured analysis and design approach a separate model is built to represent each of the following two views:

A process model

A data model

The above models present the fundamental difference between the object oriented and structured paradigms.

SSADM includes popular tools within government departments, and external contractors where external contractors produce software for the government using SSADM tools. SSADM is also used by other companies because these companies expect the use of this disciplined engineering approach will eventually improve the quality of the systems they produce. Although using SSADM is expensive and companies using it incur a considerable expense of implementing such a methodology, including staff training, etc. such companies et a compensation of these expenses through improving the quality of their products.

Structured systems analysis and design technique develops the system into set of modules and models the structure of the system as module hierarchy. SSADM applies structured methods and a collection of analysis, design, and programming techniques to manage the software systems development at the stages of system analysis and design.

SSADM is structured and consists of five main steps. Each of these five steps is in turn broken down into a complex hierarchy of stages, steps and tasks. These five steps are as follows:

Feasibility study: To determine whether it is cost effective to build the system and whether it is actually possible.

Requirements Analysis: To identify the requirements and needs of the system and to model these needs in terms of the required tasks and activities.

Requirements Specification: To list, specify, and describe the functional and non functional requirements in detail.

Logical System Specification: To create the logical and technical systems using models.

Physical Design: To actually design and create the system by converting the logical design into a real implementation. In this step the logical system specification and technical system specification is used to design a physical database and set of program specifications.

SSADM is currently a popular methodology. It breaks the system to be developed into data and control components. It uses data flow diagrams to model the system. In order to describe data SSADM uses Data Dictionaries. In order to capture the transaction/transformation information SSADM uses command flows and a process specification.

SSADM uses multiple tools, techniques, and structured methods to facilitate analysis and design. These tools are also called Computer-aided software engineering (CASE) tools. They include the following:

structure charts

data flow diagrams

data model diagrams

Structured programming

All of the above techniques use diagrams. They use structure charts for structured design, and data flow diagrams for structured analysis. These diagrams are used as a communication tool between users and developers. They are also used by the analyst and the software engineer to facilitate and improve the development process.

SSADM is used when there is little information on the best design and programming techniques, and when there are no standard techniques for documenting requirements and designs. SSADM is used to manage complex software systems where the information system development becomes hard to be developed.

In fact, structured programming led to structured design, which in turn led to structured systems analysis.

Structured analysis typically creates a proposed system hierarchy that employs multiple levels of abstraction. This method is also called functional decomposition approach. The top level of abstraction could be the system purpose and a viewpoint. Using hierarchical levels of abstraction where at the top level we present the overall function of the proposed system and then each level below the functions of the system are broken down into smaller sub-functions, maintaining the functions inputs, outputs, and control mechanisms. This functional break down method illustrates the processes of the system, and not the behavior of it.

Structured analysis & design illustrates the system from the point of view of the data i.e. it illustrates the data flow in the system, whereas the processes involved manipulate the data. This means that structured analysis and design represents the functional view of the problem. Structured analysis & design is used to manipulate the software in question by continuously breaking a problem/error down in order for it to be fully understood by the developers as well as other stakeholders. It produces a number of diagrams, process information, and definitions of data. These diagrams describe the transformations that need to take place and the data required to implement the system functional requirements.

SSADM was developed with the following objectives:

To develop a useful, high quality information system that will meet the needs of the end user.

To ensure that projects can successfully continue should a loss of staff occur without a damaging effect on the project

To improve the way in which projects are controlled and managed

To allow more effective use of experienced and inexperienced staff and their development

To make it possible for projects to be supported by computer based tools e.g. computer-aided software engineering systems

To improve communication between participants in a project so an effective framework is in place

To improve Quality and reduce the risk of system failure

To establish concrete requirements specifications and complete requirements documentation

To focus on Reliability, Flexibility, and Maintainability of system

Advantages of using SSADM include the following:

It has distinct milestones, which allows for easier project management tracking

It is visual since it uses graphical diagrams. This makes the system easier for users/programmers to understand

It is a mature technique

It allows one to plan, manage and control a project well. These points are essential to deliver the product on time.

It uses a process-oriented approach which is a natural way of thinking

It provides a means of requirements validation

It is relatively simple

It does not rely on a single technique.

Each of the used system techniques and models provides a different viewpoint of the same system, each of which are required to form a complete model of the system.

Within SSADM each of the techniques is a cross- reference against other techniques to ensure the completeness and accuracy of the complete model.

It does not require very special skills and can easily be taught to the staff.

It uses common modeling and diagramming tools including CASE tools

Disadvantages of using SSADM include the following:

It ignores non-functional requirements

It requires minimal management involvement

It is Non-iterative and requires a lot of user-analyst interaction

It does not provide a communication process with users

It is hard to decide when to stop decomposing

It does not address stakeholders’ needs

It does not suitable for Object-Oriented programming languages

It assumes that the requirements do not change during the development of a project.

It can be time consuming

It may incur delay in system delivery due to the considerable delay in the analysis and design phases which could lead to dissatisfying the business requirements at the time of delivery.

It puts high emphasis on the system analysis and specification documentation which leads to incurring very development time and cost.

One structured analysis approach is called De Marco's approach. It consists of the following objects:

Context diagram

dataflow diagram,

process specifications

a data dictionary

Another structured analysis approach has been developed by Page-Jones in 1980. It consists of three main objects:

structure charts

module specifications

a data dictionary

12.2 Structure Analysis & Design Activities

SSADM uses different modeling tasks/activities to assist in analysis and design of software systems. These modeling tasks/activities include:

Logical data modeling

Data flow modeling

Entity event modeling

In the following we describe some of these modeling tasks/activities.

Logical data modeling is the process of identifying, modeling and documenting the data requirements of an information system. A logical data is the data structure that represents a data object and the associated documentation. This data structure is the data entity and Relationships of this entity with other entities. Logical data modeling identifies data structures of the system and represent them by data entities and identifies the relationships between these entities.. Logical data modeling also identifies, models, and documents of data requirements of the system being designed are identified,

 Data flow modeling is the process of identifying, modeling and documenting the flow of data in information systems. A data flow model is a set of related Data Flow Diagrams (DFDs) with appropriate documentation. DFDs are composed of nodes that represent activities and arcs that represent data conversion by the activities (nodes). Hence, DFDs represent activities which transform data from one form to another, data stores that hold areas for data, external entities that send data into a system or receive data from a system and data flows which are the routes by which data can flow. DFDs are then oncerned with how the data moves around the information system. examines processes, data stores, external entities and data flows.

Entity event modeling is the process of identifying, modeling and documenting the system events with respect to the entities in the system and the order in which these events take place. Modeled entities are those that affect each entity and the sequence in which these events occur. An entity/event model consists of a set of Entity Life Histories (ELHs) and appropriate supporting documentation. There is one ELH for each entity.

12.3 Elements of Structured Analysis & Design

Essential model of the structured analysis and design methodology model of what the system must do but does not define how the system will accomplish its purpose. The essential model of the structured analysis and design methodology consists of three elements/models. These elements/models are shown in Figure 1. They are:

Environmental model

Behavioral model

Implementation model

In the following, we describe these elements/models in some detail.

Essential Model

Environmental Model Behavioral Model

Implementation Model

Figure 1: Elements of the structured analysis and design methodology

The environmental model defines the scope of the proposed system. It defines the boundary and interaction between the system and the outside environment. It consists of the statement of purpose, context diagram, and event list.

The behavioral model models the internal behavior and data entities of the system. It models the functional requirements of the system. It is composed of data dictionary, data flow diagram, entity relationship diagram, process specification, and state transition diagram.

Finally, the implementation model transforms the functional requirements to the hardware and software. It minimizes the cost of development and maintenance

By determining which functions should be implemented to work manually or to be automated. The implementation model is used to discuss the cost-benefits of functionality with the users and stakeholders by discussing the human-computer interface, non-functional requirements, and tools to be used in the development process such as structure charts

12.4 Structured Analysis & Design Tools and Techniques

Structured analysis and design uses a set of different integrated tools and techniques such as entity-relationship modeling, and data flow modeling, logical data modeling entity/event modeling, the Structured Query Language (SQL), structure chart, and CASE tools to support the system analysis and design.

In the following subsections we describe these techniques.

12.4.1 Structured Query Language

SQL is used for querying information from a database. It is the most widely used query language for database management systems operating on microcomputers, mainframes as well as Personal Computers as it is compatible with distributed databases.

12.4.2 Structure Chart

The breakdown of a system, to the lowest levels possible is presented in the structure chart (SC). It is widely used in structured programming as it allows the arranging of the modules (in the software program) in the shape of a tree structure. Modules are given a name and represented by a box in the chart. The tree structure also visualizes the relationships between the modules. The structure charts are implemented in order to establish the architecture of a system.

As an analysis and design tool, the structure chart allows the programmer to manipulate the software in question by continuously breaking a problem/error down in order for it to be fully understood by the developers as well as other stakeholders. The structure chart uses top-down design, or functional decomposition. To design the software system the corresponding chart is drawn and used as a way for the users and the software system developers to communicate. During the implementation of the software system the chart is commonly named the ‘master-plan’.

12.4.3 Data Dictionary

A data dictionary is a simple file that describes the way the data is arranged in a database. It keeps track of the number of files in the database, the number of records in each file, as well as attributes such as the name and type of the data fields. Most database management systems (DBMSs) hide the data dictionary from users in order to prevent any accidental or non-accidental deletion of it.

12.4.4 Data Flow Diagrams (DFDs)

Data Flow Diagrams (DFDs) are directed graphs. There are two elements in the DFDs: arcs and nodes. Data is represented by arcs and the processes (that manipulate the data) are represented by the nodes.

A process could be a fundamental/simple process which does not need to be broken down further or a complex one that is continuously broken down to a more detailed DFD which shows the sub-processes and data flows within it. DFDs can be described as a graphical representation of the information flow in a system, and they also make up one of the three elements of Structured System Analysis & Design Method (SSADM). DFDs play a major role in the design process as they allow users, as well as designers to picture how the system will work, what will it achieve, and how it will be put together to achieve its objectives. As well as this, DFDs provide users with the opportunity to see how their input affects the system as whole as well as adjacent parts of the system. However, they do have some disadvantages:

They do not display the input/output of the system in detail

Users find DFDs confusing when they first use them

They do not include time representation

12.4.5 Context Diagram

A context diagram provides a black box overview of the system and the environment surrounding it that may interact with it. This diagram is the highest level view of a system. It is similar to the block diagram, as it illustrates the overall view of the system and the inputs/outputs interacting with it. Context diagrams hide the interior structure of the system. The focus of context diagrams is to show the external factors that have an effect on the system and is used in parallel with establishing system requirements.

12.4.6 Entity Relationship Diagram (RD)

ERD is essential for the design of database tables, extracts, and metadata.

ERD uses a graphical representation of the data layout of a system at a high level of abstraction and defines data elements and their inter-relationships in the system. ERD is popular and commonly used and well understood. Since ERD is a graphical tool it is easy to read by analysts and users.

Advantages of ERD include the following:

Data objects and relationships are modeled independently from the processes

Can be used to design database architectures

Effective tool to communicate with database administrators

Advantages of ERD include the following:

May be confusing for users since it uses formal notation

It is a complex tool

12.4.7 State Transition Diagram

STD models real time behavior of the software systems and shows the time ordering between its processes. STD has two diagram elements: states and transitions. A state is represented by a circle or oval and a transition is represented by an arrow. The system goes from one state to another based on change of inputs. STD explains what action causes a state change but not when or how often the state changes.

12.5 Comparison between Structure Analysis & Design Approach and Object Oriented Analysis & Design Approach

Table 1 shows a comparison between structure analysis and design approach and object-oriented analysis design approach.

Structure Analysis and Design

Object Oriented Analysis Design

Similarities

Both are generated from programming techniques

Both use graphical design and graphical tools to analyze and model the requirements

Both provide a systematic step-by-step process for developers

Both focus on documentation of the requirements

Difference

Process-oriented

Data-oriented

encapsulates as much of the systems’ data and processes into objects

Table 1: a comparison between structure analysis and design approach and object-oriented analysis design approach

Summary

In this lecture we presented the structured systems analysis and design methodology and approach that is used in software systems development. We first presented an overview of the methodology. We defined it, listed its objectives, advantages and disadvantages. Then we presented the activities of the structured systems analysis and design methodology including logical data modeling, data flow modeling and entity event modeling. Later, we presented the elements of the essential model of the structured analysis and design methodology which are the environmental model, the behavioral model and the implementation model. After that, we presented the structured analysis and design tools and techniques including the Structured Query Language (SQL), the Structure Chart (SC), the Data Dictionary, the Context Diagram (CD), the Entity Relationship Diagram (ERD), and the State Transition Diagram (STD). Finally, a comparison between structure analysis and design approach and object oriented analysis and design approach was presented.

Exercises

What are the objectives of the structured analysis and design methodology

List three advantages and three disadvantages of the structured analysis and design methodology.

What are the elements of the structured analysis and design methodology?

What are the activities of the structured analysis and design methodology?

Describe 5 tools used by the structured analysis and design methodology.

Of the main tools of SSADM which is the most important and why from the point of view of the analyst/designer?

Which tool of the SSADM would be the easiest to understand from the end-users point of view?

"When developing information systems the technical environment should be established as soon as possible to avoid any nasty surprises in the later stages of development." Is this a valid statement? If so why within SSADM do technical system options not get considered until the stage that precedes the last module.

With so many possible implementation environments is there any point having a general physical design module?

Would SSADM be feasible without the support of CASE tools?