Represent algorithms using pseudocode and structured English, applying sequence, selection and iteration, and trace them with a desk check to verify correctness before coding

What this dot point is asking

QCAA wants you to express a solution as an algorithm: an ordered, finite, unambiguous set of steps that always terminates. You must use pseudocode or structured English with the three control structures (sequence, selection, iteration), and verify it with a desk check before writing real code. In IA1 the technical proposal is judged partly on whether your algorithms are correct, readable and clearly mapped to the requirements.

The three control structures

Every algorithm, no matter how large, is built from three constructs:

• Sequence: steps run top to bottom, one after another.
• Selection: a decision chooses between paths (IF, IF/ELSE, CASE).
• Iteration: a block repeats (pre-test WHILE, post-test REPEAT/UNTIL, count-controlled FOR).

Pseudocode is language-neutral. QCAA accepts any consistent style; what matters is that indentation shows nesting and keywords are capitalised.

BEGIN GradeClassifier
    INPUT mark
    IF mark >= 85 THEN
        SET grade TO "A"
    ELSE IF mark >= 70 THEN
        SET grade TO "B"
    ELSE IF mark >= 50 THEN
        SET grade TO "C"
    ELSE
        SET grade TO "Fail"
    END IF
    OUTPUT grade
END GradeClassifier

Iteration

A pre-test loop checks the condition before the body, so it can run zero times. A count-controlled loop runs a known number of times.

BEGIN SumEvens
    SET total TO 0
    FOR n FROM 1 TO 10 DO
        IF n MOD 2 = 0 THEN
            SET total TO total + n
        END IF
    END FOR
    OUTPUT total            // 2+4+6+8+10 = 30
END SumEvens

MOD returns the remainder, so n MOD 2 = 0 is the standard even-number test. Choosing the wrong loop type (or the wrong boundary) is the most common logic error, which is exactly what a desk check catches.

Desk checking with a trace table

A desk check is a manual walkthrough. You build a trace table with one column per variable and one row per executed line, then step through the algorithm by hand, updating values exactly as the computer would. This proves correctness without running code.

Algorithm quality

QCAA marks algorithms on more than "does it run". A strong IA1 algorithm:

• maps clearly to a stated functional requirement;
• uses meaningful identifiers (runningTotal, not x);
• handles edge cases (empty input, zero, boundary values);
• is efficient enough for the data size (avoid an unnecessary nested loop where a single pass works).

You should also state the algorithm's purpose, its inputs, its outputs and any pre-conditions, because the technical proposal is a communication document as much as a design.

Common patterns to memorise

• Accumulator: initialise a total to 0, add inside a loop.
• Counter: initialise a count to 0, increment when a condition holds.
• Flag: a Boolean that records whether something happened (found ← FALSE).
• Min/max: seed with the first value, then compare each subsequent value.

These four patterns cover most Unit 3 algorithm questions, so practise writing and tracing each from memory.

How this appears in IA1

The IA1 technical proposal asks you to design algorithms for the prescribed problem and justify them. Markers reward algorithms that are traceable, that reference the requirements, and that come with a desk check or test data showing the logic is sound. Present pseudocode in a monospaced block with consistent indentation, and pair each algorithm with a short trace or test table so the marker can see your reasoning, not just your result.