Your choices and justifications are saved automatically.
Eight scenarios. Select a design technique, justify your choice using the scenario, then check the model answer. Scenarios 5 and 8 are marked DISCUSS — either answer can be correct if well-justified.
A pupil has finished analysis for a program that asks for three test scores, calculates the average, and displays a pass/fail message. She now needs a design detailed enough that she can translate it into Python almost line by line, including the exact order of getting inputs, doing the calculation, and checking the condition.
A development team is meeting a client who has no programming background. The team wants to show the overall shape of the proposed booking system — the major stages such as checking availability, taking payment, and confirming the booking — without getting into detailed calculations or exact wording.
A programmer is designing a section of code that loops through 30 pupil scores, and for each one checks whether it is above 50 to decide whether to add it to a pass counter. He wants the design to show the exact nesting of the loop and the decision, numbered clearly enough that he can convert each line straight into code.
A team is reviewing the design of a large stock-control program with many steps. They want to sketch the whole program's breakdown on a whiteboard so everyone can see all the major sections and their sub-steps at once, and quickly spot whether any section of the program has been forgotten.
A pupil is producing design evidence for an assignment. The task requires a design for a moderately complex program with two nested loops and a selection. The marking instructions say the design must "clearly show the program's overall structure" and must also "be detailed enough to implement."
If choosing Pseudocode: The instructions also require the design to be "detailed enough to implement" — pseudocode's numbered main steps and refinements give the line-by-line detail a structure diagram's boxes do not.
Exam note: A weak answer picks one technique and ignores the other requirement in the scenario. A strong answer names both requirements from the marking instructions and explains which one the chosen technique satisfies — or notes that, in practice, this pupil might use both together.
A developer is designing a program that converts a temperature from Celsius to Fahrenheit, then to Kelvin, displaying each result in turn. She needs the design to specify the exact order of the calculations and exactly what is displayed after each one, ready to be typed directly into an editor as code.
A teacher is introducing S3 pupils to program design for the first time, before they have written any code. She wants pupils to see how a simple quiz program breaks down into "get question," "check answer," and "show score," without needing to understand any programming syntax yet.
A small software company is producing the design documentation for a new stock-ordering system before implementation begins. The documentation will be read by project managers, who want to understand the system's overall shape, and by the developers who will actually write the code from it.
If choosing Pseudocode: The developers who will write the code need design detail close to real code — pseudocode's main steps and refinements give them that starting point directly.
Exam note: The two audiences named in the scenario — managers and developers — want different things from the design. The strongest answers notice that a real project would likely produce both documents, and justify a single choice only by explaining which audience the question is really asking about.
Candidates can usually define structure diagrams and pseudocode separately, but lose marks when asked to justify choosing one over the other for a given scenario. The most common error is a vague preference — "pseudocode is more detailed" or "a diagram is easier to read" — without tying that feature to what the scenario actually needs the design to do.
The second common error is forgetting that both techniques represent the same underlying logic — the choice is about audience and purpose, not correctness. A structure diagram is not "wrong" for a complex algorithm; it is simply less suited to showing the exact sequence of steps a programmer will type. Use precise vocabulary — main steps and refinements, top-down, left-to-right, maps to one line of code, overall structure — and attach each term to a clue in the scenario.
For the two Discuss scenarios: name your choice, link it to one specific requirement or audience named in the scenario, and where the scenario clearly asks for both things a design can offer, say so rather than picking a side and ignoring the rest of the evidence.