Analysing Computational Problems

AQA 4.13.1 — Analysing computational problems (Computational Thinking: Retrieval & Synoptic Application)

Retrieval: Sequence 6 first introduced computational thinking as a structured way to approach problems — decomposition, pattern recognition, abstraction, algorithmic thinking; Sequence 14 continued it with data and procedural abstraction. This sequence is where all of that, plus everything you've built since, gets applied together — starting with the skill every real project begins with: working out exactly what a problem actually requires, before writing a single line of a solution.

Key vocabulary

• Requirement — something a solution must do (functional) or a quality it must have (non-functional, e.g. speed, security, usability).
• Constraint — a limitation the solution must work within (available data, time, hardware, existing systems).
• Success criteria — a specific, checkable statement of what "done, and done correctly" means.
• Decomposition — breaking a problem into smaller, more manageable sub-problems, each solvable (and testable) largely on its own.

Understand — why analysis comes before design

A brief like "build a system to manage court bookings at a sports centre" is not yet a problem you can solve — it's a starting point that hides dozens of unstated decisions. Real problems (NEA-style, exam-style and industry problems alike) require you to make those decisions explicit before choosing any tool, structure or algorithm: what exactly counts as an input, what output is actually needed, what's a hard constraint versus a nice-to-have, and how you'd know the finished solution actually works.

See it — turning a brief into a specification

Brief: "Members should be able to check which badminton courts are free at a given time, and book one."

Worked problem specification:

• Inputs: a requested date/time; court availability data (which courts are booked, when).
• Outputs: either a list of free courts at that time, or confirmation a booking succeeded.
• Processing required: checking a requested time against existing bookings for overlap; recording a new booking if the slot is free.
• Constraints: a court cannot be double-booked (two overlapping bookings for the same court); the centre currently has 4 courts.
• Assumptions stated explicitly: bookings are always for a fixed 1-hour slot (a genuine simplifying decision worth stating, not something the brief itself guaranteed).
• Success criteria: given a requested time, the system correctly reports whether each court is free; a booking for an already-booked court/time is correctly rejected.

Notice this specification decides nothing yet about how — no data structure, no algorithm, no paradigm has been chosen. That's deliberate, and it's the whole point of this lesson.

Decompose it — breaking the brief into sub-problems

The booking brief splits into genuinely separable sub-problems, each with its own inputs/outputs: (1) represent the current bookings in some form; (2) check whether a requested court/time overlaps an existing booking; (3) record a new booking once a slot is confirmed free. Each of these can be designed, implemented and tested largely independently — sub-problem 2 doesn't care whether sub-problem 1's data lives in a list, a dictionary or a database table, only that it can ask "is this court/time already taken?"

Identify it — spot the missing requirement

A student's problem specification for an online quiz system states: "Inputs: a list of questions and a student's answers. Outputs: a score. Processing: compare each answer to the correct answer and count matches." Identify one genuine gap in this specification — something a real system would need to handle that isn't stated anywhere.

(Several valid answers exist, e.g.: no constraint/assumption is stated about what happens if a student answers a question more than once, leaves a question blank, or submits an answer in an unexpected format; no non-functional requirement states how quickly the score must be produced or how many students might use it at once; no success criteria state how the scoring itself would be verified as correct. Any genuinely unstated gap, clearly justified, is acceptable - the skill being tested is spotting that a specification can look complete while still hiding real decisions.)

Common mistake

Jumping straight to "I'll use a dictionary" or "I'll write a for loop" while still reading the brief. Choosing a tool before the problem is properly specified risks solving the wrong problem efficiently — Sequence 6's own decomposition-before-implementation principle applies at full course scale here, not just to a single algorithm.

Check your understanding

A brief says: "Build a system to find the fastest walking route between two points on a school campus." State one input, one output, and one constraint this specification should include. (Input: e.g. the two locations (start and destination). Output: e.g. the sequence of paths/route, or the total distance/time. Constraint: e.g. only actual paths on the campus can be used, not straight-line distance - any reasonable, correctly-categorised example is acceptable.)

Challenge

Choose any coding challenge you completed earlier in this course. Write a problem specification for it (inputs, outputs, processing, constraints, assumptions, success criteria) as if you were seeing the brief for the first time, before checking it against the actual challenge description you were given.

Why this matters for the NEA

AQA's NEA analysis section is marked on precisely this skill — stating genuine, specific requirements and constraints, not just describing the finished program. A vague specification is one of the most common reasons NEA analysis sections underperform relative to the actual implementation.

Looking ahead: the next lesson takes this same badminton-booking specification and asks the harder question — given everything you now know about data structures, algorithms and paradigms, which ones actually fit, and why?