01 | WHY DRAW A STRUCTURE DIAGRAM?

Suppose you have been asked to build a school-club booking system. You need to receive requests, check duplicates, check capacity, save bookings and show reports. A paragraph can list these tasks, but it may be difficult to see which tasks belong together.

A structure diagram shows how a system or solution is organised into smaller parts. It gives a visual overview of decomposition, the process of breaking a problem into manageable parts.

Imagine looking at a school’s organisation: the school contains departments, and departments contain smaller teams. A structure diagram uses a similar hierarchy to organise the responsibilities within a solution.

You do not need to know how to program each part before drawing the overview. The diagram helps you decide what parts you will need and how their responsibilities fit together.

02 | UNDERSTAND BOXES, LEVELS AND CONNECTIONS

The top box names the whole system or overall task. Boxes beneath it name the smaller tasks that make up that whole. A task can be broken down again, producing another level of boxes.

A parent is a box that is divided into smaller parts. Its children are the boxes directly beneath and connected to it. These words describe relationships in the diagram, rather than people.

For example, “Booking management” can be the parent of “Receive request”, “Check request” and “Record accepted booking”. “Check request” can then be the parent of “Check duplicate” and “Check capacity”.

The connecting lines mean that the lower task forms part of the higher task. They do not automatically mean that data travels along the line, or that one task happens immediately after another.

03 | READ A FIRST DIAGRAM

Read the diagram from the top down. Start with the purpose of the whole system, then inspect each group of smaller tasks.

The booking system contains booking management, stored-data management and reporting. Booking management is expanded to show three responsibilities: receiving a request, checking it and recording an accepted booking.

Reporting has not been expanded in this overview. That does not mean it has no internal steps; it means the diagram currently shows less detail for that part. We can expand it when we need a more detailed plan.

For this example, recording an accepted booking means updating the working booking collection. Stored-data management saves and loads that collection so it remains available after restarting. Keeping these responsibilities distinct avoids treating “record” and “save” as unexplained duplicate tasks.

04 | EXPAND A BOX WITHOUT CHANGING ITS PURPOSE

“Check request” is still broad. We know a request can be rejected because the identifier is already booked or because no place remains. We can therefore decompose this box into two checks.

The lower boxes explain what the parent does. They are not unrelated features added simply to make the diagram larger.

If you placed “Choose poster colour” under “Check request”, the connection would not make sense: choosing a colour does not contribute to deciding whether the booking is allowed.

A useful test is to read a connection as a sentence: “Checking a request includes checking for a duplicate.” If the sentence does not describe a meaningful part of the parent’s job, reconsider the arrangement.

05 | A STRUCTURE IS NOT AN EXECUTION SEQUENCE

The diagram tells us that duplicate and capacity checking belong inside request checking. It does not, by itself, specify which check runs first or what happens after a failed check.

A flowchart or pseudocode algorithm can describe that control flow. For example, an algorithm might check for a duplicate first and stop if one is found; otherwise it checks capacity.

This distinction is important. A structure diagram answers “What parts make up the solution?” A flowchart answers “What steps and decisions happen as the algorithm runs?”

Do not add Yes/No decision branches to an ordinary decomposition diagram to explain acceptance. Those belong in a flowchart describing the decision. A structure diagram can include a task called “Check capacity” without showing its decision branches.

06 | BUILD A DIAGRAM FROM THE REQUIREMENTS

Start with a short scenario: a school canteen system must receive an order, calculate its cost, record payment and send the accepted order to the kitchen.

First name the whole task: “Canteen ordering system”. Next identify the major responsibilities: order entry, cost calculation, payment recording and kitchen reporting. Each contributes directly to a stated requirement.

Now examine cost calculation. It needs to obtain prices, calculate each item’s cost from its price and quantity, and total the item costs. These become child tasks beneath “Calculate cost”.

We have moved from the overall purpose to manageable responsibilities. We have not yet chosen every variable, written code or described the exact execution sequence. That is appropriate for this level of design.

07 | CHOOSE LABELS THAT EXPLAIN THE JOB

A box label should tell a reader what that component is responsible for. “Check capacity” is useful because it names a particular job. “Stuff”, “Process” or “Part 2” gives little information.

Where practical, use an action and the thing it acts on: “Load bookings”, “Calculate total” or “Produce attendance list”. A broad sub-system name such as “Payment management” is also useful when it groups several related responsibilities.

Try to keep boxes at the same level at a comparable level of detail. Placing “Manage all bookings” beside “Display one character” mixes a large responsibility with a tiny implementation detail.

A diagram should remain readable without a long explanation of every label. If a label could mean several different jobs, make it more specific or briefly define its responsibility beside the diagram.

08 | CHECK THAT ALL REQUIREMENTS ARE COVERED

A tidy diagram can still be incomplete. Return to the requirements and identify which component will satisfy each one.

If the club must retain bookings after restarting, the diagram needs a responsibility for saving and retrieving the records. If it only includes a success message, it has not covered persistent storage.

This check also reveals unnecessary parts. A complex online-payment component would add work to a free club-booking system unless the requirements called for it.

The structure should be driven by the problem. You can use a familiar example as a starting point, but copying its boxes without checking the new scenario may produce a design that solves the wrong task.

09 | HOW MUCH DETAIL SHOULD YOU SHOW?

A diagram for an overview may show only the main sub-systems. A diagram used to plan one difficult component may include several additional levels within that component.

Continue decomposing while a responsibility is too broad to explain or design clearly. “Manage orders” needs more detail. “Calculate item cost from price and quantity” may already be specific enough for the current task.

Do not create separate boxes for every keystroke or printed letter just to increase the number of levels. That makes the diagram harder to read without improving the plan.

There is no universal requirement for exactly three levels or a fixed number of child boxes. Follow the scenario and any question instructions. Show enough detail to make the required responsibilities and their grouping clear.

10 | ARRANGE THE DIAGRAM SO IT IS EASY TO READ

Place the overall task at the top. Put its main children on the next level, with lower-level tasks beneath the parent they belong to. Use clear connecting lines and avoid crossings where possible.

Keep text inside the boxes. If a label is long, use a line break or widen the box rather than letting it overlap another component. Leave enough space between levels so a reader can follow each parent-child connection.

A structure diagram is about the hierarchy, so left-to-right positioning alone should not be used to imply sequence. If you need to show precise execution order, draw a separate flowchart or write pseudocode.

On a small screen, the worked diagrams here stack their branches. Their grouping and labels still show the parent-child relationships, even when the branches cannot fit side by side.

11 | MORE THAN ONE VALID DESIGN IS POSSIBLE

One developer might group saving and loading inside a “Data management” component. Another might group them inside a broader “Booking management” component. Either can be sensible if the responsibilities remain clear and the requirements are covered.

Compare the meaning rather than the appearance of the diagrams. Are the child tasks genuine parts of the parent? Is an essential task missing? Are two boxes doing the same job without a clear reason?

Remember that lines in the hierarchy do not explain every connection between components. A reporting component still needs access to booking data even if it is drawn beside booking management. Additional descriptions can explain what data each component needs and produces.

Later implementation may use procedures or functions for these responsibilities. A box is a design component; it is not automatically one line of code or a hardware device.

12 | TRY A SCHOOL-TRIP SYSTEM

A school-trip system must register students, reject duplicate registrations, check available places, record payment status and produce an attendance list.

Name the overall system, then propose booking management, payment management and reporting as its main children. Under booking management, add receiving a request, checking a request and recording an accepted booking. Expand checking into duplicate and capacity checks.

Now justify the grouping. Duplicate and capacity checks both determine whether a registration is acceptable, so they belong within request checking. Payment management tracks payment status; reporting produces the attendance list.

If the scenario also requires sending reminder messages, add that responsibility in a suitable place. Explain whether it belongs within payment management or a separate communications component. The new requirement changes the design.

Draw your version before opening the sample in the Questions tab. The aim is to reason about the tasks, not simply copy a picture.

13 | EXPLAIN WHAT YOUR DIAGRAM SHOWS

To describe a structure diagram, explain the overall system and how its major components are divided into smaller tasks.

To explain why a grouping is useful, connect it to a purpose: “Duplicate and capacity checking are grouped within request checking because both determine whether a booking can be accepted.”

Avoid saying that the top box “runs first” or that every line is a data transfer. The diagram represents organisation and decomposition. An algorithm describes execution; additional interface descriptions explain information exchanged between components.

You should now be able to read a hierarchy, build one from a scenario, check its coverage and keep it distinct from a flowchart. The next lesson introduces flowchart symbols and control flow.