Skip to main content
Office of the Government Chief Information Officer Brand Hong Kong - Asia world city
  Default Font SizeA Larger Font SizeA Largest Font SizeA Search Submit Search query Site map Contact us
Mobile / Accessible Version Printer View RSS
caring organisation  This website is IPv6 Enabled 
Home  >  IT Infrastructure and Standards  >  Professional Methodologies  > 

Main Content

Structured Systems Analysis and Design Methodology

SSADM V4.2 Structural Standards

This SSADM Version 4.2 Structural Standards, which is one of the four volumes of SSADM V4.2 Practitioner Manuals, explains the typical structure of work processes of Systems Analysis and Design. It defines in detail the activities to be carried out in Feasibility Study (FS) Phase and Systems Analysis and Design (SA&D) Phase.

Each phase in SSADM consists of a number of Stages, each Stage is subdivided into Steps and each Step further contains a series of tasks. Thus the total work content of these critical phases of systems development is broken down into discrete, manageable portion. This is essential for project control and resources allocation.

The document provides a structural framework for project teams to apply SSADM. It defines "when to do it" within SSADM.

Please refer to the SSADM Documentation Standards and SSADM Techniques Guide for the description of products / techniques stated in the structure.

The framework may be customized to tailor for different project situations.

For ease of reference, parts of the contents are extracted from the document and summarized as below.

SSADM Structure

The following diagram describes the usage of SSADM in OGCIO System Development Life Cycle (SDLC):

SSADM in OGCIO System Development Life Cycle

As shown in the diagram, SSADM covers the FS, SA&D and part of the Implementation Phases of OGCIO SDLC. A Project Initiation Document will be compiled during the Project Request Phase, a Feasibility Study Report will be prepared during the FS Phase, whereas a System Analysis and Design Report will be produced during the SA&D Phase. In the course of Implementation Phase, necessary documentations will be delivered. And finally after system implementation, Post Implementation Review will be conducted.

The FS Phase corresponds to SSADM Stage 0 - Feasibility.

The SA&D Phase consists of five stages :-


  1. Investigation of Current Environment
  2. Business System Options
  3. Definition of Requirements
  4. Technical System Options
  5. Logical Design

The Implementation Phase includes Stage 6 - Physical Design.

Feasibility Study Phase

Stage 0 - Feasibility

A Feasibility Study is a short assessment of a proposed information system to determine whether the system can effectively meet the specified business requirements of the organization, and whether a business case exists for developing such a system.

A Feasibility Study is recommended as a preliminary to a full System Analysis and Design project. However, for those projects with low risk, or the Information Systems Strategic Study has been performed, the Feasibility Study can be considered to combine with System Analysis and Design.

A Feasibility Study Report will be produced at the end of Stage 0.

The steps of this stage are:

(a) Define the Problem
This step is concerned with gaining a good understanding of the business and information needs of the business area under consideration. It highlights unsatisfactory services within the current environment and additional functions and data required in the new environment. It is not, however, recommended that detailed data and process models be constructed. The purpose is to investigate to a level of details that allow the key requirements which determine the feasibility options to be defined.

(b) Select Feasibility Options
The Feasibility Options defined in this step are possible logical solutions to the requirements described in the user requirements. This step aims to develop several options that meet the defined requirements, from which users can select.

Systems Analysis and Design Phase

Stage 1 - Investigation of Current Environment

During this stage, detailed requirements are collected and models of the business are built. These models will include both existing clerical and IT systems, as well as planned business procedures and information needs.

These physical views of information and procedures are then logicalized. All the constraints and problems are recorded alongside other system objectives in the User Requirements.

(a) Develop Business Activity Model
A model of business activity is built. Business events and business rules would also be investigated as an input to the specification of the new automated system.

(b) Investigate and Define Requirements
The objective of this step is to identify the problems associated with the current environment that are to be resolved by the new system. It also aims to identify the additional services to be provided by the new system and users of the new system.

(c) Investigate Current Processing
It investigates the information flow associated with the services currently provided, and describes them in the form of Data Flow Model. At this point, the Data Flow Model represents the current services with all their deficiencies. No attempt is made to incorporate required improvement, or new facilities.

(d) Investigate Current Data
This step is to identify and describe the structure of the system data, independently of the way the data is currently held and organized. It produces a model of data that supports the current services.

(e) Derive Logical View of Current Services
The objective of this step is to develop a logical view of the current system that can be used to understand problems with the current system.

Stage 2 - Business System Options (BSOs)

To assist the management to make a sound choice, a number of business system options, each describing the scope and functionalities provided by a particular development / implementation approach, are prepared and presented to them.

These options may be supported by technical documentation such as Work Practice Model, Logical Data Model and Data Flow Model. They also require financial and risk assessments to be prepared, and need to be supported by outline implementation descriptions.

The steps of this stage are :

(a) Define BSOs
This step is concerned with identifying a number of possible system solutions that meet the defined requirements from which the users can select.

(b) Select BSO
This step is concerned with the presentation of the BSOs to users and the selection of the preferred option. The selected option defines the boundary of the system to be developed in the subsequent stages.

Stage 3 - Definition of Requirements

The objective of this stage is to specify in details the processing and data requirements of the option selected.

The steps of this stage are :

(a) Define Required System Processing
This step is to amend the requirements to reflect the selected Business System Option, to describe the required system in terms of system data flows and to define the user roles within the new system.

(b) Develop Required Data Model
This step is undertaken in parallel with the above step. The Logical Data Model of the current environment is extended to support all the processing in the selected Business System Option.

(c) Derive System Functions
During the parallel definition of data and processing, additional events are identified, which cause existing functions to be updated, and new functions to be defined. Service level requirements for each function are also identified in this step.

(d) Develop User Job Specifications
A Work Practice Model is developed to document the understanding of the user jobs in concern.

(e) Enhance Required Data Model
Its objective is to improve the quality of the required system Logical Data Model by the application of relational data analysis (also known as normalization).

(f) Develop Specification Prototypes
It is used to describe selected parts of the required system in an animated form, for demonstration to the users. The purpose is to demonstrate that the requirements have been properly understood and to establish additional requirements concerning the style of the user interface.

(g) Develop Processing Specification
This step is principally concerned with defining the detailed update and enquiry processing for the required system.

(h) Confirm System Objectives
During Stage 1 and 3, the requirements will have been recorded, as they are identified, in the user requirements. This step represents the final review of the requirements before the completion of the Definition of Requirements Stage.

Stage 4 - Technical System Options (TSOs)

Several TSOs are developed, possibly including the "no change" option (i.e. using the existing system architecture). It is important at this point to determine how many are required, based on the parameters of the cost of producing each one to a useful level of detail, the need to demonstrate practicality, and the scope for exploring alternative approaches.

Details can then be added in terms of costing, performance and impact on the organization. The detailed options are then prepared for presentation.

The steps of this stage are :

(a) Define TSOs
Its purpose is to identify and define the possible approaches to the physical implementation to meet the function definitions. It also validates the service level requirements for the proposed system in the light of the technical environment.

(b) Select TSO
This step is concerned with the presentation of the TSOs to users and the selection of the preferred option.

Stage 5 - Logical Design

The objectives of this stage are to design the menu structure and dialogues of the required system, and to specify the update/enquiry process modules.

The steps of this stage are :

(a) Define User Dialogue
This step defines the structure of each dialogue required to support the on-line functions and identifies the navigation requirements, both within the dialogue and between dialogues.

(b) Define Update Processes
This is to complete the specification of the database updating required for each event and to define the error handling for each event.

(c) Define Enquiry Processes
This is to complete the specification of the database enquiry processing and to define the error handling for each enquiry.

Implementation Phase

Stage 6 - Physical Design

The objective of Physical Design Stage is to specify the physical data and process design, using the language and features of the chosen physical environment and incorporating installation standards.

This stage addresses the following activities :

(a) prepare for Physical Design :

  • learn the rules of the implementation environment;
  • review the precise requirements for logical to physical mapping; and
  • plan the approach.

(b) complete the specification of functions;

(c) incrementally and repeatedly develop the data and process designs.
For further information, you are welcome to contact us through email Email to us.