Why is "Writing an input statement with no prompt before it." a common mistake in Input/output?

Why it happens: When testing their own program students already know what it wants, so the missing prompt is invisible to them — the flaw only appears when someone else tries to use it. How to avoid it: Write the prompt and the input as a **two-line unit**, never one without the other. Make the prompt state the expected format or range — 'Enter a mark between 0 and 100' — which also helps **prevent** invalid input. 'Suitable prompt' is listed as a separate credit point in many mark schemes. Source: AQA 8525 specification 3.2.7 requires obtaining input from the keyboard; algorithm-writing mark schemes routinely award a mark for a suitable prompt.

Why is "Using the value from `USERINPUT` directly in a calculation or a numeric comparison." a common mistake in Input/output?

Why it happens: The value looks like a number on screen, and in Python the program often runs and produces plausible-looking output — the error message, when there is one, appears at a different line from the real cause. How to avoid it: Fix the rule: **keyboard input is always a string.** Any input you intend to calculate or compare numerically must be wrapped in `STRING_TO_INT` or `STRING_TO_REAL` at the point it is read. Choose which by asking whether decimals are needed. Source: 3.2.8 lists string conversion operations precisely to solve this problem, and conversion is a separate mark in calculation and validation questions.

Why is "Placing the final OUTPUT inside the loop, so a partial result is printed on every iteration." a common mistake in Input/output?

Why it happens: The output statement is written at the moment the value is being updated, and it sits naturally next to the calculation — the indentation error is easy to make and easy to overlook. How to avoid it: Ask: **should the user see this once, or once per item?** A single final total belongs **after** `ENDFOR`; a list of every name belongs **inside**. Check by asking how many lines your program should print — if the answer is one and your loop runs twenty times, the output is in the wrong place. Source: This is the most frequently lost mark in algorithm-writing questions across Paper 1.

Why is "Writing an unhelpful error message such as 'Invalid' or 'Error'." a common mistake in Input/output?

Why it happens: The program's logic is correct — it has genuinely detected the problem — so the message feels like a finishing touch rather than part of the functionality. How to avoid it: State **what** was wrong and **how to fix it**: 'Invalid — the mark must be between 0 and 100'. In 'improve this program' questions, vague messages are one of the faults you are expected to identify, and specific messages are creditworthy in evaluation answers. Source: Program-improvement and evaluation questions award credit for actionable error messages.

Why is "Detecting invalid input with an `IF`, printing a message, and then carrying on and using the bad value anyway." a common mistake in Input/output?

Why it happens: The `IF` correctly identifies the error, which feels like the job done — students do not picture what happens on the very next line, where the invalid value is still sitting in the variable. How to avoid it: Detection is useless without **re-asking**. Validation must **loop**: use `REPEAT … UNTIL ` so the input is requested again until it passes. Trace your own algorithm with a deliberately invalid value and follow what happens next — the flaw becomes obvious in seconds. Source: AQA 8525 specification 3.2.11 requires simple data validation routines; single-IF 'validation' is a recurring weakness.

Why is "Expecting a single `USERINPUT` statement to read several values at once." a common mistake in Input/output?

Why it happens: In everyday use you might type '5 10 15' on one line, so it feels as though one input could capture all three — the one-statement-one-value rule is never explicitly stated in lessons. How to avoid it: **One `USERINPUT` reads one value.** To read several, use a **loop** with the input inside it, and store the values in an **array** so they can be processed afterwards. Put the prompt inside the loop too, so the user is asked afresh each time. Source: Multi-value input questions test whether the loop-plus-array pattern has been understood.

AQA GCSE Computer Science (8525)

Input/output

0% Complete

Detailed Study Notes

Detailed notes on Programming for AQA GCSE Computer Science, covering key concepts, explanations, examples, and exam-focused revision points.

Input/Output — AQA GCSE Computer Science 8525 (3.2.7)

The smallest subtopic in Unit 3.2 — obtain user input from the keyboard, and output data to the display — but it appears in every single algorithm-writing question on Paper 1. The marks are rarely for the input/output statements themselves; they are for the things that surround them: prompting before you read, converting the string you receive, and placing the output outside the loop. Get those three habits right and you protect marks across the whole paper.

At a glance

Input = obtaining data from the user via the keyboard. AQA pseudo-code uses USERINPUT.
Output = sending data or information from the program to the computer display. AQA pseudo-code uses OUTPUT.
Always prompt before you read — an unexplained flashing cursor tells the user nothing.
USERINPUT always returns a STRING, even when the user types digits.
Convert before calculating: STRING_TO_INT or STRING_TO_REAL (3.2.8).
Convert back for output: INT_TO_STRING / REAL_TO_STRING when joining a number onto text.
Place output AFTER a loop unless you genuinely want one line per iteration.
One USERINPUT reads one value — reading several needs several statements, usually inside a loop.
Input is where invalid data enters a program, so every input is a candidate for validation (3.2.11).

What you’ll learn

Mapped to the AQA GCSE 8525 syllabus (2027-2029).

Be able to obtain user input from the keyboard.
Be able to output data and information from a program to the computer display.

Obtaining input from the keyboard

USERINPUT reads one value — and always gives you a string.

Input means obtaining data from outside the program, normally typed by the user at the keyboard.

name ← USERINPUT

The program pauses, waits for the user to type something and press Enter, then stores what they typed in the variable.

The three rules that carry marks

1. Always prompt first.

# Poor — the user sees a blank flashing cursor and has no idea what to do
age ← USERINPUT

# Good — the user knows exactly what is wanted
OUTPUT 'Please enter your age in years'
age ← USERINPUT

A prompt is an OUTPUT statement immediately before the input. It costs one line and is frequently worth a mark in "write a program" questions.

A good prompt states the format expected: "Enter a mark between 0 and 100" is far better than "Enter a mark", because it prevents invalid input rather than merely detecting it later.

2. USERINPUT always returns a string.

This is the single most important practical fact in the subtopic. Even if the user types 25, the variable holds the two characters '2' and '5', not the number 25.

# WRONG — this concatenates or errors
age ← USERINPUT
nextYear ← age + 1

# RIGHT — convert first
age ← STRING_TO_INT(USERINPUT)
nextYear ← age + 1

Mark schemes for calculation and validation questions routinely include a mark for that conversion.

3. One USERINPUT reads one value.

To read five numbers you need five inputs — which means a loop:

FOR i ← 0 TO 4
    OUTPUT 'Enter number ', i + 1
    numbers[i] ← STRING_TO_INT(USERINPUT)
ENDFOR

Notice the prompt is inside the loop, so the user is asked afresh each time and can see which number they are on.

AQA tip. In exam code, write the prompt, the input and the conversion as a three-line unit. Doing it automatically means you never lose the conversion mark in a question that was really about something else.

USERINPUT obtains one value from the keyboard and pauses the program.
Always OUTPUT a prompt immediately before an input.
A good prompt states the expected format or range.
USERINPUT always returns a STRING — convert before doing arithmetic.
Reading several values needs several inputs, usually inside a loop.

See the full worked example for input/output →

Outputting data to the display

OUTPUT sends data to the screen. Where you put it matters more than how you write it.

Output means sending data or information from the program to the computer display.

OUTPUT 'Hello, world'
OUTPUT total
OUTPUT 'The total is ', total

Combining text and values

You will almost always want to label a value rather than print a bare number:

# Uninformative — the user sees just: 47
OUTPUT total

# Informative
OUTPUT 'Total cost: £', total

In some languages, joining a number onto text requires converting the number to a string first (3.2.8):

OUTPUT 'Total cost: £' + REAL_TO_STRING(total)

Where the output goes — the mark that is lost most often

# WRONG — prints a running total on every iteration
FOR i ← 0 TO 9
    total ← total + marks[i]
    OUTPUT total
ENDFOR

# RIGHT — one final answer after the loop
FOR i ← 0 TO 9
    total ← total + marks[i]
ENDFOR
OUTPUT 'Total: ', total

Ask yourself: should the user see this once, or once per item?

You want	Put the OUTPUT
One final result	After the loop
One line per item (e.g. a list of names)	Inside the loop
A prompt before each input	Inside the loop

Both placements are correct in the right situation — the error is choosing the wrong one for what the question asked.

Output is also how a program communicates errors

IF mark < 0 OR mark > 100 THEN
    OUTPUT 'Invalid mark — please enter a value between 0 and 100'
ENDIF

A validation routine that silently rejects input without saying why is a genuinely poor design, and questions about improving a program often expect you to notice it.

AQA tip. Make output messages specific. "Invalid" tells the user nothing; "Invalid — the mark must be between 0 and 100" tells them exactly how to fix it. In evaluation questions, the quality of the messages is a legitimate thing to comment on.

OUTPUT sends data to the display; label values rather than printing bare numbers.
Joining a number onto text may need INT_TO_STRING or REAL_TO_STRING.
Output AFTER the loop for one final result; INSIDE the loop for one line per item.
Choosing the wrong placement is the most commonly lost mark in this subtopic.
Error messages should be specific enough for the user to fix the problem.

See the full worked example for input/output →

Input → processing → output in a complete program

Every program follows this shape. Recognising it makes algorithm-writing systematic.

Every program can be described as inputs → processing → outputs (3.1.1). Making that structure explicit is the fastest way to plan an algorithm under exam pressure.

The two conversion points are where marks are most often dropped: converting on the way in, and converting back on the way out.

A complete worked program

"Ask the user for the length and width of a rectangle, then display its area."

OUTPUT 'Enter the length in metres'
length ← STRING_TO_REAL(USERINPUT)

OUTPUT 'Enter the width in metres'
width ← STRING_TO_REAL(USERINPUT)

area ← length * width

OUTPUT 'The area is ', area, ' square metres'

Check the structure:

Input: two prompted, converted USERINPUT statements.
Processing: one multiplication.
Output: one labelled result.

Why STRING_TO_REAL and not STRING_TO_INT? A length may be 3.5 metres, so the decimal part must be preserved. Choosing the conversion is a data-type judgement (3.2.1), not a mechanical step.

Planning shortcut for exam questions

Before writing anything, jot three lines in the margin:

IN: what must the user supply?
DO: what must be calculated or decided?
OUT: what must be displayed?

It takes fifteen seconds and stops you forgetting an output or an input entirely — the two most costly omissions in a long algorithm question.

AQA tip. Note that not all input comes from a user. In 3.2.10 you will meet parameters, which are how data gets into a subroutine, and in a trace question the "input" may simply be a value already stored in a variable. Read the question to see where the data is coming from.

Every program is input → processing → output.
Conversion is needed on the way IN (string to number) and often on the way OUT.
Choose STRING_TO_REAL vs STRING_TO_INT by whether decimals are needed.
Plan with three margin notes: IN, DO, OUT.
Input is where invalid data enters, so it is where validation belongs.

See the full worked example for input/output →

Writing input and output that would satisfy a user

Prompting, echoing, formatting and error messages — the design marks.

Higher-tariff questions sometimes ask you to improve a program's interface, or to comment on its usability. These are the points worth making.

1. Prompts should state the expected format

OUTPUT 'Enter your date of birth'                    # ambiguous
OUTPUT 'Enter your date of birth as DD/MM/YYYY'      # unambiguous

This is prevention rather than detection — a well-worded prompt stops invalid input arriving in the first place.

2. Echo important input back

OUTPUT 'You entered: ', name, '. Is this correct?'

Lets the user catch their own typing mistake before it matters.

3. Error messages should say what to do

OUTPUT 'Invalid'                                          # unhelpful
OUTPUT 'Invalid — the mark must be between 0 and 100'     # actionable

4. Format numbers for the context

OUTPUT 'Total: £', total                # £7.5 looks wrong
OUTPUT 'Total: £', total, '0'           # crude but shows awareness

You are not expected to know a language's formatting functions, but noticing that money should show two decimal places is a legitimate observation in an evaluation question.

5. Group related output

OUTPUT '--- Order Summary ---'
OUTPUT 'Items:  ', quantity
OUTPUT 'Price:  £', unitPrice
OUTPUT 'Total:  £', total

Readable output is part of a program working properly, not decoration.

What this connects to

Idea	Subtopic
Converting input before use	3.2.8 string conversion operations
Validating input	3.2.11 robust and secure programming
Authentication input (plain text only)	3.2.11
Identifying input/processing/output in an algorithm	3.1.1 representing algorithms

AQA tip. In a "write a program" question, a prompt for every input and a labelled message for every output cost about four extra lines and consistently pick up marks — mark schemes frequently list "suitable prompt" and "appropriate output message" as separate credit points.

Prompts should state the expected format — prevention beats detection.
Echo important input back so the user can catch their own mistakes.
Error messages should tell the user how to fix the problem.
Money and similar values should be formatted appropriately for the context.
'Suitable prompt' and 'appropriate output message' are often separate mark points.

See the full worked example for input/output →

Quick recap

Input obtains data from the user at the keyboard; output sends data to the display.
AQA pseudo-code uses USERINPUT and OUTPUT.
Always prompt with an OUTPUT immediately before an input, stating the expected format.
USERINPUT always returns a STRING — convert with STRING_TO_INT or STRING_TO_REAL before calculating.
Converting back (INT_TO_STRING / REAL_TO_STRING) may be needed to join a number onto text.
Place output after a loop for one final result, inside a loop for one line per item.
One USERINPUT reads one value — reading several requires a loop.
Input is where invalid data enters a program, so it is where validation belongs.

Memorise this

Verbatim phrases and definitions Cambridge mark schemes credit.

Input = obtaining data from the keyboard (USERINPUT). Output = sending data to the display (OUTPUT).
USERINPUT always returns a STRING — convert before doing arithmetic.
Always OUTPUT a prompt immediately before a USERINPUT.
Output AFTER the loop for one result; INSIDE the loop for one line per item.
A good prompt states the expected range or format — prevention beats detection.
Every input is a candidate for validation (3.2.11).

How it’s examined

3.2.7 is assessed on Paper 1 and is almost never worth marks on its own — but it appears inside every algorithm-writing question, which is where its marks live. Expect: (1) 1-mark recall of what input and output mean, or identifying which lines of a given algorithm are inputs and outputs (AO1/AO2, links to 3.1.1); (2) marks embedded in larger questions, typically 'suitable prompt', 'input obtained and stored', 'appropriate output message' as separate credit points inside a 6- to 12-mark algorithm (AO3); (3) 'improve this program' questions where poor prompts, missing error messages or output in the wrong place are the faults to identify (AO3). Three habits protect the most marks: prompt before every input, convert every numeric input with STRING_TO_INT/STRING_TO_REAL, and place the final output after the loop rather than inside it. Because the subtopic is small, the efficient revision is not to study it separately but to build those three habits into every algorithm you write.

Sources: AQA GCSE Computer Science 8525 specification (v1.3, 16 June 2025) — 3.2.7 Input/output; AQA GCSE Computer Science 8525 standard pseudo-code reference document; AQA GCSE Computer Science Paper 1 past papers, mark schemes and examiner reports. Last reviewed 2026-07-28.

Take this whole topic with you

Step-by-step worked examples — Input/output

Step-by-step solutions to past-paper-style questions on input/output, written exactly the way a tutor would explain them at the board.

Question type:

1Identify the inputs and outputs in an algorithm (3 marks)
Getting startedIdentify & classify• Paper 1 style — 3 marks (AO2)• identify, input, output
Question
Look at the algorithm below.

1 OUTPUT 'Enter the price' 2 price ← STRING_TO_REAL(USERINPUT) 3 vat ← price * 0.2 4 total ← price + vat 5 OUTPUT 'Total including VAT: £', total

(a) State the line number of the input. (b) State the line numbers of the outputs. (c) Explain the purpose of line 1. (3 marks)
Step-by-step solution
1. Step 1
  (a) Input is where data arrives from outside the program. Line 2 contains USERINPUT, so that is the input.
2. Step 2
  (b) Lines 1 and 5 both contain OUTPUT and send data to the display. Line 1 is a prompt, line 5 is the result — both are outputs.
3. Step 3
  (c) Line 1 is a prompt: it tells the user what data the program is waiting for, so they know what to type.
Answer
(a) Line 2 — USERINPUT obtains data typed by the user (1). (b) Lines 1 and 5 — both use OUTPUT to send data to the display (1). (c) Line 1 is a prompt. It tells the user what the program is waiting for, so they know what to enter — without it the user would see only a blank cursor and would not know what to type (1). (3)
Examiner tip
Part (b) catches candidates who count only the 'real' result and forget that the prompt is itself an output. Note that lines 3 and 4 are processing, not input — assigning a calculated value to a variable does not bring data in from outside the program.
2Write a prompted, converted input (3 marks)
Getting startedMulti-step problem• Paper 1 style — 3 marks (AO2)• input, prompt, conversion
Question
Write the pseudo-code that asks the user for their age and stores it in a variable that can be used in a calculation. (3 marks)
Step-by-step solution
1. Step 1
  Prompt first with an OUTPUT so the user knows what to type.
2. Step 2
  Read the value with USERINPUT, which pauses the program until the user presses Enter.
3. Step 3
  Convert it. USERINPUT returns a string, so it must be converted to an integer before it can be used in a calculation. An age is a whole number, so STRING_TO_INT is the correct conversion.
Answer
OUTPUT 'Please enter your age in years' age ← STRING_TO_INT(USERINPUT)

Marks: a suitable prompt using OUTPUT before the input (1); USERINPUT used to obtain the value (1); the input converted with STRING_TO_INT so it can be used in a calculation (1). (3)
Examiner tip
The conversion is a separate mark and is the one most often missed. Note the choice of conversion is a data-type judgement: an age is a whole number so STRING_TO_INT is right, but a height in metres would need STRING_TO_REAL to keep the decimal part.
3Decide where the output belongs (3 marks)
Getting startedIdentify & classify• Paper 1 style — 3 marks (AO3)• output, loop, placement
Question
The algorithm below should output the final total of ten marks, but it prints ten lines instead. Identify the error, explain its effect, and write the corrected version. (3 marks)

total ← 0 FOR i ← 0 TO 9 total ← total + marks[i] OUTPUT 'Total: ', total ENDFOR
Step-by-step solution
1. Step 1
  Identify. The OUTPUT statement is inside the loop, so it executes once per iteration.
2. Step 2
  Explain. The loop runs ten times, so ten lines are printed — each showing the running total so far rather than one final answer.
3. Step 3
  Fix. Move the OUTPUT after ENDFOR, so it runs once, after all ten marks have been added.
Answer
The OUTPUT statement is inside the loop, so it is executed on every iteration (1). Since the loop runs ten times, ten lines are printed, each showing the running total at that point rather than a single final answer (1).

Corrected version:

total ← 0 FOR i ← 0 TO 9 total ← total + marks[i] ENDFOR OUTPUT 'Total: ', total

(1)
Examiner tip
This is the single most commonly lost mark in algorithm-writing questions. Note that neither placement is wrong in itself — output inside a loop is correct when you genuinely want one line per item, such as listing every name in an array. The error is choosing the placement that does not match what the question asked for.
4Write a complete input–process–output program (4 marks)
Building confidenceWord problem• Paper 1 style — 4 marks (AO3)• ipo, write-algorithm, conversion
Question
Write an algorithm using pseudo-code that asks the user for the length and width of a rectangle in metres, then displays its area. (4 marks)
Step-by-step solution
1. Step 1
  Plan the IPO. IN: length and width. DO: multiply them. OUT: the area, labelled.
2. Step 2
  Prompt and read each value, converting with STRING_TO_REAL — a length may be 3.5 m, so the decimal part must be kept.
3. Step 3
  Process: area = length × width.
4. Step 4
  Output the result with a label and units, so the number is meaningful to the user.
Answer
OUTPUT 'Enter the length in metres' length ← STRING_TO_REAL(USERINPUT) OUTPUT 'Enter the width in metres' width ← STRING_TO_REAL(USERINPUT) area ← length * width OUTPUT 'The area is ', area, ' square metres'

Marks: both inputs prompted (1); both inputs obtained and converted with STRING_TO_REAL (1); correct calculation of the area (1); labelled output placed after the calculation (1). (4)
Examiner tip
STRING_TO_REAL rather than STRING_TO_INT is the judgement being tested — a length of 3.5 m would be truncated to 3 by an integer conversion, making every area wrong. Note also that meaningful identifier names (length, width, area) are an explicit specification requirement, not a stylistic preference.
5Read several values using a loop (5 marks)
Building confidenceMulti-step problem• Paper 1 style — 5 marks (AO3)• input, loop, array
Question
Write an algorithm that asks the user how many items they want to enter, reads that many whole numbers into an array called values, and then outputs the total. (5 marks)
Step-by-step solution
1. Step 1
  First input: how many items. Convert to an integer, since it controls a loop.
2. Step 2
  Choose the loop. Once the count is known, the number of repetitions is fixed — so this is definite (count-controlled) iteration.
3. Step 3
  Prompt inside the loop so the user is asked afresh each time and can see which item they are on. Use i + 1 in the prompt so the numbering starts at 1 for the user even though the array is zero-indexed.
4. Step 4
  Accumulate the total inside the loop, having initialised it to 0 beforehand.
5. Step 5
  Output once, after the loop.
Answer
OUTPUT 'How many numbers do you want to enter?' count ← STRING_TO_INT(USERINPUT) total ← 0 FOR i ← 0 TO count - 1 OUTPUT 'Enter number ', i + 1 values[i] ← STRING_TO_INT(USERINPUT) total ← total + values[i] ENDFOR OUTPUT 'Total: ', total

Marks: first input obtained and converted (1); total initialised to 0 before the loop (1); definite loop running count times with correct bounds (1); prompted and converted input stored in the array inside the loop (1); total output after the loop (1). (5)
Examiner tip
Two details matter. The loop bound is count - 1 because the array is zero-indexed, so entering 5 numbers uses indices 0 to 4. And the prompt uses i + 1 so the user sees 'Enter number 1' rather than 'Enter number 0' — a small usability point that shows awareness of the difference between internal indices and what the user sees.
6Improve a program's input and output (5 marks)
Building confidenceIdentify & classify• Paper 1 style — 5 marks (AO3)• improve, prompt, error-message, usability
Question
A student has written the program below to record a test mark. Suggest three improvements to its input and output, explaining why each would help. (5 marks)

mark ← USERINPUT IF mark < 0 OR mark > 100 THEN OUTPUT 'No' ENDIF OUTPUT mark
Step-by-step solution
1. Step 1
  Improvement 1 — add a prompt. There is no OUTPUT before the input, so the user sees a blank cursor and does not know what to type.
2. Step 2
  Make the prompt state the valid range — 'Enter a mark between 0 and 100' — which prevents invalid input rather than merely detecting it.
3. Step 3
  Improvement 2 — convert the input. USERINPUT returns a string, so the comparisons mark < 0 and mark > 100 compare a string against numbers, which will not work reliably.
4. Step 4
  Improvement 3 — make the error message specific. 'No' tells the user nothing about what went wrong or how to fix it.
5. Step 5
  Improvement 4 (bonus) — label the final output. A bare number on screen has no context.
Answer
Improvement 1 — add a prompt before the input (1). At present the user sees only a blank cursor with no indication of what to type. A prompt such as OUTPUT 'Enter a mark between 0 and 100' also states the valid range, which helps prevent invalid input rather than merely detecting it afterwards (1).

Improvement 2 — convert the input to an integer (1). USERINPUT returns a string, so comparing it with the numbers 0 and 100 compares characters rather than values and the range check will not work correctly; it should read mark ← STRING_TO_INT(USERINPUT) (1).

Improvement 3 — make the error message specific. 'No' gives the user no information; a message such as 'Invalid — the mark must be between 0 and 100' tells them exactly what is wrong and how to correct it (1).

(A fourth valid improvement: label the final output, e.g. OUTPUT 'Mark recorded: ', mark, and loop until the input is valid rather than continuing with a bad value.) (5)
Examiner tip
The strongest point available is the distinction between preventing and detecting invalid input: a well-worded prompt stops many errors happening at all, while validation only catches them afterwards. Best practice does both. Note also the deeper flaw worth mentioning — the program detects an invalid mark but then carries on and outputs it anyway, because there is no validation loop (3.2.11).
7Write a menu-driven input system (6 marks)
StretchMulti-step problem• Paper 1 style — 6 marks (AO3)• menu, input, validation, loop
Question
Write an algorithm using pseudo-code that displays a menu with three options (1 — Add, 2 — View, 3 — Quit), reads the user's choice, and keeps asking until a valid option is chosen. The program should then output which option was selected. (6 marks)
Step-by-step solution
1. Step 1
  Display the menu as several OUTPUT lines so each option is on its own line and readable.
2. Step 2
  Choose the loop. The number of attempts is unknown, and the menu must be shown at least once before a choice can be tested — so condition at the end (REPEAT…UNTIL).
3. Step 3
  Convert the input, since the choice is compared numerically.
4. Step 4
  Validate with a range check using AND: choice ≥ 1 AND choice ≤ 3. Each side must be a complete comparison.
5. Step 5
  Give a specific error message inside the loop when the choice is invalid.
6. Step 6
  Report the selection after the loop using nested selection.
Answer
REPEAT OUTPUT '--- MENU ---' OUTPUT '1 - Add' OUTPUT '2 - View' OUTPUT '3 - Quit' OUTPUT 'Enter your choice (1-3)' choice ← STRING_TO_INT(USERINPUT) IF choice < 1 OR choice > 3 THEN OUTPUT 'Invalid choice — please enter 1, 2 or 3' ENDIF UNTIL choice ≥ 1 AND choice ≤ 3 IF choice = 1 THEN OUTPUT 'You selected: Add' ELSE IF choice = 2 THEN OUTPUT 'You selected: View' ELSE OUTPUT 'You selected: Quit' ENDIF

Marks: menu displayed with all three options (1); REPEAT…UNTIL chosen so the menu is shown at least once (1); input obtained and converted (1); correct range validation using AND in the UNTIL (1); specific error message for an invalid choice (1); correct reporting of the selected option after the loop (1). (6)
Examiner tip
A menu is the classic case for condition-at-the-end iteration: you cannot test a choice before the user has made one, so the body must run at least once. Note the prompt states the valid range (1-3), which prevents errors, while the range check detects the ones that still occur — the prevention-plus-detection pairing that top-band answers demonstrate.
8Convert input and output in both directions (6 marks)
StretchMulti-step problem• Paper 1 style — 6 marks (AO2/AO3)• conversion, input, output, string
Question
A program asks the user for a number of items and the price of each, then displays a message such as You ordered 3 items costing £14.85 in total.

Write the algorithm, making every conversion explicit, and explain why each conversion is necessary. (6 marks)
Step-by-step solution
1. Step 1
  Input 1 — quantity. USERINPUT gives a string; convert with STRING_TO_INT because a quantity is a whole number.
2. Step 2
  Input 2 — price. Convert with STRING_TO_REAL because a price includes pence.
3. Step 3
  Process: total = quantity × price.
4. Step 4
  Output — the reverse conversion. To join numbers into a text message, they must be converted back to strings with INT_TO_STRING and REAL_TO_STRING, because concatenation joins strings.
5. Step 5
  Explain the direction of each conversion: in on the way from the keyboard, out on the way to the display.
Answer
OUTPUT 'How many items?' quantity ← STRING_TO_INT(USERINPUT) OUTPUT 'Price per item in pounds?' price ← STRING_TO_REAL(USERINPUT) total ← quantity * price OUTPUT 'You ordered ' + INT_TO_STRING(quantity) + ' items costing £' + REAL_TO_STRING(total) + ' in total'

Why each conversion is necessary.

STRING_TO_INT on the quantity: keyboard input always arrives as a string, and it must become a number before it can be multiplied (1). An integer is correct because a quantity is always whole — you cannot order 2.5 items (1).

STRING_TO_REAL on the price: the input is again a string and must be converted (1), and a real is required because a price includes a decimal part such as £4.95, which an integer would truncate (1).

INT_TO_STRING and REAL_TO_STRING on the output: concatenation joins strings, so the calculated numbers must be converted back into strings before they can be built into the message (1). Without this the join would fail or produce an error (1). (6)
Examiner tip
The conversion most often forgotten is the last one — converting the result back to a string for output. The question is really testing whether you understand that conversion happens at both boundaries of the program: on the way in from the keyboard, and on the way out to the display. Note the two input conversions differ (INT vs REAL) and each is justified by the nature of the data.
9Evaluate the input/output design of a program (6 marks)
StretchWord problem• Paper 1 style — 6 marks (AO3)• evaluate, usability, prompt, validation
Question
A hospital appointment program asks patients to enter their date of birth and their NHS number. Discuss how the input and output design could reduce errors, referring to prompts, validation and messages. (6 marks)
Step-by-step solution
1. Step 1
  Prompts should state the required format. 'Enter your date of birth' is ambiguous — is it DD/MM/YYYY or MM/DD/YYYY? Stating the format prevents a whole class of error.
2. Step 2
  Prevention versus detection. A prompt that specifies the format stops errors happening; validation only catches them afterwards. Good design does both.
3. Step 3
  Validation for the NHS number — a length check confirming it has the expected number of digits, since it is a fixed-length code.
4. Step 4
  Data type choice. The NHS number should be stored as a string, because it may contain spaces and leading zeros and no arithmetic is ever performed on it.
5. Step 5
  Echo input back for confirmation, so the patient can spot their own typing error before the appointment is booked.
6. Step 6
  Error messages must be specific and actionable, and the program must re-ask rather than continuing with bad data.
Answer
Prompts should state the exact format required (1). 'Enter your date of birth' is ambiguous — a patient might type 03/04/1985 meaning either 3 April or 4 March — whereas 'Enter your date of birth as DD/MM/YYYY' removes the ambiguity entirely. This is prevention rather than detection: a well-worded prompt stops the error occurring at all, whereas validation can only catch it afterwards (1).

Validation should check what can be checked. The NHS number is a fixed-length code, so a length check would reject an entry with too few or too many digits, and a range check on the date components would reject an impossible month such as 13 (1). Crucially, the program must loop until the input is valid rather than detecting the error and then continuing with the bad value anyway (1).

The data type matters too. The NHS number should be stored as a string, not an integer, because it may contain spaces and could begin with a zero that would be lost — and no arithmetic is ever performed on it (1).

Output should support the user. The program should echo the entered details back for confirmation before booking, so the patient can catch their own typing mistake, and any error message should be specific and actionable — 'The NHS number must be 10 digits' rather than simply 'Invalid' (1). (6)
Examiner tip
This is a design-evaluation question and rewards breadth plus judgement. The two ideas that reach the top band are the prevention-versus-detection framing and the observation that detecting an error is pointless unless the program re-asks for the input. Bringing in the data type choice for the NHS number shows synoptic command of 3.2.1 alongside 3.2.7 and 3.2.11.

Model Answers — Input/output

High-scoring sample answers for input/output on the AQA GCSE 8525 paper, with examiner-style notes mapping each response to the mark scheme and assessment objectives.

Question 1
Paper 1 style — AO12 marks
State what is meant by input and by output in a computer program. (2 marks)
Model answer
Input is data obtained by the program from outside it — typically entered by the user at the keyboard (1). Output is data or information sent from the program to the user, typically displayed on the computer display (1).
Why this scores
The words 'from outside the program' matter: assigning a calculated value to a variable is processing, not input, because no data has come in from outside. This distinction is tested in 3.1.1 identify-the-IPO questions.
Question 2
Paper 1 style — AO1/AO22 marks
State the data type of the value returned by USERINPUT, and explain why this matters. (2 marks)
Model answer
USERINPUT always returns a string, even when the user types digits (1). This matters because a string cannot be used directly in a calculation — it must first be converted using a string-to-integer or string-to-real operation, otherwise the arithmetic will either cause an error or perform concatenation instead of addition (1).
Why this scores
This single fact underlies most of the conversion marks across Paper 1. Note the consequence is not always a crash — in some languages '5' + '3' silently produces '53', so the program runs and gives a wrong answer, which is a logic error rather than a syntax error.
Question 3
Paper 1 style — AO22 marks
Explain why a program should output a prompt before obtaining input from the user. (2 marks)
Model answer
Without a prompt the program simply pauses with a blank cursor, so the user has no idea what data is expected or that the program is waiting for them at all (1). A prompt tells the user exactly what to enter, and a well-worded one also states the expected format or range — such as 'Enter a mark between 0 and 100' — which helps prevent invalid data being entered in the first place (1).
Why this scores
The second mark is available for the prevention point, which is the more sophisticated argument: a good prompt reduces the number of errors that validation has to catch. 'Suitable prompt' appears as a separate credit point in mark schemes for algorithm-writing questions.
Question 4
Paper 1 style — AO2/AO33 marks
A program totals the values in an array of 20 numbers. Explain where the OUTPUT statement should be placed and why. (3 marks)
Model answer
The OUTPUT should be placed after the loop has finished, not inside it (1). If it were inside the loop it would execute on every iteration, printing 20 lines each showing the running total at that point rather than a single final answer (1). Only once the loop has completed does total hold the sum of all the values, so that is the point at which the meaningful result exists (1).
Why this scores
The reasoning that the correct value only exists after the loop completes is what earns the third mark. Note that output inside a loop is not wrong in general — it is exactly right when listing every item — so the answer must be framed around what this particular program is meant to produce.
Question 5
Paper 1 style — AO24 marks
For each input below, state which conversion operation should be applied to USERINPUT and justify your choice.

(a) the number of tickets ordered (b) the weight of a parcel in kilograms (c) the customer's surname (4 marks)
Model answer
(a) STRING_TO_INT (1) — the number of tickets is a count, so it is always a whole number and an integer is appropriate; you cannot order 2.5 tickets (1).

(b) STRING_TO_REAL (1) — a weight may include a decimal part such as 3.25 kg, so a real is needed; converting to an integer would truncate it to 3 and the postage would be wrong (1).

(c) No conversion is needed — a surname is text, so the string returned by USERINPUT can be used directly.
Why this scores
Part (c) is the discriminator: students who have learned 'always convert' apply a conversion reflexively, but converting a name to a number would fail. The rule is that conversion is needed only when the value will be used numerically.
Question 6
Paper 1 style — AO24 marks
A user runs the program below and types 12 then 4. State exactly what appears on the display. (4 marks)
```
OUTPUT 'Enter the first number'
a ← STRING_TO_INT(USERINPUT)
OUTPUT 'Enter the second number'
b ← STRING_TO_INT(USERINPUT)
OUTPUT 'Sum: ', a + b
OUTPUT 'Difference: ', a - b
```
Model answer
Enter the first number Enter the second number Sum: 16 Difference: 8

Marks: both prompts appear, in the correct order (1); Sum: 16 correct (1); Difference: 8 correct (1); the order of all four lines correct (1).
Why this scores
The question asks what appears on the display, so the prompts must be included — they are outputs too. Note that the values typed by the user (12 and 4) are not themselves output by the program; they appear on screen only because the user typed them, which is why they are not listed as program output.
Question 7
Paper 1 style — AO38 marks
Write an algorithm using pseudo-code that asks a user to enter the marks for 5 students. Each mark must be between 0 and 100, and the program must keep asking until a valid mark is entered. The program should then output the highest mark and the average mark, both clearly labelled. (8 marks)
Model answer
CONSTANT NUM_STUDENTS ← 5 total ← 0 highest ← -1 FOR student ← 1 TO NUM_STUDENTS REPEAT OUTPUT 'Enter mark for student ', student, ' (0-100)' mark ← STRING_TO_INT(USERINPUT) IF mark < 0 OR mark > 100 THEN OUTPUT 'Invalid — the mark must be between 0 and 100' ENDIF UNTIL mark ≥ 0 AND mark ≤ 100 total ← total + mark IF mark > highest THEN highest ← mark ENDIF ENDFOR OUTPUT 'Highest mark: ', highest OUTPUT 'Average mark: ', total / NUM_STUDENTS

Marks: total and highest initialised before the loop (1); definite outer loop running 5 times (1); prompt inside the loop showing which student (1); input obtained and converted with STRING_TO_INT (1); indefinite REPEAT…UNTIL validation loop (1); correct range check using AND/OR (1); specific error message for invalid input (1); both results clearly labelled and output after the loop, using real division for the average (1). (8)
Why this scores
This question integrates 3.2.7 with 3.2.2, 3.2.3, 3.2.5 and 3.2.11, which is how input/output is actually examined. The marks specific to this subtopic are the prompt inside the loop (so the user knows which student), the conversion, the specific error message, and the labelled outputs placed after the loop — four separate credit points that cost only a few extra lines.
Question 8
Paper 1 style — AO36 marks
Discuss how a program's input and output design affects how easy it is to use and how likely errors are. Refer to prompts, error messages and confirmation. (6 marks)
Model answer
Prompts determine whether the user knows what to do. Without a prompt, a program simply pauses with a blank cursor and the user cannot tell what is expected or even that input is required (1). A prompt that states the expected format or range — 'Enter a date as DD/MM/YYYY' or 'Enter a mark between 0 and 100' — goes further and prevents many errors from ever occurring, which is more effective than detecting them afterwards (1).

Error messages determine whether the user can recover. A message such as 'Invalid' tells the user that something is wrong but not what, so they may repeat the same mistake indefinitely (1). A specific message — 'The mark must be between 0 and 100' — tells them exactly how to correct it. The program must also loop and re-ask rather than detecting the error and then continuing with the bad value, otherwise the validation achieves nothing (1).

Confirmation catches errors the program cannot detect. Echoing the entered data back — 'You entered: Amina Patel. Is this correct?' — lets the user spot a typing mistake in otherwise valid data, such as a misspelled name or a transposed digit, which no validation rule could ever identify because the value is perfectly well-formed (1).

Overall, good input/output design reduces errors at three stages: preventing them with clear prompts, catching malformed data with validation and specific messages, and catching valid-but-wrong data with confirmation (1). (6)
Why this scores
The top-band idea is the three-stage framing — prevent, detect, confirm — and especially the point that confirmation catches errors validation cannot, because a misspelled name is perfectly valid data. Answers that only list features without explaining what class of error each addresses typically score 3–4.
Question 9
Paper 1 style — AO36 marks
The algorithm below should ask for three numbers and output their average. It has three faults relating to input and output. Identify each, explain its effect, and write a corrected version. (6 marks)
```
1   total ← 0
2   FOR i ← 1 TO 3
3       num ← USERINPUT
4       total ← total + num
5       OUTPUT 'Average: ', total / 3
6   ENDFOR
```
Model answer
Fault 1 — there is no prompt before the input (line 3) (1). The user sees a blank cursor three times with no indication of what to enter or how many numbers are wanted (1).

Fault 2 — the input is not converted (line 3) (1). USERINPUT returns a string, so total + num on line 4 attempts to add a string to a number, which either causes an error or performs concatenation rather than addition, making the total wrong (1).

Fault 3 — the output is inside the loop (line 5) (1). It executes on every iteration, printing three lines showing a partial 'average' calculated from incomplete data; only after all three numbers have been added is the average meaningful (1).

Corrected version:

total ← 0 FOR i ← 1 TO 3 OUTPUT 'Enter number ', i num ← STRING_TO_INT(USERINPUT) total ← total + num ENDFOR OUTPUT 'Average: ', total / 3
Why this scores
Each fault carries a mark for identification and one for its effect, so naming three faults without explaining their consequences caps at 3 of 6. Fault 3 is the most instructive: the program produces output that looks plausible — a number labelled 'Average' — but is calculated from partial data, which is a logic error that no error message would reveal.

Key Definitions and Keywords — Input/output

Definitions to memorise and the exact keywords mark schemes credit for input/output answers — sharpened from recent examiner reports for the 2026 AQA GCSE 8525 sitting.

Input
Examiner keyword
Data obtained by a program from outside it, normally typed by the user at the keyboard. In AQA pseudo-code this is USERINPUT.
Example
name ← USERINPUT
Related: Output, Prompt, USERINPUT
Output
Examiner keyword
Data or information sent from a program to the computer display for the user to see. In AQA pseudo-code this is OUTPUT.
Example
OUTPUT 'Total: ', total
Related: Input, Prompt
USERINPUT
Examiner keyword
The AQA pseudo-code operation that obtains a value typed by the user at the keyboard. It pauses the program until Enter is pressed and always returns a string.
Related: Input, String conversion
Prompt
Examiner keyword
An output message displayed immediately before an input, telling the user what data is expected. A good prompt also states the required format or range, which helps prevent invalid input.
Example
OUTPUT 'Enter a mark between 0 and 100'
Related: Input, Validation
String conversion
Examiner keyword
Changing a value between a string and a number. Needed on input (string to integer/real) before calculating, and often on output (integer/real to string) when joining a number onto text.
Example
age ← STRING_TO_INT(USERINPUT)
Related: USERINPUT, Concatenation
Concatenation
Joining strings together end to end to build an output message. Because it operates on strings, numbers must usually be converted first.
Example
'Total: £' + REAL_TO_STRING(total)
Related: Output, String conversion
Echoing input
Displaying data back to the user for confirmation after they have entered it, so they can spot their own typing errors. Catches valid-but-wrong data that validation cannot detect.
Example
OUTPUT 'You entered: ', name, '. Is this correct?'
Related: Output, Validation
Error message
Examiner keyword
Output telling the user that their input was rejected. An effective message is specific about what was wrong and how to correct it, rather than simply saying 'Invalid'.
Example
OUTPUT 'Invalid — the mark must be between 0 and 100'
Related: Validation, Output
Prevention vs detection
Examiner keyword
Prevention means designing input so errors are unlikely — clear prompts, stated formats, numbered menu options. Detection means catching errors afterwards with validation. Good design does both.
Related: Prompt, Validation
Menu
A list of numbered options output to the user, from which they select by entering a number. Typically implemented with a condition-at-the-end loop so the menu is shown at least once.
Example
OUTPUT '1 - Add' / OUTPUT '2 - View' / OUTPUT '3 - Quit'
Related: Output, Validation, Condition at the end
Output placement
Examiner keyword
Whether an OUTPUT statement sits inside or after a loop. Inside gives one line per iteration; after gives a single final result. Choosing wrongly is the most commonly lost mark in algorithm questions.
Related: Output, Iteration
Computer display
The screen to which a program sends its output. The specification's wording is 'output data and information from a program to the computer display'.
Related: Output

Common Mistakes and Misconceptions — Input/output

The traps other students keep falling into on input/output questions — taken from recent AQA GCSE 8525 examiner reports and mark schemes — and how to avoid them.

✕Writing an input statement with no prompt before it.
AQA 8525 specification 3.2.7 requires obtaining input from the keyboard; algorithm-writing mark schemes routinely award a mark for a suitable prompt.
Why it happens
When testing their own program students already know what it wants, so the missing prompt is invisible to them — the flaw only appears when someone else tries to use it.
How to avoid it
Write the prompt and the input as a two-line unit, never one without the other. Make the prompt state the expected format or range — 'Enter a mark between 0 and 100' — which also helps prevent invalid input. 'Suitable prompt' is listed as a separate credit point in many mark schemes.
✕Using the value from USERINPUT directly in a calculation or a numeric comparison.
3.2.8 lists string conversion operations precisely to solve this problem, and conversion is a separate mark in calculation and validation questions.
Why it happens
The value looks like a number on screen, and in Python the program often runs and produces plausible-looking output — the error message, when there is one, appears at a different line from the real cause.
How to avoid it
Fix the rule: keyboard input is always a string. Any input you intend to calculate or compare numerically must be wrapped in STRING_TO_INT or STRING_TO_REAL at the point it is read. Choose which by asking whether decimals are needed.
✕Placing the final OUTPUT inside the loop, so a partial result is printed on every iteration.
This is the most frequently lost mark in algorithm-writing questions across Paper 1.
Why it happens
The output statement is written at the moment the value is being updated, and it sits naturally next to the calculation — the indentation error is easy to make and easy to overlook.
How to avoid it
Ask: should the user see this once, or once per item? A single final total belongs after ENDFOR; a list of every name belongs inside. Check by asking how many lines your program should print — if the answer is one and your loop runs twenty times, the output is in the wrong place.
✕Writing an unhelpful error message such as 'Invalid' or 'Error'.
Program-improvement and evaluation questions award credit for actionable error messages.
Why it happens
The program's logic is correct — it has genuinely detected the problem — so the message feels like a finishing touch rather than part of the functionality.
How to avoid it
State what was wrong and how to fix it: 'Invalid — the mark must be between 0 and 100'. In 'improve this program' questions, vague messages are one of the faults you are expected to identify, and specific messages are creditworthy in evaluation answers.
✕Detecting invalid input with an IF, printing a message, and then carrying on and using the bad value anyway.
AQA 8525 specification 3.2.11 requires simple data validation routines; single-IF 'validation' is a recurring weakness.
Why it happens
The IF correctly identifies the error, which feels like the job done — students do not picture what happens on the very next line, where the invalid value is still sitting in the variable.
How to avoid it
Detection is useless without re-asking. Validation must loop: use REPEAT … UNTIL <valid> so the input is requested again until it passes. Trace your own algorithm with a deliberately invalid value and follow what happens next — the flaw becomes obvious in seconds.
✕Expecting a single USERINPUT statement to read several values at once.
Multi-value input questions test whether the loop-plus-array pattern has been understood.
Why it happens
In everyday use you might type '5 10 15' on one line, so it feels as though one input could capture all three — the one-statement-one-value rule is never explicitly stated in lessons.
How to avoid it
One USERINPUT reads one value. To read several, use a loop with the input inside it, and store the values in an array so they can be processed afterwards. Put the prompt inside the loop too, so the user is asked afresh each time.

Input/Output — AQA GCSE Computer Science 8525 (3.2.7)

# Poor — the user sees a blank flashing cursor and has no idea what to do age ← USERINPUT # Good — the user knows exactly what is wanted OUTPUT 'Please enter your age in years' age ← USERINPUT

# WRONG — prints a running total on every iteration FOR i ← 0 TO 9 total ← total + marks[i] OUTPUT total ENDFOR # RIGHT — one final answer after the loop FOR i ← 0 TO 9 total ← total + marks[i] ENDFOR OUTPUT 'Total: ', total

You want

Put the OUTPUT

One final result

After the loop

One line per item (e.g. a list of names)

Inside the loop

A prompt before each input

Inside the loop

OUTPUT 'Enter the length in metres' length ← STRING_TO_REAL(USERINPUT) OUTPUT 'Enter the width in metres' width ← STRING_TO_REAL(USERINPUT) area ← length * width OUTPUT 'The area is ', area, ' square metres'

Idea

Subtopic

Converting input before use

3.2.8 string conversion operations

Validating input

3.2.11 robust and secure programming

Authentication input (plain text only)

3.2.11

Identifying input/processing/output in an algorithm

3.1.1 representing algorithms

OUTPUT 'How many numbers do you want to enter?' count ← STRING_TO_INT(USERINPUT) total ← 0 FOR i ← 0 TO count - 1 OUTPUT 'Enter number ', i + 1 values[i] ← STRING_TO_INT(USERINPUT) total ← total + values[i] ENDFOR OUTPUT 'Total: ', total

REPEAT OUTPUT '--- MENU ---' OUTPUT '1 - Add' OUTPUT '2 - View' OUTPUT '3 - Quit' OUTPUT 'Enter your choice (1-3)' choice ← STRING_TO_INT(USERINPUT) IF choice < 1 OR choice > 3 THEN OUTPUT 'Invalid choice — please enter 1, 2 or 3' ENDIF UNTIL choice ≥ 1 AND choice ≤ 3 IF choice = 1 THEN OUTPUT 'You selected: Add' ELSE IF choice = 2 THEN OUTPUT 'You selected: View' ELSE OUTPUT 'You selected: Quit' ENDIF

OUTPUT 'How many items?' quantity ← STRING_TO_INT(USERINPUT) OUTPUT 'Price per item in pounds?' price ← STRING_TO_REAL(USERINPUT) total ← quantity * price OUTPUT 'You ordered ' + INT_TO_STRING(quantity) + ' items costing £' + REAL_TO_STRING(total) + ' in total'

CONSTANT NUM_STUDENTS ← 5 total ← 0 highest ← -1 FOR student ← 1 TO NUM_STUDENTS REPEAT OUTPUT 'Enter mark for student ', student, ' (0-100)' mark ← STRING_TO_INT(USERINPUT) IF mark < 0 OR mark > 100 THEN OUTPUT 'Invalid — the mark must be between 0 and 100' ENDIF UNTIL mark ≥ 0 AND mark ≤ 100 total ← total + mark IF mark > highest THEN highest ← mark ENDIF ENDFOR OUTPUT 'Highest mark: ', highest OUTPUT 'Average mark: ', total / NUM_STUDENTS

Input/output

Detailed Study Notes

At a glance

What you’ll learn

Obtaining input from the keyboard

The three rules that carry marks

Outputting data to the display

Combining text and values

Where the output goes — the mark that is lost most often

Output is also how a program communicates errors

Input → processing → output in a complete program

A complete worked program

Planning shortcut for exam questions

Writing input and output that would satisfy a user

1. Prompts should state the expected format

2. Echo important input back

3. Error messages should say what to do

4. Format numbers for the context

5. Group related output

What this connects to

Quick recap

Memorise this

How it’s examined

Take this whole topic with you

1Identify the inputs and outputs in an algorithm (3 marks)

2Write a prompted, converted input (3 marks)

3Decide where the output belongs (3 marks)

4Write a complete input–process–output program (4 marks)

5Read several values using a loop (5 marks)

6Improve a program's input and output (5 marks)

7Write a menu-driven input system (6 marks)

8Convert input and output in both directions (6 marks)

9Evaluate the input/output design of a program (6 marks)

Input

Output

USERINPUT

Prompt

String conversion

Concatenation

Echoing input

Error message

Prevention vs detection

Menu

Output placement

Computer display

✕Writing an input statement with no prompt before it.

✕Using the value from USERINPUT directly in a calculation or a numeric comparison.

✕Placing the final OUTPUT inside the loop, so a partial result is printed on every iteration.

✕Writing an unhelpful error message such as 'Invalid' or 'Error'.

✕Detecting invalid input with an IF, printing a message, and then carrying on and using the bad value anyway.

✕Expecting a single USERINPUT statement to read several values at once.

Input/output

Detailed Study Notes

At a glance

What you’ll learn

Obtaining input from the keyboard

The three rules that carry marks

Outputting data to the display

Combining text and values

Where the output goes — the mark that is lost most often

Output is also how a program communicates errors

Input → processing → output in a complete program

A complete worked program

Planning shortcut for exam questions

Writing input and output that would satisfy a user

1. Prompts should state the expected format

2. Echo important input back

3. Error messages should say what to do

4. Format numbers for the context

5. Group related output

What this connects to

Quick recap

Memorise this

How it’s examined

Take this whole topic with you

1Identify the inputs and outputs in an algorithm (3 marks)

2Write a prompted, converted input (3 marks)

3Decide where the output belongs (3 marks)

4Write a complete input–process–output program (4 marks)

5Read several values using a loop (5 marks)

✕Using the value from `USERINPUT` directly in a calculation or a numeric comparison.

✕Detecting invalid input with an `IF`, printing a message, and then carrying on and using the bad value anyway.

✕Expecting a single `USERINPUT` statement to read several values at once.