• An algorithm is a precise set of instructions for solving a specific problem or task — precise means unambiguous, every step has exactly one meaning.
• There are three ways examiners expect you to design/represent an algorithm: structure diagrams (top-down hierarchy), flowcharts (visual shapes + arrows), and pseudocode (structured English-like text).
• Structure diagrams break a big system down into smaller and smaller sub-problems — like a family tree of tasks.
• Flowcharts use specific shapes: ovals for start/stop, parallelograms for input/output, rectangles for processes, and diamonds for decisions — connected by arrows showing the flow of control.
• Pseudocode is more structured than plain English but must never use real programming syntax like print() or semicolons — that loses marks in the exam.
• To explain an existing algorithm, you look at its inputs, its processing steps, its outputs, and (for complex ones) any comments, its context, or you test it with sample data.
• If a question just says "write an algorithm" with no format specified, default to pseudocode — it's faster and it's what examiners expect unless told otherwise.

Think about a recipe for making toast: put bread in toaster → wait 2 minutes → take bread out → spread butter. That's an algorithm — it's a sequence of exact, unambiguous steps that, if followed correctly by anyone (or any computer), always solves the same problem the same way.

The exam definition is short but every word matters: an algorithm is a precise set of rules or instructions to solve a specific problem or task. "Precise" is the key word — vague instructions like "cook it until it's done" aren't an algorithm, because different people would interpret "done" differently. A real algorithm might say "heat for exactly 4 minutes at 200°C."

Algorithms don't have to be written as computer code. Before a programmer ever writes a line of Python or Java, they usually design the algorithm first using one of three tools, because it's much easier to spot logic mistakes in a diagram or in plain-ish English than buried inside code syntax:

Structure diagrams show a system broken down in a hierarchical, top-down way — like a family tree, but for tasks instead of people. You start with the whole system at the top, and each level below breaks that system into smaller, more manageable sub-problems. This process is sometimes called top-down design or decomposition.

Why bother? Because a big problem (like "build a mobile phone's software") is far too complex to solve or code all at once. But if you break it into "voice calls," "text messages," and "contact data store," and then break each of those down further, each individual box becomes small enough that it could realistically be written as a single subroutine (a mini-program/function).

Every box represents a task or sub-system. Lines with arrows connect a "parent" task to its "children" — the smaller tasks that make it up. The further down you go, the more detailed and specific the tasks become, until each box at the bottom is small enough to implement directly.

Notice the naming pattern: Sub-system 2 breaks into 2.1 and 2.2. This numbering shows exactly where each box sits in the hierarchy — very handy for referencing specific parts of a large design.

The chapter's mobile phone example shows this in action. At the top is "Mobile phone." It splits into three sub-systems: "Voice calls," "Text messages," and "Contact data store." "Voice calls" then splits further into "Receive voice" and "Receive data," and those split even further — "Receive voice" leads down to things like "Convert to analogue" and eventually "Vibrate" (the phone alerting the user). Each branch keeps getting more specific and more technical the further down you travel.

A flowchart is a visual tool that uses specific shapes to represent different types of steps in an algorithm, connected by arrows that show the flow of control — meaning the order in which steps actually happen. Unlike a structure diagram (which shows what a system is made of), a flowchart shows how the logic actually runs from start to finish, including decisions and loops.

Cambridge IGCSE only expects you to recognise and use four shape types. Getting the right shape for the right job is an easy way to pick up marks — examiners really do check this.

Imagine a casino website that only lets in users aged 18 or over. Here's the logic traced through step by step:

Notice both branches of the decision eventually meet back up before "Stop" — that's a key habit in good flowchart design: don't leave a dangling branch that never reconnects to the main flow (unless it genuinely ends the algorithm early).

Pseudocode is a text-based way of writing an algorithm using short, structured, English-like statements. It sits in a sweet spot between plain English (too vague, too wordy) and real programming code (too strict, too fussy about syntax). It's "code-shaped" but doesn't belong to any specific programming language — which is exactly why exam boards love it: it tests your logic, not your memory of Python syntax.

Here's exactly the same logic as the flowchart above, written instead as pseudocode:

And here's the "refined" version that also asks for and uses the user's first name:

Notice how closely this mirrors the flowchart's logic — same inputs, same decision, same two outputs. This is intentional: structure diagrams, flowcharts, and pseudocode are three different notations for representing the exact same underlying algorithm. You should be able to convert between them.

Half of this chapter is about writing algorithms — the other half is about being able to read and explain one that someone else has written. This is a genuinely different skill: you're given a finished flowchart, pseudocode, or code snippet, and asked "what does this actually do?"

A well-designed algorithm should be understandable to a new reader just by following its instructions — that's the whole point of it being "precise." But when an algorithm gets complex (nested IFs, loops inside loops, arrays), you may need extra strategies to fully understand it:

Let's trace through this pseudocode line by line, the way you should in an exam:

Reading this top to bottom: three variables get set to starting values (this is called initialising the variables). Then the loop begins — it asks the user to input a Number, adds that Number onto a running Total, and increases Count by 1 to keep track of how many numbers have been entered so far. This repeats until Count is greater than 10, meaning it will have looped exactly 10 times. Finally, it outputs the Total.

Purpose: the algorithm adds ten user-entered numbers together and outputs the sum.

This is the trickier worked example from the chapter — a teacher's grading algorithm that uses arrays and deeply nested IF statements:

Here's the trick to reading nested IFs without getting lost: work from the top condition downward, and remember only ONE branch ever actually runs for a given score. A score of 65 checks "is it ≥70?" → No → drops into the ELSE → checks "is it ≥60?" → Yes → assigns Grade "B" and skips all the rest. The nesting is really just a chain of "if this doesn't apply, check the next possibility" — like a sorting hat trying category after category until one fits.

This algorithm: stores 30 inputted marks in the array Score[], checks each mark against a series of boundaries (70, 60, 50, 40, 30), assigns a matching letter grade, stores that grade in Grade[] at the same index as the mark it came from, and stops once 30 marks have been processed.

• I can define what an algorithm is, and explain why "precise" matters
• I can name the three ways to design an algorithm
• I can draw a structure diagram that breaks a system into sub-systems
• I know all four flowchart shapes and what each one means
• I can trace a flowchart from Start to Stop, following decision branches correctly
• I can write pseudocode using INPUT, OUTPUT, IF...THEN...ELSE...ENDIF
• I know NOT to use real code syntax (print(), semicolons, brackets) in pseudocode
• I can write and read a REPEAT...UNTIL loop
• I can trace through nested IF statements and identify which single branch runs
• I can explain what a given algorithm does in plain English, describing its purpose and processes
• I understand how arrays like Score[] and Grade[] link together by matching index
• I know to default to pseudocode when a question doesn't specify a format