Before you write any code, read the scenario. Pick out the inputs, processes and outputs, note every named data structure, and list every requirement. Once that plan is complete, the coding can begin.
Paper 2 ends with a 15-mark programming scenario question — about a fifth of the paper. You are given a real-world problem in words and asked to write a complete program for it. With 75 marks in 1 hour 45 minutes, plan on spending about 20–25 minutes on it.
You can answer in pseudocode or in program code (Python, Java or Visual Basic). The activities on this site read pseudocode.
A Cambridge examiner report (2024) noted that candidates whose answers closely matched the requirements in the scenario, and covered every point, achieved the highest marks. Careful reading is how you get there.
"Analyse the scenario before you code." This Read Lab is the drawing office: you read the problem and draw up the plan. The Build Lab practises the code patterns. The Ship Lab puts it all together into a complete answer.
First read for the big picture: what does the program do overall? Second read for detail: what does each sentence ask for? The second read catches the things that are easy to miss — a 2D array, a limit such as "a maximum of 1000", or the guidance at the end.
Scenarios name the arrays and variables you must use — for example TeamName[], TeamPoints[], ClassSize. Note whether each is a 1D array, a 2D array or a single variable. Use these names exactly in your answer — don't rename them.
Under "Write a program that…" the scenario lists what the program must do. Count them. Each one needs code in your answer.
Three columns: Inputs (what the program takes in), Processes (what it calculates, counts, checks or finds), Outputs (what it displays). Add the expected extras too: validation for each input, a message with every input and output, and comments to explain each part.
Not every scenario has an input. If the guidance says the arrays are already filled with data, the program starts by processing that data.
Most scenarios finish with a short block of guidance, such as "You do not need to declare the arrays" or "All inputs and outputs must contain suitable messages". It tells you what to include — and what you can leave out.
Go through the requirement list and find the row of your IPO table that covers each one. If a requirement has no row, add one. If a row matches no requirement, ask whether you need it.
Scenario extract: The 1D array TeamName[] stores the team names. The 2D array TeamPoints[] stores the points each team was awarded in each match: 3 for an away win, 2 for a home win, 1 for a draw and 0 for a loss. The arrays are already filled with data.
TeamName[] (1D, team names), TeamPoints[] (2D, points per team per match), LeagueSize (variable, number of teams), MatchNo (variable, number of matches).Scenario extract: The 2D array ScreenTime[] is used to store the number of minutes each student spends in front of a screen on each day of a week. StudentName[] stores the names. ClassSize stores the number of students.
StudentName[] (1D), ScreenTime[] (2D, student × 7 days), ClassSize (variable).After one read the scenario looks simple. The second read catches the 2D array, the limits and the guidance at the end.
Each listed requirement needs to be covered. A requirement with no code is marks left behind.
Validation of inputs, messages with inputs and outputs, and comments are expected even when they aren't in the bullet list.
Reading fast, you treat "the 2D array TeamPoints[]" as a 1D list. Your loops don't nest and the data isn't used the way the scenario describes.
"Output the name(s) of the student(s) with the lowest total" — two students could share the lowest total. Outputting only the first one misses the other.
In our own words — the kinds of thing the mark scheme looks for in a scenario answer.
StudentName[]. Can you call it Names[] in your answer?Head to Activities and try the Scenario Reader — eight Paper 2 style scenarios to plan.
📍 11.1–11.2 Read Lab (this page)
11.3 Build Lab
11.4 Ship Lab
Topic 11 is this site's practice for the 15-mark scenario question at the end of Paper 2. It isn't a separate syllabus topic: the question draws on syllabus Topic 7 (algorithm design and problem-solving) and Topic 8 (programming).
Getting started. Why do scenario questions feel harder than short questions? Because the answer is hidden inside everyday language. You translate first, then code.
Context. A typical scenario begins: "The 2D array ScreenTime[] is used to store the number of minutes each student spends in front of a screen on each day…" — data structures first, then a list of what the program must do, then guidance.
Discussion. Two students see the same scenario. One spends five minutes on an IPO table before coding; the other starts coding straight away. Who is more likely to cover every requirement, and why?
Best for: scenarios that take data, work on it and output results — most scenarios.
Watch out for: spending too long planning.
Best for: menu-driven scenarios, where the program repeats and branches on the user's choice.
Watch out for: missing unusual cases.
This lab practises Method 1. The Ship Lab uses Method 2 for a menu-driven scenario.
A quick warm-up. It looks for verbs: input / enter / read → Input; calculate / count / total / find / check / validate → Process; output / print / display → Output. It's a starting point, not a marker — always check its draft.
| Phrase in the scenario | What it means for your code |
|---|---|
| "the 1D array X[] stores…" | One loop goes through it. Use the name X. |
| "the 2D array Y[] stores…" | Nested loops go through it — one per dimension. |
| "input and validate…" | An input with a loop that asks again until the value is valid. |
| "output the name(s) … with the highest / lowest …" | Find the highest or lowest value, then output every name that matches it. |
| "the position of each student's data is the same in both arrays" | Use the same index in both arrays (parallel arrays). |
| "a maximum of N…" | A limit your loop or validation must respect. |
You feel confident and skip the second read — and miss a data structure or a requirement.
The list doesn't say "validate" or "add comments", but validation of inputs, messages and comments are all expected.
You treat a 2D array as a 1D list. Your loops don't nest and the data isn't used as described.
Arrays in pseudocode use the bounds they are declared with — often 1 to N, but sometimes 0 to N−1. If the scenario gives the size as ClassSize, your loop must match.
The last few lines tell you things like "you do not need to declare the arrays". Miss them and you waste time — or leave out something that was asked for.
The scenario names MatchNo and ClassSize, but you invent N and Count. Use the names given.
DECLARE ScreenTime : ARRAY[1:ClassSize, 1:7] OF INTEGER — two dimensions, using the given name. (Many scenarios say the arrays are already declared, so check the guidance first.)IF Score < 0 OR Score > 100 THEN INPUT Score ENDIF enough validation?Read like a planner: the scenario is a specification.
Head to Activities — the Scenario Reader and four short drills.
The Scenario Reader gives you a full scenario to plan: name the data structures, then tag each sentence as Input, Process or Output. Four short drills practise each skill on its own.
Free mode (no requirement list, no hints) unlocks after you plan 3 scenarios successfully in Guided mode.
Choose Input, Process or Output for each phrase, then press Check.
Read the extract. Is the named structure a 1D array, a 2D array or a single variable?
Tap every item that is a requirement of this scenario — including the expected extras. Some items are not needed.
Quick questions on IPO, 1D or 2D, and requirements. Sprint is for speed — it doesn't change your Mastery.
8 scenarios in the style of Paper 2. ✅ = planned successfully.
1 · Scenario Reader — plan a whole scenario: data structures, then Input / Process / Output for each sentence.
2 · IPO Sort — Input, Process or Output, one phrase at a time.
3 · Structure Spotter — 1D, 2D or variable.
4 · Requirement Extractor — pick out what's required, and what isn't.
5 · Sprint — 60 seconds of quick recall.
Across four skills: IPO identification, data structure spotting, requirement extraction and expected extras. Skills you get wrong come back more often. Missed questions are saved to Mistakes.
Paper 2 style questions on reading a scenario. Answer every part, then press Mark my answer — each part is checked automatically.
Written in the style of Cambridge Paper 2. The scenarios are made up for practice. Written answers are checked for key ideas, so use clear words.
Read these before your exam. Then look at Mistakes to see the ones you make.
Six one-liners to recite before your exam.
Tick each item as you master it. In the skill grid, tap a status chip to set it yourself. When all 12 are ticked, the Module Mastered banner appears.
Mastered = 3+ attempts and at least 70% accuracy. Tap the status chip to override it.
Practise the code patterns that most scenario answers are built from: validation loops, totals, counts, highest and lowest, and nested loops.
📍 11.1–11.2 Read Lab (this page)
11.3 Build Lab
11.4 Ship Lab
Every wrong Practice, Exam or Scenario Reader answer is saved here automatically.
Your attempts, accuracy and mastery counts in the Read Lab.
Bookmark an exam question to save it here.
Jot notes as you learn. Everything here is saved on this device only.
Sent mistakes and saved key facts, in one place.