Computational Problem Solving

AQA 4.4.1 — Computational problem solving

Retrieval: Year 12 Sequence 6 introduced computational thinking's core tools — abstraction, decomposition, pattern recognition, algorithmic thinking, evaluation. This sequence steps back from any specific algorithm or data structure (Sequences 10–13) and returns to that toolkit directly, applying it to genuinely unfamiliar problems before any solution exists yet.

Key vocabulary

• Objective — what the solution is actually trying to achieve.
• Input — the data the solution is given to work with.
• Output — what the solution must produce.
• Constraint — a rule the solution must obey, genuinely limiting which solutions are acceptable.
• Success criteria — how you'd actually check whether a proposed solution genuinely works.

Understand — why problem analysis comes before any solution

A precise, systematic analysis of what a problem actually requires must happen before attempting how to solve it. Skipping straight to code or an algorithm risks solving the wrong problem entirely, or missing a genuine constraint until far too late to fix cheaply.

See it — analysing an unfamiliar problem

"A school wants a system to automatically generate exam seating plans, avoiding placing known-distracting student pairs next to each other."

• Objective: produce a valid seating plan for the exam.
• Inputs: the list of students sitting the exam; the room's seating capacity and layout; the list of student pairs known to distract each other.
• Outputs: a specific seat assignment for every student.
• Constraints: no known-distracting pair may be seated adjacently; every student must be assigned exactly one seat; the room's actual capacity may not be exceeded.
• Success criteria: every student has a seat; no constraint is violated; ideally, the room's available seats are used efficiently.

Reason about assumptions

This analysis has already made assumptions worth naming explicitly: that "distracting" is a genuinely symmetric relationship (if A distracts B, B also distracts A); that every student must be seated (no valid solution simply excludes a student); and that "adjacent" has one agreed, specific meaning for this room's layout. A different assumption on any of these would genuinely change what counts as a valid solution — naming assumptions explicitly is part of the analysis, not a side note to it.

Common mistake

Jumping straight to "how" (which algorithm, which data structure) before "what" has been properly established. A solution can be technically well-implemented and still fail completely if it solves a problem slightly different from the one that was actually asked — for example, quietly assuming "distracting" only needs checking in one direction.

Why this matters for the NEA

This exact discipline — precisely identifying objectives, inputs, outputs, constraints and success criteria before designing a solution — is what an NEA project's own Analysis section is required to demonstrate. It's not a formality to complete quickly; it's the genuine foundation the rest of the project's design decisions are justified against.

Apply it

A public library wants a system to recommend books to a member based on their past borrowing history. Identify the objective, inputs, outputs, at least two genuine constraints, and success criteria.

(Objective: recommend books the member is likely to want to read next. Inputs: the member's borrowing history; the full library catalogue; possibly other members' borrowing patterns. Outputs: a list of recommended titles. Constraints: recommended books must currently be available (or at least exist) in the catalogue; a book the member has already borrowed should not normally be re-recommended. Success criteria: recommendations are drawn from genuinely available stock; recommendations plausibly relate to the member's actual reading history.)

Check your understanding

A charity wants a system to match volunteers to shifts based on availability and skill requirements. Identify which of the following is a genuine constraint on this problem, as distinct from an input, the objective, or a success criterion: (a) the list of volunteers and their stated availability; (b) producing a complete shift schedule; (c) a volunteer can only be assigned to one shift at any given time; (d) the number of shifts successfully filled. (2 marks)

(c) - a volunteer being assigned to only one shift at a time is a genuine rule limiting which schedules are acceptable, regardless of the specific data. (a) is an input (data supplied to the system); (b) is the objective itself; (d) is a success criterion (a way to check how well a proposed schedule performed), not a rule the schedule must obey while being constructed.)

Challenge

A ride-sharing app wants to match riders to nearby available drivers. Analyse this problem fully: objective, inputs, outputs, at least two constraints, and success criteria.

Looking ahead: the next lesson moves from analysing what a problem requires to constructing and tracing the algorithms that solve it — using pseudocode as a deliberate abstraction in its own right.