Systems Analysis

SSADM

Last Session
System Lifecycles:
Traditional
Prototyping

Aim of this session

Give you an overview of SSADM and
Requirements Analysis

Outcomes
You will understand the purpose of
SSADM
Requirements Analysis
Functional
Non-Functional

SSADM
Structured
Systems

Analysis and
Design

Method

SSADM
Methodology for analysing business
information systems.
Highly structured and rigorous method of
systems development
(Weaver,1998)

SSADM
Developed by Learmonth and Burchett
Management Systems and launched in
1981.
Title is Crown copyright, but anyone is
entitled to use the methodology free of
charge.

Strategy
Planning

Feasibility

Analysis

SSADM
Lifecycle

Design

Implementation

Maintenance

S
S
A
D
M

Feasibility
Study
Requirements
Analysis
Requirements
Specification
Logical System
Specification
Physical Design

SSADM
top down stepwise refinement
Starts with an overall view of the
system.
Analyses all processes within the
system.

SSADM
Users are closely involved.
Users get the system they want.
SSADM provides a good method of
communication between users and
developers

SSADM

"Verification: 'Are we building the

product right?

Validation: 'Are we building the

right product?"

SSADM
Provides Physical and Logical views of
the system.
Uses diagrammatic and non-diagrammatic
techniques

Data Driven

Strategy
Planning

Feasibility

Analysis

Design

SSADM
Lifecycle

Implementation

Maintenance

S
S
A
D
M

Feasibility
Study

Requirements
Analysis

Requirements
Logical System
Specification
Specification
Physical Design

Stages of
SSADM

Stage 0
Feasibility

Stage 1
Investigation of Current Environment

Stage 2
Business System Options
Stage 3
Definition of Requirements

Stage 4
Technical System Options

Requirements Analysis

Requirements Specification

Stage 5
Logical Design

Stage 6
Physical Design

Requirements Analysis
The aim is to produce a specification
that is:
Clear
Concise
Unambiguous
Understandable to the customer or end
user.

Functional

Non-Functional

Functional Requirements
Relate directly to the operation of the
system.
Specify what the customer wants the
system to do, highlighting the main aims
within the document.
Specify the main functions inherent in the
user requirements.

Functional Requirements
E.g. In an invoicing system
Functional Requirements:
Produce an invoice
Store Customer details
Store Product Details

Non-Functional Requirements
Often known as constraints. They
provide information about what
limitations will be imposed on the
system.
E.g.
Response times
Hardware/software that is available
Programming language to be used

Requirements Gathering
Interview Users
Questionnaires
Observation

Problems with
Requirements Gathering
Functional and non-functional
requirements are not obviously
separated.

Users have different views of the system

or may be hostile to the situation.
The requirements document may have
omissions or ambiguous statements.

Interview Techniques
Ask open questions
How?
What?
Where?
Who?

Ask for clarification or explanations to

avoid ambiguities.

Any Questions?

Task 2
Create a technical manual for use in
your organisation
Use examples from the North Sea
Liners Case Study
Evaluate techniques used
Create in Word, Excel, PowerPoint or Visio

North Sea Liners

Case Study

Documentation

Diagram Description
Group:
System:
Analyst:
Date:

Page

# of #

Draft/Final

Requirements
System:
Group:
Analyst:
Date:

Page:

Functional Requirements

Draft/Final

Non-functional Requirements