Course Toolkit

The Course Specifications at a Glance

Course Specifications pp.4–21 Every tool, notation and list NESA names, and where it turns up in the exam

Why the specifications are examinable

NESA states on page 4 that the specifications “indicate the depth of study required for some concepts” and that the syllabus “must be applied in conjunction with” them. In practice this means three things. First, the symbols are fixed: a data store is an open-ended rectangle, not a cylinder. Second, the lists are fixed: NESA names four SQL keywords, and those are the ones you are expected to know. Third, some depth is fixed: for machine learning you only need to know what it is used for, not how it works.

Where each tool sits, and what the 2025 HSC asked

The last column is our summary of NESA’s 2025 marking feedback. NESA’s own wording is on its 2025 HSC exam page ↗.

How each tool is laid out

Each section follows the same routine so you can revise quickly: what the tool is for, NESA’s notation, how to draw or use it step by step, a warning about common exam mistakes, an exam tip and a short “Try this” task with a model answer you can reveal after you have had a go. Symbol keys and worked examples are redrawn from NESA’s own; the extra examples (a school canteen, a games database) are ours.

Data Flow Diagrams (DFDs)

Course Specifications pp.4–5 Four symbols, the voting-system example and the Level 0 diagram

What it is for

A data flow diagram shows what data moves between the people and organisations outside a system, the processes inside it and the places data is kept. It does not show when things happen or how they are coded, which makes it the standard tool for agreeing requirements with a client. In NESA’s own Gantt chart example (p.12) “Produce a data flow diagram” is a task in requirements gathering.

NESA’s symbols (p.4)

Level 0 and Level 1 (p.5)

NESA describes a Level 0 diagram as an overview of the entire system that shows no data stores and no internal processes. The diagram above it on p.5, with three processes and two stores, shows the detail behind that overview. NESA does not name it, but the 2025 HSC called it a Level 1 diagram, so we do too.

How to draw one, step by step

We will build a diagram for an online ordering system in a school canteen. Students place an order and the canteen manager sets the menu and receives the order list.

1. List the external entities: everyone and everything outside the system that sends or receives data. Here: Student and Canteen manager.
2. Draw Level 0. Put one circle in the centre, name it for the whole system, place the entities around it and add a labelled flow for every piece of data that crosses the boundary.
3. Break the system into processes. Name each circle for a job the system does, with a verb: Manage menu, Take order, Prepare order list.
4. Add data stores wherever data has to be kept for a later process to use: Menu and Orders.
5. Connect and label every flow. Label each arrow with the data itself (Order request, not “send”).
6. Check the balance: every flow that crosses the boundary in Level 0 must appear, with the same label, in Level 1. Every process needs at least one flow in and one flow out.

Flowcharts

Course Specifications p.6 Four symbols, read top to bottom and left to right

What it is for

A flowchart represents logic: the steps a process follows and the decisions along the way. It is what you draw when you must show how a rule works, such as when a delivery charge applies, before writing the program or formula that carries it out.

NESA’s symbols (p.6)

NESA’s worked example

To trace a flowchart, put your finger on START and follow the arrows, answering each decision with test data. The table shows four tests on NESA’s example.

How to draw one, step by step

1. Write the rule in plain words and list every input the logic needs.
2. Draw a START terminator at the top, then an input for each value you need.
3. For each condition, draw a decision diamond with the question inside, using the same wording and symbols as the rule (“>10km?”).
4. Draw two exits from each diamond and label both (Yes and No). Follow each one to a process or another decision.
5. Bring separate paths back together where the logic joins, then finish with one END terminator.
6. Trace the chart with test data for every path, including the boundary values.

System Flowcharts

Course Specifications p.7 Nine symbols for the main processes and devices in a system

What it is for

A system flowchart shows the main processes and devices in a system: what is typed in, what is stored, what is displayed or printed and where data travels over a network. Where a flowchart shows the order of decisions, a system flowchart shows where the data goes. NESA says its arrows show “the direction of data between each of the symbols”.

NESA’s symbols (p.7)

NESA only names each symbol. The “typically stands for” column is our explanation.

NESA’s worked example

How to draw one, step by step

1. List the processes the system carries out, in the order the data reaches them.
2. For each process, list where its data comes from (online input, paper document, storage) and where its results go (storage, display, printout, cloud).
3. Choose the correct symbol for each device or store and write a short name inside it: what the data is, or what the process does.
4. Join symbols with arrows that point the way the data moves. Use a double-headed arrow when a process reads and writes the same store.
5. Insert the telecommunications link where data crosses a network, for example to reach a cloud service.
6. Check that every process has an input and an output and that every store is joined to a process.

Decision Trees

Course Specifications p.8 All the combinations of decisions and their resulting actions, in two layouts

What it is for

A decision tree lays out every possible combination of conditions and the action that results from each. NESA adds that each decision path leads either to another decision or to a final action. It is the tool for rules with several factors, such as the settings for a smart house or whether to buy a car.

NESA’s two forms (p.8)

How to draw one, step by step

1. List the conditions (inputs) and the actions (outputs) the rule involves.
2. Choose the first condition and make it the root. Each answer becomes a labelled branch.
3. From each branch, add the next condition that matters for that branch, or a final action if the answer is settled.
4. Make sure the branches from any one condition cover every possible value once: no gaps and no overlaps (for example >30, 15–30 and <15).
5. Trace at least one path to every final action to confirm the tree gives the outcome the rule requires.

Data Dictionary

Course Specifications p.9 A comprehensive description of each field in a database

What it is for

A data dictionary describes every field in a database in enough detail that a developer could build the table and a data-entry operator could fill it in correctly. NESA says it commonly includes six things, and its table has exactly these six columns: field name, data type, data format, field size, description and example.

NESA’s example (p.9)

NESA’s own examples count field size slightly differently: the pay rate counts every character including the dollar sign and point, while the height counts only the digits. Whichever you choose, apply it consistently and say what you counted.

How to build one, step by step

1. List each table, then every field in it. Use one row per field.
2. Choose the data type by how the field is used. Text for names and for numbers you will never calculate with (phone numbers, postcodes). Date, Currency, Real and Boolean, as in NESA’s table, for the rest. Whole numbers are usually called Integer.
3. Write the data format with X, N and #, or DD/MM/YYYY for dates, so the layout is unambiguous.
4. Set the field size to the longest value the field must hold.
5. Write a description that adds information, such as units or rules, rather than repeating the name.
6. Give a realistic example that matches the format.

If a question also asks for validation, add a column for it. It is not one of NESA’s six, so treat it as an extension, as in our canteen example below.

Storyboards

Course Specifications p.9 The screens of an interface and the links between them

What it is for

A storyboard shows the various interfaces (screens) of a product and the links between them. You draw one before building a website or app so that the client and the team can agree on what each screen contains and how a user moves around.

NESA’s notation (p.9)

How to draw one, step by step

1. List the screens the user needs and give each a title.
2. Draw each screen as a rectangle with the same layout: title, Help button, navigation column, content panel.
3. Sketch the content in each panel: headings, text lines, image boxes, tables. Detail is not needed; positions are.
4. Show the navigation. Highlight the current screen’s button and draw an arrow from every button to the screen it opens.
5. Number the screens and check every screen can be left: there must be a way back and an Exit.

Network Diagrams

Course Specifications p.10 Symbols for the devices (nodes) and how they are connected

What it is for

A network diagram, also called a network map, documents a network: the devices (nodes) and how they connect. It is what you would give a technician who has to set up, extend or fix the network.

NESA’s notation (p.10)

How to draw one, step by step

1. List every device on the network, including the connection to the internet.
2. Place the central device (usually the router) in the middle, and the internet above it.
3. Add the hubs or switches, then group the end devices around the one they connect through.
4. Draw a line for each connection. Use a different line style for wireless connections and add a small key if you use more than one line style.
5. Label every device with its type, and its name or purpose where that helps (for example “Printer – front office”).

Graph and Network Theory

Course Specifications p.11 Nodes and links, applied to the design of social networks

What it is for

Graph and network theory represents things and the relationships between them. NESA says it can be applied in the design of social networks: people and groups become circles, and their connections become lines. Drawing the network makes it easy to see who or what is central and which groups cluster together.

NESA’s notation (p.11)

Reading the graph: the number of links at a node shows how connected it is, a cluster is a group of nodes mostly linked to each other, and a node that joins two clusters is a bridge between them. NESA does not name these ideas, but they are how a graph is interpreted.

How to draw one, step by step

1. List the nodes: the individuals and the categories in the network.
2. Decide which links exist and what each relationship is called.
3. Place the most important node in the centre and draw it largest if size is used to show importance.
4. Draw straight lines between related nodes and write the relationship on each line.
5. Group related nodes near each other so clusters are visible.

Gantt Charts

Course Specifications p.12 Tasks on a dated timeline, with dependencies, milestones, resources and progress

What it is for

A Gantt chart displays each component task of a proposed system development on an estimated timeline. It answers: what has to be done, how long each task should take, which tasks depend on others, who is doing them and how far along they are. NESA says other formats are acceptable, so what matters is that the main elements are present.

The main elements (NESA example 1)

Resources and percentage completion (NESA example 2)

NESA’s second example allocates team members to tasks and shows the percentage complete of each. It also says the chart should be regularly updated during development to reflect actual versus estimated times.

How to build one, step by step

1. List the tasks the project needs, with names that explain themselves. Group them into phases if there are many.
2. Estimate a duration for each task in days or weeks.
3. Find the dependencies: which tasks cannot start until another finishes. Tasks with no dependency between them can run in parallel.
4. Draw the timeline with dates, then place each bar so it starts after the tasks it depends on. Add arrows for the dependencies.
5. Mark milestones: the points that matter, such as “Requirements approved” or “Testing complete”.
6. Allocate people to tasks and check nobody is double-booked at the same time.
7. Track and update: shade each bar to the percentage complete and revise the plan when actual times differ from the estimates.

One useful reading skill, though NESA does not name it: the longest chain of dependent tasks decides the earliest finish date. In example 1, tasks 1, 2, 5, 6 and 7 form that chain, so a delay to any of them delays the milestone.

Process Diaries and Log Books

Course Specifications p.13 Documenting the progress of a project at regular intervals

What it is for

A process diary (or log book) documents the progress of a project as it happens. Where a Gantt chart shows the plan, the diary records what was done, what went wrong and what you learned. It is also evidence of your own work when a project is marked.

What NESA says an entry should include (p.13)

Entries are made by team members at regular intervals and should include the following eight items.

How to keep one, step by step

1. Decide the interval (for example after every lesson or work session) and stick to it.
2. Write the entry as soon as you finish, while the detail is fresh.
3. Cover every item in the list, even briefly. If nothing went wrong, say so.
4. Record problems honestly: what happened, how you found it, what you did and whether it worked.
5. Read back over earlier entries when you plan the next one, so your reflections shape what you do.

System Implementation Methods

Course Specifications p.14 Recognise and understand: direct, parallel, pilot and phased

What it is for

Implementation is the step where a new or redesigned system replaces the old one, or is put into use for the first time. The method you choose decides how much risk you take, how much it costs and how long the changeover lasts.

The four methods

Choosing a method for a scenario

How to choose, step by step

1. Ask how critical the system is. If failure is costly or dangerous, lean towards parallel or pilot.
2. Ask how many users and locations are involved. Many sites suggest pilot or phased.
3. Ask whether the system splits into independent modules. If it does, phased is possible.
4. Weigh cost and time. Parallel is safest but most expensive, and direct is cheapest but riskiest.
5. Justify the choice with a reason drawn from the scenario, and name the disadvantage you are accepting.

Methods for Testing a System

Course Specifications p.15 Recognise and understand: functional, acceptance, live data, simulated data, beta and volume testing

What it is for

Testing checks that a system does what it should before people rely on it. Different methods find different kinds of problems, so a project normally uses several.

The six methods

Testing with simulated data: a worked example

Here is a functional test plan with simulated data for NESA’s delivery charge flowchart. The expected column is worked out from the rule before the test is run. The actual column is filled in during testing.

How to plan testing, step by step

1. List what the system must do (its functions) from the requirements.
2. For each function, choose test data: normal values, boundary values and invalid values.
3. Work out the expected result before testing, so you are checking the system rather than believing it.
4. Run the tests and record the actual result, then fix and retest anything that fails.
5. Move on to the client’s acceptance test, a beta release if the system will be used widely, and a volume test if it must handle a lot of data or users.

Relational Databases: Normalisation and Schemas

Course Specifications p.16 Minimising duplication with linked tables, and drawing the schema

Normalisation

NESA describes normalisation as a process in relational database design where data duplication is minimised by separating the database into a number of smaller, linked tables. Each table should include fields that are solely dependent on the primary key in that table. NESA gives the reason: if a database contains redundant data, the copies may not be updated consistently, which leads to a data integrity problem. NESA does not ask you to name normal forms such as 1NF, 2NF or 3NF.

The problem: one flat table

Suppose the games database began as one flat file. The publisher’s name and the developer’s name are typed again on every row.

“Games Inc” is stored four times and Mia Nguyen twice. If the publisher renames itself, four rows must be edited. If one is missed, the database now holds two versions of the same publisher, and a search for “Games Inc” misses some of its games. This is the data integrity problem NESA describes.

The fix: separate, linked tables

Move each repeating group into its own table, give each table a primary key and link the tables with a foreign key. Now “Games Inc” is stored once, and each game holds only the Publisher_ID that points to it.

NESA’s schema (p.16)

NESA says there are other acceptable ways to represent a schema, so a different notation (for example crow’s foot lines for the many end) is fine if it clearly shows the tables, the fields, the primary keys and the relationships.

The sample data we use for SQL

The queries in the next section run on this data. The tables follow NESA’s schema. The rows and the dates (day/month/year, as in NESA’s example) are ours.

How to normalise, step by step

1. Start with the flat table and look for values repeated across rows (a publisher, a customer, a supplier).
2. Move each repeating group into its own table, and give the new table a primary key.
3. Check that every other field in a table depends only on that table’s primary key. A game’s cost belongs in Games. A publisher’s name belongs in Publishers.
4. In the original table, replace the repeated details with a foreign key that holds the other table’s primary key value.
5. Draw the schema: tables, fields, (P) and (F) markers and a 1 and ∞ on each relationship line.

SQL Syntax

Course Specifications p.17 SELECT, FROM, WHERE and ORDER BY, applied to the games schema

What it is for

NESA describes Structured Query Language (SQL) as a language used to access and manipulate data in relational databases. For the HSC Enterprise Computing course, NESA lists exactly four pieces of standard syntax:

• SELECT (what is to be displayed)
• FROM (the tables to be used)
• WHERE (the search criteria which may come from multiple tables)
• ORDER BY (the sequence in which the results are displayed)

NESA’s own examples also use AND to combine criteria, the comparison operators =, >= and <=, ASC and DESC after ORDER BY, and the Table.Field form for naming a field. The database software specification (p.19) adds the logical operators AND, OR and NOT, which you can use in a WHERE clause.

The shape of a query

SELECT   the fields to display
FROM     the table or tables that hold them
WHERE    the criteria a record must meet          (optional)
ORDER BY the field to sort on, then ASC or DESC   (optional)

The clauses always come in this order. Text and dates go inside single quotes. Numbers do not. If two tables have a field with the same name (Name appears in Games and Publishers), write Table.Field so the database knows which you mean. ASC (A to Z, smallest first) is the default, and DESC reverses it.

All the results below were checked by running the queries on the sample data, with the dates compared as real dates.

Worked queries on the games schema

1. SELECT and FROM: display chosen fields

List the name and cost of every game. With no WHERE clause, every record is returned.

SELECT Name, Cost
FROM Games

Result (8 rows)

2. WHERE: choose which records

Only records that meet the criterion appear. Here, games that cost less than $15.

SELECT Name, Cost
FROM Games
WHERE Cost < 15

Result (3 rows)

3. WHERE with text

Text criteria go in quotes. Here, the developers whose last name is Patel.

SELECT First_name, Last_name
FROM Developers
WHERE Last_name = 'Patel'

Result (1 row)

4. ORDER BY: put results in order

Sort by cost with the most expensive first. DESC reverses the default ascending order.

SELECT Name, Cost
FROM Games
ORDER BY Cost DESC

Result (8 rows)

5. Sorting on more than one field

List games by publisher, and within each publisher alphabetically by game name. The first field decides the main order and the second breaks ties.

SELECT Publisher_ID, Name
FROM Games
ORDER BY Publisher_ID ASC, Name ASC

Result (8 rows)

6. NESA example 1: WHERE with AND, and ORDER BY

NESA’s first example displays the name and release date of all games released from 1 March 2022 to 31 March 2023, in alphabetical order by name.

SELECT Name, Release_date
FROM Games
WHERE Release_date >= '01/03/2022' AND Release_date <= '31/03/2023'
ORDER BY Name ASC

Result (6 rows)

The two conditions are joined with AND, so a game must satisfy both. Tidal Trader (September 2023) and Coral Code (January 2022) fall outside the range.

7. OR and brackets

Use OR when either condition is enough. Put brackets around the OR so it is worked out before the AND. Here, games from publisher 2 or 3 that cost less than $20.

SELECT Name, Cost
FROM Games
WHERE (Publisher_ID = 2 OR Publisher_ID = 3) AND Cost < 20

Result (3 rows)

Joining tables

Data about a game and its publisher are in different tables, so a query that shows both must join them. NESA’s method has two parts: list every table in FROM, separated by commas, then add a WHERE condition that makes the primary key equal the matching foreign key.

8. A join of two tables

Show each game with its publisher. The condition Games.Publisher_ID = Publishers.Publisher_ID pairs each game with only its own publisher. Both tables have a Name field, so each is written as Table.Field.

SELECT Games.Name, Publishers.Name
FROM Games, Publishers
WHERE Games.Publisher_ID = Publishers.Publisher_ID
ORDER BY Games.Name ASC

Result (8 rows)

9. NESA example 2: a join of three tables

NESA’s second example shows each developer’s name and the games they developed for the publisher “Games Inc”, in descending order of the developer’s last name. It needs two join conditions, one for each foreign key, plus the search criterion.

SELECT Developers.First_name, Developers.Last_name, Games.Name
FROM Games, Developers, Publishers
WHERE Publishers.Name = 'Games Inc'
AND Publishers.Publisher_ID = Games.Publisher_ID
AND Developers.Developer_ID = Games.Developer_ID
ORDER BY Developers.Last_name DESC

Result (4 rows)

The order is Walker, Patel, O’Brien, Nguyen: last names in reverse alphabetical order.

How to write a query, step by step

1. Underline what the question wants displayed. Those fields go after SELECT.
2. Find which tables hold those fields and any field named in the criteria. Those tables go after FROM.
3. If you need more than one table, add a WHERE condition for each link: the primary key of one table equals the foreign key of the other. You need one fewer join condition than tables.
4. Add the search criteria with AND (both must be true), OR (either) or NOT, using brackets when you mix them.
5. Add ORDER BY with the field and ASC or DESC.
6. Read the query back in words and check it against the question.

SELECT Games.Name, Publishers.Name
FROM Games JOIN Publishers ON Games.Publisher_ID = Publishers.Publisher_ID
ORDER BY Games.Name ASC

Exam-style practice

Use the games tables above. Write each query first, then check your answer.

SELECT Games.Name, Publishers.Name
FROM Games, Publishers
WHERE Games.Publisher_ID = Publishers.Publisher_ID
AND Games.Cost > 20
ORDER BY Games.Cost DESC

SELECT Developers.First_name, Developers.Last_name, Games.Name
FROM Games, Developers, Publishers
WHERE Publishers.Name = 'Southern Cross Games'
AND Publishers.Publisher_ID = Games.Publisher_ID
AND Developers.Developer_ID = Games.Developer_ID
ORDER BY Developers.Last_name ASC

SELECT Name, Cost
FROM Games
WHERE Cost >= 10 AND Cost <= 30
ORDER BY Name ASC

SELECT Name, Name
FROM Games, Publishers
WHERE Cost > 20
ORDER BY Cost

Machine Learning and Statistical Modelling

Course Specifications p.18 Know what they are used for; the underlying logic is not required

What NESA expects

NESA says that machine learning and statistical modelling can be used independently or together to analyse datasets and make predictions. Students are not required to understand the underlying logic of either, but should be aware of their use in real-world scenarios. So the exam tests whether you can recognise a suitable use and describe it, not whether you can calculate a model.

Both depend on the quality of the data they are given. Poor, biased or out-of-date data leads to poor predictions, which is why the ethical use of these tools is covered under Intelligent Systems and data quality under Data Science.

Database Software

Course Specifications p.19 What database software should allow you to do

What NESA lists

NESA says database software should allow you to do the following. The right-hand column is our explanation.

Operators, with the games table

NESA gives CONTAINS and DOES NOT CONTAIN as operators in the database software list but does not include them in its SQL syntax. In many products they are written as a pattern search, for example LIKE '%Run%'. Treat that spelling as an extension.

Spreadsheet Software

Course Specifications p.20 Formulas, functions, referencing, charts and the other features spreadsheet software should provide

Our worked spreadsheet

All the examples use a school canteen’s sales sheet. Column D holds revenue, which is price times quantity, and the loyalty table in J1:K5 gives a discount by points. The GST rate sits in its own cell, H1.

Entering formulas and copying them

A formula starts with =. NESA lists these skills: enter text, numeric values and formulas; copy cells using both absolute and relative referencing; and fill down and across.

The dollar signs lock a reference. $H$1 locks column and row, H$1 locks only the row and $H1 locks only the column. Without the dollar signs, the GST reference would slide to H2, H3… when copied, and the results would be wrong.

The functions NESA lists

Relational operators and IF

NESA lists the relational operators less than or equal to (<=), equal to (=), not equal to (<>), greater than (>) and greater than or equal to (>=). Less than (<) works the same way. They give TRUE or FALSE, which is what IF tests. IF can be nested to handle more than two outcomes, and it can be combined with the other functions:

Two things to remember about lookups. With FALSE as the last input, VLOOKUP needs an exact match and gives an error if there is none. With TRUE, the first column must be sorted in ascending order, and it returns the row for the largest value that is not more than the one you are looking up. That is why 120 points falls in the 100-point band.

The other features NESA lists

Choosing a chart (NESA lists five)

How to build a formula, step by step

1. Say in words what the cell must show, for example “total revenue after the loyalty discount”.
2. Choose the function or operator that does each part: SUM for the total, VLOOKUP for the discount, IF for any condition.
3. Decide which references must stay fixed when copied. Put dollar signs on those (an absolute reference) and leave the rest relative.
4. Type the formula, then check it on test data whose answer you already know.
5. Fill down or across, then spot-check the last row to confirm the references moved as intended.

Exam-style practice

Use the sales sheet above.

Expert System Software

Course Specifications p.20 Develop IF–THEN rules, change them, and display the rules used as text and as a decision tree

What NESA lists

Expert system software should allow you to develop a set of IF–THEN rules, add, remove and edit rules and display the rules the system has used to reach a conclusion, both in a text format and as a decision tree. An expert system stores the knowledge of a human specialist as rules and applies them to the facts a user provides, so a non-expert can get expert-style advice. The rules and the reasoning make it different from a database: it draws a conclusion, it does not just retrieve a record.

Rules, and the tree they make

Here are five IF–THEN rules for a laptop help-desk expert system:

When the user answers the questions, the system can show why it reached its conclusion. In text: “Power light on = Yes. Screen shows a picture = Yes. Wi-Fi connected = No. Rule R2 fired: restart the Wi-Fi adapter.” As a decision tree, it highlights the path that was followed.

How to build and maintain a rule set, step by step

1. Identify the decision the system must support and the questions the user can answer.
2. Write each rule as IF conditions THEN conclusion, with one rule for each possible outcome.
3. Check that every combination of answers fires exactly one rule: no gaps and no conflicts.
4. Test with real cases and compare the system’s advice with what an expert would say.
5. Edit as needed: add a rule for a new case, edit a rule whose advice is wrong and remove a rule that no longer applies. For example, add R6: IF the battery is swollen THEN stop using the laptop and take it to IT.

Graphics and Presentation Software

Course Specifications p.21 Bitmap and vector images, and the features of presentation software

Graphics software: what NESA lists

Presentation software: what NESA lists