Analysis

The stage where you find out what the problem actually is — before a single line of code is written.

• Problem definition — state precisely what must be achieved.
• Fact finding — interviews, questionnaires, observation, and study of the existing system's documents.
• Requirements specification — a testable list of what the system must do (functional) and how well (non-functional: speed, capacity, usability, security).
• Feasibility study — is it possible technically, economically, legally, and within the time available?
• Data flow diagrams — model how data moves through the current and the proposed system.

The most expensive mistake in software is made here. A requirement misunderstood in analysis and discovered after release costs orders of magnitude more to fix than one caught on day one. Every requirement must be written so that it can be tested — "the system should be fast" is not a requirement; "search must return within 2 seconds for 10 000 records" is.

Design

Design decides how the solution will work — still without writing production code.

• Decomposition — break the problem into sub-problems, and those into subroutines.
• Algorithm design — pseudo-code or flowcharts for each module.
• Data structure design — which structures, chosen on complexity grounds (a hash table for O(1) lookup; a BST to keep data sorted).
• Data / file design — record structures, field types, sizes, validation rules.
• User interface design — screen layouts, navigation, accessibility, error messages.
• Test plan — written now, from the requirements, not after the code exists.

Why write the test plan before the code: if you design the tests afterwards, you unconsciously write tests your code already passes. Deriving them from the requirements instead means they test what the system was supposed to do.

Testing

Test data must cover three categories:

• Normal / typical — data the system should accept (age = 25);
• Boundary / extreme — values right on the edge of validity (for a range 1–100: 0, 1, 100, 101);
• Erroneous / invalid — data the system must reject gracefully (age = "banana").

Boundaries are where bugs live. Almost every off-by-one error hides at the edge of a range — a < written where a <= was meant. Testing 50 in a 1–100 range proves nothing. Testing 0, 1, 100 and 101 finds the bug.

Your turn — boundary testing

Your turn — white-box paths

Implementation and evaluation

Implementation is writing, translating and installing the code — with meaningful identifiers, comments, and a modular structure that mirrors the design. Then comes installation: direct changeover, parallel running, phased, or pilot.

Evaluation judges the finished system against the original requirements specification — not against how proud you feel of it. It asks:

• Does it meet each requirement? Cite the evidence.
• Is it robust, usable, maintainable and efficient enough?
• What does the end user say?
• What are its limitations, and what would you do differently?

The mark-scheme trap: "it works and I am pleased with it" scores nothing. Evaluation is evidence-based comparison against a specification, requirement by requirement, including the ones you failed to meet. Naming a shortcoming honestly, and explaining how you would fix it, earns marks. Pretending there are none does not.

Black-box vs white-box

Test data

Evaluation

Data flow diagrams and structure charts

Two diagrams do most of the work in this topic.

A data flow diagram (DFD) models how data moves through a system. It uses just four symbols: external entities (sources and sinks of data), processes (which transform it), data stores (where it rests), and data flows (arrows). A DFD deliberately says nothing about timing, hardware or control flow — it is a pure abstraction of the movement of information.

A structure chart models the hierarchy of the solution: which module calls which, and what parameters pass between them. It is the visual form of top-down decomposition.

Why draw the current system first? Because you cannot improve what you do not understand. Modelling the existing process almost always exposes duplicated data entry, a step nobody can justify, or a data store two departments each believe they own.

Requirements

Iterative development and prototyping

The five stages are not always walked through once, in order. Two alternatives matter:

• Iterative development — cycle through analysis, design, implementation and testing repeatedly, each time adding a slice of functionality. Problems surface early, while they are still cheap to fix.
• Prototyping — build a rough, throwaway version so the user can react to something real. Users are far better at criticising a thing in front of them than at imagining one from a document.

The classic failure mode: a strictly linear process discovers a misunderstood requirement during testing — the most expensive possible moment. Iteration exists to bring that discovery forward. The cost is a moving target for scope, which is why the requirements must still be written down.

Your turn — sizing the test plan

After release — maintenance

Software is not finished when it ships. Maintenance is usually the largest part of a system's total cost, and it comes in four kinds:

• Corrective — fixing the bugs that testing missed;
• Adaptive — changing the system because the world changed (a new OS, a new tax rate, a new law);
• Perfective — improving performance or adding features users have asked for;
• Preventive — refactoring to reduce the chance of future faults.

Why maintainability is designed in, not added on: meaningful identifiers, modular subroutines, comments and clear documentation cost a little now and save enormously later — because the person maintaining this code in three years will almost certainly not be you, and will have no idea what you were thinking.

Which stage is it?

Tap the activity, then tap the stage it belongs to.

Match the term to its meaning

Tap an item on the left, then its partner on the right.

The big ideas to know

That is the whole of AQA 4.13. Press Finish to see your score.