Criterion B: Planning
Marks: 4 • Recommended words: 150
Criterion B is short. It is about breaking the problem down into manageable parts and showing a realistic timeline for building the product. Two things must be in the planning section:
- A decomposition of the problem scenario into component parts.
- A plan, a chronology of the steps involved in planning, designing, developing, testing and evaluating the solution.
The planning must be consistent with the problem specification in Criterion A. Each component in your decomposition should map to one or more success criteria; each phase in your chronology should cover work needed by the product you described.
The 2027 guide does not require a Record of Tasks (RoT). The old RoT-based structure is gone. Your plan’s job is to show decomposition and chronology, not to log every task you did.
Decomposition vs planning: get the distinction right
Students often blur the two. They are not the same:
- Decomposition answers what needs building. It is the solution’s blueprint: functional parts of the intended product, broken down enough to plan against.
- Planning answers when and how each part will be developed. It is the development pathway: the chronology, dependencies, and resources.
A decomposition diagram describes the product. A plan describes the work. Both belong in Criterion B, but they do different jobs and should not be merged into one artefact.
1. Decomposition
Decomposition is breaking the problem scenario down into smaller, more manageable sub-problems or components. The aim is a set of pieces that, taken together, make a plan constructable.
A reasonable decomposition:
- Covers every essential component of the product. Nothing critical left out.
- Breaks parts down to a level that is small enough to plan against but not so small that it dissolves into trivia.
- Makes the dependencies visible (e.g. you need data storage before you can build the shopping-list generator).
Decomposition is most effectively shown as a diagram. Good formats:
- Structure chart / hierarchy diagram: top-down breakdown of modules.
- Mind map: central problem, branches for each sub-problem.
- Component list with a short caption for each: acceptable but less visual.
Example decomposition (for the meal planner)
Meal Planner
├── Recipe management
│ ├── Add / edit / delete recipes
│ ├── Validate ingredient entries
│ └── Tag by cuisine
├── Pantry management
│ ├── Add / edit / delete pantry items
│ └── Track quantities
├── Weekly plan
│ ├── Assign recipes to day slots
│ └── Swap recipes
├── Shopping list generation
│ ├── Aggregate ingredients across planned recipes
│ ├── Compare against pantry
│ └── Export to text file
└── Persistence
└── Save / load data between sessions
Each branch maps to at least one success criterion from Criterion A, so the reader can see what each component is for.
Decomposition patterns by solution type
Different kinds of solution decompose along different axes. Pick the axis that fits your product:
| Solution type | Useful decomposition axis |
|---|---|
| Procedural code (e.g. a game loop) | Functions: handle input, update state, render |
| Object-oriented program | Entities + responsibilities (e.g. Recipe, WeeklyPlan, PantryItem) |
| Web-based application | Pages / views, interactive elements, data layer |
| Mobile application | Core features, UI components, data handling, platform services |
| Database-driven tool | Entities, relationships, query layer, UI |
| Simulation | Model state, update rules, visualisation, parameters |
An OOP product decomposed as if it were a procedural game (or vice versa) reads as forced. Match the decomposition to how the product actually works.
2. The plan (chronology)
The plan is a proposed chronology for the steps involved in planning, designing, developing, testing and evaluating the solution.
The 2027 guide names two common formats and accepts others:
- Gantt chart: time on the x-axis, tasks on the y-axis, bars showing duration and overlap. Good for linear or partly-parallel work.
- Agile chart / Kanban / sprint plan: iterations with grouped tasks per sprint. Good for incremental development with re-prioritisation.
- Milestone table: dated milestones with the work that feeds into each. Acceptable if the durations and dependencies are clear.
The plan should:
- Address all five phases: planning, designing, developing, testing, evaluating.
- Fit within the 35 hours recommended for the IA (plus your own time, as relevant).
- Show dependencies (what must be finished before what).
- Name any relevant research or existing code libraries you intend to use (permitted and encouraged where appropriate). Be honest about whether you have used the library before; a plan that depends on JavaFX in week 3 when you have never opened JavaFX is not a realistic plan.
Example (Gantt-style, compressed)
| Week | Planning | Design | Develop | Test | Evaluate |
|---|---|---|---|---|---|
| 1 | Scenario + success criteria | ||||
| 2 | Research libraries | System model | |||
| 3 | Testing strategy | Recipe CRUD | |||
| 4 | Pantry module + persistence | Unit tests per module | |||
| 5 | Weekly plan + shopping list | ||||
| 6 | Export + polish | Integration tests | |||
| 7 | Evaluate vs. success criteria + improvements |
A simple table like this is sufficient for a 150-word section. A formal Gantt diagram is equally acceptable.
Tabular plan (alternative format)
A row-per-task table with explicit SC tagging works just as well as a Gantt and is often easier to read:
| Week | Date range | Stage | Task | Success criteria | Dependencies | Resources |
|---|---|---|---|---|---|---|
| 2 | 14 Apr to 18 Apr | Design | UI wireframes for recipe entry | SC1 | none | Figma |
| 3 | 21 Apr to 25 Apr | Develop | Recipe CRUD module | SC1 | wireframes | |
| 4 | 28 Apr to 2 May | Develop + Test | Pantry module + unit tests | SC4 | recipe model | |
| 5 | 5 May to 9 May | Develop | Shopping list aggregation | SC3 | pantry, recipe | |
| 7 | 19 May to 23 May | Evaluate | Compare product vs each SC | all | working build | testing notes |
The two non-negotiable features in either format: every task ties to one or more SC, and all five stages appear (Plan, Design, Develop, Test, Evaluate).
Mark bands
| Marks | Level descriptor |
|---|---|
| 0 | The response does not reach the standard described below. |
| 1–2 | The response: constructs a partial decomposition of the problem scenario; constructs a plan that addresses some of the success criteria of the solution. |
| 3–4 | The response: constructs a reasonable decomposition of the problem scenario; constructs a plan that addresses the success criteria of the solution. |
The step from 1–2 to 3–4 turns on whether both the decomposition and the plan are reasonable and complete:
- Partial decomposition: some essential components are missing or under-specified.
- Reasonable decomposition: every essential component is present and broken down enough to plan against.
- Plan addresses some of the success criteria: some success criteria are not represented in the chronology.
- Plan addresses the success criteria: the chronology covers the work needed to meet every success criterion.
Word count and formatting
- Recommended word count: 150 (excluding diagrams).
- Diagrams do not count toward the 150 words, so invest the space in a clear Gantt / decomposition rather than prose.
- Suggested filename inside the single-PDF documentation: section heading “Criterion B: Planning”.
Common pitfalls
- Copy-pasting a generic SDLC diagram with no content tied to your specific problem. Examiners see this constantly; it scores in the 1–2 band.
- Listing every task you did instead of a forward-looking plan. The criterion asks for a proposed chronology (i.e. at the start of the work), not a diary. A diary entry reads like “Week 1: came up with idea. Week 2: started coding. Week 3: kept coding. Week 4: more coding…“: pure description of activity with no decomposition, no dependencies, no phases. This scores in the 1–2 band regardless of how much work was actually done.
- Missing one of the five phases. Make sure planning, designing, developing, testing and evaluating are all represented. The “Evaluate” phase is the most frequently omitted in weak plans; “Design” is the second most common.
- A decomposition that does not match the success criteria. Every branch should map to at least one success criterion; every success criterion should be covered by at least one branch.
Where this criterion most often loses marks
- A plan that never references the success criteria. A visually-clean Gantt with no SC linkage scores in the lower band. SC tagging on each task is the single most important plan feature.
- “Design” missing from the chronology. Plans that jump straight from idea to development cost marks. So does omitting “Evaluate” at the end.
- A generic decomposition. “Add user input, process data, show output” applied to any product without specific terminology from your scenario pulls the strand down.
- Plan embedded in the decomposition rather than presented as its own artefact. Decomposition shows structure; the plan shows time. They should be separate.
- Vague success criteria in Criterion A leak into B. If the SC are limited, the plan and decomposition cannot fully address them. The remedy belongs in A, not here.