What is SSADM

• Abbreviation: Structured Systems Analysis and Design Method
• It is a systems approach to the analysis and design of information systems
• SSADM divides an application development project into modules, stages, steps and tasks.
• It provides a framework for describing a project in a way that’s suited to managing it.

SSADM’s objectives

• improve project management and control.
• make more effective use of experienced and inexperienced development staff.
• develop better quality systems
• to make projects resilient to the loss of staff.
• enable projects to be supported by computer-based tools such as computer-aided software engineering systems (CASE)
• establish a framework for good communication among project participants

Show

Why use the Structured Systems Analysis and Design Method (source: TechTarget)

SSADM techniques

Logical data modelling

• The process of identifying, modelling and documenting the data requirements of the system being designed

⇒ The result is a data model containing

• entities (things about which a business needs to record information)
• attributes (facts about the entities)
• relationships (associations between the entities).

Data Flow Modelling

• The process of identifying, modelling and documenting how data moves around an information system.
• Data Flow Modeling examines
  • processes (activities that transform data from one form to another)
  • data stores (the holding areas for data)
  • external entities (what sends data into a system or receives data from a system)
  • data flows (routes by which data can flow).

Entity Event Modelling

• A two-stranded process: Entity Behavior Modelling, Event Modelling
  • Entity Behavior Modelling, identifying, modelling and documenting the events that affect each entity and the sequence (or life history) in which these events occur
  • Event Modelling, designing for each event the process to coordinate entity life histories

Stages

• The SSADM method involves the application of a sequence of analysis, documentation and design tasks in the following

Stage 0 – Feasibility study

• There must be some form of investigation into the goals and implications (a logical relation between propositions p and q of the form `if p then q’; if p is true then q cannot be false) of the project, so we can determine whether or not a given project is feasible.
• When a feasibility study is carried out, there are four main areas of consideration

Technical

• is the project technically possible?

Financial

• can the business afford to carry out the project?

Organizational

• will the new system be compatible with existing practices?

Ethical

• is the impact of the new system socially acceptable?
• To answer these questions, the feasibility is effectively a condensed version of a comprehensive system and design.
• The requirements and usages are analyzed to some extent, some business options are drawn up and even some details of the technical implementation are. The product of this stage is a formal feasibility study document.

Stage 1 – Investigation of the current environment

• The developers of SSADM understood that in almost all cases there is some form of the current system even if it is entirely composed of people and paper.
• Through a combination of interviewing employees, circulating questionnaires, observations and existing documentation, the analyst comes to a complete understanding of the system at the start of the project. This serves many purposes

Stage 2 – Business system options

• Having investigated the current system, the analyst must decide on the overall design of the new system.
• To do this, he or she develops a set of business system options using the outputs of the previous stage. These are different ways in which the new system could be produced varying from doing nothing to throwing out the old system entirely and building an entirely new one.
• The analyst may hold a brainstorming session so that as many and various ideas as possible are generated.

Stage 3 – Requirements specification

• This is probably the most complex stage in SSADM
• Using the requirements developed in stage 1 and working within the framework of the selected business option, the analyst must develop a full logical specification of what the new system must do.
• The specification must be free from error, ambiguity and inconsistency. By logical, we mean that the specification does not say how the system will be implemented but rather describes what the system will do.
• To produce the logical specification, the analyst builds the required logical models for both the data-flow diagrams (DFDs) and the Logical Data Model (LDM), consisting of the Logical Data Structure (referred to in other methods as entity relationship diagrams) and full descriptions of the data and its relationships.
• These are used to produce function definitions of every function which the users will require of the system, Entity Life-Histories (ELHs) which describes all events through the life of an entity, and Effect Correspondence Diagrams (ECDs) which describe how each event interacts with all relevant entities. These are continually matched against the requirements and where necessary, the requirements are added to and completed.
• The product of this stage is a complete requirements specification document which is made of
  • the updated data catalogue
  • the updated requirements catalogue
  • the processing specification which in turn is made up of
    • user role/function matrix
    • function definitions
    • required logical data model
    • entity life-histories
    • effect correspondence diagrams

Stage 4 – Technical system options

• This stage is the first towards a physical implementation of the new system application. Like the Business System Options, in this stage, many options for implementing the new system are generated.
• This is narrowed down to two or three to present to the user from which the final option is chosen or synthesized.
• However, the considerations are quite different being:
  • The hardware architectures
  • The software to use
  • The cost of the implementation
  • The staffing required
  • The physical limitations such as space occupied by the system