Computational Methods: Solvable Problems, Recognition & Decomposition (OCR A-Level CS 2.2.2)

Free Computational Methods revision resources (OCR A-Level Computer Science, 2.2.2)

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

Before you can write a solution, you have to understand the problem — what it is, whether a computer can solve it, and how to break it down. Spec point 2.2.2(a)–(c) covers the features that make a problem solvable by computational methods, problem recognition, and problem decomposition. Paper 2 tests this with "state what data could be collected", "describe decomposition" and a regular 9-mark "discuss the features that make this solvable" essay.

What makes a problem solvable by computational methods

Not every problem suits a computer. A problem is solvable by computational methods when it has features a computer can work with:

• It can be broken down into smaller, well-defined steps (an algorithm).

• The inputs can be identified and represented as data the computer can store.

• There are clear rules / calculations that turn the inputs into outputs (no need for human judgement, intuition or emotion).

• A useful, well-defined output can be produced.

• It can be solved in a reasonable time with available resources.

"Predict tomorrow's weather from sensor data" fits well — measurable inputs, mathematical rules, a clear output. "Decide which painting is the most beautiful" does not — it relies on subjective human judgement that can't be reduced to data and rules. Recognising that distinction is the core of 2.2.2(a).

Problem recognition

Problem recognition is working out exactly what the problem is — turning a vague real-world situation into a precisely defined problem a computer can tackle. It means identifying:

• the goal (what a solution must achieve),

• the data available (the relevant inputs you can collect),

• the constraints (rules and limits the solution must respect).

For example, "help a café reduce waste" is too vague. Recognising the problem means pinning down the data you'd collect — items sold per day, time of day, weather, day of week — and the goal: predict demand so the café orders the right amount. A favourite exam task is "state four items of data that could be collected to solve this problem."

Problem decomposition

Decomposition is breaking a problem into smaller sub-problems that are each easier to understand and solve (the same idea as thinking procedurally in 2.1.3). For 2.2.2(c) you should be able to describe the process and explain why it helps:

• Each sub-problem is simpler to understand, design and test on its own.

• Sub-problems can be shared among a team and worked on in parallel.

• Sub-problems often become reusable subroutines.

• It's easier to find and fix bugs in a small, focused module.

You show decomposition with a structure diagram (hierarchy chart): the whole problem at the top, broken into sub-tasks below. "Complete the structure diagram" and "explain why decomposition helps the design" are recurring questions.

Worked example: a holiday-cost calculator

Recognise and decompose "work out the total cost of a holiday":

• Recognition — data: flights, hotel nights, nightly rate, number of people, extras; goal: a total price; constraints: a budget, valid dates.

• Solvable? Yes — the inputs are measurable data and the cost is a clear calculation.

• Decomposition — sub-problems: getFlightCost, getHotelCost, getExtrasCost, addUpTotal, compareToBudget. Each is a small routine you can write and test alone.

Recognise → check it's solvable → decompose into sub-problems: that's the whole of 2.2.2(a)–(c) in one example.

Common exam mistakes

• Vague "solvable" answers. Give concrete features: definable inputs, clear rules, a useful output, finishes in reasonable time.

• Confusing recognition with decomposition. Recognition = define the problem (goal/data/constraints); decomposition = break it into sub-problems.

• Listing data that isn't relevant. In "state four data items", choose data that actually affects the goal.

• Forgetting why decomposition helps. Say it: simpler to design/test, reusable, team-friendly, easier debugging.

• Treating subjective problems as computable. Problems needing human taste/emotion aren't solvable by computational methods alone.

Quick recap

• A problem is solvable by computational methods if it has definable data inputs, clear rules, a useful output, and can be done in reasonable time — not if it needs subjective judgement.

• Problem recognition = define the problem precisely: its goal, available data, and constraints.

• Decomposition = break the problem into smaller sub-problems (shown on a structure diagram).

• Decomposition helps because sub-problems are simpler to design/test, reusable, and team-friendly.

• The flow: recognise → check it's solvable → decompose.

Frequently asked questions

What makes a problem solvable by computational methods? A problem is solvable by computational methods when it can be broken into well-defined steps, its inputs can be represented as data, there are clear rules or calculations that turn those inputs into outputs without needing human judgement, and a useful output can be produced in a reasonable time. Problems requiring subjective taste or emotion are not solvable this way.

What is problem recognition? Problem recognition is working out exactly what a problem is, turning a vague real-world situation into a precisely defined problem a computer can tackle. It involves identifying the goal a solution must achieve, the data available as inputs, and the constraints the solution must respect.

What is problem decomposition? Problem decomposition is breaking a problem into smaller sub-problems that are each easier to understand and solve. The sub-problems can be designed, written and tested individually, often as reusable subroutines, and are commonly shown on a structure diagram with the whole problem at the top.

Why does decomposition help when designing a solution? Decomposition helps because each sub-problem is simpler to understand, design and test on its own, sub-problems can be shared among a team and worked on in parallel, they often become reusable subroutines, and it is easier to locate and fix bugs within a small, focused module than in one large program.

What kind of data would you collect for a problem? You collect data that is relevant to the goal — data that genuinely affects the output. For example, to predict a café's demand you might collect items sold per day, the time of day, the day of the week and the weather, because each of these influences how much is sold.

What is the difference between problem recognition and decomposition? Problem recognition is about defining the problem clearly — its goal, data and constraints — before you start solving it. Decomposition is the next step of breaking that defined problem into smaller sub-problems. Recognition tells you what to solve; decomposition organises how to solve it.