What are the stages of the systems development life cycle, and what does each stage produce?
The stages of the systems development life cycle, the activities carried out in each stage and the documented outputs each stage hands on to the next.
A CCEA A-Level Digital Technology answer on the systems development life cycle: its stages from feasibility through analysis, design, implementation, testing and maintenance, the activities in each, and the documents each stage produces.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
CCEA wants you to know the systems development life cycle (SDLC) as an ordered set of stages, to describe the work done in each stage, and to name the document each stage produces and passes to the next. This is the backbone of AS 1: every other topic in the unit slots into one of these stages.
The stages and their outputs
The stages CCEA expects you to recognise are:
- Feasibility study. Decide whether the project is worth doing on technical, economic, legal, operational and schedule grounds. Output: a feasibility report recommending go or no-go.
- Analysis (investigation). Study the existing system, gather requirements through fact-finding, and model what the new system must do. Output: a requirements specification.
- Design. Specify inputs, outputs, processing, file and database structures, and the user interface. Output: a design specification with data flow diagrams, screen and report layouts and a data dictionary.
- Implementation (development). Build, code and configure the system from the design. Output: the working software plus technical documentation.
- Testing. Run unit, integration, system and acceptance tests against a test plan. Output: a completed test plan with results and a defect log.
- Installation (changeover). Move from the old system to the new one using a chosen changeover method, train users and convert data. Output: an installed live system and user training.
- Maintenance. Correct faults, adapt to change and improve the system over its life. Output: change requests and updated documentation.
Why each stage matters
The early stages dominate the eventual quality of the system. An error introduced in analysis (for example, a missed requirement) costs little to fix while still on paper, but becomes expensive once it has propagated into design, code and live data. This is the central reason CCEA stresses thorough investigation and clear documentation before any code is written.
How the stages connect to the rest of AS 1
The remaining AS 1 dot points expand each stage: development methodologies decide how the stages are sequenced and repeated; the feasibility study and requirements analysis cover the early stages in depth; system design covers the design deliverables; implementation, testing and documentation each cover a later stage. Knowing the cycle as a whole lets you place any exam question in its correct stage.
Try this
Q1. Name the document produced by the analysis stage. [1 mark]
- Cue. The requirements specification.
Q2. State two reasons an error found late in the life cycle is more expensive to fix than one found early. [2 marks]
- Cue. It has propagated into design, code and live data; more work and retesting are needed to unpick it; live users may be disrupted.
Q3. Explain why a feasibility study is carried out before analysis. [2 marks]
- Cue. It avoids spending effort on detailed analysis of a system that turns out to be technically, financially, legally or operationally unviable.
Exam-style practice questions
Practice questions written in the style of CCEA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
CCEA AS 16 marksDescribe three stages of the systems development life cycle and state one document produced in each.Show worked answer →
Choose three distinct stages and pair each with a named output. A strong answer names the stage, describes its activity in a sentence, then states the deliverable.
Feasibility study: the analyst checks whether the proposed system is technically, economically, legally and operationally worthwhile. Output: a feasibility report recommending whether to proceed.
Analysis: the analyst investigates the current system and gathers requirements using interviews, questionnaires and observation. Output: a requirements specification listing the functional and non-functional requirements.
Design: the team specifies the inputs, outputs, processing, data structures and user interface. Output: a design specification with data flow diagrams, screen layouts and a data dictionary.
Markers award one mark for naming each stage and one for a correct, matching output. Listing the stages in the wrong order, or pairing a stage with an output that belongs to a different stage, loses the output mark.
CCEA AS 14 marksExplain why the systems development life cycle is described as iterative rather than purely linear.Show worked answer →
A purely linear cycle would run each stage once, in order, with no return. In practice teams revisit earlier stages, so the cycle is iterative.
During testing a fault may reveal a design flaw, sending the team back to the design stage. During analysis a stakeholder may add a requirement, reopening earlier investigation. Maintenance routinely triggers a fresh, smaller pass through analysis, design, implementation and testing to add or correct features.
Treating the cycle as iterative reduces the risk of carrying an early error all the way to delivery, where it is most expensive to fix. Markers reward the idea of feedback loops between stages and at least one concrete example of returning to an earlier stage, plus the point that the cycle repeats over a system's life through maintenance.
Related dot points
- The waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, advantages, disadvantages and the situations that suit each.
A CCEA A-Level Digital Technology answer comparing the waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, strengths, weaknesses and the projects that suit each approach.
- The purpose and types of feasibility (technical, economic, legal, operational and schedule), fact-finding techniques for requirements gathering, and functional and non-functional requirements.
A CCEA A-Level Digital Technology answer on the feasibility study (technical, economic, legal, operational and schedule), fact-finding techniques for gathering requirements, and the difference between functional and non-functional requirements.
- Designing the inputs, outputs, processing, data storage and user interface of a system, and the design tools used: data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
A CCEA A-Level Digital Technology answer on the design stage: specifying inputs, outputs, processing, data storage and the user interface, and the design tools used including data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
- Implementation and installation of a system, the changeover methods (direct, parallel, phased and pilot), their advantages, disadvantages and suitability, and data conversion and user training.
A CCEA A-Level Digital Technology answer on implementing and installing a system: the direct, parallel, phased and pilot changeover methods, their advantages, disadvantages and suitability, and data conversion and user training.
- Levels of testing (unit, integration, system and acceptance), the purpose of a test plan, and the use of normal, boundary and erroneous test data.
A CCEA A-Level Digital Technology answer on testing: the levels of testing (unit, integration, system and acceptance), the purpose of a test plan, and the use of normal, boundary and erroneous test data with expected results.
Sources & how we know this
- CCEA GCE Digital Technology specification — CCEA (2016)