Systems Development Life Cycle

>65011 >65012 >65013

Stages of the Cycle
1. Problem definition
2. Feasibility study
3. Analysis
4. Design
5. Implementation
6. Maintenance
Why do we need the SDLC?

 The software crisis of the late ‘60s and early ‘70s

 Systems were delivered years late
 They were over budget
 Unreliable
 Difficult to maintain
 Did not do what was required
What does the SDLC do?
 Systems Development Life Cycle was an attempt to
establish a structured approach to systems development.
 For management, each stage of the life cycle was a
milestone with an associated date and set of deliverables.
Deliverables
 Each stage has an associated set of deliverables
 Sets of documents produced at each stage in the life cycle
1. Problem Definition

 The problem definition forms the basis of the problems

and requirements list (see later)
 It records all problems and requirements mentioned by
clients in interviews, or which are subsequently
discovered during analysis of the system.
Problem Definition Report – the purpose

 To provide a written statement of the user's current

problems and requirements; to get agreement with the
user.
 To ensure that the right problem is being tackled
 To force the user to become involved
 To define the current state of the system and the
required end state
Problem Definition Report – the sections

 Problem
 Objectives
 Scope
 Preliminary ideas
 Recommended action
2. Feasibility Study
 Feasibility study - is there a practical solution to the problem outlined in
the initial problem definition.
 In particular, the feasibility study examines the technical, financial and
organisational feasibility of the project:
 Can it be done?

 Can we afford it?

 Will the proposed new system fit in with existing procedures?

 Feasibility study report

 Presented by the system developer to the user

 Decision is made whether or not to proceed.

3. Analysis
 Deliverable from the analysis stage is the ‘Specification of
requirements’
 Logical model of the required system
 States WHAT the system is to do
 Says nothing about HOW to implement it
 Includes
◦ Data flow diagrams
◦ Data dictionary
◦ Process definitions
◦ E/R model
◦ Entity life histories or state diagrams
4. Design
This has two stages:
 Provides several different solutions to the problem
 Selects one solution and specifies it in detail
Design – Alternative solutions
 A very cheap solution which does the job and no more.
 A medium price solution which does the job well and is
convenient for the user;
 A high cost, all-singing, all dancing solution
How solutions may differ
 System boundaries;
 Automation boundaries; could remain manual.
 Hardware
 Software
 Design strategies
 User interface
 Costs
Design – Selecting a solution
Specification may include:
 Program design (e.g. structure charts) and specification
 Specification of the user man/machine interface
 Specification of the layout of reports and other system
outputs
 File and record specifications
 Hardware specifications, including costs
 Implementation schedule
5. Implementation
 Program listings, test plans and supporting
documentation
 Manual of operating procedures
 Manual of clerical procedures
 User manual
 Hardware on which the system will run
 The system must be installed at the clients' site on their
equipment
 Changeover from the old to the new system supervised
 Often a hand-holding period
6. Maintenance
 Starts as soon as the system is handed over
 Term maintenance often euphemism for finding and
correcting errors
 True maintenance is modifying the system to meet
evolving client requirements
 System developer must start again at the beginning of the
cycle
An example, simplified system
The System Requirements
Background
 Errors in requirements may account for approximately
50 per cent of the total cost of debugging a software
system.
 Many of the traditional system development methods
merely pay lip service to identifying, describing and
validating the client’s requirements for the system.
 Today requirements engineering is recognised as a crucial
stage in the development of software.
Requirements – what are they?
No consensus of opinion as to what is meant by
requirements
 System requirements - the client’s needs and wishes.
 Software requirements - constraints put on the
system development, such as hardware, software and
design methods.
Requirements Engineering
Covers three phases:
 elicitation (identifying requirements)
 specification (describing them in an appropriate language
or notation)
 validation (checking with the client that the description
accurately records his or her needs and wishes).
Different types of requirements
 Functional requirements: what the system has to
do what its inputs and outputs are and how these are
linked.
 Non-functional requirements: the attributes of
the system as it performs its job; can be divided into
1. non-functional requirements of the system and
2. non-functional requirements arising from external sources.
Non-functional System Requirements
 Usability
 Performance
 Reliability
 Security
Elicitation
This covers several different activities:
 Observation of the users at work
 Study of relevant documents
 User questionnaires
 Talking to the people involved in the system
The Requirements Specification
 A cornerstone of a system development project
 Encapsulates the shared understanding and intentions of
all the stakeholders
 May be used as a vehicle for communication between
developers, users and other stakeholders
The Requirements Specification
 May form the basis of a legal contract between developer
and client
 Guides the programmers in their implementation of the
system
 Desirable qualities of a requirements specification can be
found in the IEEE Recommended Practice for Software
Requirements Specifications from the IEEE Standard 831–
1993.
Requirements Validation
 Technically feasible to confirm that the requirements
specification document is of the desired quality
 Not easy to ascertain whether the requirements
expressed in the specification are really what the client
wants and needs
 The client may not know what he or she wants
Requirements Validation
 Prototyping allows the client and users to get some
feeling for how their ideas would work once
implemented in a computer system.

 Talk through the requirement specification with the client

and users.
 Summary
Stage Content Deliverable

1. Problem Definition What is the problem? Problem Definition Report - statement of

problems, scope and objectives
objectives of new system
2. Feasibility Study Is there a feasible Feasibility Study Report - rough cost benefit
solution – quick look analysis
ahead to see if you can - system scope and objectives cost benefit
do something about the analysis
problem
3. Analysis What must be done to Specification of Requirements –logical
solve the problem model of required system
4. Design How should the problem Technical Design Specification –includes
be solved program specifications, hardware
specifications, cost estimates and an
implementation schedule
5. Implementation Do it Working system, includes program listings and
documentation, test plan, hardware, operating
procedures, clerical procedures
6. Maintenance Modify system as Working system - Operational system, modified
necessary and documented as required