SSADM

Structured
Systems
Analysis and
Design
Method
 What is SSADM?
 How is SSADM Structured?
 What are the Major Techniques of SSADM?
 Structured Systems Analysis and Design
Method

 SSADM is sometimes thought of as a

‘cookbook’ approach to the analysis and
design stages of the systems development
lifecycle
 Developed to standardise many UK
governmental IT projects
 Data driven – concentration on the data

rather than processes. 

 Highly structured with rules, guidelines

and standards
 Documentation is crucial to all aspects of

the system project development

Smaller stages lead to:
◦ Improved planning
◦ Better scheduling
◦ Early identification of problems
◦ Better quality
◦ Flexibility and ease of change
1.
1.Feasibility
FeasibilityStudy
Study Stage 0: Feasibility

Stage 1: Investigation of Current Environment

2.
2. Requirements
RequirementsAnalysis
Analysis Stage 2: Business Systems Options

Stage 3: Definitions of
3.
3.Requirements
RequirementsSpecification
Specification Requirements

Stage 4: Technical Stage 5:

4.
4. Logical
LogicalSystem
System Specification
Specification System Options Logical Design

Stage 6: Each step follows on

5.
5.Physical
PhysicalDesign
Design Physical Design from the previous
complete step
1.
1.Feasibility
FeasibilityStudy
Study Stage 0: Feasibility

 Examine whether project is technically,

financially and socially feasible

 In other words – whether it is in

accordance with the current business
model

 Determine whether the project is cost-

effective (benefits vs. costs)
 Stage 1: Investigation of Current Environment
2.
2. Requirements
RequirementsAnalysis
Analysis Stage 2: Business Systems Options

 Stage 1: Investigation of current Environment

◦ Learn the terminology and function of the users’ environment
◦ The current system forms the basis
◦ Understand the data required
◦ Set the system boundary clearly
◦ Model the current system in terms of processes (DFD) and data
structures (LDS)
◦ Analyse the business operations for problems etc.
◦ Users are involved in walk-through at the end of this stage

 Stage 2: Business System Options

◦ A decision is made by users as which option best meet their
needs
 Stage 3: Definitions of
3.
3.Requirements
RequirementsSpecification
Specification Requirements

 A detailed specification of the required system

is built up and checked extensively.
 Requirements are defined for processes and
data structures modelled in the previous step.
 Both functional and non-functional
requirements are defined

 The selected way to go is developed and refined,

ELHs introduced
 Stage 4: Technical Stage 5:
4.
4. Logical
LogicalSystem
System Specification
Specification System Options Logical Design

 Stage 4: Selection of technical options

Cost/benefit analysis is performed for each of the system’s
hardware and software options
 Stage 5: Logical design
The specification developed in stage 3 is expanded to a
high level of detail:
◦ Define the logic of databases, user dialogues etc
◦ Define update and operations processes
◦ Define how enquiries are processed
◦ Define the sequence of logical processes
 Stage 6:
5.
5. Physical
PhysicalDesign
Design Physical Design

 The complete logical design - both data and processing is

converted into a design that will run on the target
environment.
 Logical and Technical Specifications are used to produce a
physical database design and a set of program
specifications, i.e. how the programs should work
 Create function component implementation map (FCIM) to
document the logical to physical mapping
 Optimise physical data design
 Complete function specification
 Consolidate process data interface
 Assemble physical design
Modelling of:
1 Underlying structure of the data in the
system: entities and their relationships
(LDS s)
2 Data flows in / out of the system and
any data transformation (DFD s)
3 The way in which data in the system
changes over time by events acting on
entities (ELH s)
These 3 models are used to cross check
for consistency & completeness
[This will probably look familiar]
 Modelling and
documenting the Customer
Customer
data requirements

 These
requirements are Order Part
Part
Order
then separated
into entities
(objects) and
relationships Order_Line
Order_Line
(between entities).
  Entity - A thing that is of interest to an
organisation about which information is
stored
 The items of interest are called ATTRIBUTES

Example
• System = University
• Entity = Student
• Example = Fred Smith
• Attributes ?????
 A diagram to show RELATIONSHIPS
between entities
 e.g. A TUTOR teaches many STUDENTS

Tutor Students
teaches

• Alternative names
– Data Model
– Entity-Relationship Model
– Bachman Diagram
 Identify the University Student
entities
 Find the University Student
RELATIONSHIPS
between them
 Decide the University Student
CARDINALITY 1 Many
 Must, Must Doctor Patient

 May, Must Doctor Patient

 Must, May Doctor Patient

 May, May
Doctor Patient
 Each…[must be/may be]….[one or more/one
and only one]
 e.g. Each DOCTOR may be responsible for

one or more PATIENTS

 Do not create ENTITIES from Attributes e.g.
A Human has 2 ARMS (These are
attributes)
 Do not put in unnecessary links
 Avoid Many-to-Many relationships
These cause problems as it is difficult to trace
which example of entity A refers to which of
entity B. Put an extra entity in between.

Flight Ticket Passenger

 CUSTOMERS make sales ORDERS
 A single order has several PRODUCTS
 Each customer is in one of 621 AREAS
 Each customer is serviced by one of 20
DEPOTS
 Each customer is allocated a depot
depending on their customer location
 All products are stocked in depots

Customer Order Product

Area Depot
 CUSTOMERS make sales ORDERS
 A single order has several PRODUCTS
 Each customer is in one of 621 AREAS
 Each customer is serviced by one of 20
DEPOTS
 Each customer is allocated a depot
depending on their customer location
 All products are stocked in depots

Customer Order Order Line Product

Area Depot
 CUSTOMERS make sales ORDERS
 A single order has several PRODUCTS
 Each customer is in one of 621 AREAS
 Each customer is serviced by one of 20
DEPOTS
 Each customer is allocated a depot
depending on their customer location
 All products are stocked in depots

Customer Order Order Line Product

Area Depot Stock Item

Exclusivity Bank Building
Society

Account

School

Sub Types
Public Private
School School
A Logical Data Model consists of:
 Logical Data Structure
 Entity description
 Relationship description
 Attribute descriptions
 Modelling the way that Customer
Customer
data flows within a Customer and
system Order Details
 Looks at data in terms of 11 Accounts
Accounts
◦ Processes (which transfer
data from one form to Check
CheckCustomer
Customer
another) Details
Detailsand
andCreate
CreateOrder
Order
◦ Data Stores (which are
places where data is held) Valid Order Details
◦ External Entities (objects
from which data comes, or D1
D1 Orders
Orders
objects which receive data)
◦ Data Flows (routes by which
the data can flow)
 Maps the route of data around a system

Data Source and Sink

Data Store

Flow Line

Process
• is easy to understand and communicate
• does not show procedures and control as a
flowchart does
 Person or entity
Process responsible for process
number
2.3.4 Sales
Process customer
order
Process descriptor
 Customer
Customer
Payment
Deposit
Bank 1
Process Payment

1 Remittance data
Receivables
information
2 Credit
2 Accounts Update receivables
receivable
ma
nag
 Data does not flow directly
between processes
 Data does not flow directly
between data stores
 Data cannot be transferred
directly from store to sink or
source to store
Method by Tom De Marco
1. Identify all net input and output data flows of the system
What are What are
the inputs? the outputs?
2. Work your way from inputs to outputs, backward from outputs
to inputs, or from the middle out
From, input to output

From output to input

From middle out
3. Label all the interface data flows
4. Label all the functions/processes
 Method by Geoff Cutts
1. Create a physical document flow diagram
Use ‘Ellipse’ to represent a person or
department/section

Order form Sales Dept. Picking notes

Customer Warehouse
Invoice
Cheque Dispatch note
Accounts
Dept.
 2. Identify the boundary of the system. Draw dotted
line to indicate the boundary. Anything outside
the boundary will be the external entities (source
and receipt of data).

Order form Sales Dept. Picking notes

Customer Warehouse
Invoice
Cheque Dispatch note
Accounts
Dept.
 3. Create the current physical DFD.
Make processes of the ‘Ellipses’ inside the
boundary

Order form 1 Sales Dept. Picking notes

Process Order

Customer Warehouse
Invoice
Cheque Dispatch note
2 Accounts Dept.
Prepare Invoice
 4. Create the context diagram (Level 0), which
shows the external interfaces with the outside
world, i.e. the global view of a system.

0
Order form Picking notes
Customer Invoice Warehouse
Sales &
Cheque Accountancy Dispatch note
System
 5. Create lower level diagrams. Each process can
be expanded (decomposed) into lower levels
and lower level DFDs show more details

Level 1 1 After further

2 investigations,
process 1 may
become
1.1
Level 2 – 1.2 Ensure inputs
Reference ID is & outputs
1.1, 1.2 …. 1.3 match
 A system may have a set of DFDs with levels
0 to level N (3 to 4 is common).
 Each level should have at the most 7

processes (easy to digest & to remember)

 Those processes (functions) at the bottom

level, which cannot be decomposed further,

are called Primitive functions.
6. Ensure all data flows are given a name

“A DFD cannot be considered to be

completed unless all data flows and
functions have been given a meaningful
name”

7. Add Data Stores where needed

 Information sink – No output form a process

 Write-only-files – File becomes larger

 Overly complex interfaces - Octopus

 Unnamable data flows

 Unnamable processes
 A physical DFD represents HOW things are
happening.
It contains the problems of the current system, and
is people or machine dependent.
It tends to contain redundant data stores/
processing.
It tends to mention names of departments, people,
forms, devices used and where data is stored

 A logical DFD is extracted from a physical DFD. It is

a logical representation of the system, which
indicates WHAT the system accomplishes.
It is implementation-independent: it focuses on the
flow of data between processes without regard to the
specific devices, storage location or people in the
system.
 Physical Logical
Order Order
Clerk
form form
Receive order Order Order
Receive
and write out an order
order file

Dispatch Dispatch
note Typist details
Invoice
Produce
Type invoice Invoice
Price invoice
Price file
information
 Current Physical DFD How the current system works

What the current system

Current Logical DFD
accomplishes

Current System Requirements for

Problems New System

What the new system

Required Logical DFD
is required to accomplish
 What the new system
Required Logical DFD
is required to accomplish

Technical System
Option chosen

How the new system

New Physical DFD will work
 Logicalise the data flow
What data contents are required, remove physical
descriptions e.g form/card
 Remove time dependencies due to
implementation
e.g. The orders are not to be processed until the number is
bigger than 20
 Logicalise the functions
Remove unnecessary processes, remove control
information, functions which perform only physical
tasks
 Logicalise the data stores
For the data flows from or to a data store (physical),
replace the data flow with the entity or entities
referenced, and replace the physical data store with a
logical data store
 An entity may be effected by several events.
 An event may effect several entities.
 This can be represented by

◦ a matrix (Entity Event Matrix)

◦ separately for each entity (Entity Life History)
◦ separately for each event (Effect Correspondence
Diagram)
 List all entities (from LDS) across the top of
the page.
 List all events (system functions, from DFD)
down the side of the page.
 Fill in the matrix as follows:
◦ If an event creates an entity, mark with C.
◦ If an event deletes an entity, mark with D.
◦ If an event modifies an entity, mark with M.
(Include modifications to relationships)
◦ All entity columns should have at least one C, D,
M.
 Entities

n
ti o
Events er

va
w

er
pe
rro

r
an

to

tle
M M C

es
Ta

Ac
Bo

Lo
sue Video

Ti
R
deo Return M M D M
servation Request C
ew Video C C
llect Reservation M M C D
Models how the system’s data is changed
over time by events acting on entities.

Customer
Customer
Deletion:
Deletion:
Creation:
Creation: Main
MainLife
Life Outstanding
First Cycle Outstanding
FirstOrder
Order Cycle Balance
Balance==00and
and
Placed
Placed No
NoOrders
Ordersfor
for66Months
Months

Detail
DetailChanges
Changes Balance
BalanceChanges
Changes

Detail Change**
DetailChange Balance Change**
BalanceChange

Name O
Address O Tel. O
Payment
PaymentMade
Made O Order
OrderAccepted
O O
Name O Address O Tel. O Accepted O
 An Entity life history consists of a tree, the top
node of which is the entity.
 The next level contains nodes indicating the
organisation of events.
 The almost lowest level contains nodes
representing the individual events which change
the entity.
 The lowest level contains the processing
operations which achieve the effects of the higher
nodes.
 SEQUENCE - left to right

 SELECTION: either or

 ITERATION: 0 or more times

*
1. Create an Entity-Event matrix (as above)
2. Inspect each column of the matrix - Entity
Life
3. Inspect for ‘Normal life’ (Creation,
Amendment, Deletion)
4. Build up ELH using constructs
(Sequence, Selection, Iteration, Parallel)
Include all known events
5. Look for abnormal events and insert
 “For each entity, make out an entity life
history”
 In a real situation

Identify entities that

- Effect a lot of other entities
- Change states a lot
 These are used to ensure that the Entity
Life Histories are completed satisfactorily.

Example. A customer cancels an order with

company ABC. It consisted of several order
lines. The order was already confirmed on the
delivery schedule and will have to be removed
from there.
*Set of Order
Order Lines

Delivery
Schedule Order Lines
 List all entities effected (updated) by an
event.
 Draw as for LDS, including only entities and

relationships effected by the event.

 If one event can effect an entity in different

ways, use selection boxes, listing the effect

roles in the box.

Booking

o o
Provisional Confirmed
 If one event can effect several occurrences
of an entity, use an iteration box, describing
the set of occurrences in*Setthe box.
of Order
Lines

Order Lines
 Entities required by the event for enquiry
purposes can also be listed, along with the
reasons for enquiry and attributes needed.
Entities needed more than once for different
reasons, will be displayed more than once,
but boxed together.
 The Business

*
Models can reference
each other to form a
complete system view
 Relationship between DFD & LDS:
Each data store should correspond to an entity or
a group of entities in the LDS.
  Relationship between LDS & ELH :
An ELH is constructed for each entity in the
required LDS. The construction of each ELH
required reference to both DFD and LDS.
 Relationship between DFD & ELH :
The events reflected in the ELH are referenced in
the DFDs.
 Enquiry Access path
Route through the logical Data model from an entry
point to the entity(s) required for a particular enquiry
function.

 I/O structure
The input to and output from a function or part of a
function
 Dialogue Design
Identify which functions will be on-line/batch and
those functions which may be prototyped. Detailed
dialogue for the user is shown.
 Logical Database Process Design
Contain operations and conditions forming a very
detailed specification of the processing.
 Relational data analysis
The use of normalization of data to cross check the
required system logical data to ensure data
completeness.

 Requirement Definition
The analyst tries to develop a consensus amongst
users regarding the definition of each requirement
and its importance.
 Function definition
Functions are initially defined from the required
system DFDs and then refined as the specification
become more detailed.

 Formulation of options
Business and technical options are formulated for
users to select

 Specification prototyping
Deals with the selection, construction,
demonstration, evaluation, review, and re-
specification of the core critical functions. The
results feedback into systems design.
 Users should be consulted at the end of
each phase by:
◦ Structured walkthroughs
◦ Reviewing the models
 Two stages involve users a lot, namely:
◦ Selection of business options
◦ Selection of technical options
 At the end of all the phases the product
is reviewed to determine any errors with
the product.
 Systems are built to:
◦ Meet the systems’ objectives
◦ Gain the users’ acceptance
 All levels of users should be involved (From
the beginning of a project - involvement in,
and commitment to the development of their
system)
 Tentative designs for the new system are to
be put to the users
 A business system option describes a
system:
the boundary, the inputs and outputs and the
functionality.
 Options can vary in:
◦ Distributed nature, levels of autonomy, and
position of system boundary.
◦ There could be different ways in which a system
can be organized, each having strengths and
weaknesses.
 Each possible solution will have cost/ benefit
analysis and also have an impact analysis on
the future users of the system.

 Brainstorming can generate other possibilities

of options.
 In the physical design stage, there is a need
to consider the technical architecture for the
future system.

 Possible technical architectures are to be

considered by management to decide which
architecture is more appropriate.
 Each option will contain details of: technical
architecture, system sizing, functionality
supported, cost and benefits, impact on the
organisation, plan for construction and
implementation.

 Certainly, users should be guided to make

the decision.
 Only suitable to well-structured
environment (objectives are clear)
 No real ‘social’/’organization’ dimension
(Nothing on how to manage the organization &
nor human change processes, people side – job
satisfaction)
 Life cycle coverage - ‘headless’ or
‘tailless’ (Only analysis & design)
 No project planning/ control standard
(When project is time or budget limited)
 CASE support required (Graphic
Documentation)
 Skills of System Analyst required
 3 views of a system for cross-checking (DFD,
LDS, ELH)
 Build in checking mechanism
 Design is independent of implementation
(more flexible system)
 Better communication with and
involvement of user
 Earlier and better validation of stages of
analysis and design
 SSADM standard (structural, procedural and
documentary)
 Using SSADM is an accurate and
controlled way of developing a system

 It produces an in-depth system view

and allows for a level of standardisation
in the way IT projects are developed

 However, it doesn’t account for social /

psychological factors within the
organisation
 www.csd.abdn.ac.uk/~jmasthof/teaching/CS
5540/.../lecture9.
ppt