System Development Methods

CT00046-3-2

Structured
Methodologies
 Topic & Structure of the Lesson

1. Principles of structured methodologies.

2. Phases in Waterfall methodology, Structured
Systems Analysis and Design Methodology
(SSADM), and V-Model.
3. Strengths and weaknesses of structured
methodologies.

Module Code & Module Title Slide Title SLIDE 2

Slide 2
 Slide 3 (of 17)

Learning Outcomes

By the end of this lecture, you should be able to :

1. Explain the underlying principles of Structured
Methodologies.
2. Describe the phases in Waterfall, Structured
Systems Analysis and Design Methodology
(SSADM), and V-Model.
3. Identify the strengths and weaknesses of
Structured Methodologies.

Module Code & Module Title Slide Title SLIDE 3

Slide 3
 Slide 4 (of 17)

Key Terms you must be able to use

If you have mastered this topic, you should be able to

use the following terms correctly in your assignment
and exam:
 Structured Methodologies
 Waterfall Methodology
 SSADM
 V-Model

Module Code & Module Title Slide Title SLIDE 4

Slide 4
Slide 5 (of 19)

Traditional / Structured
Methodologies
System development is organized into phases, with
deliverables and milestones to measure progress.
Developed in the 70’s.
Also known as Traditional Methodologies
Very detailed steps explained.
 The formulation for beginners to develop a system.
Requirements need to be clear and fixed.
Focus on error free product
Rigid and strict rules.
Emphasis on full documentation.
Example methodologies: Waterfall Model,
Structured Systems Analysis and Design
Methodology (SSADM), V-Model.
Module Code & Module Title Slide Title SLIDE 5
Slide 5
 Waterfall Methodology

Introduced in the 1970s by Dr. Winston W.

Royce.
Close to SDLC phases
Can be used for almost all types of projects
Highly structured and rigid -
sequential development process.
 One should move to the next phase only
when its preceding phase is completed and
perfected.
Promotes quality control of process and
product.
Emphasis on good documentation
Module Code & Module Title Slide Title SLIDE 6
Slide 6
 Waterfall Methodology
Phases

Requirements

Design

Implementation

Integration & Testing

Deployment

Maintenance

Module Code & Module Title Slide Title SLIDE 7

Slide 7
 Waterfall Methodology
Phases .. cont.

 Requirement Gathering and Analysis

– All possible requirements of the system to be developed
are captured and documented into System Requirement
Specification (SRS) document.
 System Design
– The SRS is studied, and system design is prepared.
– System Design helps in specifying hardware and system
requirements and helps in defining overall system
architecture.
 Implementation
– With inputs from system design, the system is first
developed in small programs called units, which are
integrated into the next phase.
– Each unit is developed and tested for its functionality
which is referred to as Unit Testing.
Module Code & Module Title Slide Title SLIDE 8
Slide 8
 Waterfall Methodology
Phases .. cont.
Integration and Testing
– All the units developed in the implementation phase
are integrated into a system after testing each unit.
– Post integration the entire system is tested for any
faults and failures.
Deployment
−Once the functional and nonfunctional testing is done,
the product is deployed in the customer environment or
released into the market.
Maintenance
– Aimed to fix some issues which come up in the client
environment.
– Also, to enhance the product some better versions are
released.
Module Code & Module Title Slide Title SLIDE 9
Slide 9
 Structured Systems Analysis and
Design Methodology (SSADM)

Popular
methodology used
in the late 80s
Rigid and
document-led
approach to system
design
Good for projects
with complex
database design.
Has strategies to
align business
needs with system
development.
Module Code & Module Title Slide Title SLIDE 10
Slide 10
 SSADM Phases

Decide how viable the project

really is.

Investigation of current system

and provides users with
options that meet their
requirements.
Refine the requirements based
on the selected business
system option.
Evaluation of the best
technical products and
provides detailed specification.

Covers everything needed for

construction and
Slide Title
implementation.
Module Code & Module Title SLIDE 11
Slide 11
 Project Definition

• Before a project can begin, we must establish the

objectives and the areas of the business
which are involved.
• The need to begin a new project may arise from a
variety of causes . For example:
– It may be that the existing manual system has
proved inadequate to handle a particular set of
circumstances,
– It may be that the requirements of an entirely
new company or department need to be
defined and subsequently satisfied.

Module Code & Module Title Slide Title SLIDE 12

Slide 12
 Project Definition (Cont.)

• The starting point for a project should be a Project

Initiation Document that includes 'terms of
reference’ .
• In systems analysis, the terms of reference are usually
produced jointly by the client (or user) and the
analyst and define:
– The objectives and scope of the investigation or
project.
– The resources available or required and the
timescales involved.
– Any limitations or constraints

Module Code & Module Title Slide Title SLIDE 13

Slide 13
 Feasibility Study

• Once the terms of reference have been defined, it

may be necessary to carry out a feasibility study in
order to decide how viable the project really is
before too many resources are committed.
• Within a feasibility study, a preliminary investigation,
analysis and design are carried out with the aim of:
– understanding the operation of the present system
and its problems
– identifying the requirements for the new system
– identifying a range of viable solutions to the
problem
– identifying the cost/benefit implications involved
Module Code & Module Title Slide Title SLIDE 14
Slide 14
 Feasibility Study (Cont.)

More specifically, the study should embrace the

following
• Overview of the current system (if appropriate)
− objectives
− outline description of processing
− -outline description of input and output data
requirements
− operational constraints, e.g., volumes of data,
timescales for processing, etc.
− problems, shortcomings, costs
• Requirements for the new system
− objectives
− overview of output, input, processing and data
Module Code & Module Title Slide Title SLIDE 15
Slide 15
 Feasibility Study (Cont.)

• Overview of a range of alternative solutions comprising, for

each solution:
− technical feasibility, i.e., will the proposed hardware and/ /or
software be able to solve the problem?
− are suitably qualified personnel available to develop the
system?
− economic feasibility, i.e., how much will the solution cost
(hardware, software, staff, training, etc.)?
− what are the benefits? can they be quantified (reduction in
staff)?
− what are the risks of implementing the system (e.g.,
financial loss)?
− what is the cost of not implementing the system? (e.g., loss
of competitive edge)
− operational feasibility: can the system be developed and
implemented within the given timescales?
Module Code & Module Title Slide Title SLIDE 16
Slide 16
 Feasibility Study (Cont.)

• Overall recommendation.
−other implications. For example, if the system is
to hold personal data, is the company registered
under the Data Protection Act? or software be
able to solve the problem?

Module Code & Module Title Slide Title SLIDE 17

Slide 17
 Investigation of Current Environment

• Investigation of the current environment documents the

current system (if it exists) and production of a Requirements
Catalogue, data model and process model.
– Requirements generally consist of a collection of
problems which have been identified in the current
system, together with a set of requirements for the new
system.
– As there may be millions of items of data within a small
system, it is necessary to simplify the analysis procedure by
grouping data relating to the same or similar objects
and treating it as a single entity. An entity is an object
of the real world about which information is held in a
particular system.
– Data is moved around the system by processes . These
processes may be triggered in several ways ; for
example, time, input of data from outside or from another
part of the system.
Module Code & Module Title Slide Title SLIDE 18
Slide 18
 Business System Options

• Provides User Management with prepared

options (Business System Options/BSO) describing the
scope and functionality of alternative ways of
developing a system to meet their requirements , user
and task identification.
• Describe 'what the system should do' rather than
'how it will do it’ .
• The set of options should be designed to give the
user the opportunity to decide what approach
should be taken to solve the problems of this part
of his business. It is normal for the analyst to produce
several options for discussion with the user.
• The proposed options are chosen, this choice
then enables the analyst to proceed with the
detailed logical design of the proposed system.
Module Code & Module Title Slide Title SLIDE 19
Slide 19
 Definition of Requirements

• Definition of Requirements take the selected Business

System Option and refines the requirements
catalogue, data and process models expanding the
detail into function descriptions and Input/Output
structures.
• The following tasks are carried out and documentation is
amended or created to support the development of the
required system model.
– Defining Required System Processing
– Development of Required Data Model
– Derive System Functions
– Structure Diagrams
– Specification Prototypes
Module Code & Module Title Slide Title SLIDE 20
Slide 20
 Technical System Options
• Technical system option is the evaluation of the best technical
products to meet the requirements specification. This is
carried out in parallel with the next phase Logical Design). The
options are normally produced in outline from a 'brainstorming'
session and consider some aspects, for example:
– Will we need processing to be available at more than one point,
in which case what levels of processing are needed and where
are the processor(s) and terminals going to be located?
– Does data need to be passed between sites and, if so, what do
we need?
– What software will need to be bought and/or developed? the
software was able to support adequate response times at peak
loading.
– What if the production of invoices were not held up due to
insufficient printers (or to the lack of a sufficiently large buffer
in the printer or printers).
Module Code & Module Title Slide Title SLIDE 21
Slide 21
 Logical Design
• Logical Design, (i.e., what the new system will do)
providing the detailed specification of
processing structures, data and Human
Computer Interfaces in the form of dialogues.
The three parts of this stage can be carried out in
sequence or in parallel, this will depend on the skills
and size of the project team.
– Dialogue Design: This area of design is important
to users as often they see their interaction with
the system as synonymous with the functionality of
the system.
– Define Update Processing: This step completes
the specification of the update processing and the
associated error handling.
– Define Enquiry Process: This step completes the
Slide Title
Module Code & Module Title SLIDE 22
Slide 22
 Physical Design

• Physical design (i.e., how the new system will work)

specifies the physical data, processes, inputs and
outputs. It covers everything needed to decide an
application's construction and implementation
methods.
• The stage requires expertise in the form of
designers, programmers and other specialists.
Analysts can specify function components, but
experienced designers are required to decide how
those components can be implemented.

Module Code & Module Title Slide Title SLIDE 23

Slide 23
 Physical Design

• Some tasks in this stage including:

– Create Physical Design Strategy: include Processing System
Classification, DBMS Data Storage Classification, DBMS
Performance Classification.
– Overview of Physical Data and Process Design.
– Space and Performance: If the previous activities have been
completed, the design may need to be modified to meet the
required storage and performance objectives.
– Physical Process Specification: the logical design products are
converted into programs, physical I/O formats and physical
dialogue designs that will work in the selected physical
environment.

Module Code & Module Title Slide Title SLIDE 24

Slide 24
 SSADM
Design Techniques

Logical Data Modeling

– To determine the high-level requirement for the
system
– System components, entities, main process, etc.

Data Flow Modeling

– To determine the ‘movement’ of data within the
system
– Data transformation, storage, data flow, etc.

Entity Event Modeling

– To determine the processes and operations
Module Code & Module Title Slide Title SLIDE 25
Slide 25
 V-Model

Derived and modified from Waterfall Model.

After the implementation phase, the phases in the V-
Model bent upwards to form the ‘V’ shape. This
represents the association between each phase with
its testing phase.
The horizontal dimension of the V-Model denotes
the project completeness (project time).
The vertical dimension of the V-Model denotes the
multiple levels of the system of interest. The
topmost level represents the system context in
which the system operates. The bottommost level
represents the parts that can be obtained and hence
suffice to be defined in a black-box-view.
Module Code & Module Title Slide Title SLIDE 26
Slide 26
 V-Model
Phases

Module Code & Module Title Slide Title SLIDE 27

Slide 27
 V-Model
Phases (Cont.)

Concept of Operations
Identify goals and objectives of the proposed
system, study business strategies and
policies to determine system constraints.
Study organizations entities, stakeholders,
activities, etc.
Produce a checklist that contains:
 Clear reasons to develop a new system or
upgrade the existing system.
 Stakeholders and their roles.
 Identified internal, external, support, physical
and operational environments of the proposed
system., etc.
Module Code & Module Title Slide Title SLIDE 28
Slide 28
 V-Model
Phases (Cont.)

 Requirements Analysis and Architecture

Requirements Analysis: User requirements are
collected using requirement engineering techniques i.e.,
interview, survey, observation, etc. Requirements the
documented in a System Requirements Specification
(SRS) describing functional and non-functional
requirements.
System Design: Study the SRS, figure out possibilities
and techniques to implement the defined requirements.
If any unfeasible requirements, user is informed to discuss
the alternative replacements. The software specification
document is produced that contains structure of system
menu, structure of data, data dictionary, list of
business scenarios, test plans, etc.
Architecture Design/Physical Design: Includes software
architecture, database tables, interface relationships,
Module Code & Module Title Slide Title SLIDE 29
Slide 29
 V-Model
Phases (Cont.)
 Detailed/Module Design
The proposed system has broken down into smaller and
manageable units/modules, then each unit is explained
in detail. The detailed design includes database tables with
type, size, and constraints, detail interfaces, detail input and
output for each module, etc.
 Verification and Validation
Unit testing: each unit is tested to discover and resolve any
defects and bugs.
Integration testing: some integrated units will be tested
together to discover and resolve any issues in the interfaces
and interaction.
System testing: aimed to check the overall system meets the
specified requirements.
User acceptance testing: used by the users to verify the
system, to determine whether a system satisfies their
Module Code & Module Title Slide Title SLIDE 30
Slide 30
 V-Model
Phases (Cont.)

Operation and Maintenance

 Identify best practices for system operations,
problem management and support/help desk
best practices, release management and quality
assurance in system operations, characteristics
and best practices for IT asset management,
hardware maintenance and hardware
monitoring, capacity planning and monitoring
activities, maintenance, and service
management activities within an organization,
etc.

Module Code & Module Title Slide Title SLIDE 31

Slide 31
 V-Model
Techniques
Takes the ‘top-down’ development approach
– Concept, Architecture Design, high-level design, etc.
Verification and Validation at end of each phase /
process which can include:
1. Validation of stakeholder requirements
2. Validation of allocated requirements
3. Validation of system element definitions
4. Validation of the virtually integrated system
5. Validation of the operational system deployed into
its environment
6. Validation of the in-service system.
Use various testing techniques for product
– Unit, integration, system, user acceptance, etc.
Module Code & Module Title Slide Title SLIDE 32
Slide 32
 Strengths with Structured
Methodologies
(in general)

A hierarchical approach tends to generate well-

organized systems. Its step-by-step approach (parallel
to the system development life cycle).
Simplifies project management, risk management,
and resource management.

Module Code & Module Title Slide Title SLIDE 33

Slide 33
 Problems with Structured
Methodologies
(in general)

Rigid phases, discourage skipping of unimportant

steps.
Emphasize of process and product quality rather than
customer satisfaction
Requirement need to be defined at the beginning of
the project and not encouraged to change towards the
end.
Too many ‘red-tapes’, wasting time and resources

Module Code & Module Title Slide Title SLIDE 34

Slide 34
 Summary

 Traditional/Structured Methodologies contains detailed steps

explained, requirements that need to be clear and fixed,
focus on error-free product, rigid and strict rules, and
emphasis on full documentation.
 The Waterfall methodology can be used for almost all types
of projects, is highly structured, and use a
sequential development process - one should move to the
next phase only when its preceding phase is completed and
perfected.
 The SSADM is suitable for projects with complex database
design, has strategies to align business needs with system
development, and ends at the design stage.
 The V-Model contains the horizontal dimension that denotes
the project completeness (project time) and the vertical
dimension that denotes the multiple levels of the system of
interest. Besides, verification and validation can be
Module Code & Module Title Slide Title SLIDE 35
Slide 35
 Question & Answer

Module Code & Module Title Slide Title SLIDE 36

Slide 36
 Next Session

• Agile Methods

Module Code & Module Title Slide Title SLIDE 37

Slide 37
 References

Tilley, S. (2019). Systems Analysis and Design

12th Edition. Cengage Learning. ISBN-13: 978-
0357117811. ISBN-10: 0357117816
Pressman, R., & Maxim, B. (2019). Software
Engineering: A Practitioner's Approach 9th Edition.
McGraw Hill. ISBN-13: 978-1259872976. ISBN-10:
1259872971
Dennis, A., Wixom, B,. & Roth, R.M. (2021).
Systems Analysis and Design 8th Edition. Wiley.
ISBN: 978-1-119-80378-2

Module Code & Module Title Slide Title SLIDE 38

Slide 38