Thinking procedurally — OCR A-Level Computer Science
Thinking procedurally explained
Thinking procedurally covers 4 specification points, including (a) Identify the components of a problem.
Read the full explanation
and (b) Identify the components of a solution to a…. Open a point below for its explanation and revision guidance.
(a) Identify the components of a problem.
Identifying the components of a problem means separating a written scenario into its distinct parts before any design starts. A problem usually has a goal stating what the system must achieve, inputs supplied to the solution, outputs it must produce, and constraints such as limits on time, memory, cost or user access. In a timetabling scenario, the goal is a conflict-free weekly timetable, inputs are room lists and teacher availability, outputs are printed timetables, and a constraint forbids booking a teacher in two rooms at once. Read the scenario once for the aim, then reread it marking data, actions and limits. Listing these parts in a table gives a clear base for later steps.
(b) Identify the components of a solution to a problem.
Identifying the components of a solution means naming the parts of a proposed method that together meet the problem's requirements. A solution usually includes ordered steps or sub-tasks, the data it stores, the inputs it accepts and outputs it produces, and the decisions or repetitions that control the work. For example, a timetabling solution might read room and teacher data, loop over unplaced lessons, reject any clash, and write the finished timetable. Match each requirement to the step that satisfies it, so none is left without a component. This shows how the solution works, not only what it must achieve.
(c) Determine the order of the steps needed to solve a problem.
This statement asks you to determine the order of the steps needed to solve a problem. Start by listing every action the solution requires, then examine what each step needs as input and what it produces. A step can only run once its inputs exist, so a step that produces a value must come before any step that uses it. For example, to find the largest value in a list, read the list before comparing items and set a stored maximum before the comparison loop begins. Where two steps do not depend on each other, either order works, so more than one valid sequence can exist. Check your final sequence by tracing it with sample data to confirm each step runs in the right place.
(d) Identify sub-procedures necessary to solve a problem.
This statement asks you to identify the sub-procedures necessary to solve a problem as part of procedural thinking. Decomposing a complex system into smaller, modular sub-procedures makes software easier to design, implement, test, and maintain. Sub-procedures may be functions that return a value or procedures that perform an action without returning a value; they may take parameters or operate parameterlessly. Candidates for sub-procedures include tasks that repeat across different parts of the program, tasks with well-defined distinct responsibilities, and components that can be independently developed and tested. Unnecessary over-fragmentation should be avoided by keeping trivial sequential steps unified.
Your focus
- Identify the goal, inputs, outputs and constraints in a given problem scenario.
- Distinguish problem components from solution choices in a written scenario.
- Produce a labelled list of problem components from an unseen scenario.
Show all 12 objectives
- Identify the steps, data and control elements that make up a given solution.
- Match each component of a solution to the requirement it satisfies.
- Produce a labelled list of solution components for an unseen problem scenario.
- Sequence the steps of a given problem so that every input exists before it is used.
- Justify the position of a step by naming the value it produces or consumes.
- Trace a sequence of steps with sample data to confirm that it produces the required output.
- Decompose a computational problem into necessary modular sub-procedures.
- Distinguish between functions and procedures within problem solutions.
- Identify opportunities for code reuse through sub-procedure abstraction.
Thinking procedurally exam tips
Marking Points
- Names the goal the problem requires the system to achieve.
- Identifies the inputs the solution receives from the scenario.
- Identifies the outputs the solution must produce.
- Identifies constraints or limits that restrict how the solution may work.
- Distinguishes problem components from solution choices such as a particular programming language.
- Identifies the ordered steps or sub-tasks that make up the method.
- Identifies the data structures or stored values the method uses.
- Identifies the inputs the method accepts and the outputs it produces.
- Identifies control elements such as selection and iteration that govern the order of work.
- Links each component to a stated requirement of the problem.
- Lists every action the solution requires before arranging them.
- Orders each step after the steps that produce the values it uses.
- Places a step that stores a value before any step that reads that value.
- Recognises when two steps can occur in either order and says so.
- Checks the final sequence by tracing it with sample data.
- Decomposes a problem into self-contained sub-procedures with clear, distinct responsibilities.
- Recognises that sub-procedures can be procedures (which execute actions without returning a value) or functions (which return a value).
- Identifies repeated tasks across an algorithm as ideal candidates for sub-procedures to avoid code duplication.
- Explains how identifying modular sub-procedures facilitates independent testing, debugging, and team development.
Examiner Tips
- 💡For each scenario, write separate headings for goal, inputs, outputs and constraints, then fill each heading from the text.
- 💡Check each item against the wording of the scenario so that every entry can be traced to a stated requirement.
- 💡Keep answers brief and specific, naming each component in a short phrase rather than a long explanation.
- 💡Work through the solution in order, naming each step, and then check that each stated requirement has a matching component.
- 💡Name data items and control elements separately so that storage, input, output and sequencing are each clearly covered.
- 💡Use short, precise phrases for each component rather than general descriptions of the whole system.
- 💡Write each step as a short verb phrase and number them so the order is visible.
- 💡Trace a small worked example through your sequence to catch misplaced steps before you finish.
- 💡When two steps are independent, state the order you chose and note that the reverse order would also be valid.
- 💡Distinguish between functions (return values) and procedures (do not return values) when naming sub-procedures.
- 💡Look for repeated algorithmic steps in problem descriptions to identify candidates for procedural reuse.
- 💡Ensure every identified sub-procedure addresses a clear, coherent part of the overall problem specification.
Common Mistakes
- Lists a programming language as a problem component; language choice belongs to the solution, not the problem.
- Describes how the system should work instead of what it must achieve; keep to the requirement itself.
- Omits constraints and lists only inputs and outputs; add limits on time, memory, cost or access.
- Restates the problem's requirements as if they were the solution; name the steps that satisfy those requirements instead.
- Gives a single step, such as writing the output, as the whole solution; name every component the method needs.
- Lists the problem's inputs without showing how the method processes them; link each input to the step that uses it.
- Places steps in the order they came to mind, ignoring data dependencies; order them so every input exists before it is used.
- Reads a value before it has been stored, so the sequence fails; move the storing step earlier.
- Treats one valid order as the only possible answer; state that independent steps may swap positions.
- Omits a necessary step, such as initialisation, so the sequence cannot run; add it at the point where it is needed.
- Believes every sub-procedure must return a value; procedures can perform actions such as outputting data or updating state without a return value.
- Assumes all sub-procedures require input parameters; parameterless subroutines are fully valid and frequently used.
- Over-decomposes trivial single-line operations into unnecessary separate sub-procedures, which reduces clarity.