Community resourceWorksheet
OCR H446 2.1.3 Procedural order and sub-procedures
Part 2 of 2 · H446 2.1.3 · Thinking procedurally
Correct components in the wrong order still produce an incorrect solution, which is the reasoning OCR H446 2.1.3 examines here. A digital escape-room booking workflow drives the ordering work, supported by a trace table, a Python admission function and a pseudocode design task.
Students will:
- order sub-procedures using data dependencies, preconditions and state changes
- explain why validation must come before any change to stored capacity
- trace a workflow and record which route reaches confirmation
- implement an ordered admission function that leaves external state unchanged
- design pseudocode from named sub-procedures showing parameters and returned values
Inside: 7 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells, 2 written answers, 1 Python task and 1 trace table. 22 marks, about 25 to 35 minutes.
Series: H446 2.1.3 · Thinking procedurally, part 2 of 2.
Shared by Coding PathwayVerified teacher
- 14 cells
- About 30 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 15 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Thinking procedurally: order and sub-procedures
An escape-room booking system must validate a request, reserve places, calculate a price and send a confirmation. These are suitable components, but the solution will still fail if they happen in an unsuitable order.
By the end, you will be able to
- put steps in order by identifying what each step needs;
- explain why an unsuitable order causes a problem;
- identify the sub-procedures needed to solve a problem;
- show parameters, returned values and a correct sequence in code or pseudocode.
Remember: parameters pass input data into a sub-procedure. A function can pass a result back using return.
Read arrows as dependencies
A dependency exists when one step needs information or a change produced by another step. Both calculate price and reserve place need a valid request, so validation must happen first. Sending a confirmation needs the calculated price and a successful reservation, so it must wait for both.
The order is determined by these needs, not by personal preference. For example, a program cannot confirm a payment before the payment has succeeded, and it cannot process a file before the user has selected one.
Worked correction
Invalid order: send confirmation → reserve place → validate request.
This fails because the confirmation does not yet have a price or a successful reservation. Reserving first could also reduce the remaining capacity for a request that should later be rejected.
A suitable order is: validate the request → calculate the price and reserve the place → send the confirmation after both have succeeded. If validation fails, the procedure should return a rejection before changing the stored capacity.
Which sequence can produce a valid booking confirmation?
- AConfirm → reserve → validate → calculate
- BValidate → reserve and calculate → confirm
- CReserve → confirm → calculate → validate
- DCalculate → confirm → validate → reserve
- validated
- reservation
- parameters
- abstraction
Trace this OCR ERL workflow and record which route reaches confirmation.
Enter a value only when it changes. Follow the listing in order.
Use one row for each pass through the loop. Fill in a box only when that value changes on that row, and leave the rest blank.
remaining = 3requested = 2confirmed = Falseif requested >= 1 AND requested <= remaining thenremaining = remaining - requestedconfirmed = Trueendifprint(remaining)print(confirmed)
| Row | remaining | requested | confirmed | requested >= 1 AND requested <= remaining | Output |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
Explain why the capacity update occurs before confirmed becomes True, and describe what would happen for requested = 4.
Explain what must be true before success is recorded. Then trace the condition again using requested = 4.
Students type their answer here.
Identify the required sub-procedures
validate_request(requested, remaining) → Boolean
calculate_price(requested, price_each) → real value
reserve_places(requested) → success Boolean
build_confirmation(reference, price) → string
Each sub-procedure performs one part of the solution. The names inside the brackets are parameters: they show the input data supplied to that sub-procedure. The arrow shows the value returned. These inputs and results make the dependencies between sub-procedures visible.
Independent transfer: implement an ordered admission function
Return “rejected” for a count below 1 or above remaining. Otherwise return the new remaining capacity as an integer. Do not change external/global state.
def admit(requested, remaining):
# Reject a request below 1 or above the remaining capacity.
if requested < 1 or requested > remaining:
return "rejected"
# A valid request reaches this line. Return the new capacity.
return remainingDesign pseudocode for the full escape-room booking workflow. Call at least three named sub-procedures, show the parameters or returned values, and place the calls in a valid order. Then explain one dependency that determines this order.
Validation must happen before a place is reserved. A confirmation must not be sent until the price and reservation are available.
Students type their answer here.
Checkpoint
Complete the procedural explanation from memory. Your teacher will review your answers.
Review your understanding
Before submitting, check that you can put steps in order from their dependencies, identify suitable sub-procedures, and show the data passed between them.