Decomposition means breaking a problem into a number of sub-problems, so…

The idea

This definition adds detail to the basic idea. Decomposition breaks a problem into a number of sub-problems, and each sub-problem must accomplish an identifiable task, meaning you can say clearly what that part is for. The definition also notes that a sub-problem might itself be further subdivided, so decomposition can happen at more than one level. For example, a quiz game could be split into loading questions, checking answers and scoring; the scoring sub-problem could then be subdivided into counting correct answers and calculating a percentage. Each level still has a clear, identifiable task, and the smaller pieces are easier to design, test and debug before being combined into the whole program.

What earns the marks

• States that decomposition breaks a problem into a number of sub-problems.
• Explains that each sub-problem accomplishes an identifiable task with a clear purpose.
• Recognises that a sub-problem might itself be further subdivided into smaller parts.
• Applies the idea to a scenario by naming sub-problems and, where sensible, a further subdivision.

Common mistakes and how to put them right

• Treating sub-problems as vague areas of work.

  Put it right: Each must accomplish an identifiable task you can describe clearly.

• Assuming decomposition happens only once.

  Put it right: A sub-problem might itself be further subdivided.

• Confusing further subdivision with abstraction.

  Put it right: Subdividing keeps splitting the problem, whereas abstraction removes unnecessary detail.

Exam tips

• Use the phrase 'identifiable task' when explaining each sub-problem so the purpose is clear.
• Show a second level of decomposition in a scenario to demonstrate the 'further subdivided' clause.
• Keep each sub-problem focused on one job so it is easy to test separately.