I can identify the data types and structures a problem needs before designing it
I can read a structure diagram showing top level design and data flow
I can create a refinement that breaks a top-level step into greater detail
Success criteria
I can number a top-level design 1 to 4 in a logical order
I can label the data flowing into and out of each step as IN or OUT, using variable names
I can number a refinement of step 2 as 2.1, 2.2, 2.3 and keep it consistent with the parent step
Warm up — recap from SDD2
Answer all three questions, then check your answers.
Question 1
Every functional requirement must begin with which two words?
Question 2
What term describes a project expanding beyond its original plan as new features are added?
Question 3
Which phase of the iterative development process comes immediately after analysis?
Key vocabulary
Structure diagram
A diagram that shows the major steps of a solution and how data flows between them.
Top level design
The major numbered steps of a design, usually 3–5 steps, before any further detail is added.
Data flow
The data that moves into (IN) or out of (OUT) each step of a design.
Refinement
A more detailed breakdown of a single top-level step, numbered as a sub-step (e.g. 2.1, 2.2).
Sub-program
A named, self-contained section of a design (and later, code) with its own inputs and outputs.
Data structure
A way of organising related data, e.g. a parallel array, a record, or an array of records.
Why design comes before code
Once analysis has produced a set of functional requirements, the next job is to plan how the system will meet them — without writing any code yet. This is the design phase. Two techniques are used at Higher: structure diagrams (this lesson) and pseudocode (SDD4). Both express the same underlying design; a structure diagram just shows it visually rather than as numbered text.
Before drawing anything, a designer identifies the data types and structures the problem will need. A problem that processes a single value per pupil might only need simple variables; a problem that processes many related values together (many day's rainfall, many pupils' records) will need a structure such as a parallel array, a record, or an array of records — the data structures covered in SDD5 and SDD6. Deciding this early keeps the rest of the design consistent.
Top level design
A structure diagram starts with the top level design: the major steps needed to solve the problem, numbered in the order they happen. A well-formed top level design usually has somewhere between three and five steps — fewer than that and steps are probably too vague; more than that and some steps should really be refinements of an earlier one.
Data flow
Every step in a structure diagram must show its data flow: what data goes IN to that step, and what data comes OUT of it. Data flow is what connects the separate steps together into one coherent design — the OUT of one step is very often the IN of a later step. Getting this right matters more than it might seem: an examiner reading your structure diagram is checking whether the data genuinely flows correctly from one step to the next, not just whether the step descriptions sound sensible.
Refinements
Some top-level steps are too complex to implement directly and need to be broken down further. This breakdown is called a refinement. A refinement of step 2 is numbered 2.1, 2.2, 2.3 and so on — the numbering always shows which top-level step it belongs to. Refinements can be shown as a separate diagram underneath the top level design, or written out as numbered lines in the same style as pseudocode. Not every step needs a refinement; only the ones that are too complex to go straight to code.
Worked examples
Example 1 — Top level design: Weekly Rainfall Tracker
1
Scenario: A program reads the rainfall total (in mm) recorded for each of the 7 days in a week. It calculates the total rainfall for the week and displays which day had the highest rainfall.
Step 1
Get rainfall readingsOUT: rainfall()
↓ rainfall() flows into steps 2 and 3
Step 2
Calculate total rainfallIN: rainfall() · OUT: total
↓
Step 3
Find day with highest rainfallIN: rainfall() · OUT: highest day position
↓ total and highest day position flow into step 4
Step 4
Display resultsIN: total, highest day position
✓
Notice how rainfall() is the OUT of step 1 and reappears as the IN of both steps 2 and 3 — this is what makes it a connected design rather than four unrelated steps.
Example 2 — Refining step 1
1
Step 1 ("Get rainfall readings") needs a refinement because it involves reading 7 separate values, not a single action.
1.1Start fixed loop for each of the 7 days (OUT: day counter)
1.2Get rainfall reading for the day (OUT: rainfall(day counter))
1.3End fixed loop
✓
The refinement is numbered 1.1–1.3 because it belongs to step 1 — never 2.1 or a plain new list. Refinements elaborate an existing step; they don't add new top-level functionality.
Example 3 — Top level design: Class Quiz Score Checker
1
Scenario: A program reads the score out of 20 that each pupil in a class of 25 achieved in a quiz. It counts how many pupils scored 10 or more (a pass) and displays that count.
This design only needs three top-level steps — resist the urge to pad it out. A refinement of step 2 (the counting loop, comparing each score to 10) would be a sensible addition if more detail were required.
Now you try
A program reads the temperature (°C) recorded at midday for 5 different cities. It calculates the average temperature across the 5 cities, then displays the name of any city whose temperature was above that average.
Write: a top level design (3–4 numbered steps) with data flow shown as IN/OUT for each step.
Step 1 — Get city temperatures (OUT: city(), temperature())
Step 2 — Calculate average temperature (IN: temperature() · OUT: average)
Step 3 — Find cities above average (IN: city(), temperature(), average · OUT: above-average cities)
Writing step names with no data flow at all — every step needs its IN and/or OUT labelled, not just a description
Numbering a refinement as a fresh list (1, 2, 3) instead of tying it to its parent step (e.g. 2.1, 2.2, 2.3)
Showing one data flow label for the whole design instead of per step — data flow is specific to each individual step
Turning a refinement into new functionality rather than extra detail on an existing step
Using a different variable name for the same data in the top level design and its refinement (e.g. rainfall() vs readings()) — names must stay consistent throughout
📝 Exam tip
Always match variable names exactly between the top-level design and any refinement of it. If step 1's OUT is rainfall(), its refinement must also use rainfall() — not a renamed version. Examiners specifically check for this consistency, and it is one of the easiest marks to lose unnecessarily.
Task Set A — Core questions
Task Set A — Core questions
Work through all questions, then check your answers.
Question 1
What is the term for the major numbered steps of a design, before any further detail is added?
Question 2
In a structure diagram, which label is used for data that is produced by a step and passed on to a later step?
Question 3
If a refinement of step 2 is written, what would its first sub-step be numbered?
Question 4
A design has: Step 1 — Get pupil names and marks (OUT: name(), mark()). Step 2 — Calculate average mark (IN: mark(), OUT: average). Which is the correct IN for Step 3, "Display names of pupils above average"?
Question 5
What term describes data that organises related values together, such as a parallel array, a record, or an array of records?
Question 6
Explain why data flow should be shown for every step in a structure diagram, not just described in words. (2 marks)
Model answer
Question 7
Which of the following top-level designs is correctly numbered and ordered?
Question 8
A refinement always belongs to exactly one what?
Question 9
A program reads a raw coursework mark for each of 30 pupils, converts each to a percentage, then displays which pupil achieved the highest percentage. Write a 4-step top level design with data flow. (4 marks)
Model answer (examples — accept any correctly ordered, correctly labelled design)
Question 10
In the data flow notation "IN: score() · OUT: pass count", what does the empty brackets after "score" indicate?
Task Set B — Extension
Task Set B — Extension · Beyond the specification
Longer written answers — no auto-check. Discuss your answers with your teacher.
Extension 1
A program records how long (in minutes) a school bus journey took each day for 5 days. It calculates the average journey time, then counts how many days took longer than average. Write a top level design (4 steps) and a refinement of the counting step. (5 marks)
Model answer
Extension 2
Explain when it might be more appropriate to use a structure diagram rather than pseudocode, and when the reverse might be true. (3 marks)
Model answer
Extension 3
A pupil draws this design: Step 1 — Get item prices (OUT: price()). Step 2 — Calculate total cost (no IN or OUT shown). Step 3 — Display total (IN: total). Identify the fault in Step 2 and explain how to fix it. (2 marks)
Model answer
📁 File this in OneNote under: Higher Computing Science → Software Design & Development → SDD3
📌 Teacher notes — not for pupils
Single period. First design-technique lesson — pupils have only seen written analysis so far, so the shift to a semi-visual notation can take a moment to land. Draw the rainfall example on the board step by step rather than presenting it complete.
Suggested timing: 5 min warm-up · 15 min notes + vocab · 15 min worked examples 1–2 (draw live) · 5 min worked example 3 (pupils attempt before reveal) · 5 min "now you try" · 15 min Task Set A.
Common pupil confusion: they treat refinement numbering as a completely new list rather than a sub-numbering of the parent step. Model this explicitly on the board — write "2" then "2.1, 2.2, 2.3" directly underneath it.
Task Set B is unlikely to be finished in the single period — set as homework or fold into the start of SDD4 as a recap activity.