The scenario becomes code — but not yet. First, you read. Extract inputs, processes, and outputs. Identify every named data structure. List every requirement. Only when the blueprint is complete does the coding begin.
Topic 11 is the single highest-yield question on Paper 2. Every sitting since 2023 includes one 15-mark extended-response programming scenario as the final question — worth roughly 20% of the whole paper. Get it right and you can afford to lose marks elsewhere.
Cambridge accepts pseudocode, Python, Java, or VB.NET. The 2025 s25 examiner report says: "Candidates who answered algorithm questions using pseudocode, as stated in the question, achieved the best marks."
"Analyse the scenario before you code." Lab A is the drafting room. You read the problem, extract the shape, and make the blueprint. Lab B is where you assemble the pattern blocks. Lab C is where you ship the finished program.
First read for context: what does the program do overall? Second read for detail: what does each sentence specify? The 2025 s25 examiner report flagged "candidates whose responses closely matched the requirements stated in the scenario, ensuring that all points were fully covered, achieved the highest marks." Two reads is how you make that happen.
Scenarios name the arrays and variables you must use — TeamName[], TeamPoints[], ClassSize, MatchNo. Underline them. Do not rename them in your solution. The 2024 s24 mark scheme rewards "data structures required with names as given in the scenario".
Under the words "Write a program that…" Cambridge lists bulleted requirements. Count them. Cover each one in your solution. Miss one and you lose the marks for it, plus the "all criteria covered" axis of the mark scheme.
Three columns: Inputs (what the program reads), Processes (what it calculates/counts/finds), Outputs (what it displays). One row per action. Include implicit rows: validation (input processing), messages (output labelling), comments (documentation).
Does the IPO table cover every requirement? Highlight each requirement bullet, then find the IPO row that fulfils it. If any requirement has no corresponding row, add it. If any IPO row has no requirement, delete it.
Scenario extract: "The 1D array TeamName[] contains the names of teams in a sports league. The 2D array TeamPoints[] contains the points awarded for each match."
Scenario extract: "The 2D array ScreenTime[] is used to input the number of minutes on each day spent in front of a screen."
The scenario looks simple after one read. Second read catches: array indices, implicit constraints ("a maximum of N…"), the "additional guidance" block at the end.
The bullet list is not a "wishlist". Every bullet is a marking axis. The 2024 s24 mark scheme literally checks "all criteria stated for the scenario have been covered".
Validation, input/output messages, and comments are always required by the mark scheme — even when the requirements list doesn't spell them out.
Reading fast, you miss the "(2D)" tag in a phrase like "the 2D array TeamPoints[]". Your DECLARE has one dimension. Your loops don't nest. You lose the whole "data structures used correctly" mark-scheme axis.
A requirement says "output the student with the lowest weekly total" — you output one name and move on. But multiple students can tie for the lowest. All matches lose marks otherwise. This is the killer 2025 s25 P22 Q11 examiner-cited trap.
DECLARE Scores : ARRAY[1:N, 1:M] OF INTEGER. Using a 1D array here loses the "data structures used correctly" axis.StudentName[]. In your solution, can you rename it Names[]?Head to Activities and try the Scenario Reader — 8 real Paper 2 stems ready for you to tag.
Getting Started. Why do programming scenarios feel harder than practice questions? Because they hide the answer inside natural language. You have to translate first, code second.
Context. The 2024 s24 P22 Q11 scenario begins: "The 2D array ScreenTime[] is used to input the number of minutes on each day spent in front of a screen. The position of each student's data in the two arrays is the same…" This is the shape of every Paper 2 Q11.
Discussion. Two students see the same scenario. One writes an IPO table before coding. The other starts coding immediately. Who scores higher, and why?
Best for: IPO-shape scenarios — most Paper 2 Q11s.
Time cost: upfront (~5 min planning).
Failure mode: analysis-paralysis if the student over-plans.
Best for: menu-driven or state-machine scenarios (e.g. 2025 s25 P22 Q10 membership codes).
Time cost: distributed (plan-as-you-code).
Failure mode: missing edge cases.
Lab C teaches Method 2 in depth. Lab A drills Method 1 — the default for most scenarios.
Quick warm-up before Scenario Reader. Keyword detection: input/read/enter → INPUT; output/print/display/return → OUTPUT; calculate/count/total/find/sort → PROCESS. Review + correct — the tool is a starter, not a marker.
| Scenario phrase pattern | Code implication |
|---|---|
| "one-dimensional (1D) array X[] contains…" | DECLARE X : ARRAY[1:N] OF Datatype |
| "two-dimensional (2D) array Y[] is used to…" | DECLARE Y : ARRAY[1:N, 1:M] OF Datatype |
| "input and validate the …" | Validated input loop (Trap 1 target) |
| "output the … with the highest/lowest …" | MIN/MAX + second pass for all matches (Trap 5 target) |
| "the position of X's data is the same in both arrays" | Parallel array indexing pattern |
| "a maximum of N …" | Bounds check inside validation loop |
You look at the scenario, feel confident, and skip the second read. You miss a data structure or a requirement bullet.
Scenario doesn't literally say "validate the input" but the mark scheme axis rewards validation. Same for messages and comments.
Reading fast, you miss the "(2D)" tag. Your DECLARE has one dimension. Your loops don't nest. You lose the whole data-structures axis.
Python and most modern languages start arrays at 0. Cambridge Pseudocode starts at 1. FOR i ← 0 TO ClassSize is off by one at both ends.
At the end of every scenario is a small block about pre-declared arrays, initialisation not needed, or message requirements. Miss it and you re-declare arrays that were supposed to be assumed, wasting time and clarity.
You invent your own variable names (MyCounter, Total) when the scenario names them (MatchNo, ClassSize). Rename penalty.
DECLARE ScreenTime : ARRAY[1:ClassSize, 1:7] OF INTEGER — two dimensions, integer, using given name.IF Score < 0 OR Score > 100 THEN INPUT Score correct validation?Read like an examiner. See the scenario as a spec.
Head to Activities — five drills, with the signature Scenario Reader at the top.
Five drills. The signature is Scenario Reader — highlight-and-tag phrases in real Paper 2 stems. Behind it: four partner drills that isolate the four sub-skills — IPO sorting, data structure spotting, requirement extraction, and 60-second sprint.
Progressive disclosure: Scenario Reader Free mode unlocks after 3 completed Guided scenarios.
⌨️ Keyboard: Tab to select a phrase, then use the tag toolbar buttons. Arrow keys within IPO table cells. Sprint answers with digits/letters as prompted.
| Inputs | Processes | Outputs |
|---|---|---|
Tap each phrase to place it in Input, Process, or Output. Immediate feedback per tap.
Read a scenario excerpt. Tap the correct dimension (1D or 2D) plus the array name.
Tap each bulleted requirement in the stem. Miss the implicit ones (validation/messages/comments) and you lose the "all criteria covered" axis.
Rapid recall: IPO signals · 1D-vs-2D detection · requirement counting. Weak skills surface 2× more often.
8 scenarios · 6 from real Paper 2, 1 from textbook, 1 synthetic.
1 · Scenario Reader — signature. Full stem, tag phrases, marker returns coverage + accuracy.
2 · Speed Sort — isolate the IPO categorisation reflex.
3 · Structure Spotter — isolate the 1D-vs-2D reflex.
4 · Requirement Extractor — count the bullets + implicit reqs.
5 · Sprint — 60s rapid recall on all three sub-skills.
Distributed across the four reading skills: IPO identification (6), data structure spotting (4), requirement extraction (4), implicit requirements (4). Adaptive: weak skills surface 2× more often.
Real Cambridge Paper 2 Q11 scenarios from 2023-2025, plus textbook cases. Every citation verified against source. Answer, then reveal the mark-scheme checklist.
The traps here are the ones examiner reports flag repeatedly across 2023-2025. Read this tab the morning of the exam.
Six one-liners. Recite these before your exam.
Tick each item as you internalise it. Tap the status pill on a skill to override the automatic marker. When all 12 are ticked, the Module Mastered banner appears.
Once all 12 checked → Lab B · Build (Forge). Assemble reusable technique blocks.
Every wrong answer captures here automatically.
Your attempts, accuracy, and mastery counts across Lab A.
Spotted something wrong or unclear? Log it here.