1. Systems Development Life Cycle
SDLC: A simplified introduction

2. Stages of the Cycle Problem definition Feasibility study Analysis
Design
Implementation
Maintenance

3. 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

4. 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.

5. Deliverables Each stage has an associated set of deliverables
Sets of documents produced at each stage in the life cycle

6. 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.

7. 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

8. Problem Definition Report – the sections
Objectives
Scope
Preliminary ideas
Recommended action

9. 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.

10. 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

11. 4. Design This has two stages:
Provides several different solutions to the problem
Selects one solution and specifies it in detail

12. 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

13. How solutions may differ
System boundaries;
Automation boundaries; could remain manual.
Hardware
Software
Design strategies
User interface
Costs

14. 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

15. 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

16. 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

17. An example, simplified system

18. The System Requirements

19. 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.

20. 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.

21. 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).

22. 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.

23. Non-functional System Requirements
Usability
Performance
Reliability
Security

24. 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

25. 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

26. 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.

27. 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

28. 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.

29. 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
solution – quick look
ahead to see if you can
do something about the problem
Feasibility Study Report - rough cost benefit analysis
- system scope and objectives cost benefit analysis
Analysis
What must be done to
solve the problem
Specification of Requirements –logical
model of required system
4. Design
How should the problem
be solved
Technical Design Specification –includes 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
necessary
Working system - Operational system, modified and documented as required

30. Tasks
Using one or two A4 sides, list each stage of the SDLC, using illustrations and diagrams where appropriate
Present your work in a professional manner, using headers and footers and other advanced formatting options