Your choices and justifications are saved automatically.
Eight scenarios drawn from across the whole SDD course — development process, design technique, selection and loop, standard algorithms, and testing and evaluation. Select the option that best fits, justify your choice using the scenario, then check the model answer. Scenarios 7 and 8 are marked DISCUSS — either answer can be correct if well-justified.
A community group commissions a program to sell and log tickets for a one-off charity raffle. The full specification is agreed and signed off by the committee before any design work begins. Design is completed and approved, then implementation follows the design exactly. Once every feature is coded, the whole system is tested for the very first time in a single testing phase, then handed over with no further changes planned.
Every stage — analysis, design, implementation, testing — happens once, in strict order, and testing only happens right at the end after every feature is already built. This is not iterative: an iterative process would build a small part, test it with users, and revise the design based on their feedback before moving on, and nothing here is tested until the whole system is complete.
A pupil has finished analysing a program that asks for the price of three items, applies a 10% discount only if a valid discount code is entered, and displays the final total. She now needs a design detailed enough that she can translate it into Python almost line by line — including the exact condition for checking the discount code and the exact order of the price calculation.
She needs a design she can convert "almost line by line" into code, including the exact IF condition and the exact calculation order — this precise, sequential level of detail is what pseudocode provides. A structure diagram would show the overall breakdown of the program into stages (get prices, check code, calculate total, display total) but would not spell out the exact condition or calculation order needed to type the code directly.
A car park barrier system asks a driver to enter a 4-digit code. If the code matches the one stored for that day, the barrier lifts and the screen displays "Welcome"; if it does not match, the screen displays "Access denied" and the barrier stays down. The code is checked exactly once per vehicle — there is no retry built in.
The code is checked once and exactly one of two messages is displayed depending on whether it matches — a single either/or decision, which is what selection (
IF/ELSE) does. This is not a loop: the scenario explicitly says the check happens once per vehicle with no retry, so nothing is repeated.
A tuck shop manager stores the number of items sold each day over a five-day school week in an array. She wants a program that reports the single busiest day of the week — not the total number of items sold across the whole week added together, which is a different figure she is not asking for here.
She wants to find the single largest value in the array — the busiest day — which is exactly what the maximum algorithm identifies. This is not a running total: the scenario explicitly rules out adding every day's figure together to get a combined weekly figure, which is what a running total would produce instead.
A raffle-ticket program asks for the number of tickets sold, then divides the prize fund by that number to work out the value per ticket. When Mrs Adams tests it by entering 0 tickets sold, the program runs and displays the prize fund correctly, but then suddenly stops with the message ZeroDivisionError at the division line.
The program starts, runs correctly for a while, and displays output before it crashes — so the grammar (syntax) was fine. It only fails once it actually reaches the division line and hits a genuine run-time problem, dividing by zero, which stops the program with a visible Python error message. This is not a syntax error: a syntax error would stop the program before it ever started, so nothing would be displayed at all.
A school trip payment tracker only accepts individual payments between £5 and £250 inclusive. When designing her test plan, a pupil deliberately chooses to test the program by entering £250 — the highest amount the system is supposed to accept.
£250 is the exact maximum boundary of the accepted range £5–£250, which is the definition of extreme (boundary) test data. This is not normal test data: normal data is a typical value comfortably inside the range, such as £100 — it does not sit exactly on the edge where an off-by-one mistake (
> instead of >=) could wrongly reject a valid payment.
A school kiosk asks a pupil to enter their year group, an integer from 1 to 6. If the number entered is outside 1–6, the program displays "Invalid year group, try again" and asks for it again — this keeps happening for as many attempts as it takes until a valid year group is finally entered.
IF condition testing whether the entered number falls outside 1–6 — that single condition is selection.If choosing Input validation: The scenario describes the full named pattern from SDD's standard algorithms — a condition nested inside a loop that keeps re-asking until the input finally passes the check — which is precisely what "input validation" names as a standard algorithm, not just the selection statement alone.
Exam note: This is exactly the trap a mixed paper sets. "What construct checks the year group?" wants selection; "What standard algorithm does this scenario show?" wants input validation. A weak answer spots the
IF and stops there, missing that the repeat-until-valid pattern has its own name. A strong answer recognises both: selection is the building block, and repeating it until the input passes is the named standard algorithm.
An after-school club's event RSVP program has only two stated requirements: (a) accept a pupil's name, and (b) accept their yes/no answer to attending. There is no requirement to check that the answer is actually "yes" or "no". When a pupil types "maybe" as their answer, the program does not crash — it happily stores "maybe" and displays "Response recorded".
If choosing Robustness: Robustness asks whether a program copes sensibly with input nobody explicitly ruled out, whether or not it was written into the requirements — and silently storing "maybe" as an attendance answer without any check is exactly this kind of gap.
Exam note: As in Section E, this is the pairing candidates confuse most. A program can be fully fit for purpose and still not robust at the same time — the two criteria judge different things about the same code. Naming only one, or treating them as opposites, loses marks; naming both and explaining why they give different verdicts here is what scores full marks.
The single biggest difference between a mixed paper and a single-topic worksheet is that nothing tells you which topic a question belongs to. Before you can apply the right rule, you have to recognise which rule is even in play — development process, design technique, selection vs loop, which standard algorithm, or testing/evaluation. Reading the command word and the nouns in the question (does it mention "array"? "test"? "design"? "requirements"?) is what narrows this down fast, before you start reasoning about the answer itself.
Once you've identified the topic, the deciding question for each one stays exactly as it was in Sections A–E: for development process, did testing happen once at the end or repeatedly throughout? For design technique, does it need to show overall shape or be detailed enough to code directly from? For selection vs loop, does something happen once or does it repeat? For standard algorithms, what single fact is actually being extracted from the array? For testing, did the program crash, and if so when — and where does a test value sit relative to the valid range?
Scenarios 7 and 8 show the sharpest version of this: sometimes a scenario genuinely sits across two topics at once, and the strongest answers say so explicitly rather than forcing a single label onto a situation that has two correct answers depending on exactly what is being asked.