01 | WHY A SCENARIO CAN FEEL OVERWHELMING

A question describes a club, a shop or a school competition, then asks you to produce an algorithm. You recognise the individual ideas, but a blank page makes it difficult to know where to start.

The problem is often the jump from a paragraph to a complete solution. The paragraph mixes context, input rules, calculations and outputs. Separate those ideas before writing code.

Think of the task as a sequence of decisions you can make: what must happen, what information is needed, which parts repeat and which parts choose between alternatives?

This lesson works through one complete scenario. Each stage has a reason, so you can apply the method to a different question rather than memorising this particular program.

A useful first goal is a clear plan, not a perfect final answer in one attempt.

02 | READ THE SCENARIO CAREFULLY

A school runs an activity session with three participating classes. For each class, input the number of students attending. This must be a whole number from 0 to 30 inclusive; ask again if the number is outside that range. Calculate and display the total attendance. If total attendance is at least 60, display “Large session”; otherwise display “Small session”. Assume every entry is a whole number.

The school context helps you understand the task, but the actionable requirements are the three inputs, permitted range, retry, total and final classification.

The final sentence deliberately limits input handling: every entry is already a whole number. We need range validation, but we do not need to invent a text-to-number conversion routine for this scenario.

Read twice: first for the purpose, then for every rule and required output. Words such as “for each”, “again”, “inclusive” and “at least” affect the algorithm.

03 | TURN THE WORDING INTO CHECKABLE REQUIREMENTS

Write a short list of jobs in your own words, keeping every numerical rule intact.

Do not add unrelated features such as storing names, charging fees or producing individual rankings. They are not part of this scenario.

Equally, do not omit the retry merely because the total is the most obvious calculation. A solution must meet all the stated requirements.

This checklist will become a final coverage check. Each requirement should have a visible place in the design and a suitable test.

04 | IDENTIFY INPUTS, PROCESSES AND OUTPUTS

The inputs are the three class attendance values, including any replacement attempts after an invalid range entry.

The processes are checking each range, accumulating accepted attendance and comparing the completed total with sixty.

The outputs are prompts or rejection guidance where useful, the final total and one classification message.

No requirement asks to preserve all three class values for later reporting. A current Attendance value and running Total are sufficient for this task. If later requirements include a per-class report, the data design would need to change.

Distinguish useful working data from permanent storage. The total needs to remain available while processing, but the scenario does not ask for a file or database.

05 | DECOMPOSE THE WORK INTO SMALLER PARTS

Break the solution into receiving a valid class attendance, adding it to the total, repeating for three classes, outputting the total and choosing a session message.

The valid-input part is itself a smaller problem: receive a value, check whether it lies from zero to thirty, and repeat input if it does not.

By solving that smaller part once, you can place it inside the three-class repetition. You do not need three separate copies of the same instructions.

Keep the final classification separate from per-class processing. A session is large or small according to the completed total, not according to any one class.

Decomposition makes the plan manageable while retaining the relationship between the parts.

06 | CHOOSE VARIABLES FOR SPECIFIC JOBS

Attendance holds the current class’s value. Total retains the sum of accepted values so far. ClassIndex controls which of the three classes is being processed.

All three can use INTEGER because the scenario uses whole-number attendance and a count of classes.

Total begins at zero before any class is processed. Attendance receives a value through INPUT. ClassIndex gets its values from the FOR construct.

Do not declare a separate variable for every phrase in the question. “Large session” is an output message, not necessarily a stored variable. Choose names for information the algorithm actually needs to retain.

07 | MATCH EACH JOB TO A CONTROL STRUCTURE

“For each of three classes” suggests a count-controlled FOR loop. Its three passes represent three accepted class values.

“Ask again if outside the range” suggests a retry loop. REPEAT UNTIL can receive a value first and stop when it is acceptable.

“If total is at least sixty” suggests IF selection with an ELSE branch. The comparison is Total >= 60, not a strict greater-than check.

These choices are justified by the task. Other correct arrangements may exist, but you must be able to explain their repetition and stopping rules.

First express the jobs clearly. Only then choose the syntax that carries them out.

08 | BUILD THE VALID-INPUT PART FIRST

Write the smaller algorithm that receives one class’s valid attendance.

REPEAT
    OUTPUT "Enter class attendance from 0 to 30"
    INPUT Attendance
UNTIL Attendance >= 0 AND Attendance <= 30

The body runs at least once to receive Attendance. The condition uses AND because both lower and upper limits must hold.

With inputs 31 then 18, the first check is false and the next input is requested. Eighteen makes the condition true and remains in Attendance when the loop finishes.

The output message explains the permitted input. An invalid value is not silently changed to thirty; the user supplies a replacement.

This fragment assumes Attendance has been declared INTEGER and every input is a whole number, as specified in the scenario.

09 | PLACE THE RETRY INSIDE THE CLASS LOOP

Now repeat that valid-input job for the three classes and add each accepted value.

Total ← 0
FOR ClassIndex ← 1 TO 3
    REPEAT
        OUTPUT "Enter class attendance from 0 to 30"
        INPUT Attendance
    UNTIL Attendance >= 0 AND Attendance <= 30
    Total ← Total + Attendance
NEXT ClassIndex

Total is initialised once before FOR. The inner REPEAT stays within the current class until an accepted attendance value is obtained.

Add Attendance after UNTIL, not inside the retry body before acceptance. Otherwise an out-of-range attempt might be included in the total.

For inputs 12, 31, 18 and 30, the second class first supplies 31, then replaces it with 18. The third class supplies 30. There are four attempts but only three accepted class values.

Reaching the inner UNTIL condition does not automatically advance ClassIndex. The outer NEXT is reached only after the valid value has been added.

10 | ADD THE FINAL OUTPUT AND DECISION

After the outer loop, Total includes all three accepted class values. Output it, then choose the required session message.

OUTPUT "Total attendance: ", Total
IF Total >= 60
  THEN
    OUTPUT "Large session"
  ELSE
    OUTPUT "Small session"
ENDIF

Total equal to sixty follows THEN because “at least sixty” includes equality. A total of fifty-nine follows ELSE.

These final instructions belong after NEXT, not inside the per-class body. Otherwise the system would output and classify incomplete totals after each class.

One run produces one final classification. It should not output both “Large session” and “Small session”.

Compare the placement with your requirement checklist: the total and classification depend on the completed collection.

11 | READ THE COMPLETE SOLUTION

Combine the declarations, initial state, nested input processing and final output into one algorithm.

DECLARE Attendance : INTEGER
DECLARE Total : INTEGER
DECLARE ClassIndex : INTEGER
// Assume every input is a whole number
Total ← 0
FOR ClassIndex ← 1 TO 3
    REPEAT
        OUTPUT "Enter class attendance from 0 to 30"
        INPUT Attendance
    UNTIL Attendance >= 0 AND Attendance <= 30
    Total ← Total + Attendance
NEXT ClassIndex
OUTPUT "Total attendance: ", Total
IF Total >= 60
  THEN
    OUTPUT "Large session"
  ELSE
    OUTPUT "Small session"
ENDIF

Look at the indentation and closing keywords. UNTIL closes the inner retry; NEXT closes the three-class loop; ENDIF closes the final selection.

Each part now contributes to a requirement. The code is not just a collection of familiar keywords; its order and nesting establish the intended behaviour.

In this syllabus, Paper 2 coding answers generally require pseudocode, with the stated exception for the 15-mark scenario question where the specified programming languages may be used. Follow the question’s required representation. This lesson uses Cambridge-style pseudocode.

12 | TRACE A COMPLETE RUN INCLUDING REJECTED INPUT

Use input sequence 12, 31, 18 and 30. Follow which class each attempt belongs to.

Total becomes 12 after the first class. The invalid thirty-one does not change it. Accepted eighteen makes it 30. The final thirty makes it 60.

The algorithm outputs total 60 and “Large session”. The input prompt appears four times because there were four input attempts.

This trace checks more than a normal total. It provides evidence that the retry stays within the second class and excludes its invalid attempt.

13 | TEST DIFFERENT REQUIREMENTS SEPARATELY

Choose tests that cover normal operation, input endpoints, rejected input and the final decision threshold.

Zero is a valid class attendance here. All three zeros give total zero and the small-session message. Do not assume a school attendance must be positive when the specified range includes zero.

For the final classification, 59 and 60 test different sides of the decision. Both can be formed using valid class inputs.

If a test fails, identify the relevant part: range comparison, retry placement, total initialisation or final threshold. Retest after the correction and check other relevant cases.

14 | AVOID THE MOST COMMON SCENARIO MISTAKES

Writing before planning: an early checklist helps prevent missed requirements.

Counting attempts instead of accepted values: the retry belongs inside the class repetition, so invalid attempts do not finish a class.

Adding invalid values: accumulation follows successful validation.

Resetting Total inside FOR: this discards previous class values.

Using > 60: this excludes the required equality case.

Adding unnecessary features: focus on the problem given rather than building a different application.

These mistakes are easier to see when you map each statement to its purpose and dry-run a small example.

15 | TRANSFER THE METHOD TO A NEW SCENARIO

A shop receives five valid non-negative item prices and outputs their total. The same planning pattern applies: identify the repeated input, permitted values, accumulated total and final output.

The variable types change because prices may have fractional parts. A price total can use REAL while a loop index remains INTEGER. The outer loop repeats five times rather than three.

If a discount applies when the total is at least one hundred, that is a separate final decision after accumulation. Do not apply it after each price unless the scenario specifically requires that behaviour.

Notice what transfers: the reasoning steps. You are not copying attendance-specific names and limits into a different task.

The independent activity in Questions asks you to use that process on library loans before revealing a sample solution.

16 | EXPLAIN YOUR DESIGN WITH REASONS

A useful explanation is: “The FOR loop handles three classes, while the inner REPEAT retries an out-of-range entry for the current class. Attendance is added only after it passes the range condition, therefore invalid attempts do not affect the total.”

For the final decision: “Classification happens after the loop because it depends on the total of all three accepted values. The comparison includes equality because the rule says at least sixty.”

If you become stuck, return to the next small job: what information does it need, what should it produce and does it repeat or choose?

You should now be able to turn a scenario into requirements, data, smaller tasks, control structures and a tested complete algorithm. The next lesson builds on this by amending and checking an existing solution.