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.
Ends at design stage.

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 implementation.
Module Code & Module Title Slide 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?
− what impact will the system have on the users (e.g., skill implications,
retraining, redundancy, etc.)?

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 database
Enquiry Process specification and associated error handling.

Module Code & Module Title Slide 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:

– Preparing for Physical Design.
– Create Physical Design Strategy: include Processing System Classification,
DBMS Data Storage Classification, DBMS Performance Classification.
– Overview of Physical Data and Process Design.
– Physical Data 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.
– Function Component Implementation Map.

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
– Event sequence, dependency, etc.
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, required technologies, brief
functionality of the module, etc.

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 criteria. Includes interface quality and
overall requirements.

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.
Additionally, this methodology’s tools and techniques can all be
used to support other methodologies.

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.
Cost and time is often unpredictable for large projects.
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 conducted at end of each phase.

Module Code & Module Title Slide Title SLIDE 35

Slide 35
 Next Session

• Agile Methods

Module Code & Module Title Slide Title SLIDE 36

Slide 36
 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 37

Slide 37