What does the CCEA AS 1 Approaches to Systems Development unit cover?

AS 1 covers how complex digital technology systems are developed. It includes the systems development life cycle and its stages, the waterfall, iterative and agile or rapid application development methodologies, the feasibility study and requirements gathering, system design with tools such as data flow diagrams and the data dictionary, implementation and the changeover methods, levels of testing and test data, technical and user documentation, fact-finding techniques, and the types of system maintenance.

What are the stages of the systems development life cycle?

The life cycle runs through feasibility, analysis, design, implementation, testing, installation or changeover, and maintenance. Each stage has defined activities and produces a documented output, such as a feasibility report, a requirements specification, a design specification and a completed test plan, which the next stage uses. The cycle is iterative because testing, new requirements and maintenance send the team back to earlier stages.

What is the difference between the waterfall and agile methodologies?

Waterfall runs the life-cycle stages once, in a fixed sequence, with each stage signed off before the next begins, which suits stable, heavily documented projects. Agile delivers the system in short iterations, each producing working software, with the customer involved throughout, which suits projects whose requirements are unclear or likely to change. Waterfall favours predictability and documentation; agile favours flexibility and early feedback.

What are the changeover methods in AS 1?

There are four: direct changeover switches over at once (fast and cheap but risky, with no fallback), parallel running keeps the old and new systems running together (safe but expensive), phased changeover introduces the new system one part at a time, and pilot changeover runs the whole system in one site before a wider rollout. The right method depends on weighing risk against cost, so safety-critical systems favour parallel or phased.

What is the most common mistake in AS 1?

Confusing closely related ideas: presenting waterfall as the only life cycle rather than one methodology, mixing up phased and pilot changeover, confusing integration testing with system testing, and confusing adaptive with perfective maintenance. Scenario questions also lose marks when a candidate names a method without justifying it from the clues in the question.

How should I revise the AS 1 unit?

Work through each dot point against the specification. Learn the life-cycle stages and the document each produces, the characteristics and trade-offs of each methodology, the four changeover methods with advantages and disadvantages, the levels of testing and the three types of test data, the contents and audience of each kind of documentation, the fact-finding techniques, and the three types of maintenance. Practise scenario questions where you recommend and justify a methodology or changeover method.

Northern IrelandDigital Technology

CCEA A-Level Digital Technology AS 1 Approaches to Systems Development: a complete overview of the life cycle, methodologies, testing and documentation

A deep-dive CCEA A-Level Digital Technology guide to the AS 1 Approaches to Systems Development unit. Covers the systems development life cycle, development methodologies, feasibility and requirements, system design, implementation and changeover, testing, documentation, fact-finding and maintenance, with the concepts CCEA examines.

Generated by Claude Opus 4.816 min readCCEAUpdated 2026-06-16

Reviewed by: AI editorial process; not yet individually human-reviewed

Jump to a section

What this unit demands
The life cycle and methodologies
Feasibility, requirements and design
Building, testing and installing
Maintenance
How this unit is examined
Check your knowledge

What this unit demands

AS 1 Approaches to Systems Development is the process half of CCEA AS Digital Technology. It is about how complex systems are planned, built, tested, installed and maintained, rather than the technology inside them (which is AS 2). The examiners test two things: precise knowledge of the life cycle, methodologies, testing, documentation and maintenance, and the judgement to recommend and justify an approach for a given scenario.

This guide ties the unit's dot points together. Each topic has its own page with worked questions; this overview shows how they connect.

The life cycle and methodologies

Every system follows a systems development life cycle: feasibility, analysis, design, implementation, testing, installation and maintenance, with each stage producing a document the next stage uses. A methodology decides how those stages are ordered and repeated. Waterfall runs them once in sequence with sign-off; iterative and incremental development builds in repeated cycles and slices; agile and rapid application development use short iterations with heavy customer involvement and lighter documentation. The choice depends on how stable the requirements are and how much documentation is needed.

Feasibility, requirements and design

A feasibility study judges a project on technical, economic, legal, operational and schedule grounds and ends in a feasibility report. Fact-finding (interviews, questionnaires, observation, document inspection) gathers the requirements, which split into functional (what the system does) and non-functional (qualities and constraints). Design then specifies the inputs, outputs, processing, data storage and user interface, documented with data flow diagrams, system flowcharts, entity relationship diagrams and a data dictionary.

Building, testing and installing

Implementation builds the system from the design. Testing proceeds through unit, integration, system and acceptance levels, driven by a test plan and using normal, boundary and erroneous test data. Installation moves the system into live use through a chosen changeover method (direct, parallel, phased or pilot), with data conversion and user training. Both technical documentation (for developers and maintainers) and user documentation (for operators) are produced.

Maintenance

After delivery the system enters maintenance, the longest and most expensive stage. Corrective maintenance fixes faults, adaptive maintenance responds to a changed environment such as new hardware or new laws, and perfective maintenance adds enhancements to a working system. Maintenance reopens the life cycle on a small scale, which is why it is described as iterative.

How this unit is examined

A typical CCEA profile for AS 1:

Recall. Listing the life-cycle stages and their outputs, the changeover methods, the levels of testing and the types of maintenance.
Comparison. Weighing methodologies and changeover methods by their advantages and disadvantages.
Application. Recommending and justifying a methodology or changeover method for a described scenario.
Definitions. Distinguishing functional from non-functional requirements, technical from user documentation, and the three types of maintenance.

Check your knowledge

A mix of recall and application questions covering the unit. Attempt them under timed conditions, then check against the solutions.

List four stages of the systems development life cycle in order. (2 marks)
State one situation in which waterfall is more suitable than agile. (1 mark)
Name the five types of feasibility a feasibility study considers. (3 marks)
Distinguish between a functional and a non-functional requirement. (2 marks)
Name two design tools and state what each documents. (2 marks)
Describe the parallel running changeover method and give one advantage. (2 marks)
For a field accepting 1 to 12 (a month number), give one boundary and one erroneous test value. (2 marks)
Name the three types of maintenance. (3 marks)

Solutions

Q1: Any four in order from: feasibility, analysis, design, implementation, testing, installation, maintenance.
Q2: When requirements are stable and full, signed-off documentation is required, for example for an audited or regulated system.
Q3: Technical, economic, legal, operational and schedule (time) feasibility.
Q4: A functional requirement states what the system must do (a feature); a non-functional requirement states a quality or constraint such as speed, security or usability.
Q5: For example, a data flow diagram documents how data moves between processes and stores; a data dictionary documents the name, type, size and validation rule of each field. (Also acceptable: system flowchart for processing logic, entity relationship diagram for data relationships.)
Q6: Parallel running runs the old and new systems together for a period and compares their outputs; advantage: the old system is a fallback and a cross-check, so risk is low.
Q7: Boundary: 1 or 12 (or just outside, 0 or 13). Erroneous: a non-number such as "Jan", or a clearly invalid value such as 20.
Q8: Corrective, adaptive and perfective maintenance.

Sources & how we know this

CCEA GCE Digital Technology specification — CCEA (2016)