Analysis & Design of Algorithms: Choosing the Right Approach (OCR A-Level CS 2.3.1)

Free Analysis Design Algorithms revision resources (OCR A-Level Computer Science, 2.3.1)

We’ve made exam-style practice for this exact topic, free to download: Analysis Design Algorithms question sheet, mark scheme and cheat sheet. Grab them, have a go, then read the full guide below.

Before you compare algorithms or work out their Big-O, you need to analyse the problem and design a solution. Spec point 2.3.1(a)–(b) covers analysing and designing algorithms for a situation, and judging which algorithm best suits a task and its data set — weighing execution time against memory (space). Paper 2 tests this with "describe the algorithm/design" and "which algorithm is most suitable and why" questions.

Analysis: understanding the problem (the "what")

Analysis is working out exactly what the solution must do before deciding how. It produces a clear specification of the problem, including:

• the inputs the algorithm receives and the outputs it must produce,

• the processing needed to get from inputs to outputs,

• the requirements / success criteria — measurable statements of what a correct, finished solution must achieve,

• the test data that will later prove it works (normal, boundary and erroneous data).

Analysis answers "what must this do, and how will we know it's right?" Getting it wrong here means building the wrong thing — so it's the foundation of everything that follows.

Design: planning the solution (the "how")

Design is deciding how the solution will work, before writing real code. It draws on the computational-thinking skills from 2.1–2.2:

• Decompose the problem into sub-problems (shown on a structure diagram).

• Choose the data structures (array, list, stack, tree…) and the algorithms that fit.

• Express the algorithm clearly using pseudocode, a flowchart, or a structure diagram so it can be checked and coded.

• Plan the test data that will be used to validate each part.

A good design can be followed and tested before any code is written — which is exactly what "describe the design of an algorithm" questions are looking for.

Suitability: choosing the right algorithm

Spec point 2.3.1(b) is about picking the best algorithm for the task and its data set, judged mainly on two resources:

• Execution time — how long it takes (the time complexity, formalised by Big-O in the next post). For huge data sets, a faster algorithm matters enormously.

• Memory / space — how much storage it needs (the space complexity). On limited hardware, a memory-light algorithm may win even if it's slower.

The best choice depends on the data:

• For a small data set, a simple algorithm (even an inefficient one) is fine and easier to write.

• For a large data set, efficiency dominates — choose a fast algorithm.

• Some algorithms have preconditions: a binary search is far faster than linear search, but only works if the data is already sorted.

• There's often a time–space trade-off: you can sometimes use more memory to save time (e.g. caching), or vice versa.

Worked example: searching a contacts list

You need to find a contact by name.

• Analysis — input: the list and a target name; output: the contact (or "not found"); success criterion: finds any existing contact, reports missing ones, in acceptable time.

• Design — store contacts in an array sorted by name; use a binary search to find the target; test with a name present, a name absent, and the first/last names (boundaries).

• Suitability — for a large, sorted contacts list, binary search (≈ log₂n steps) beats linear search (up to n steps). If the list were unsorted and rarely searched, a linear search might be simpler and not worth the cost of sorting first.

Analyse → design → choose the algorithm that fits the data: that's 2.3.1(a)–(b) end to end.

Common exam mistakes

• Confusing analysis with design. Analysis = what (requirements, I/O, success criteria); design = how (structures, algorithm, pseudocode).

• Forgetting success criteria / test data. A good analysis states how you'll know it works.

• Judging an algorithm on speed alone. Consider space (memory) too — and the size and nature of the data.

• Ignoring preconditions. Binary search needs sorted data; recommending it for unsorted data is wrong unless you sort first.

• One-sided suitability answers. Justify the choice for this data set — small vs large, sorted vs unsorted, time vs space.

Quick recap

• Analysis = define the problem: inputs, outputs, processing, success criteria, test data (the "what").

• Design = plan the solution: decompose, choose data structures & algorithms, express in pseudocode/flowchart, plan tests (the "how").

• Suitability (2.3.1b) = pick the best algorithm for the task and data set, weighing execution time vs memory.

• Small data → simplicity is fine; large data → efficiency matters; mind preconditions (binary search needs sorted data).

• Watch the time–space trade-off — sometimes more memory buys speed.

Frequently asked questions

What is the difference between analysis and design of an algorithm? Analysis is working out what a solution must do — its inputs, outputs, processing, success criteria and test data — before deciding how. Design is planning how the solution will work: decomposing the problem, choosing data structures and algorithms, and expressing them in pseudocode, flowcharts or structure diagrams ready to be coded.

What are success criteria? Success criteria are measurable statements of what a correct, finished solution must achieve. They are decided during analysis and are used later to judge whether the solution works, for example "finds any contact that exists and reports those that do not, within an acceptable time".

How do you decide which algorithm is most suitable for a task? You judge suitability mainly on execution time and memory use, in the context of the data set. For a large data set a faster algorithm matters most; on limited hardware a memory-light algorithm may be preferred; and you must respect preconditions, such as a binary search needing sorted data.

Why does the size of the data set affect the choice of algorithm? For a small data set even an inefficient algorithm runs quickly, so a simple one is fine and easier to write. For a large data set the difference in efficiency becomes huge, so a faster algorithm is worth the extra complexity. The best choice therefore depends on how much data will be processed.

What is the time–space trade-off? The time–space trade-off is the idea that you can often reduce the time an algorithm takes by using more memory, or reduce memory use at the cost of more time. For example, caching results uses extra memory to make repeated work faster, so the best balance depends on which resource is more limited.

Why must you consider preconditions when choosing an algorithm? Preconditions are conditions that must hold for an algorithm to work correctly. A binary search only works on data that is already sorted, so choosing it for unsorted data would give wrong results unless the data is sorted first, which itself takes time. Ignoring preconditions leads to an unsuitable choice.