A-Level Computer Science / Unit 9: Computational Thinking and Algorithm Design

9.2.4 Stepwise Refinement: From Outline to Programmable Detail

🔒 Lesson slides are available to signed-in users. Sign in

9.2.4 Stepwise Refinement: From Outline to Programmable Detail

A first solution often describes what should happen without explaining exactly how a computer could carry it out. Stepwise refinement develops that outline through several levels, replacing broad instructions with precise input, processing, decisions, repetition and output.

By the end of this section, you should be able to:

  • Explain why an outline algorithm may need further detail.
  • Refine a broad instruction through more than one level.
  • Recognise when a step is precise enough to translate into a program.
  • Preserve the purpose and order of an algorithm while detail is added.
  • Use input, output, assignment, sequence, selection and iteration in a refined solution.
  • Check a refined algorithm for missing data, ambiguous conditions and incorrect dependencies.
  • Distinguish stepwise refinement from abstraction and decomposition.
This page completes Unit 9 by showing how a high-level design becomes detailed enough to implement. Procedure and function definitions are developed later in Unit 11.3.

What Is Stepwise Refinement?

Stepwise refinement begins with a high-level description of a solution. A designer selects one broad step, replaces it with smaller steps, and repeats the process wherever more precision is needed. Each new level should explain the same solution more clearly rather than changing its purpose.

Stepwise refinement: developing an outline algorithm through successive levels of detail until its instructions can be implemented using well-defined programming constructs.

For example, process each greenhouse zone is useful in an early outline, but it does not state which values are read, how a watering decision is made, how the amount is calculated or what is output. Refinement exposes those details one layer at a time.

Exam tip: A strong definition includes both the starting point and the end point: begin with an outline, then add detail until the task could be programmed.

A Repeatable Refinement Process

  1. State the required result. Make sure the overall purpose is clear.
  2. Write a high-level outline. Use a small number of meaningful actions.
  3. Choose an unclear step. Look for verbs such as process, check, prepare or handle.
  4. Expand that step. Identify its data, calculations, conditions, repeated actions and outputs.
  5. Check dependencies. Confirm that every value exists before it is used.
  6. Repeat where necessary. Continue until each remaining instruction is unambiguous and implementable.
  7. Trace the result. Use sample data to confirm that the refined version still meets the original purpose.
Common misconception: Refinement is not simply adding more words. Each extra detail should remove uncertainty about data, order, calculations, conditions or repetition.

When Is a Step Detailed Enough?

A step is usually ready for implementation when another programmer would not need to make an important design decision to translate it into code.

Check Question to ask Evidence of sufficient detail
Data Which values are needed and where do they come from? Inputs and stored values have clear identifiers and units.
Processing What calculation or update is performed? The formula or assignment is stated explicitly.
Decision What exact condition chooses a path? The condition evaluates to TRUE or FALSE.
Repetition What repeats, and when does repetition stop? The loop body and control rule are both defined.
Order Are values produced before later steps use them? Dependencies are respected throughout the sequence.
Result What is output and for whom? The required output is explicit and complete.
Exam tip: Statements such as calculate the result and check the reading normally need refinement because the calculation and condition are still missing.

Worked Scenario: Greenhouse Watering Planner

A greenhouse is divided into several growing zones. For each zone, the system receives its area and current soil-moisture percentage. A zone requires watering when its moisture is below 38%. A dry zone receives 1.7 litres per square metre. The algorithm must display the recommendation for every zone and the total water required for the whole greenhouse.

Initial outline

1. Obtain the run settings.
2. Process every growing zone.
3. Report the total water required.

This outline shows the overall sequence, but the second step hides most of the design. The next sections refine it without changing the original goal.

The fixed design rules in this example are a moisture threshold of 38% and a watering rate of 1.7 litres per square metre.

Building the Refinement Levels

Level 1: expand the three main stages

1. Obtain the run settings.
   1.1 Input how many zones will be processed.
   1.2 Set the greenhouse water total to zero.

2. Process every growing zone.
   2.1 Repeat once for each zone.
   2.2 Input the zone's area and moisture reading.
   2.3 Decide whether watering is required.
   2.4 Calculate the water for this zone.
   2.5 Display the zone recommendation.
   2.6 Add the zone amount to the greenhouse total.

3. Report the total water required.
   3.1 Output the greenhouse water total.

Level 1 reveals the repeated work, but steps 2.3 and 2.4 still leave important decisions to the programmer.

Level 2: refine the decision and calculation

2.3 Decide whether watering is required.
    2.3.1 Compare MoisturePercent with 38.

2.4 Calculate the water for this zone.
    2.4.1 IF MoisturePercent < 38 THEN
              WaterLitres ← AreaM2 * 1.7
          ELSE
              WaterLitres ← 0
          ENDIF

The threshold, operator, formula and alternative result are now explicit. These details can be written directly using assignment and selection.

IdentifierRolePurpose
NumberOfZonesInputStores how many zones must be processed.
ZoneCounterControlTracks the current repetition.
AreaM2InputStores the area of the current zone in square metres.
MoisturePercentInputStores the current zone's moisture reading.
WaterLitresProcess/outputStores the calculated water for the current zone.
TotalWaterLitresAccumulatorStores the sum of all zone requirements.

Complete Programmable-Level Algorithm

INPUT NumberOfZones
TotalWaterLitres ← 0

FOR ZoneCounter ← 1 TO NumberOfZones
    INPUT AreaM2
    INPUT MoisturePercent

    IF MoisturePercent < 38 THEN
        WaterLitres ← AreaM2 * 1.7
    ELSE
        WaterLitres ← 0
    ENDIF

    OUTPUT ZoneCounter, WaterLitres
    TotalWaterLitres ← TotalWaterLitres + WaterLitres
NEXT ZoneCounter

OUTPUT TotalWaterLitres

The refined algorithm now states the input, initialisation, loop boundary, decision, calculation, per-zone output, running-total update and final output. No major design choice is left unstated.

Common mistake: TotalWaterLitres must be initialised before the loop. If it is reset inside the loop, the final output will contain only the most recent zone's amount.

Check That Refinement Preserved the Solution

Adding detail can introduce errors. Compare each refined level with the original problem and trace representative data before accepting the design.

Zone Area (m²) Moisture (%) Condition Water (L) Running total (L)
1122929 < 38 → TRUE20.420.4
285252 < 38 → FALSE0.020.4
3103333 < 38 → TRUE17.037.4

Useful checking questions

  • Is every requirement from the problem represented?
  • Does each refined group still perform the broad step it replaced?
  • Are threshold values, units and boundaries correct?
  • Can the loop terminate after the intended number of zones?
  • Are all values initialised before use?
  • Does tracing normal and boundary data produce sensible results?
Exam tip: When asked to refine one named step, keep the numbering or indentation visibly linked to that parent step. This makes the relationship between levels clear.

Abstraction, Decomposition and Refinement

TechniqueMain purposeQuestion it answersGreenhouse example
Abstraction Remove irrelevant detail. What information matters for this task? Use area and moisture, but ignore the colour of the plant labels.
Decomposition Divide the overall problem into sub-problems. What separate parts must be solved? Separate data collection, zone processing and reporting.
Stepwise refinement Add detail to an outline solution. Exactly how will each broad step be carried out? Replace “process a zone” with input, decision, calculation, output and update steps.
Common mistake: Decomposition separates the problem into parts. Stepwise refinement develops the instructions within a proposed solution. The two techniques can be used together, but they describe different design actions.

Interactive: Refinement Explorer

Use the first mode to reveal the greenhouse solution one level at a time. Then switch to the trace mode to watch the refined algorithm process three sample zones and build its running total.

Refinement levels

Result / explanation

X

Common Mistakes and Misconceptions

  • Replacing a broad step with another equally vague phrase.
  • Adding unrelated features that change the original problem.
  • Refining calculations but leaving conditions or loop boundaries undefined.
  • Using a value before the step that creates or inputs it.
  • Forgetting an alternative path when a condition is false.
  • Initialising a counter or total inside the repeated block.
  • Stopping after one level even though important design decisions remain.
  • Assuming that more detail automatically means correct detail.

Practice

Try these original questions

  1. Explain stepwise refinement without using the phrase “break a problem down”.
  2. Why is check whether the parcel can be collected not yet programmable detail?
  3. Refine calculate the journey charge when the charge is a £1.80 starting fee plus £0.32 per minute.
  4. Write a high-level three-step outline for processing attendance at an after-school club.
  5. Refine the step process each attendee so that it includes input, a decision and an output.
  6. For the greenhouse algorithm, calculate the water and running total for a fourth zone with area 9 m² and moisture 38%.
  7. Identify two errors that would occur if the total were set to zero inside the loop.
  8. Explain one difference between decomposition and stepwise refinement.
  9. Create two refinement levels for a system that inputs five noise readings and reports how many exceed 65 dB.
  10. Describe how you would decide that your final refinement is detailed enough to implement.

Review

QuestionA strong answer should include
What is refined?The steps of an outline algorithm.
Why refine?To remove ambiguity and reach implementable detail.
What may appear in the final level?Input, output, assignments, sequence, conditions and loops.
What must remain unchanged?The original purpose and required result.
How is the design checked?Compare with requirements, inspect dependencies and trace sample data.
How does it differ from decomposition?Refinement adds detail to steps; decomposition separates the overall problem into parts.
Final exam tip: Do not jump from one vague sentence directly to long pseudocode. Show at least one meaningful intermediate level so the development of the solution is visible.