Skip to content

Decomposition diagram

Planning artefact: Criterion B: planning

Breaks the problem into components and sub-tasks for planning.

What it explains and when it is useful

A decomposition diagram breaks the problem from Criterion A into components and then into sub-tasks small enough to plan, build and test. It is a planning artefact for Criterion B, not a picture of the program's code.

When to use it: Always useful in Criterion B. The IB guide says decomposition “can be effectively constructed using diagrams”; the IA Guide adds that diagrams need supporting text.

Worked example

Illustrative: PracticePal is a fictional project used throughout this guide.

Decomposition of PracticePal: the whole system, six components and the sub-tasks of each, with the success criteria each component deliversPracticePalpractice-room booking system1 AccountsSC1Register students from CSVHash and check passwordsLog in / log out, roles2 Week gridSC2, SC3Generate 30-min slotsRead bookings for a weekDraw grid, colour states3 Booking rulesSC4–SC6Clash checkWeekly cap of 3Loud-room adjacencySafe when 2 book at once4 Waiting listSC7Join queue for a slotOffer slot to frontExpire unanswered offers5 Check-inSC8Check-in button / QRScheduled no-show release6 Head of musicSC9, SC10Block rooms for datesCancel + notifyWeekly usage CSVEach component maps to the success criteria it delivers; every sub-task becomes a task in the plan.
PracticePal decomposed into six components and their sub-tasks, each labelled with the success criteria it delivers.

Scroll sideways to see the whole diagram.

Notation and legend

Symbol or partMeaning
Top boxThe whole problem or product
Second rowMajor components (features or subsystems)
Small boxesSub-tasks: each becomes a task in the plan
SC labelsThe success criteria a component delivers

Design decisions it communicates

A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:

  • Booking rules (SC4–SC6) form one component because the three checks must run together in one transaction.
  • Check-in is separate from the waiting list even though both free slots: they have different triggers (a student vs the clock).
  • The head of music's tools are grouped by role, matching the use-case diagram in C.

Common mistakes

  • Generic parts (“GUI”, “database”, “backend”) that would fit any project.
  • Stopping at the top level, with nothing small enough to plan.
  • A diagram with no explanation (capped at 2/4 in the exemplars).
  • Calling it a structure chart or class diagram: those describe code, not the problem.

Checklist for your own version

Ticks are saved in this browser only, so you can use the list while you draft.