Year 12 Digital Solutions External Exam Revision

• Revision topics
• Pseudocode and algorithm reasoning
• Cybersecurity and the CIA triad
• Security strategies and their appropriate uses
• Data-flow diagrams and exchange-system relationships
• User interfaces, useability and annotated mock-ups
• Cognitive verbs and constructing responses
• Reading criteria and interpreting unseen stimulus
• JSON and structured data
• Data dictionaries and specifications
• Australian Privacy Principles
• Data-exchange technologies
• Network performance
• Constraints, requirements and criteria
• Classical encryption algorithms
• Visual communication principles
• Emerging technologies
• SQL in a Unit 4 context
• Broader personal, social and economic impacts
• Exam clinics
• Pseudocode and desk checking
• Cybersecurity and the CIA triad
• Data-flow diagrams
• Practice exams
• 2024 Digital Solutions practice exam
• 2025 Digital Solutions practice exam

Revision topics

Pseudocode and algorithm reasoning

Inputs, processes and outputs

Most algorithms can be understood by identifying what data enters, what happens to it and what result is produced.

• Input: What data enters the algorithm?
• Process: What calculations, decisions or repetitions occur?
• Output: What must be displayed, stored or returned?

Identify the three parts

A roadside safety system receives a vehicle's speed from a sensor. It compares that speed with the road's speed limit. If the vehicle is travelling too quickly, the system displays a warning to the driver.

Copy and complete the following:

• Input: ...
• Process: ...
• Output: ...

Writing clear pseudocode

Pseudocode communicates the logic of an algorithm without requiring the exact syntax of a programming language. Its steps must still be ordered, consistent and unambiguous.

BEGIN
INPUT temperature
SET status = "safe"

IF temperature > 40 THEN SET status = "warning" ENDIF

OUTPUT status END

• Give variables names that reveal their job.
• Indent code so its structure is easy to see.
• Give totals, counters, lists and flags a starting value.
• Close structures with ENDIF, ENDFOR or ENDWHILE.
• Avoid syntax that belongs to one programming language, such as JavaScript, PHP or Python.

Selection and iteration

Selection chooses a path

IF condition THEN
    instructions
ELSE
    alternative instructions
ENDIF

Iteration does it again

FOR EACH item IN items DO
    process item
ENDFOR

WHILE condition DO repeat instructions ENDWHILE

Use FOR EACH when processing every item in a collection. Use WHILE when repetition depends on a condition.

Check for understanding

A registration form cannot predict how many times a user will enter an invalid password. It must keep requesting another password while the entered password contains fewer than 12 characters.

Analyse the situation. Choose either a FOR EACH loop or a WHILE loop, then explain why it suits this repetition.

INPUT password
WHILE LENGTH(password) < 12 DO
    OUTPUT "Password must contain at least 12 characters"
    INPUT password
ENDWHILE

Translate criteria into algorithm steps

Before writing pseudocode, break the problem into smaller jobs. Every criterion must be represented by one or more working steps in the algorithm.

Example criteria

• Read every sensor record.
• Identify readings above 80.
• Store the location of each high reading.
• Display the number of high readings.

Connect each criterion to a step

1. Input the collection of sensor records.
2. Initialise an empty list and a counter.
3. Iterate through every record.
4. Select records whose reading is above 80.
5. Store their locations and increment the counter.
6. Output the counter and stored locations.

Check for understanding

A review app stores a list of numerical ratings for each product. It must calculate the product's average rating. Some new products have an empty ratings list, so the algorithm must not attempt to divide by zero.

Analyse the requirement below before writing any pseudocode:

Display the average rating, or display “No ratings” when there are no reviews.

Write:

1. the three variables needed to total, count and average the ratings
2. the calculation used to find the average
3. the condition that decides whether the calculation is safe.

Lists and objects

A list is an ordered collection. An object groups related values under named keys. Digital solutions often store objects inside lists and lists inside objects.

stations = [
    {"name": "North", "readings": [24, 31, 29]},
    {"name": "South", "readings": [35, 38]}
]

• stations is a list.
• Each station is an object.
• station["name"] accesses a named value.
• station["readings"] accesses a nested list.

Accessing nested data

FOR EACH station IN stations DO
    SET total = 0

FOR EACH reading IN station["readings"] DO
    SET total = total + reading
ENDFOR

SET average = total / LENGTH(station["readings"])
OUTPUT station["name"], average

ENDFOR

The outer loop picks a station. The inner loop opens that station's readings and handles them one at a time.

Check for understanding

The current algorithm divides total by LENGTH(station["readings"]). Consider what happens when a station has no readings and the list length is zero.

Identify the error that could occur. Then recommend an IF statement that prevents it and displays No readings instead.

IF LENGTH(station["readings"]) > 0 THEN
    SET average = total / LENGTH(station["readings"])
    OUTPUT station["name"], average
ELSE
    OUTPUT station["name"], "No readings"
ENDIF

Modularisation and library functions

Modularisation divides a larger problem into smaller, focused jobs. Library functions provide existing operations that can be reused when their documented inputs, outputs and purpose match the problem.

SET congestion = CalculateCongestion(sensorReadings)
SET safestRoute = FindSafestRoute(start, destination, hazards)

Check a function's inputs, output and purpose. A function called FindSafestRoute will not send an alert unless its description explicitly says so.

Useful comments

# Criterion: warn the user about unavailable routes
IF safestRoute = NONE THEN
    OUTPUT "No safe route is available"
ENDIF

A useful comment explains intent or connects code to a criterion. A comment such as # Add one to count only repeats the instruction and adds little value.

Worked example: choosing suitable rooms

A venue needs to place a group in a suitable room. The algorithm must display every room big enough for the group, then count how many of those rooms are accessible.

BEGIN
INPUT rooms
INPUT groupSize
SET accessibleCount = 0

FOR EACH room IN rooms DO IF room["capacity"] >= groupSize THEN OUTPUT room["name"]

    IF room["accessible"] = TRUE THEN
        SET accessibleCount = accessibleCount + 1
    ENDIF
ENDIF

ENDFOR

OUTPUT "Accessible suitable rooms:", accessibleCount END

Check for understanding

The venue algorithm is tested with a group of 18 people and the following room data:

rooms = [
    {"name": "A1", "capacity": 20, "accessible": TRUE},
    {"name": "B2", "capacity": 12, "accessible": TRUE},
    {"name": "C3", "capacity": 30, "accessible": FALSE}
]

groupSize = 18

1. Explain why accessibleCount is initialised before the loop.
2. Explain why the accessibility selection is nested inside the capacity selection.
3. Determine every value displayed by the algorithm.

Desk checking an algorithm

A desk check traces an algorithm manually using supplied test data and a table. Record every variable change, decision and output in sequence rather than jumping directly to the expected result.

Independent practice: event check-in

A community event uses a check-in app. Staff need to see who has arrived and receive an alert when a checked-in attendee is under 18. Attendees who have not checked in must not be displayed or included in the count.

The app receives these attendee records:

attendees = [
    {"name": "Ari", "checkedIn": TRUE, "age": 17},
    {"name": "Mika", "checkedIn": FALSE, "age": 22},
    {"name": "Sam", "checkedIn": TRUE, "age": 31}
]

Available library function: SendAlert(message) sends a message to event staff.

Criteria

• Process every attendee.
• Display the name of each checked-in attendee.
• Count checked-in attendees who are under 18.
• If at least one checked-in attendee is under 18, use the library function to alert staff.
• Display the final under-18 count.

Develop and symbolise a complete algorithm in pseudocode. Add comments showing where each criterion is addressed. Then desk check the variables and output using the supplied data.

Expected output

Submit:

1. one complete pseudocode algorithm
2. one desk-check table showing the value of under18Count during every iteration
3. the names, alert and final count produced as output.

BEGIN
INPUT attendees
SET under18Count = 0

    # Criterion: count checked-in attendees under 18
    IF attendee["age"] < 18 THEN
        SET under18Count = under18Count + 1
    ENDIF
ENDIF

Cybersecurity and the CIA triad

Threats, vulnerabilities and risks

Cybersecurity protects digital systems, networks and data from harm. The harm may be deliberate, such as stealing records, or accidental, such as deleting a shared file. A power failure, faulty update or overloaded server can also create a security problem.

To investigate a scenario, separate three ideas:

• Threat: something that could cause harm, such as an attacker, fire or careless user.
• Vulnerability: a weakness that could be exploited, such as a shared password or missing backup.
• Risk: the possibility that a threat exploits a vulnerability and causes a consequence.

Spot the threat, weakness and risk

A club stores its membership database on one unprotected laptop. Match each item to threat, vulnerability or risk.

1. The laptop is stolen.
2. The laptop has no sign-in protection or encrypted storage.
3. An unauthorised person may read members' addresses.

Confidentiality, integrity and availability

In cybersecurity, the CIA triad identifies three properties that data and systems should preserve.

Classifying a compromise

• Who saw it? Think confidentiality.
• Who or what changed it? Think integrity.
• Could the right person use it at the right time? Think availability.

Check for understanding

Determine the main CIA property compromised in each incident.

1. A student changes another student's attendance record.
2. A flood damages the only server holding assessment files.
3. A spreadsheet containing home addresses is emailed to the wrong group.
4. A surge of traffic prevents customers from opening an online store.

Constructing a risk analysis

Writing “confidentiality risk” names a category but does not show the reasoning. Build a short chain that connects evidence to a consequence.

Because [scenario evidence], [threat or event] could [what happens to the data or service], which compromises [CIA property] because [consequence for an authorised user, person or organisation].

Worked example

A sports club lets every volunteer use the same administrator account to view and edit member records.

Too vague: There is an integrity risk.

Analysed: Because every volunteer shares an administrator account, a volunteer could alter a member's payment status without the change being reliably attributed. This compromises integrity because staff may act on an inaccurate account balance.

Apply the risk-analysis structure

A school canteen app stores allergy details and account balances. At a busy event, staff record purchases on paper and update the app several hours later.

Analyse the scenario to determine one risk to data integrity. Produce one complete risk statement that includes:

• specific evidence from the scenario
• what could happen to the data
• why the consequence is an integrity problem.

One incident can have several effects

The triad is a thinking tool, not three sealed boxes. One incident may compromise several properties, but each claim needs its own cause and consequence.

Imagine ransomware that encrypts a medical clinic's patient files and sends a copy to an attacker:

• Confidentiality: the attacker possesses private patient data.
• Integrity: records may have been altered and can no longer be trusted.
• Availability: clinicians cannot access records needed for care.

Identify each affected property

A malicious user deletes the only copy of a community centre's booking database after reading the contact details inside it. Analyse the incident and identify every CIA property directly compromised. Justify each choice with a different consequence.

Privacy and confidentiality are different

A confidential dataset can still create a privacy concern. For example, an organisation might securely restrict access to location data but collect far more of it than its service needs. No outsider saw the data, yet the collection may still be inappropriate.

Privacy, confidentiality or both?

For each scenario, identify whether the main issue is confidentiality, privacy, or both.

1. An employee posts a customer's private support message publicly.
2. A fitness app collects precise location every minute even when its route feature is turned off, but keeps the data securely restricted.
3. A clinic collects relevant health data for patient care, but an unauthorised contractor reads it.

Independent investigation: the late-night library

A public library launches an after-hours locker service. Members reserve items in an app, then enter a six-digit collection code at a locker terminal. Consider this system:

• The terminal displays the previous member's full name and borrowed titles until the next person enters a code.
• Staff sometimes mistype locker numbers when adding reservations manually.
• All locker terminals rely on one network connection. If it fails, no reserved item can be collected.
• Members need the service after the staffed library has closed.

On paper, analyse the scenario to determine one risk to each part of the CIA triad. For each risk, write:

1. the relevant scenario evidence
2. the event or data problem that could occur
3. the consequence that justifies your classification.

Security strategies and their appropriate uses

Start with the vulnerability

A security strategy is appropriate when it addresses a particular weakness or threat. Naming a powerful-sounding technology is not enough.

For example, if anyone can edit every record after signing in, stronger encryption does not fix the permission problem. Role-based access control does.

Choose the missing link

A sports centre encrypts bookings while they travel between its app and server. However, every staff account can change payment records.

Analyse the weakness. Is the most appropriate additional strategy encryption, a checksum or role-based access control? Justify your choice.

Authentication: prove who or what you are

Authentication verifies a claimed identity before access is granted. It may authenticate a person, device, application programming interface (API) or server.

Two-factor authentication (2FA) uses two different factor types. Multi-factor authentication (MFA) uses two or more. A password followed by a second password is two steps, but not two factors: both are something the user knows.

Verification codes and biometrics

A verification code from an authenticator app demonstrates possession of a registered device. A biometric comparison tests a physical or behavioural characteristic.

• Verification code: can be changed by re-registering the device, but the user needs access to it.
• Biometric: convenient and difficult to share casually, but false matches or rejections are possible and a biometric characteristic cannot be replaced like a password.

Check for understanding

Determine which sign-in process uses two different factors.

1. Password followed by a PIN.
2. Password followed by a code from an authenticator app.
3. Fingerprint followed by facial recognition.

Authorisation: control what an identity may do

Authentication asks, “Who are you?” Authorisation asks, “What are you allowed to access or change?” Authorisation occurs after identity is established.

Role-based access control (RBAC) assigns permissions to roles rather than granting every user the same access.

The principle of least privilege gives each identity only the access needed for its work. This limits both accidental damage and misuse of a compromised account.

Apply least privilege

A school event app has student, teacher and administrator roles. Students need to view events and save favourites. Teachers also publish notices. Only administrators approve new user accounts.

Recommend permissions for each role and justify why students should not receive administrator access.

Encryption: make intercepted data unreadable

Encryption transforms plaintext into ciphertext using an algorithm and key. An authorised recipient uses the required key to decrypt it.

• Data in transit: encrypt data as it travels between a device, server or service.
• Data at rest: encrypt stored files, databases, devices or backups.

Encryption primarily supports confidentiality. It is appropriate when an unauthorised party might intercept a transmission or access stolen storage.

Symmetric and asymmetric approaches

Real secure exchanges may combine both approaches: asymmetric techniques establish or protect a shared secret, then symmetric encryption efficiently protects the session data.

Check for understanding

A student sends assessment feedback through café Wi-Fi. Recommend a strategy for protecting the feedback while it is transmitted and explain its effect.

Hashing: create a one-way digest

A cryptographic hash function accepts input of any practical length and produces a fixed-length digest. A small input change should produce a very different digest.

• It is designed to be one-way: the original input is not decrypted from the digest.
• The same input produces the same digest with the same algorithm.
• Comparing digests can reveal that data has changed.

For password verification, a system stores a salted password hash rather than a decryptable password. At sign-in, it hashes the entered password with the stored salt and compares the result with the stored digest.

Hashing and integrity

A sender can calculate a digest before transfer and the receiver can recalculate it afterwards. Different digests show that the data changed. However, a plain hash alone does not prove who created the data: an attacker who can replace both file and digest could make them match.

Select encryption or hashing

For each purpose, determine whether encryption or hashing is more appropriate.

1. A clinic must recover and display a patient's stored notes.
2. An app must check an entered password without storing the password itself.
3. A recipient must detect whether a downloaded file differs from the expected file.

Checksums: detect transmission errors

A checksum is a value calculated from a block of data. The receiver recalculates it and compares the values. A mismatch indicates that the data was altered or corrupted during storage or transmission.

Checksums are useful for detecting accidental errors, such as a damaged packet. They do not hide the data and a simple checksum is not reliable protection against a malicious attacker who can alter both the data and checksum.

Layer strategies instead of searching for one fix

One strategy rarely addresses every risk. Defence in depth combines controls so that one failure does not expose the whole system.

For a payment exchange:

• server authentication helps the app recognise the intended server
• encryption protects payment details in transit
• MFA makes a stolen password less useful
• role-based access control restricts which staff can view refunds
• hashing supports password verification and change detection
• monitoring and audit logs help identify suspicious actions.

Match controls to weaknesses

A community health portal has these weaknesses:

1. Patients can sign in using only a reused password.
2. Appointment details cross an untrusted network as readable text.
3. Receptionists can open clinicians' private case notes even though their work does not require it.
4. A transmitted booking sometimes arrives with digits missing.

For each weakness, recommend the most directly relevant strategy from MFA, encryption in transit, role-based access control or checksum. Justify each match.

Write a justified recommendation

A strong recommendation names the specific strategy, connects it to scenario evidence and explains the protective mechanism.

Recommend [specific strategy] because [evidence identifies the vulnerability]. It [explain the mechanism], which reduces [event or consequence] and protects [CIA property]. [Relevant limitation or supporting control].

Worked example

A tutoring app uses one shared staff login. Tutors need to view session times, but only the coordinator should change invoices.

Too vague: Use better security so hackers cannot enter.

Justified: Use individual accounts with role-based access control because the shared login gives every tutor the same permissions and actions cannot be reliably attributed. Give tutors read access to session times and reserve invoice changes for the coordinator. This reduces unauthorised or accidental changes and protects invoice integrity. MFA could additionally reduce account takeover, but it would not replace permission controls.

Independent practice: festival wallet

A school festival uses a mobile wallet. Students add funds before the event and scan a code at stalls. The proposed system has these characteristics:

• The app sends student identifiers and payment amounts to the server over the venue's shared wireless network.
• An account uses only an email address and password.
• Volunteers and finance staff have identical access to balances, refunds and personal details.
• The database currently stores each user's password as readable text.
• Occasional network faults corrupt a transaction packet before it reaches the server.

On paper, analyse the system and recommend four security strategies. For each recommendation:

1. quote or paraphrase the relevant evidence
2. name a specific strategy
3. explain how it works in this context
4. justify the CIA property it helps protect.

At least one response must address authentication, one must address authorisation and one must secure data transmission.

Data-flow diagrams and exchange-system relationships

What a data-flow diagram shows

A data-flow diagram (DFD) represents where data comes from, how a system transforms it, where it is stored and where it goes. It focuses on logical data relationships rather than screen layout, program-control order or network hardware.

A DFD can contain physical objects and manual storage as well as digital data. For example, a library process may receive a book identifier, update a digital record and release a physical book from a shelf.

DFD or flowchart?

Determine which representation best suits each purpose.

1. Show the decisions and repetition in an account-login algorithm.
2. Show how login credentials move from a user to a verification process and user store.

The four Gane–Sarson elements

QCAA Digital Solutions uses Gane–Sarson notation. Copy the shapes accurately enough that their different functions are unambiguous.

Classify each system component

A canteen ordering system includes a student, a process that calculates the order total, a collection of menu records and the order details sent into that process.

Recognise each DFD element and give it a suitable label.

Name and number elements precisely

Good labels allow a reader to understand the system without guessing.

• Use nouns for entities, flows and stores: Customer, payment details, Orders.
• Use verbs or verb–object names for processes: Validate payment, Record order.
• Number processes: 1.0 Validate request, 2.0 Record booking.
• Number and type stores: D1 Accounts, M1 Paper forms, T1 Session cache.

Repair the labels

A draft DFD uses Member for an entity, Bookings for a process, Save for a data store and data for a flow containing a requested date and room identifier.

Analyse the labels and rewrite the three unsuitable ones.

Connections must pass through a process

A process is the active element that transforms, validates, records or retrieves data. Therefore an external entity cannot exchange data directly with another external entity or a data store.

Use a separate arrow for each direction. A request and reply are different flows and should be labelled separately.

Find three convention errors

A draft diagram shows a Customer entity sending details directly to D1 Orders. The store sends stuff directly to a Kitchen entity. A process between them is named Order.

Analyse the draft and describe three corrections.

Worked example: equipment loans

A student submits a student ID and equipment ID. The system checks the equipment record, stores an approved loan and returns either a collection notice or an unavailable notice.

Trace the worked example

Do not merely list connected shapes. Explain what moves, in which direction, and what each process does with it.

1. The Student sends a student ID and equipment ID to 1.0 Check availability.
2. The process sends the equipment ID to D1 Equipment and receives the equipment status.
3. If unavailable, the process returns an unavailable notice to the Student.
4. If available, approved loan details flow to 2.0 Record loan.
5. The second process writes a loan record to D2 Loans and sends a collection notice to the Student.

Explain a relationship

Explain the relationship between the Student entity and D2 Loans. Include any process between them.

Explain relationships, not just arrows

An explanation should connect evidence from the complete path.

[Source] sends [named data] to [process]. The process [transformation] using [data read from a store, if relevant], then sends or stores [named output] in [destination].

If the diagram mixes manual, physical and digital flows, state that distinction. A paper consent form can be an M store; a physical item can flow from a manual store through a delivery process; a digital identifier can trigger that action.

Build the explanation

A volunteer sends a ticket code to 1.0 Validate ticket. The process reads valid-code data from D1 Tickets and returns an entry decision to the volunteer.

Explain the relationship between the Volunteer and D1 Tickets in two or three sentences.

Data flow within and between systems

A digital solution may contain a front end, back end and database while also exchanging data with external services.

• Front end: collects input and presents output through the user interface.
• Back end: validates requests, applies rules and coordinates data exchange.
• Database: retains structured data.
• External service: another system outside the area of study, such as a weather or payment service.

Whether something is an external entity depends on the chosen system boundary. If the diagram studies a booking app, a payment service may be external. If it studies the payment provider itself, that provider contains processes and stores.

From scenario to DFD plan

A beach-safety app receives a location from a Beachgoer. Its back end sends the location to an external Weather service, receives current conditions, combines them with alert rules from a database and returns a safety message.

Before drawing, extract the elements:

• Entities: Beachgoer; Weather service
• Process: 1.0 Generate safety message
• Store: D1 Alert rules
• Flows: location, conditions request, current conditions, alert rules, safety message

Notice that conditions request and current conditions are separate arrows because they travel in opposite directions.

Check for understanding

Symbolise this scenario as a DFD on paper. Then check that every entity and store connects only through the process.

Develop a DFD systematically

1. Set the system boundary: decide what is inside the area of study.
2. Underline external sources and destinations.
3. Circle transformations described by verbs.
4. Identify retained, manual and temporary stores.
5. List the actual data entering and leaving each process.
6. Draw and number processes and stores.
7. Add one labelled arrow for each direction.
8. Trace every path and test the conventions.

Final convention check

• Does every process have at least one meaningful input and output?
• Does every arrow have a noun label and a clear direction?
• Do all entity and store flows pass through a process?
• Are processes named with verbs and numbered?
• Are stores numbered and correctly identified as D, M or T?
• Does the diagram show the scenario without inventing unsupported data?

Independent practice: community garden lockers

A community garden lends tools through secure lockers. A Member enters a membership code and tool ID at a terminal. The system must:

• check the membership code against retained member records
• check whether the requested tool is listed as available
• when both checks pass, record the loan and send an unlock instruction to the external Locker controller
• return a collection message or rejection reason to the Member
• store loans on disk so they remain after the terminal is turned off.

Use these required components:

• external entities: Member and Locker controller
• processes: Validate request and Record loan
• data stores: Members, Tools and Loans.

On paper, develop a complete Gane–Sarson DFD. Number all processes and stores, identify each store type, and label every flow with the data it carries. Then explain the relationship between the Member and Loans store.

User interfaces, useability and annotated mock-ups

User interface and user experience

A user interface (UI) is the point where a person interacts with a digital solution: screens, controls, labels, messages, sound and other inputs or outputs. User experience (UX) is the broader experience produced while using the solution, including how understandable, efficient, useful and reassuring it feels.

A visually polished screen may still provide poor UX if a user cannot find the required function, understand a label, correct an error or operate a control.

Interface or experience?

A bus app contains a search field and a Find route button. A commuter completes the route search quickly and feels confident that the result is current.

Recognise the UI elements and the UX evidence.

The five useability principles

Useability describes how well users can interact with a solution. QCAA identifies five principles.

Classify the main principle

Analyse each situation and identify the main useability principle affected.

1. A booking form has pale grey text on a white background.
2. A user can permanently delete all records with one accidental tap.
3. A route app has no way to request wheelchair-accessible travel.
4. A first-time user cannot tell whether a magnifying-glass icon searches or zooms.
5. A worker must convert coordinates in another app before locating each job.

Accessibility: remove barriers

Accessibility considers the range of people and technologies that may interact with a solution. A user might navigate with a keyboard, use a screen reader, magnify content, have reduced colour perception, experience limited dexterity or need plain language.

• Use clear text labels, not icons alone when meaning could be ambiguous.
• Provide meaningful alternatives for non-text content.
• Use sufficient contrast and readable text sizes.
• Do not communicate status using colour alone; add text or a symbol.
• Make controls operable without requiring precise pointer movement.
• Use a logical reading and focus order.

Accessibility is not a special mode added at the end. It should shape the interface and its programmed behaviour from the beginning.

Improve an inaccessible status

A task list shows overdue work only by changing its title from black to red. Recommend one refinement and Justify how it improves accessibility.

Effectiveness and utility

These principles are related but answer different questions.

• Utility: Is the required tool or feature available?
• Effectiveness: Does the interface let the user achieve the intended result accurately and successfully?

A maintenance app might have a search feature, satisfying some utility. If it searches only meaningless file names while workers know street names, the feature is ineffective in context.

Separate the principles

A canteen app must allow students to identify meals containing allergens. It displays a list of meal names but provides no allergen information or filtering.

1. Explain the utility problem.
2. Explain how adding allergen labels and a filter could improve effectiveness.

Safety and error recovery

A safe interface reduces the chance and consequence of harmful user error. The design should help before, during and after an action.

Design safe feedback

A volunteer records a medication delivery. The current form clears immediately after Save, even if the network request fails.

Recommend two UI refinements that protect safety and Justify each one.

Learnability and consistent interaction

Learnability improves when the interface makes actions predictable and reduces what users must remember.

• Use familiar controls for familiar actions.
• Keep navigation, terminology and control placement consistent.
• Prefer descriptive labels such as Save booking over vague labels such as Go.
• Show current status and provide immediate feedback.
• Reveal complexity when needed instead of crowding the first view.

A new user should be able to infer the next action from the interface. Instructions can support a design, but they should not compensate for unclear controls.

Check for understanding

A three-screen form places Next in the bottom right on screens one and two, but labels the same action Continue now in the top left on screen three.

Evaluate this choice using learnability and recommend a refinement.

Evaluate from evidence

A complete evaluation moves from observed evidence to a supported judgment.

Evidence: [specific interface feature or omission]. Effect: [what happens when a particular user completes a task]. Principle and judgment: therefore the interface has [strong/weak] [useability principle]. Refinement: [specific feasible change] would [expected improvement].

Worked example

A field-work app lists jobs only by internal file name and latitude/longitude. Workers know jobs by street address and often work where mobile data is unreliable.

Too vague: The app is ineffective and should have a better layout.

Evaluated: The list provides file names and coordinates rather than the street information workers use, forcing them to translate each location through another service. This causes delay and may fail without connectivity, so the interface is ineffective for locating jobs. Display a cached street address and allow searching or filtering by suburb and status so workers can find the correct job directly.

Evaluate two principles

A sports-centre kiosk asks users to enter a booking code. Its only instruction is a small placeholder reading code. After submission the screen does not change for ten seconds, and repeated taps create duplicate check-ins.

Evaluate the interface using two useability principles. For each, identify evidence, explain the effect and recommend a refinement.

Low-fidelity mock-ups

A low-fidelity mock-up communicates layout, controls, content and interaction without requiring production styling. It should be quick to draw and easy to revise.

A useful mock-up shows:

• the screen boundary and a clear screen name
• the information users need at that point
• inputs, outputs, navigation and feedback
• important states, such as loading, validation error or success
• annotations that connect features to users, criteria and programmed behaviour.

Worked annotated mock-up

A student needs to report a broken drinking fountain. The criteria require a location, a short description, an optional photo and clear submission feedback.

Connect the mock-up to programmed behaviour

The drawn control is only the visible part of a feature. Explain what data enters, what programmed action occurs and what output returns.

An annotation such as “button saves data” is incomplete. Identify the data, validation, result and feedback that fulfil the criterion.

Design from criteria and user context

Translate every criterion into visible interface evidence or programmed behaviour.

User characteristics also change the design. An outdoor worker wearing gloves may need larger controls and offline information. A young child may need concise language, images with text, audio support and immediate feedback. Do not rely on stereotypes: use characteristics provided by the scenario.

Independent practice: after-school activity check-in

A school needs a tablet interface for staff checking students into after-school activities. The tablet is used outdoors, sometimes with glare and unreliable internet. Relief staff may be using it for the first time.

Criteria

• Search for a student by name or student ID.
• Show the student's selected activity and emergency-contact status.
• Record one of three states: present, collected or absent.
• Prevent collected being recorded without confirmation.
• Make unsynchronised records clearly visible without using colour alone.
• Allow failed records to be retried when connectivity returns.

On paper, Symbolise one low-fidelity tablet screen that addresses every criterion. Add at least six numbered annotations. Each annotation must explain:

1. the interface element
2. its programmed behaviour or information
3. the criterion or useability principle it supports.

Then Evaluate your mock-up against two different useability principles and Recommend one refinement.

Cognitive verbs and constructing responses

The verb tells you what thinking to show

A cognitive verb is not an instruction about response length. It identifies the kind of thinking the response must make visible.

Same topic, different demand

Consider a booking system that stores passwords as readable text.

1. Recognise the main confidentiality vulnerability.
2. Explain how the vulnerability could affect users.
3. Recommend and Justify a suitable refinement.

Read the whole instruction

Questions often combine a cognitive verb with a quantity, content focus, source and response form.

Evaluate the interface to identify two useability principles that may cause errors. Justify each response using evidence from the scenario.

Turn that instruction into a checklist before writing:

• two different principles
• a judgment about each principle
• specific interface evidence for each
• an explanation of how each feature causes an error for the user.

Completing only the first verb leaves the reasoning unfinished. “Safety and effectiveness” identifies two principles but does not evaluate or justify them.

Decompose the instruction

Analyse the following instruction and write a four-item response checklist.

Recommend one new system feature and one new hardware component that improve pedestrian safety. Justify both recommendations.

Use evidence, not invented assumptions

Scenario evidence is the bridge between knowledge and a response. Select a detail, interpret its significance and connect it to the requested concept.

A useful chain is:

Because [specific evidence], [event or mechanism] could [result], which means [consequence connected to the requested concept].

Worked example

A maintenance app lists jobs using random video file names and geographic coordinates. Workers recognise jobs by street name and report delays finding the correct record.

Weak: The app has poor effectiveness because it is confusing.

Evidence-based: Because the list uses file names and coordinates rather than the street names workers recognise, they must translate each location before selecting a record. This delays successful job identification, so the interface has poor effectiveness for the stated task.

Relevant inference or invention?

A community app runs on one server and must remain accessible during an emergency.

Determine which statement is supported by the scenario.

1. The server will definitely fail because it is ten years old.
2. A failure of the only server could make the app unavailable when residents need it.
3. The developer forgot to install antivirus software.

Explain by connecting cause and effect

An explanation reveals a relationship. It usually needs more than a description of separate facts.

Words such as because, therefore, so and which causes can make reasoning visible, but the logic matters more than the connector.

Upgrade a description

The statement “A checksum is recalculated after transmission” describes an action. Explain how a checksum supports data integrity during transmission.

Justify a choice in context

A justification proves why a conclusion or recommendation is suitable. It should connect:

1. the scenario need, vulnerability or criterion
2. the specific choice
3. how the choice works
4. the resulting benefit, risk reduction or trade-off.

Worked comparison

A school app gives students, visitors and administrators identical access to personal records.

Recommendation only: Use role-based access control.

Recommendation with justification: Use role-based access control because the three user groups require different functions. Restrict visitors to public information, students to their own records and administrators to authorised management tasks. This applies least privilege and reduces unauthorised disclosure or alteration of personal data.

Choose and justify

A clinic must send patient results across an untrusted network. Staff need to read the original results at the destination.

Recommend either encryption or hashing as the main protection for the transmitted content, then Justify your choice and explain why the other option is insufficient by itself.

Evaluate against a criterion

Evaluation requires a judgment, not merely a list of strengths and weaknesses. Name or infer the relevant criterion, test the evidence against it and reach a conclusion.

Criterion: what good performance means. Evidence: what the stimulus or result shows. Judgment: the extent to which the criterion is met. Refinement: a change that addresses the identified gap, when requested.

Worked evaluation

Criterion: A booking search should return the correct room within two seconds.

Evidence: Test 1 returned the correct room in 1.2 seconds. Test 2 returned the correct room in 3.8 seconds when 200 bookings existed.

Evaluation: The search is accurate in both tests but only partially meets the criterion because its response exceeds two seconds with the larger dataset. Indexing the searched database field should be investigated and the same large-data test repeated.

Make the judgment explicit

A mobile interface must allow outdoor workers to find a job without internet access. A test shows that previously opened jobs remain available offline, but unopened jobs display a blank screen.

Evaluate the interface against the criterion and Recommend a refinement.

Recommend a feasible refinement

A recommendation should address the diagnosed problem. “Make it more secure” or “improve the interface” does not say what must change.

Feasible does not mean perfect or unlimited. Consider the scenario's time, data, users, hardware, connectivity and existing components.

Symbolise in the requested form

Some responses communicate through conventions rather than prose. The verb and the named form both matter.

• DFD: use Gane–Sarson entities, numbered processes and stores, labelled directional flows, and valid connections.
• Pseudocode: use ordered, unambiguous logic with meaningful names and complete control structures.
• Annotated mock-up: show interface elements and explain their purpose, behaviour and connection to criteria.
• Data dictionary or specification: use the requested fields, types, formats, constraints and examples consistently.

Choose the response form

Match each demand to the main response form.

1. Symbolise data movement between a customer, payment process and orders store.
2. Develop an algorithm that totals valid sensor readings.
3. Symbolise and Explain interface features for reporting an error.

Plan, write and check

Before writing

1. Box the cognitive verb or verbs.
2. Underline the quantity, topic and scenario limits.
3. Circle the requested response form or convention.
4. List the evidence and make a checklist for compound demands.

While writing

1. Lead with the requested conclusion, feature or judgment.
2. Use precise subject terminology.
3. Connect evidence to a mechanism and consequence.
4. Keep each part traceable to the instruction.

Before finishing

1. Tick every demand, quantity and required source.
2. Remove repetition that adds no reasoning.
3. Check diagram, pseudocode or table conventions.
4. Confirm that pronouns such as it have an unambiguous meaning.

Independent practice: event-alert system

A community event app sends severe-weather alerts. Consider this evidence:

• Alerts are displayed only as red text at the bottom of the home screen.
• Every volunteer uses one shared administrator account.
• Weather data is updated every 30 minutes.
• The criterion states that a severe warning must be visible and announced within five minutes of receipt.
• In a test, a warning arrived from the weather service at 14:02 and appeared in the app at 14:28. No sound or notification was produced.

On paper, complete all three responses.

1. Evaluate the alert interface against accessibility and the timing criterion. Use evidence to support both judgments.
2. Determine one confidentiality or integrity risk created by the account design and Justify your conclusion.
3. Recommend two specific refinements: one for the alert interface and one for account access. Justify each recommendation.

Reading criteria and interpreting unseen stimulus

Unseen does not mean unknowable

Unseen stimulus gives you a new context, not a new subject. Your job is to connect supplied evidence with familiar Digital Solutions concepts.

Expect useful information to be distributed across a scenario, criteria list, diagram, table, interface, pseudocode or data sample. A relationship may only become clear when two sources are combined.

Fact or assumption?

A locker app uses a six-digit code and depends on one network connection. Determine which statement is directly supported.

1. The code is encrypted with AES.
2. A network failure could prevent code verification.
3. Every user has a weak password.

Classify what you read

A test result only becomes meaningful when compared with a criterion. Eighteen minutes is neither good nor bad until the required time is known.

Sort a short stimulus

A school has six weeks to create a web app using its existing server. The app must return matching resources within two seconds. A test with 1000 records takes 3.4 seconds.

Recognise one time constraint, one technical constraint, one criterion and one test result.

Turn criteria into observable checks

A useful criterion states the expected behaviour, relevant condition and observable result. Vague goals such as “easy to use” are difficult to test.

Make it testable

The requirement says, “The interface must clearly show offline records.” Interpret this as one observable criterion.

Read across sources

Use a reference map when evidence is spread across formats.

1. Identify the named component in the question.
2. Find it in each relevant source.
3. Trace identifiers, labels and flows that connect the sources.
4. Record only facts that help answer the question.

For example, a mock-up may show a Save report button, pseudocode may show the validation it triggers, and a data dictionary may reveal which fields are required. Together they explain the complete feature.

Combine three sources

A mock-up contains a required room list and Submit button. A data specification states room_id: INTEGER, required. Pseudocode checks that room_id exists before saving.

Explain how the three components work together.

Annotate with a purpose

On paper, use a small set of consistent marks rather than highlighting everything.

• Box cognitive verbs and requested quantities.
• Underline criteria and constraints.
• Circle named entities, processes, fields or functions.
• Use short margin labels such as C for confidentiality or EV for evaluation evidence.
• Draw a line between matching identifiers across sources.

Annotations should reduce rereading. If every sentence receives the same mark, no information has been prioritised.

Build an evidence table

A useful scratch table can keep reasoning aligned:

Resolve apparent contradictions

Two pieces of stimulus may describe different states or conditions rather than truly conflict.

• A requirement describes the intended result; a test result describes actual behaviour.
• A DFD shows logical movement; a network diagram shows physical connections.
• A mock-up shows a proposed interface; a screenshot may show the current interface.
• A general rule may be narrowed by a scenario-specific constraint.

State the distinction explicitly. For example: “The criterion requires five minutes, but the observed 18-minute result shows the current implementation does not meet it.”

Independent practice: library collection lockers

Read this unfamiliar system description.

• Members reserve books in a mobile app and collect them after hours.
• The app displays a six-digit collection code.
• A locker terminal requires a continuous network connection to verify the code.
• The criterion states that an authorised member can open the correct locker within 20 seconds.
• Test A: a valid code opens the correct locker in 12 seconds.
• Test B: during a network interruption, the terminal displays a spinning icon for 90 seconds and does not open.
• The terminal keeps the previous member's name and book title visible until another code is entered.
• Staff manually copy locker numbers from a spreadsheet into the reservation system.

On paper:

1. Recognise one functional requirement, one criterion and two pieces of test evidence.
2. Evaluate the system against the 20-second criterion.
3. Determine one confidentiality, one integrity and one availability risk. Support each with different evidence.
4. Explain why the two test results do not contradict each other.

JSON and structured data

Structured data has an organised shape

Structured data follows a predictable organisation so programs can locate, filter and transform values. JSON (JavaScript Object Notation) is a text format commonly used to exchange data between systems and applications.

{
  "event_id": 42,
  "name": "Robotics showcase",
  "cancelled": false,
  "tags": ["technology", "community"]
}

Objects, arrays, keys and values

Read the structure

{
  "station": "North",
  "readings": [18, 21, 19],
  "active": true
}

Recognise the object, its three keys, the array and each value's type.

JSON value types

• String: text inside double quotes, e.g. "open".
• Number: an integer or decimal without quotes, e.g. 27 or 3.5.
• Boolean: lowercase true or false.
• Null: lowercase null, meaning no value is supplied.
• Object: nested named values inside braces.
• Array: an ordered collection inside square brackets.

A quoted number such as "27" is a string. Its appearance does not change its type.

Choose suitable types

Determine a suitable JSON type for an attendee name, ticket price, checked-in state, optional accessibility note and list of session IDs.

Valid JSON syntax

• Keys and string values use double quotes.
• A colon separates a key from its value.
• A comma separates pairs or array items, but no comma follows the final item.
• Braces and brackets must be balanced and correctly nested.
• Comments and undefined are not part of standard JSON.

Repair malformed JSON

{
  event_id: 7,
  "title": 'Night market',
  "open": True,
  "stalls": [12, 15,],
}

Analyse the data and rewrite it as valid JSON.

{
  "event_id": 7,
  "title": "Night market",
  "open": true,
  "stalls": [12, 15]
}

Nested objects and arrays

{
  "venue": {
    "name": "River Hall",
    "address": {"suburb": "West End", "postcode": "4101"}
  },
  "sessions": [
    {"session_id": 1, "places": 0},
    {"session_id": 2, "places": 8}
  ]
}

Read a path one container at a time. The postcode path is venue → address → postcode. The second session's places path is sessions → item 2 → places.

Trace the paths

Determine the suburb, the first session ID and the number of places in the second session.

Collections of records

An API response often wraps an array of consistently shaped objects.

{
  "results": [
    {"id": 101, "suburb": "Nundah", "status": "open"},
    {"id": 102, "suburb": "Nundah", "status": "closed"},
    {"id": 103, "suburb": "Milton", "status": "open"}
  ],
  "result_count": 3
}

Consistency matters. The same concept should normally use the same key name and compatible type in every record.

Filter the records

Develop language-independent pseudocode that outputs the ID of each open Nundah record.

FOR EACH record IN data["results"] DO
    IF record["suburb"] = "Nundah" AND record["status"] = "open" THEN
        OUTPUT record["id"]
    ENDIF
ENDFOR

Parse, validate, transform and serialise

1. Receive: obtain JSON text from a file, message or API.
2. Parse: convert the text into an internal object or collection.
3. Validate: check required keys, types, formats and allowed values.
4. Transform: filter, calculate, rename, group or combine data.
5. Serialise: convert internal data back into JSON text for exchange.

Valid syntax does not guarantee valid data. {"places": -9} is syntactically valid but may break a rule that places cannot be negative.

Validate before use

A booking requires booking_id as a positive integer, email as a non-empty string and confirmed as a Boolean.

{"booking_id": "24", "email": "", "confirmed": "false"}

Analyse the record against the rules.

Design data for exchange

Choose keys that are meaningful, consistent and unambiguous. Avoid mixing display labels with stable identifiers.

• Use student_id to identify a student reliably, even if their displayed name changes.
• Choose one naming convention, such as snake_case, and apply it consistently.
• Represent repeated items as an array rather than numbered keys such as item1 and item2.
• Do not include sensitive fields unless the receiver needs them.
• Document units and date formats in the data specification.

Explain a design choice

Explain why an array is more suitable than the keys tag1, tag2 and tag3 for storing an unknown number of tags.

Independent practice: community workshops

{
  "generated_at": "2026-08-05T09:30:00+10:00",
  "workshops": [
    {
      "workshop_id": 11,
      "title": "Bike repair",
      "venue": {"name": "Shed A", "accessible": true},
      "capacity": 16,
      "booked": 16,
      "tags": ["practical", "transport"]
    },
    {
      "workshop_id": 12,
      "title": "Native gardens",
      "venue": {"name": "Courtyard", "accessible": false},
      "capacity": 20,
      "booked": 13,
      "tags": ["outdoors"]
    }
  ]
}

1. Describe the outer structure and the structure of one workshop.
2. Determine the path to the second workshop's accessibility value.
3. Develop pseudocode that outputs the titles of accessible workshops with at least one place remaining.
4. Explain why workshop_id should be retained when sending a selected workshop back to the server.

Data dictionaries and specifications

A shared description of data

A data dictionary or specification documents what each data item means and how it must be represented. It helps user interfaces, algorithms, databases and exchanged messages agree.

Choose data types by meaning and use

Choose types

Determine suitable types for student_name, attendee_count, paid, start_time and phone_number.

Names should reveal meaning

• Use one concept per field: first_name and family_name if they must be processed separately.
• Include units when otherwise ambiguous: duration_minutes.
• Use consistent conventions: do not mix eventID, event_id and EventId.
• Use stable identifiers: venue_id should not be replaced by a changeable venue name.
• Avoid vague fields such as data, value or type without context.

Improve the names

A sensor table contains id, value, time and ok. The value is temperature in degrees Celsius, and ok records whether calibration is valid.

Recommend clearer field names.

Constraints and validation rules

A constraint limits stored values. Validation checks input against those rules.

• Required: a value must be supplied.
• Range: a number or date lies within stated limits.
• Length: text has an allowed size.
• Format: data follows an agreed pattern.
• Allowed values: a value belongs to an enumerated set.
• Uniqueness: no other record uses the same value.
• Referential: a foreign identifier matches an existing related record.

Validation checks plausibility and rule compliance; it does not prove truth. A correctly formatted but mistyped email may pass validation.

Validation and verification

Validation tests data against rules. Verification checks that data was transferred or entered as intended, such as comparing an entry with its source.

A date picker can validate that a booking is not in the past. A confirmation screen can help the user verify that the selected venue and date match their intention.

Classify each check

1. An email must contain a non-empty local part and domain.
2. A staff member compares a scanned consent form with the entered record.
3. A password is entered twice and the values must match.

Keys and relationships

A primary key uniquely identifies a record in its table. A foreign key stores the primary-key value of a related record.

VENUE(venue_id, venue_name, suburb)
BOOKING(booking_id, venue_id, booking_date, attendee_count)

VENUE.venue_id identifies a venue. BOOKING.venue_id links each booking to an existing venue without repeating the venue's name and suburb in every booking.

Explain the relationship

Explain why venue_id is preferable to storing only venue_name in BOOKING.

Specifications across a solution

The same rule should remain compatible across UI, JSON, algorithms and database storage.

Evaluate fitness for purpose

A specification is useful only if it stores the data required to answer questions and perform processes.

A dataset has region, licence_type, valid_licence and registration_date. It must track how one licence changes between active, suspended and expired over time.

Evaluate the specification and Recommend a refinement.

Independent practice: equipment loans

Design a data dictionary for a school equipment-loan record. The system must identify the loan, link it to an existing student and item, record checkout and optional return times, store item condition as good, damaged or missing, and record whether staff have checked the return.

Determine a field name, data type, required state, constraint and example for each item. Then Justify the types used for the student identifier and checked state.

Australian Privacy Principles

Privacy principles govern a data lifecycle

The Privacy Act 1988 includes 13 Australian Privacy Principles (APPs). They govern standards, rights and obligations for handling personal information by organisations and agencies covered by the Act, called APP entities.

This page supports Digital Solutions analysis, not legal advice. The Office of the Australian Information Commissioner provides the current official guidance.

What counts as personal information?

Personal information is information or an opinion about an identified individual, or an individual who is reasonably identifiable. Context matters: several ordinary data points may identify someone when combined.

• Name, address, account ID and identifiable photo may be personal information.
• Location history or device data may become personal information when linked to a person.
• Sensitive information includes particular higher-risk categories and generally receives stronger protection.
• De-identified data has identifying information removed or altered so individuals are no longer reasonably identifiable; removing only names may be insufficient.

Personal, sensitive or de-identified?

Analyse these examples.

1. A named student's allergy record.
2. A public count of 318 visits with no individual records.
3. A dataset without names that contains exact birth date, postcode and rare medical condition.

The 13 APPs at a glance

APPs 1 and 2: plan and be transparent

APP 1 concerns open and transparent management, including an up-to-date privacy policy and practices for handling inquiries or complaints. APP 2 concerns giving individuals the option of anonymity or a pseudonym where practicable, subject to limited exceptions.

A public event timetable may not need a user's identity just to show session times. A personalised ticket purchase may require information to complete the transaction.

Is identity necessary?

A council feedback form requires full name, date of birth and a verified account before a person can suggest a new park bench location.

Determine the most relevant APP concern and Explain why.

APPs 3, 4 and 5: collect carefully

• APP 3: concerns when solicited personal information may be collected, with higher standards for sensitive information.
• APP 4: concerns personal information received without being requested and whether it could have been collected; information may need to be destroyed or de-identified where lawful and reasonable.
• APP 5: concerns taking reasonable steps to notify people about collection matters, such as who is collecting, purpose and likely disclosures.

Analyse collection

A workshop booking needs a name and contact method. The form also requires annual income, precise live location and a medical history without explaining why.

Analyse the collection using APPs 3 and 5.

APPs 6 to 9: control use and disclosure

• APP 6: limits use or disclosure for another purpose unless an exception applies, such as consent or a related expected purpose in relevant circumstances.
• APP 7: sets conditions around direct marketing and mechanisms to stop receiving it.
• APP 8: concerns reasonable steps before disclosing personal information overseas and possible accountability for handling by the recipient.
• APP 9: limits adopting, using or disclosing government-related identifiers as an organisation's own identifier.

Purpose is central. Information collected to deliver a service should not silently become unrestricted material for an unrelated purpose.

Primary and secondary purposes

A sports app collects an email to send booking confirmations. It later supplies emails and exercise histories to an unrelated advertiser.

Determine the primary and secondary purposes and the main APP concern.

APPs 10 and 11: quality and security

APP 10 concerns reasonable steps to ensure personal information is accurate, up to date, complete and relevant for its use or disclosure. APP 11 concerns reasonable steps to protect information from misuse, interference, loss and unauthorised access, modification or disclosure.

APP 11 also includes considering destruction or de-identification when personal information is no longer needed, subject to exceptions such as legal retention requirements.

APPs 12 and 13: access and correction

APP 12 concerns an individual's access to personal information held about them. APP 13 concerns reasonable steps to correct information that is inaccurate, out of date, incomplete, irrelevant or misleading for the purpose for which it is held.

Access does not mean every person can browse all records. It concerns an individual accessing information about themselves through an appropriate process, subject to applicable grounds and procedures.

Design for rights

A membership app displays a wrong date of birth but has no correction request or privacy contact.

Recommend a refinement and Justify it using APP 13.

Construct an APP analysis

Evidence: what information is handled and what happens to it. Principle: the most relevant APP and its focus. Consequence: why the handling matters to the person. Refinement: a specific change that addresses the issue.

Independent practice: youth activity platform

A community organisation's platform:

• requires exact birth date and home address to view a public activity timetable
• shows a brief notice saying only “We collect data”
• uses booking emails to advertise an unrelated paid service
• lets every volunteer download participant contact and health details
• retains cancelled-account data without a documented reason or review date
• provides no way for a participant to view or correct their information.

Analyse four different issues. For each, identify the evidence, relevant APP, possible consequence and a specific refinement.

Data-exchange technologies

One exchange uses several layers

A mobile app does not reach into another system's database. It communicates through an agreed interface.

• API: a defined interface through which software requests data or actions.
• REST: an architectural approach that treats data and capabilities as resources addressed by identifiers such as URLs.
• HTTP: an application-layer protocol that carries web requests and responses.
• JSON or XML: formats that structure data inside a message.

Request and response

GET /api/events/42 HTTP/1.1
Host: example.org
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"event_id": 42, "title": "Repair café", "places": 6}

The client identifies a resource and acceptable representation. The server processes the request and returns a status, metadata headers and optional body.

Trace the exchange

Recognise the method, resource identifier, requested format, response status and body type.

HTTP methods communicate intent

The server defines the actual API contract. A method name alone does not grant permission or guarantee a particular implementation.

Choose a method

Determine a suitable method for retrieving all venues, creating a booking and changing only its status.

Status codes describe outcomes

• 2xx: request succeeded, e.g. 200 OK or 201 Created.
• 4xx: the request cannot be completed as sent, e.g. 400 Bad Request, 401 Unauthorised, 403 Forbidden or 404 Not Found.
• 5xx: the server failed while handling an apparently valid request, e.g. 500 Internal Server Error or 503 Service Unavailable.

Handle more than success

A robust client checks the response before using the body.

SET response = SendRequest(request)

IF response.status = 200 THEN SET data = ParseJSON(response.body) DisplayEvents(data) ELSE IF response.status = 401 THEN OUTPUT "Sign in again" ELSE IF response.status = 503 THEN OUTPUT "Service unavailable. Try again later." ELSE OUTPUT "Request could not be completed" ENDIF

Parsing a missing or error body as if it contains valid event data can create a second error.

JSON and XML represent structured data

{
  "sensor_id": 7,
  "reading": 18.4
}

<sensor>
  <sensor_id>7</sensor_id>
  <reading>18.4</reading>
</sensor>

• JSON uses objects, arrays, keys and values and maps naturally to common application data structures.
• XML uses nested elements and attributes, supports namespaces and can be validated against a schema.
• Either can represent the example. Suitability depends on the systems, contract, tooling, validation and interoperability requirements.

Neither format encrypts data. Secure transport and access controls are separate concerns.

Compare formats

A partner's established system accepts only XML validated against its published schema. Recommend JSON or XML and Explain the decisive evidence.

REST resources and representations

A resource is a conceptual item such as an event or booking. A URL identifies it; a representation such as JSON describes its current data.

GET /events                 # collection
GET /events/42              # one event
GET /events?suburb=Milton   # filtered collection
POST /events/42/bookings    # create a related booking

Good resource paths normally use nouns. The HTTP method communicates the action.

REST exchanges are usually stateless: each request includes the information needed to process it. The server may store resources, but it should not rely on hidden conversational state from an earlier request.

APIs need a contract

Documentation should specify:

• endpoints and supported methods
• authentication and permissions
• required headers, parameters and body fields
• data types, formats and allowed values
• response bodies and status codes
• rate limits, pagination and versioning where relevant.

A client and server can both produce valid JSON yet fail to interoperate if one sends eventDate and the other requires event_date.

Analyse a failed exchange

The contract requires POST /reports with {"location_id": INTEGER, "description": STRING}. A client sends:

POST /report
{"location": "Oval", "description": 42}

Analyse three incompatibilities.

Secure and reliable exchange

• Use encrypted, authenticated transport such as HTTPS for sensitive exchanges.
• Authenticate the caller and check authorisation for every protected operation.
• Validate all external data before processing.
• Return useful but non-sensitive error information.
• Use timeouts, controlled retries and duplicate protection.
• Log relevant outcomes without unnecessarily recording secrets or personal data.

Retrying a create request blindly can produce duplicates. An idempotency key or server-side duplicate check can let a repeated request be recognised safely.

Independent practice: repair reports API

A mobile app sends repair reports to a council API. The contract uses JSON and includes:

POST /reports
Authorization: Bearer [token]
Content-Type: application/json

{ "location_id": 18, "category": "water_leak", "description": "Tap will not turn off" }

Possible responses are 201 with the created report, 400 with field errors, 401 when the token is invalid and 503 during an outage.

1. Explain the role of the API, HTTP, JSON and authentication token.
2. Determine how the app should respond to each status.
3. Evaluate the exchange if it uses HTTP rather than HTTPS on public Wi-Fi.
4. Recommend one strategy that reduces duplicate reports after a timeout.

Network performance

Performance is more than speed

Match the evidence

Determine the main issue in each case.

1. A 100 Mbps link transfers at 42 Mbps.
2. Video-call packets arrive at irregular intervals.
3. A button response takes 600 ms even though the message is tiny.
4. Some voice packets never arrive.

Calculate transfer time carefully

Use compatible units and distinguish bits from bytes.

transfer time (seconds) = data size (bits) / throughput (bits per second)

A 20 megabyte file contains approximately 160 megabits. At an actual throughput of 40 megabits per second, the idealised transfer time is:

160 Mb / 40 Mb/s = 4 seconds

Real transfers may take longer because of protocol overhead, changing conditions, competing traffic and retransmissions.

Calculate a transfer

A 75 MB video transfers at 30 Mbps. Determine the idealised time.

Packet switching

Packet switching divides data into packets that can travel through a shared network. Each packet carries control information used to deliver and reassemble the data.

1. The sender divides and labels the data.
2. Network devices forward packets towards the destination.
3. Packets may take different routes or arrive out of order.
4. The receiver checks and reassembles them.
5. Missing or damaged data may be recovered according to the protocol.

Sharing links improves network use, but variable routes and congestion can change delay and loss.

Routing and forwarding

• Routing determines paths and maintains information about how networks can be reached.
• Forwarding is the local action of moving an arriving packet to the appropriate outgoing interface.

A route may change when a link fails or another path becomes preferable. More hops do not automatically prove poor performance; link quality, distance, load and processing also matter.

Explain the relationship

Explain how routing and forwarding work together.

Congestion and flow control

Congestion occurs when offered traffic exceeds the capacity of network resources. Queues grow, latency rises and buffers may discard packets.

Congestion control adjusts sending behaviour in response to network conditions. Flow control prevents a sender from overwhelming the receiving endpoint's ability to process data.

Read a performance pattern

Analyse the likely change at 12:30.

Error detection and correction

Transmission systems use error-control processes to detect corrupted or missing data and respond appropriately.

• A checksum or other integrity check can reveal changed data.
• Sequence information can reveal missing or reordered segments.
• Acknowledgments confirm receipt.
• Retransmission replaces missing or damaged data.
• Some systems use forward error correction to recover certain errors without retransmission.

Retransmission supports reliability but consumes capacity and adds delay. Real-time media may prefer a small gap over waiting for a late packet.

TCP, UDP and application needs

Applications may add their own reliability or security. “UDP is always faster” is too broad; suitability depends on implementation and purpose.

Quality of service

Quality of service (QoS) mechanisms classify and manage traffic so important flows receive appropriate treatment during contention.

• Prioritise delay-sensitive voice over a background software download.
• Reserve or shape traffic to protect essential services.
• Manage queues to reduce delay and loss for selected classes.

QoS manages limited capacity; it does not create unlimited bandwidth. Prioritising one class may delay another, so priorities must reflect actual requirements.

Choose a priority

A hospital link carries a live remote consultation and a scheduled archive backup. Recommend a QoS priority and Explain the trade-off.

Evaluate with application criteria

Use the required task to judge measurements.

Independent practice: community event network

A temporary event network supports payment terminals, a live stream and overnight photo uploads. At peak time, measurements show 95% link utilisation, latency rising from 28 ms to 420 ms, 4% packet loss and highly variable video delay. Payments sometimes time out.

1. Analyse the evidence to identify the likely performance condition.
2. Explain how it affects payments and live video differently.
3. Recommend two refinements, including one QoS decision.
4. Evaluate the claim: “The only solution is to increase bandwidth.”

Constraints, requirements and criteria

Four different jobs

Functional and non-functional requirements

• Functional requirements state what the solution does: inputs, processes, outputs, data exchange and user actions.
• Non-functional requirements state how well or under what quality conditions it operates: useability, security, performance, reliability, compatibility and maintainability.

“The user can submit a report” is functional. “A valid report is confirmed within two seconds” adds performance and feedback quality.

Classify requirements

1. Store an equipment loan.
2. Only authorised staff can issue refunds.
3. Return search results within two seconds.
4. Display all bookings for a selected date.

Find constraints in the context

Constraints can concern time, cost, technology, compatibility, data, people, law, environment or scope.

A constraint is not automatically a flaw. It becomes useful analysis when its effect on design, risk or testing is explained.

Explain an impact

A mobile app must use the school's existing server, which has limited storage. Explain one consequence for an image-reporting feature.

Write strong criteria

A strong criterion is specific enough to test and relevant to the user and requirement.

Under [condition], [user or system] can [observable behaviour] with [measurable or clearly judgeable result].

Avoid false precision

Numbers are helpful when they come from the context or a reasoned target. Do not invent “99.99% accurate” merely to sound measurable. Some qualities are tested through observable tasks and evidence rather than arbitrary percentages.

A useful set of criteria covers normal, boundary and error conditions. For a capacity rule, test one below capacity, exactly at capacity and one above it.

Refine a criterion

The requirement is “Users must recover from an accidental cancellation.” Determine a testable criterion.

Build a traceability table

Traceability reveals orphan features that address no need, requirements with no implementation and criteria that test the wrong behaviour.

Resolve competing requirements

Requirements may trade off rather than fit perfectly together.

• Detailed data may improve personalisation but increase privacy risk.
• Immediate synchronization improves freshness but may fail with unreliable connectivity.
• High-resolution media improves detail but increases storage and transfer time.
• Frequent confirmation can reduce some errors but interrupt routine work.

Use the scenario's priorities and consequences to justify a balance. Do not declare one quality universally more important.

Analyse a trade-off

A field app needs recognisable damage photos but must operate on slow connections and limited storage. Recommend a balanced requirement.

Evaluate with test evidence

State whether each criterion is met, partially met or not met, using actual results.

Independent practice: emergency relief hub

A temporary relief hub needs a tablet app to record supply requests. Internet access is intermittent; existing tablets have limited storage; volunteers change each shift; and medical notes must be visible only to authorised health staff.

The app must record a request, show its status, work during short outages and synchronise safely later.

1. Recognise three constraints and Explain one design effect of each.
2. Determine four functional and three non-functional requirements.
3. Write one observable criterion for offline operation, access control, synchronisation integrity and useability.
4. Justify how each criterion traces to a requirement.

Classical encryption algorithms

A shared numerical model

Use the mapping A = 0, B = 1, ..., Z = 25. Addition encrypts; subtraction decrypts. Modulo 26 wraps results into the alphabet.

encrypted = (plaintext + shift) MOD 26
plaintext = (encrypted - shift + 26) MOD 26

For a shift of 5, X = 23 encrypts to (23 + 5) MOD 26 = 2, which is C.

Modulo practice

Determine the encrypted letters for A, M and Z using shift 4.

Caesar cipher

A Caesar cipher applies one fixed shift to every plaintext letter.

The ciphertext is FRGH.

Decrypt

Determine the plaintext for KHOOR with Caesar shift 3.

Evaluate Caesar security

There are only 25 useful non-zero shifts. An attacker can try them all quickly. The same plaintext letter always becomes the same ciphertext letter, so language patterns and letter frequency remain visible.

Vigenère cipher

Vigenère repeats a keyword. Each key letter supplies a different shift using A = 0.

CATCH with key DOG becomes FOZFV.

Encrypt with Vigenère

Use key KEY to encrypt DATA. Determine the repeated key and ciphertext.

Evaluate repeated-key security

Vigenère hides simple single-letter frequency better than Caesar because the same plaintext letter can encrypt differently at different key positions. However, a repeated keyword creates a period. With enough ciphertext, attackers can investigate repetition, infer key length and apply frequency analysis by position.

A longer keyword increases possibilities, but a predictable word and repeated use remain weaknesses.

Gronsfeld cipher

Gronsfeld uses a repeating sequence of decimal digits as shifts. It works like a Vigenère cipher whose shifts are limited to 0–9.

With repeating key 204, MAPS becomes OATU.

Gronsfeld varies shifts but uses only ten possible shift values and repeats the digit key, so it remains vulnerable to period and frequency analysis.

One-time pad

A one-time pad uses a key that is:

• truly random
• at least as long as the plaintext
• kept secret
• used once only.

Encryption can still use modular addition, but the key does not repeat. Under the required conditions, the ciphertext does not reveal a unique plaintext because every same-length plaintext has a possible key.

Why reuse fails

Two messages use the same pad. Explain the resulting weakness.

Compare the algorithms

Develop an encryption algorithm

BEGIN
INPUT plaintext
INPUT shifts
SET ciphertext = ""
SET keyIndex = 0

FOR EACH character IN plaintext DO IF character IS A LETTER THEN SET plainNumber = LetterToNumber(UPPERCASE(character)) SET shift = shifts[keyIndex MOD LENGTH(shifts)] SET cipherNumber = (plainNumber + shift) MOD 26 SET ciphertext = ciphertext + NumberToLetter(cipherNumber) SET keyIndex = keyIndex + 1 ELSE SET ciphertext = ciphertext + character ENDIF ENDFOR

OUTPUT ciphertext END

One design choice is whether spaces and punctuation advance the key. State and apply the choice consistently. The example advances only for letters.

Desk check the algorithm

Use plaintext AZ! and shifts [2, 4].

The output is CD!.

Independent practice: compare keys

Use plaintext NETWORK.

1. Encrypt it with Caesar shift 4.
2. Encrypt it with Vigenère key LINK.
3. Encrypt it with Gronsfeld key 314.
4. Analyse the repeated patterns and Evaluate relative resistance to simple brute force and frequency analysis.

Visual communication principles

Elements are materials; principles organise them

Visual elements are the building materials visible in a composition. Principles describe how those elements are arranged to communicate.

Visual elements

• Space: occupied and empty areas; separates groups and reduces crowding.
• Line: divides, connects or guides attention.
• Colour: can distinguish state, category or emphasis when used accessibly.
• Shape: creates controls, containers and recognisable symbols.
• Texture: suggests surface or variation; usually restrained in interfaces.
• Tone: relative lightness and darkness.
• Form: appearance of three-dimensional volume.
• Proportion: size relationship between parts.
• Scale: size relative to a reference, screen or user context.

Not every interface needs every element to be visually obvious. Use them to communicate, not to fill space.

Recognise the element

A form uses blank space between address and payment sections, a thin rule beneath the heading and a much larger title. Identify the main element in each decision.

Balance

Balance distributes visual weight so a composition feels stable. Symmetrical balance mirrors weight; asymmetrical balance uses different elements with comparable visual influence.

A large chart on the left may be balanced by a grouped summary and controls on the right. Balance does not require identical halves.

Contrast

Contrast creates a noticeable difference using colour, tone, shape, size, weight or space. It helps users distinguish content and action.

• Dark text on a light background supports readability.
• A larger, heavier heading distinguishes it from body text.
• A primary action can stand out from secondary actions.
• A warning can combine text, symbol and visual emphasis.

Colour contrast supports accessibility, but visual communication should not rely on colour alone.

Explain the effect

A dashboard displays every label, heading and button at the same size and weight. Explain how contrast could improve it.

Proximity and alignment

Proximity places related items closer together and separates unrelated groups. Alignment places elements along shared edges or axes to create order.

A field label should sit closer to its own input than the previous input. Form fields aligned to a consistent edge are easier to scan.

Diagnose grouping

A validation message appears halfway between two fields, and buttons use unrelated left edges. Analyse the visual communication problems.

Repetition and harmony

Repetition reuses visual patterns such as typography, icon style, spacing and component appearance. Harmony is the coherent overall relationship among elements.

• Repeated card structure lets users learn where each value appears.
• Consistent button styles communicate similar behaviour.
• A compatible type and colour system creates a unified experience.

Repetition supports learnability, but identical styling should not be applied to actions with different importance or risk.

Hierarchy

Hierarchy communicates order and importance. It can be produced through scale, position, contrast, spacing and grouping.

1. Screen purpose or urgent state
2. Section headings and primary task
3. Supporting content and secondary actions
4. Metadata and low-priority detail

Hierarchy should reflect user goals, not the organisation's desire to promote every feature.

Rank the content

An emergency-alert screen contains the warning type, affected location, time, safety action, app logo and settings link. Determine a useful hierarchy.

Principles work together

A section heading may use larger scale and darker tone for contrast, align with its fields, repeat a type style used elsewhere and sit close to related controls. Together these choices create hierarchy and harmony.

Evaluate with a cause-and-effect chain

The interface uses [element evidence] to create or weaken [principle]. This [effect on perception or grouping], helping or hindering [specific user task].

Weak: The colours have harmony and look professional.

Stronger: The interface repeats one restrained colour palette and icon style across all booking cards, creating harmony and making components feel related. A contrasting status label still distinguishes cancellations without disrupting the overall system.

Independent practice: repair dashboard

A repair dashboard has these features:

• all text, including headings, uses the same size and weight
• status is indicated only by red, amber or green text
• each card places its address in a different position
• large empty gaps appear inside cards, but unrelated cards touch
• the Delete button is larger than Update status
• icons come from several unrelated visual styles.

1. Analyse four visual communication problems using four different principles.
2. Recommend one specific refinement for each.
3. Justify each refinement using a worker's task.

Emerging technologies

A family of related ideas

• Artificial intelligence (AI): broad field of systems performing tasks associated with intelligent behaviour.
• Machine learning (ML): methods that learn patterns from data to make predictions or decisions rather than relying only on hand-written rules.
• Neural network: an ML model made from connected layers of weighted processing units.
• Deep learning: ML using neural networks with multiple processing layers to learn complex representations.
• Natural language processing (NLP): methods for analysing, generating or interacting through human language; these may use rules, statistical ML or deep learning.
• Reinforcement learning: an agent learns a policy by interacting with an environment and receiving rewards or penalties.

Classify a description

A system learns to label road images using thousands of examples and a multi-layer neural network. Recognise the most specific terms that apply.

Supervised and unsupervised learning

These labels describe how learning occurs, not whether a system is accurate, fair or safe.

Training and inference

1. Define the task: specify input, desired output and success criteria.
2. Collect and prepare data: clean, label, encode and split records appropriately.
3. Train: adjust model parameters to reduce error on training examples.
4. Validate: tune decisions using separate evidence.
5. Test: estimate performance on unseen examples.
6. Infer: apply the trained model to new input.
7. Monitor: detect changing data, failures and unequal outcomes.

Training or inference?

A model adjusts weights using labelled pothole images, then later assigns a severity category to a new image. Determine which event is training and which is inference.

Data shapes model behaviour

A model learns statistical patterns present in its data. Problems include:

• missing or incorrect labels
• under-representation of relevant conditions or groups
• historical decisions that encode unfairness
• features that indirectly reveal protected or sensitive information
• training data that differs from real operating conditions
• data drift as behaviour or environments change.

“More data” is not automatically better. Relevance, quality, coverage, lawful handling and representativeness matter.

Analyse dataset coverage

A road-damage model is trained only on clear daytime photos from one city. It will be used across Queensland at night, in rain and on unsealed roads.

Analyse the risk and Recommend a refinement.

Neural networks and deep learning

A neural network combines inputs through weighted connections and transformations. Training changes weights to reduce a defined error. Hidden layers can learn intermediate representations useful for the output.

• Input layer receives encoded features.
• Hidden layers transform combinations of values.
• Output layer produces scores, categories or numerical predictions.

Deep networks can model complex image, audio and language patterns but may require substantial data and computation. Their internal reasoning can be difficult to explain, which matters in high-consequence decisions.

Natural language processing

NLP systems process language tasks such as classification, search, translation, summarisation, speech interaction and response generation.

Language is ambiguous and context-dependent. A support classifier may misread slang, negation, multilingual text or an uncommon request.

Design for uncertainty

Recommend one interface response when a chatbot has low confidence in the user's intent.

Reinforcement learning

An agent observes a state, chooses an action, receives a reward and updates its policy to increase expected future reward.

state → policy chooses action → environment changes → reward → learning

The reward function matters. A traffic agent rewarded only for vehicle throughput might create long pedestrian waits. Simulation, safety constraints and evaluation of unintended strategies are essential.

Evaluate more than accuracy

• Performance: appropriate accuracy, error rates, latency and reliability.
• Fairness: outcomes and errors across relevant groups and conditions.
• Privacy: collection, consent, inference, retention and disclosure of personal data.
• Transparency: users understand when automation is used and what it can affect.
• Accountability: responsibility, review, logging and challenge processes exist.
• Safety: failures are detected, limited and recoverable.
• Security: training data, model, interface and output are protected.
• Environmental and economic cost: computation, infrastructure and ongoing monitoring are justified.

An overall accuracy can hide unequal error types. In a hazard detector, a missed hazard and a false alarm have different consequences.

Use a confusion matrix

Explain why false negatives may deserve special attention in a pedestrian-hazard detector.

Human oversight

Human involvement should be designed, not added as a slogan.

• Show the relevant input, output and uncertainty to the reviewer.
• Give reviewers time and authority to disagree.
• Record overrides and outcomes for monitoring.
• Provide a path for affected people to question or correct data.
• Do not overload one person with more alerts than can be meaningfully reviewed.

Independent practice: event safety classifier

An organisation proposes an NLP system that classifies incoming event messages as routine, urgent or emergency. Historical labels were created by one team; messages in languages other than English are rare in the training set; emergency messages are only 1% of examples; and an emergency classification automatically locks venue gates.

1. Analyse four risks in the data, output or automated action.
2. Evaluate whether overall accuracy alone is a suitable criterion.
3. Recommend three controls covering testing, interface design and human oversight.

SQL in a Unit 4 context

SQL behind a data exchange

A client might send JSON to an API, but the back end may validate the request and use SQL to read or update a relational database.

mobile app → HTTPS/JSON → API validation → parameterised SQL → database
mobile app ← JSON response ← result transformation ← SQL result

Use a small relational schema

VENUE(
    venue_id PRIMARY KEY,
    venue_name,
    suburb,
    accessible
)

EVENT( event_id PRIMARY KEY, venue_id FOREIGN KEY REFERENCES VENUE(venue_id), title, event_date, capacity, status )

BOOKING( booking_id PRIMARY KEY, event_id FOREIGN KEY REFERENCES EVENT(event_id), attendee_email, places, booking_status )

Keys connect records without repeating all venue and event data in every booking.

Trace a relationship

Explain how a BOOKING record is connected to a VENUE.

SELECT, WHERE and ORDER BY

SELECT event_id, title, event_date
FROM EVENT
WHERE status = 'open'
  AND event_date >= '2026-08-05'
ORDER BY event_date ASC, title ASC;

• SELECT chooses columns.
• FROM identifies the table.
• WHERE filters rows before grouping.
• ORDER BY sorts the result; ASC is ascending and DESC descending.

Text and date literals use quotes. Numeric and Boolean syntax depends on the database system and schema.

Write a query

Develop a query that returns the title and capacity of cancelled events, largest capacity first.

SELECT title, capacity
FROM EVENT
WHERE status = 'cancelled'
ORDER BY capacity DESC;

Conditions and IN

SELECT event_id, title
FROM EVENT
WHERE status IN ('open', 'full')
  AND capacity >= 20;

IN tests membership of a set. Combine conditions with AND, OR and parentheses so the intended logic is unambiguous.

Aggregate functions and GROUP BY

Aggregate functions summarise rows: COUNT, MIN, MAX, AVG and SUM.

SELECT event_id, SUM(places) AS booked_places
FROM BOOKING
WHERE booking_status = 'confirmed'
GROUP BY event_id;

Each output row represents one event group. Non-aggregated selected columns normally need to appear in GROUP BY.

Count by status

Develop a query that counts bookings for each booking_status.

SELECT booking_status, COUNT(*) AS booking_count
FROM BOOKING
GROUP BY booking_status
ORDER BY booking_status;

WHERE and HAVING do different jobs

• WHERE filters individual rows before groups are formed.
• HAVING filters groups after aggregation.

SELECT event_id, SUM(places) AS booked_places
FROM BOOKING
WHERE booking_status = 'confirmed'
GROUP BY event_id
HAVING SUM(places) >= 20;

The WHERE clause excludes non-confirmed rows. HAVING keeps only event groups whose confirmed places total at least 20.

INNER JOIN related tables

SELECT EVENT.title, VENUE.venue_name, VENUE.suburb
FROM EVENT
INNER JOIN VENUE
    ON EVENT.venue_id = VENUE.venue_id
WHERE EVENT.status = 'open'
ORDER BY EVENT.title;

An inner join returns only rows with a matching relationship. Qualify column names with table names when ambiguity is possible.

Join three tables

Develop a query returning booking ID, event title and venue name for confirmed bookings.

SELECT BOOKING.booking_id, EVENT.title, VENUE.venue_name
FROM BOOKING
INNER JOIN EVENT
    ON BOOKING.event_id = EVENT.event_id
INNER JOIN VENUE
    ON EVENT.venue_id = VENUE.venue_id
WHERE BOOKING.booking_status = 'confirmed';

Subqueries

A subquery supplies a result to another query.

SELECT title, capacity
FROM EVENT
WHERE capacity > (
    SELECT AVG(capacity)
    FROM EVENT
);

The inner query calculates the average capacity. The outer query returns events above it.

Use a join when combining related columns and a subquery when one result naturally supplies a condition. Either may sometimes express the same goal; clarity and database behaviour matter.

Filter by a related set

Develop a subquery that returns event titles at accessible venues.

SELECT title
FROM EVENT
WHERE venue_id IN (
    SELECT venue_id
    FROM VENUE
    WHERE accessible = TRUE
);

CREATE and constraints

CREATE TABLE BOOKING (
    booking_id INTEGER PRIMARY KEY,
    event_id INTEGER NOT NULL,
    attendee_email VARCHAR(254) NOT NULL,
    places INTEGER NOT NULL CHECK (places > 0),
    booking_status VARCHAR(20) NOT NULL,
    FOREIGN KEY (event_id) REFERENCES EVENT(event_id)
);

Types and supported constraint syntax vary by database system. Constraints provide a final integrity layer but do not replace clear UI validation and server-side checks.

INSERT and UPDATE

INSERT INTO BOOKING
    (booking_id, event_id, attendee_email, places, booking_status)
VALUES
    (501, 42, 'sam@example.org', 2, 'confirmed');

UPDATE BOOKING
SET booking_status = 'cancelled'
WHERE booking_id = 501;

Update a specific event

Develop an UPDATE that marks event 42 as full.

UPDATE EVENT
SET status = 'full'
WHERE event_id = 42;

ALTER and DROP

ALTER TABLE EVENT
ADD registration_url VARCHAR(500);

ALTER changes an existing structure. DROP removes a database object, such as a table, and can cause irreversible data loss.

Before structural change, consider existing data, defaults, nullability, dependent queries and exchange contracts. Adding a required field without a value for old records can break the system.

Secure application queries

Never build SQL by directly joining untrusted input into a query string.

# Unsafe idea
query = "SELECT * FROM BOOKING WHERE attendee_email = '" + input + "'"

Safe pattern

query = "SELECT booking_id, event_id, places FROM BOOKING WHERE attendee_email = ?" ExecuteWithParameters(query, [input])

• Use parameterised queries or prepared statements.
• Grant the application database account only needed permissions.
• Authorise the user before querying protected records.
• Select only fields the response needs.
• Avoid exposing database errors or schema details to clients.

Parameters protect values, not arbitrary table names or SQL keywords. Dynamic structure requires a controlled allow-list.

Independent practice: event availability

Using the VENUE, EVENT and BOOKING schema:

1. Develop a query returning open event titles, venue names and dates in accessible venues, earliest first.
2. Develop a query returning each event ID and confirmed booked-place total, but only totals of 10 or more.
3. Develop a subquery returning events whose capacity is greater than the maximum capacity of events at venue 3.
4. Explain why attendee email should not be returned by a public events endpoint.

Broader personal, social and economic impacts

Impact is a change with a stakeholder

An impact response should identify who experiences a change, how the solution causes it and why it matters.

Classify without oversimplifying

A route app reduces commuting time, but its live-location requirement prevents people with limited mobile data from participating. Determine one personal, social and economic impact.

Map stakeholders before judging

Stakeholders may experience different outcomes.

• Primary users and people represented in the data
• Staff who operate, review or maintain the solution
• The organisation and service partners
• People indirectly affected by automated or data-informed decisions
• Communities, governments and future users

Ask who gains, who carries cost or risk, who has decision power and who may be missing from the design process.

Stakeholder contrast

A council replaces staffed booking counters with an app. Analyse one benefit and one cost for two different stakeholders.

Data exchange changes reach and risk

Exchanging data can remove duplicated entry, speed coordination and enable new services. It can also spread inaccurate or sensitive information beyond its original setting.

• Benefit: emergency teams receive timely, consistent status data.
• Risk: more systems and recipients increase exposure and dependence.
• Question: Is each field necessary for the receiving purpose?
• Control: minimise fields, authenticate parties, encrypt transmission and document responsibilities.

Interoperability can create public value, but an exchange should not be assumed ethical merely because it is technically possible.

Storage creates long-term consequences

Stored data can support history, accountability, personalisation and research. Retention also extends the time during which data may be misused, breached, misunderstood or applied to a new purpose.

Accuracy affects decisions

Data can be syntactically valid but inaccurate, incomplete, outdated or misleading. When a system scales, one error can be copied into many decisions.

Consider:

• who can correct a record
• whether source and update time are visible
• how conflicting values are resolved
• whether uncertainty is communicated
• what happens before a high-consequence decision.

Trace an accuracy impact

A relief database incorrectly records that a household has received supplies. The automated system blocks a second request.

Explain a personal, social and economic consequence.

Ownership, control and responsibility

“Who owns the data?” may hide several different questions:

• Who is the information about?
• Who collected, created or inferred it?
• Who controls storage, access and disclosure?
• Who holds intellectual-property or contractual rights?
• Who is accountable for accuracy, security and correction?
• Can a person access, move, correct or delete it in the circumstances?

A platform possessing a copy does not mean it can ethically use that data for any purpose. Analyse legal obligations, notices, expectations, contracts and power relationships separately.

Access and the digital divide

Digital solutions can extend services across distance and time. They can also exclude through:

• device and data cost
• unreliable connectivity
• language and literacy barriers
• disability access barriers
• limited digital confidence
• identity-document or authentication requirements.

Providing an app is not the same as providing equitable access. Alternatives, assisted channels and accessible design may be required.

Recommend inclusion

A health appointment system moves to smartphone-only booking with mandatory biometric authentication. Recommend two inclusion refinements.

Work, cost and productivity

Automation may reduce repetitive work, increase consistency and allow a service to scale. Economic impacts can also include:

• development, infrastructure, energy, licensing and security costs
• training, role redesign or displacement
• new specialist and support work
• dependence on a provider or proprietary format
• costs of outages, errors and breaches
• unequal benefits between organisations and communities.

A serious evaluation avoids “technology creates jobs” versus “technology removes jobs”. Identify which tasks change, what new capabilities are required and who bears transition costs.

Environmental impacts

Digital services use devices, networks, data centres and storage. Impacts include energy use, cooling, hardware manufacture, electronic waste and replacement cycles.

Possible refinements include efficient data retention, appropriately sized models and media, renewable-energy procurement, repairable devices and avoiding unnecessary computation. An environmental claim should use evidence rather than assume that paperless always means impact-free.

Evaluate rather than list

Stakeholder: who is affected? Mechanism: what feature or data practice causes change? Impact: what benefit or harm occurs? Extent: under which conditions and for whom? Judgment: how significant or acceptable is it? Response: what refinement changes the balance?

Weak: The app has positive and negative impacts.

Evaluated: Real-time availability reduces wasted travel for connected users, but smartphone-only access excludes residents without reliable devices or data. The benefit is therefore unevenly distributed. A public kiosk and assisted booking channel would retain efficiency while reducing exclusion.

Independent practice: smart community transport

A regional service proposes an app that predicts demand and changes bus routes each hour. It collects precise passenger location, payment history and accessibility needs. The model was trained mainly on weekday smartphone users. Cash booking and the staffed phone line will close. The provider promises lower operating cost and shorter average waits.

1. Analyse two personal, two social and two economic impacts for different stakeholders.
2. Evaluate whether shorter average waiting time is enough to establish success.
3. Recommend four refinements covering data, access, model evaluation and accountability.

Exam clinics

Pseudocode and desk checking

How to use this clinic

This clinic brings together authentic QCAA external-assessment questions involving pseudocode, algorithm reasoning and desk checking.

1. Attempt each question on paper without looking ahead.
2. Compare your answer with the worked response and explanation.
3. Use the QCAA marking criteria to check what earned the marks.
4. Add anything missing to your answer in a different-coloured pen.

Cybersecurity and the CIA triad

How to use this clinic

This clinic brings together authentic QCAA external-assessment questions about cybersecurity and the confidentiality, integrity and availability triad.

1. Attempt each question on paper without looking ahead.
2. Compare your answer with the worked response and explanation.
3. Use the complete QCAA sample response and marking criteria to check what earned the marks.
4. Add anything missing to your answer in a different-coloured pen.

Data-flow diagrams

How to use this clinic

This clinic brings together authentic QCAA external-assessment questions about data-flow diagrams and exchange-system relationships.

1. Attempt each question on paper without looking ahead.
2. Compare your answer with the worked response and explanation.
3. Use the complete QCAA sample response and marking criteria to check what earned the marks.
4. Add anything missing to your answer in a different-coloured pen.

Practice exams

2024 Digital Solutions practice exam

Complete 2024 practice examination with the original QCAA material and independent, student-friendly explanations.

What is included

• Original 2024 stimulus book
• Original multiple-choice question book
• Original question and response book
• Official QCAA marking guide and sample responses
• Independent explanations for every question
• Alternative valid answers and worked visual examples where appropriate

Topics covered

Visual communication and accessibility; impacts of data use; algorithms and JSON; useability; cybersecurity and data exchange; Australian Privacy Principles; data-flow diagrams; and interface design.

How to use the booklet

1. Complete the stimulus and examination questions on paper.
2. Compare your response with the official marking guide.
3. Read the independent explanations at the end, including why multiple-choice distractors do not fit.
4. Compare alternative responses and identify which marking criteria each one satisfies.

Download

Open or download the 2024 practice-exam booklet

The same PDF is also available from the Attachments panel on this page.

Original assessment material: © State of Queensland (QCAA) 2024. The original documents retain their attribution and licence notices. The added cover and explanations are independent teaching material and are not an official QCAA publication or marking decision.

2025 Digital Solutions practice exam

Complete 2025 practice examination with the original QCAA material and independent, student-friendly explanations.

What is included

• Original 2025 stimulus book
• Original multiple-choice question book
• Original question and response book
• Official QCAA marking guide and sample responses
• Independent explanations for every question
• Alternative valid answers and worked visual examples where appropriate

Topics covered

Encryption and hashing; programming and JSON; privacy and security; file transfer; data-flow diagrams; constraints; data dictionaries; desk checking; smart traffic systems; and useability.

How to use the booklet

1. Complete the stimulus and examination questions on paper.
2. Compare your response with the official marking guide.
3. Read the independent explanations at the end, including why multiple-choice distractors do not fit.
4. Compare alternative responses and identify which marking criteria each one satisfies.

Download

Open or download the 2025 practice-exam booklet

The same PDF is also available from the Attachments panel on this page.

Original assessment material: © State of Queensland (QCAA) 2025. The original documents retain their attribution and licence notices. The added cover and explanations are independent teaching material and are not an official QCAA publication or marking decision.