QCE Digital Solutions Unit 4 — Complex Digital Data Exchange Problems and Solution Requirements Hangman

The 134 key terms

1data exchange

The transfer of data between people, systems or organisations, where a sender and receiver use an agreed format over an agreed channel, such as a bank transfer or sharing records.

2data interface

The agreed point where one system gives data to, or takes data from, another. It sets the format and rules of the exchange, such as a file or an API.

3scope

The boundary of what a solution will and will not include. Features inside the boundary are in scope. Features left out, or saved for later, are out of scope.

4constraint

A limit on how a solution can be made, such as time, cost, skills, devices or software. A constraint is not a feature; it limits what you can build.

5Technical constraint

A limit set by technology, such as the hardware, operating system, network or existing software, that a solution must work within.

6legal constraint

A law or regulation a solution must obey, such as privacy law, copyright and licensing rules, or industry regulations. It limits what the software can do and how it handles data.

7economic constraint

A limit on money that restricts a solution, such as a fixed development budget, software licence fees, or the ongoing costs of hardware, hosting and staff.

8social constraint

A limit on a solution from the needs, values or abilities of the people affected, such as accessibility, cultural expectations and user acceptance.

9The solution must

Starts a functional requirement: one thing a digital solution must do. It says what the solution does, not how, and covers one action. Example: The solution must show the score.

10Non-functional requirement

A quality describing how well a system performs, such as speed, security, or reliability, rather than what it does

11measurable non-functional requirement

A quality of a solution, such as speed, security or usability, written with a testable target, like a page loads in under 2 seconds, so you can check whether it is met.

12requirements list

A list that sorts what a solution must do (requirements) from the limits it must work within (constraints), for one problem. Each item should be clear and testable.

13Software requirements specification (SRS)

A formal document recording what software must do, so client and developer agree, and used as the basis for design, testing and reference during development.

14SRS content

The parts of an SRS that state the functional and non-functional requirements, the constraints on the solution, and its scope (what is and is not included).

15data requirements

A list of the data items, types, sources and amount needed to answer a research question, such as the variables, primary or secondary source, time period and sample size.

16interoperability

The ability of software to work with other systems, devices and file formats and exchange data with them, for example by using standard formats like CSV or PDF across platforms.

17Confidentiality

Only authorised people or systems can read data. Everyone else is kept out, like student marks seen only by the student and teacher. A breach is when someone else sees them.

18Integrity

Data stays accurate and unaltered unless an authorised person changes it. It protects data from accidental changes and deliberate tampering.

19Availability

Authorised users can reach data and systems when they need them. Attacks like denial of service and hardware failure reduce it. It is one part of the CIA triad.

20asset

Anything of value in a digital system that needs protecting, such as data, accounts, devices or services. Examples: a student database (data) or a school laptop (hardware).

21threat

Anything that could cause harm to an asset, such as an attacker, malware, human error or a power failure. Threats can be deliberate or accidental, and internal or external.

22vulnerability

A weakness in software, hardware, a process or a person that a threat could use to harm an asset. A vulnerability is only a weakness, not an attack.

23accidental threat

Harm to data caused by a mistake with no intent to cause damage, such as emailing the wrong person, deleting files by accident, misconfiguring sharing or losing a device.

24deliberate threat

An intentional action by an attacker or malicious insider to steal, damage, alter or block access to data, usually for profit or revenge.

25events-based threat

An event outside anyone's control, such as fire, flood, storm or power failure, that damages data or systems or blocks access to them.

26insider threat

Harm to data or systems caused by someone with legitimate access, either on purpose (malicious insider) or by mistake, like emailing the wrong person or setting a file to public.

27Unauthorised access

Gaining entry to a network or system without permission, often to steal or damage data

28man-in-the-middle attack

An attack where someone secretly sits between two parties and can read or change the data passing between them, such as logins, session tokens or code sent over an unsecured network.

29Denial of service attack

An attack that floods a target with traffic, overwhelming its resources and blocking legitimate users

30social engineering

Tricking people, instead of hacking systems, into giving away access or information, often by pretending to be someone trusted or creating urgency. Phishing is one type.

31risk = likelihood x impact

Risk is how likely a threat is to succeed combined with how much harm it would cause. Rate each as low, medium or high to decide which risks matter most.

32risk matrix

A grid that plots how likely a threat is against how bad its impact would be, giving each risk a priority rating (such as low, medium or high) so you know which to fix first.

33trust boundary

A line on a diagram where data passes between parts of a system with different levels of trust, such as from a user's device to a server. Threats often cluster here.

34Poor decision-making

Decisions made from inaccurate or untimely data are likely to be wrong, causing wrong forecasts, misleading analysis and false conclusions.

35financial loss

Money lost when corrupted or incorrect data causes errors, rework, refunds and lost sales, such as wrong payments and the cost of fixing the data.

36impacted operations

Poor data integrity disrupts daily business, causing delayed orders, systems taken offline to fix data errors, and staff time wasted checking and correcting records.

37personal data

Information that identifies you or can be linked to you, such as your name, birthday, address, photos or school. A favourite colour on its own is not personal data.

38sensitive information

A special kind of personal information, like health, ethnic origin, religion or biometric data, that the Privacy Act protects more strictly because misuse can cause serious harm.

39Privacy Act 1988

Commonwealth legislation that sets rules for how organisations must collect, use, and store people's personal information.

40Australian Privacy Principles (APPs)

13 legal principles in the Privacy Act 1988 that set rules for how organisations collect, use, store, give access to and correct personal information. Use them as a checklist.

41APP 3

Australian Privacy Principle 3: only collect personal information that is reasonably necessary for your functions, and collect it lawfully and fairly. Take extra care with sensitive information.

42consent

Asking permission before collecting someone's personal data and explaining how it will be used. The person can say no. For young people, a parent or guardian may also need to agree.

43Australian Privacy Principle 6

Requires organisations to only use or disclose personal information for the purpose it was originally collected for, unless consent or an exception applies.

44APP 8

Before sending personal information overseas, such as to a cloud server, an organisation must take reasonable steps to make sure the overseas recipient will also protect it.

45Australian Privacy Principle 11

Requires organisations to protect personal information from misuse, loss, and unauthorised access, and to destroy it when no longer needed.

46data minimisation

Only collect the personal data you need for your purpose. Less data means less risk, so skip unneeded questions, store data safely and delete it when finished.

47security measures

Controls such as passwords, access control, encryption and backups that protect personal information in a dataset from misuse, loss or unauthorised access.

48security control

A measure that reduces risk by preventing an attack, detecting it or helping recovery. Controls can be technical, physical or procedural, and layering several works best.

49data in transit

Data moving across a network, such as email or web traffic. It is protected by encrypting it (e.g. HTTPS or a VPN) so intercepted data cannot be read.

50data at rest

Data stored on a device, server or backup, not moving. Protect it with encryption (disk or database) and access control, so a stolen laptop or backup is unreadable.

51security requirement

A statement of the protection a system must provide for its data and functions, based on its assets, users and laws, written so it can be tested.

52gap analysis

Comparing a case study's current practices with secure practice to find vulnerabilities, then rating the risk each gap creates by its likelihood and impact.

53Risk treatment

Matching each threat to a response chosen by its risk rating: eliminate it, reduce it, transfer it (e.g. insure) or accept it. High risks are treated first.

54API key

A secret code that identifies your program to an API. Keep it in a separate file, out of the repository and shared code, because it is linked to your usage limits.

55secrets management

Keeping passwords, API keys and tokens in a protected vault or environment variable, not in source code, and rotating keys and scanning commits for leaks.

563-2-1 rule

Keep 3 copies of data on 2 different types of media, with 1 copy stored offsite (such as cloud storage), so one disaster cannot destroy both the data and its backups.

57evaluation criterion

A measurable standard used to judge a solution, linked to a requirement and written so it can be answered with evidence, such as a target, a yes/no check or a rating.

58data exchange criteria

Measurable standards used to judge how well a data exchange solution protects data, keeps it secure (CIA) and interacts with other systems and users.

59Evaluate against CIA

Judge how well a security strategy protects confidentiality, integrity and availability, using evidence to rate each one and weigh up trade-offs between them.

60evaluation criteria

Measurable standards, such as incidents per year or recovery time, used to judge how well a security strategy meets its goals and protects confidentiality, integrity and availability.

61completeness

Data is complete when every required value is present. There are no blank fields and no missing records, so everything the exchange needs has arrived.

62Data consistency

Data is consistent when the same thing is recorded in the same form (one spelling, date format and unit) and agrees everywhere it appears, including across different sources.

63Correctness

Data is correct when it is in the right form and follows set rules, such as the right data type, format, valid values and calculation. It is not the same as accuracy.

64reasonableness

Data is reasonable when its value is sensible and believable in its context, so impossible values or odd outliers (like an age of 250) are flagged by reasonableness checks.

65Authenticity

Data is authentic when it genuinely comes from the source it claims and has not been forged or spoofed. Verifying its origin shows it can be trusted.

66timeliness

Data is timely when it is up to date and available when needed. Out-of-date records or delayed updates can lead to poor time-critical decisions.

67data integrity

How trustworthy data is. Test it against six characteristics, one at a time: accuracy, authenticity, correctness, reasonableness, relevance and timeliness. Failing any one means it can't be trusted.

68raw data copy

An untouched copy of the original data, made by duplicating the worksheet or using Save As before cleaning, so you clean only the copy and never lose the original.

69missing value

An empty cell where data should be. Find it with a filter for blanks, then delete the row, fill it from a reliable source or exclude it so AVERAGE and COUNT are not distorted.

70=COUNTIF($A$2:$A$100,A2)>1

Gives TRUE when the value in A2 appears more than once in column A. Put it in a helper column to flag duplicate rows, then filter for TRUE.

71Find and Replace

A spreadsheet tool that swaps every spelling variation of a category, such as Vic or VIC, for one agreed value like Victoria, so each category is counted only once.

72=VALUE(A2)

Converts text that looks like a number, such as '45' stored as text, into a true number so it can be added, averaged and sorted correctly. Left-aligned numbers are a warning sign.

73=TRIM(A2)

A text function that returns a tidy copy of the text in A2 with extra spaces removed. UPPER, LOWER and PROPER work the same way to fix capitals, e.g. =PROPER(A2) gives Mia Chen.

74cleaning log

A record of each change made to the data: what changed, how many rows it affected and why. It lets other people check the cleaning and repeat it.

75validation

An automatic check that data is reasonable and in the right form when entered. It blocks bad data early, but it cannot prove the data is true (a valid age of 15 could still be wrong).

76validation check

A test that an entry is sensible. Types include presence, data type, range, length, format and list. Each one tests a different property of the entry.

77if value.strip() == '':

An existence check tests that a value was actually entered. strip() removes spaces, so this is True for empty or space-only input, and an error message can be shown.

78type check

A check that input is the expected data type, using .isdigit(), try/except around int() or float(), or isinstance(). input() is always text, so check before converting.

791 <= age <= 120

A range check: tests that a number lies between a minimum and a maximum (inclusive here). Values outside the limits, such as 0 or 121, are rejected as invalid.

80def is_valid_age(text):

A validation function that runs the existence, type and range checks in order and returns True or False, so the same checks can be reused for many inputs and tested.

82checksum

A value calculated from a block of data by a set rule and sent with it. The receiver repeats the calculation and compares the results. If they differ, an error occurred.

83hash function

A one-way function that turns any input into a fixed-length value. The same input always gives the same hash, a tiny change gives a very different one, and it cannot be reversed.

84hash comparison

Hash the file before and after transfer. If both hashes (checksums) match, the data is unchanged. A different hash shows the file was altered or tampered with, so its integrity is lost.

85End-to-end integrity checking

Following data through every stage, from collection to chart, and confirming at each stage that it is unchanged and correct, for example by matching record counts and totals.

86analytical tools

Diagrams like context, data flow and use case diagrams that show how users, data and systems relate, so the existing system is understood before a solution is designed.

87context diagram

A Level 0 diagram that shows the whole system as one process in the centre, with external entities around it outside the system boundary.

88data flow

A labelled arrow on a context diagram showing data passing between an entity and the system. The arrowhead shows direction (input or output) and the label names the data.

90Level 1 DFD process

A numbered, named step (e.g. 1.0 Validate Order) in a Level 1 DFD. It uses a verb phrase and shows one main task from the context diagram's single system.

91Data store

On a Level 1 DFD, a data store is where data is held (e.g. a file or database). Entities sit outside the system and send or receive data. Both must match the context diagram.

93Level 1 DFD

Breaks a system into processes, data stores, entities and labelled flows found in a scenario, then checks the rules, e.g. every process has an input and an output and no flow is missing.

94Input, Process, Output, Storage

Read the scenario and sort every part into input (data in), process (what is done), output (result shown) or storage (data kept). Then check nothing is missing or in the wrong group.

95decomposition

Splitting a big problem into smaller sub-problems, such as input, process and output. Each part can be solved on its own, then the solutions are combined.

96hierarchy chart

A diagram that splits one main problem into smaller sub-problems in boxes, level by level, until each box is a small task that can be solved on its own.

97IPO chart

A three-column table listing a solution's inputs (data entered), the processes applied to that data, and the outputs it produces, such as a total or report.

98procedure vs function

A procedure carries out a task without returning a value, while a function returns a value to the code that called it, so the result can be stored or used.

99def main(): greet()

A function can call another function inside its body. Big problems get split into small helper functions that each do one job, like boxes in a decomposition.

100def main():

Defines a function called main that holds the main steps of your program. You call main() once at the end of the file, after the other functions are defined, to start the program.

102test each sub-problem separately

Each sub-problem is tested on its own before being joined to the rest, so an error is traced to the part that causes it and only that part needs fixing, not the whole program.

103primary data vs secondary data

Primary data is data you collect yourself, like a survey. Secondary data was collected by someone else, like data from a website or database.

104authentic data

Real data collected by a trusted organisation and kept in a large repository; check its publisher, date and relevance to your question.

105file format

The way a dataset's data is structured and stored in a file, such as CSV, XLSX, JSON or XML. Choose the format that suits the software you will open it in.

106CSV

A text file with one record per line, fields split by a delimiter such as a comma, and an optional header line of field names. Text containing commas goes in quotes.

107<student><name>Mia</name></student>

XML stores data in nested, named elements. Each element has an opening and closing tag, and child elements sit inside a root element. The tags describe the data.

108API

An application programming interface: a defined set of requests and responses that lets one program use the features or data of another program.

109response.json()

Converts the JSON text of an API response into Python dictionaries and lists, so you can read values by key, e.g. data['name'], or loop over a list of results.

110Data storage system

The hardware and software an organisation uses to hold its data for ongoing access.

111database

A database gives every record the same fields and data types and lets you query large amounts of data; a spreadsheet is a flexible grid.

112int(input())

input() always returns a str, so convert it (e.g. with int) to store it as a number. Turn it back into text with str() or an f-string when you output it.

113library

A collection of ready-made code you can reuse. The standard library comes with Python; third-party libraries are made by others and must be installed separately (e.g. with pip).

115import math

Loads Python's math module, giving you extras like math.sqrt(), math.pi, math.ceil() and math.floor() that basic operators don't have. Call them with the math. prefix.

116statistics.mean(data)

The statistics module calculates descriptive statistics on a list: mean() is the average, median() the middle value, stdev() the spread. Use import statistics first.

117hashlib.sha256(text.encode()).hexdigest()

Python code that turns text into bytes, hashes it with SHA-256 and returns a fixed-length hex string. Same input gives the same hash; one changed letter gives a new hash.

118third-party dependency

A library written by someone else that your program imports and relies on. A flaw in it affects every app that uses it, and it may pull in its own dependencies too.

119end if

A closing keyword in VCAA pseudocode that ends an if block; every nested construct uses end followed by its matching keyword: end if, end while, end for

121input

A VCAA pseudocode keyword that accepts a value from the user and stores it in a named variable. Example: input age stores the user's entered value in the variable age

122print

A VCAA pseudocode keyword that outputs a value, variable or expression as a result. Example: print area displays the current value stored in the variable area

124AND

A VCAA pseudocode boolean operator that combines two conditions. The overall result is true only when BOTH conditions are true. Example: x > 0 AND x < 10

125IF-THEN-ELSE

A selection structure that runs one set of instructions if a condition is true, and a different set if it is false

126ELSE IF

A keyword that adds another condition to check if the previous IF or ELSE IF condition was false

127FOR i FROM 1 TO n

A loop that repeats its instructions a fixed number of times, counting the variable i from 1 up to n

128WHILE condition DO

A loop that repeats its instructions for as long as the given condition remains true, checked before each repetition

129count <- count + 1

A counter. It adds 1 to a variable each time a loop repeats. Set it to 0 before the loop. An accumulator works the same way: total <- total + x adds a value each time.

130scores[1]

Accesses the array element at index 1, using square brackets to specify the position.

131student.name

Accesses the name field of the student record, using a dot to connect the record to its field.

132addNumbers(a: INTEGER, b: INTEGER): INTEGER

A function header specifying the function's name, its typed parameters, and the data type of its return value

133define

A keyword that starts a function definition, naming the function and listing the parameters it accepts

134return

A keyword that sends a value back from a function to where it was called, ending the function's execution at that point

135addNumbers(3, 4)

Calling a function by writing its name followed by arguments in brackets, running its instructions and possibly producing a value

136IPO to pseudocode

Turn each IPO input into an INPUT statement, each process into assignments or IF selection, and each output into a PRINT statement, in that order.

137internal documentation

Explanation written inside the code to say what it does and why, so other programmers can understand, fix and update it later.

138scores = [] # marks for each student

A comment beside a variable, list, record or class that says what it stores and how it is used, so other programmers can understand the data and code structures.

139header comment

A comment at the top of a file that records the program's purpose, author, date and any changes made, so others can understand and maintain the code.

140"""docstring"""

A triple-quoted string placed first in a function or class that describes its purpose, parameters and return value. It is internal documentation.

141pass

A Python statement that does nothing. It fills a stub's empty body, often beside a # TODO comment, so the program still runs while the real code is written later.