LearningP is independent of AQA. Use the current official documents for assessment requirements.
TRY IT TOGETHER · NO SIGN-UP
Three questions. See the difference.
Try three different Computer Science skills from this AQA route. See what went right, understand a mistake, and find a useful next step.
3questions · 3 skills
A small preview of how LearningP turns answers into a clearer learning picture for students and parents.
Question 1 of 3 · No calculator needed
Within Data types, which definition of scalar data types is accurate?
Integer, real, Boolean, character and string types restrict the values and operations that are meaningful for stored data. Use an integer for the count, a real for the price and a Boolean for the open-or-closed state; each choice matches the value domain.
Question 2 of 3 · No calculator needed
One 200-line block performs input, sorting, printing and file saving. Which explanation correctly analyses this case in Subroutines (procedures/functions)?
maintainability is the relevant idea. Split the unrelated responsibilities into focused subroutines; this reduces coupling and makes a change less likely to damage another task. Meaningful subroutine names and single-purpose bodies make code easier to understand, change and review.
Question 3 of 3 · No calculator needed
A new service distributes personal information across servers and users in several countries. Which explanation correctly analyses this case in Individual, social, legal and cultural issues and opportunities?
legislative challenge is the relevant idea. Legislators face definitions, jurisdiction, enforceability, proportionality and future-proofing challenges; technical and affected-party evidence is needed. Digital technology changes faster than many legal processes, crosses jurisdictions and creates trade-offs between innovation, rights, enforcement and unintended consequences.
YOUR SAMPLE HEATMAP
These tiles show your answers to three questions. They are a starting point, not a mastery score or grade prediction.
Data types
Correct answer: Integer, real, Boolean, character and string types restrict the values and operations that are meaningful for stored data.
Integer, real, Boolean, character and string types restrict the values and operations that are meaningful for stored data. Use an integer for the count, a real for the price and a Boolean for the open-or-closed state; each choice matches the value domain.
Subroutines (procedures/functions)
Correct answer: maintainability: Split the unrelated responsibilities into focused subroutines; this reduces coupling and makes a change less likely to damage another task.
maintainability is the relevant idea. Split the unrelated responsibilities into focused subroutines; this reduces coupling and makes a change less likely to damage another task. Meaningful subroutine names and single-purpose bodies make code easier to understand, change and review.
Individual, social, legal and cultural issues and opportunities
Correct answer: legislative challenge: Legislators face definitions, jurisdiction, enforceability, proportionality and future-proofing challenges; technical and affected-party evidence is needed.
legislative challenge is the relevant idea. Legislators face definitions, jurisdiction, enforceability, proportionality and future-proofing challenges; technical and affected-party evidence is needed. Digital technology changes faster than many legal processes, crosses jurisdictions and creates trade-offs between innovation, rights, enforcement and unintended consequences.
For parents: look at the explanation together. A correct answer is encouraging; a missed answer gives you something specific to work on. Broader practice over time is needed to understand progress.
Original LearningP practice, aligned to specification 7517. Your taster answers stay on this page and reset when you leave or reload.
YOUR TOPIC MAP
Find your starting point.
171 areas
01Data types
Specification reference: 4.1.1.1
A user-defined type is built from language-defined types to model a problem-domain value with a clear structure or permitted set of values. Define an enumerated status type so invalid status text cannot be introduced and the permitted states are explicit.
Watch for: Do not describe Data types vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
02Programming concepts
Specification reference: 4.1.1.2
Indefinite iteration repeats until a condition changes and can test that condition either before or after the loop body. A post-condition loop suits the requirement because it performs one input before testing whether another repetition is necessary.
Watch for: Do not describe Programming concepts vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
03Arithmetic operations in a programming language
Specification reference: 4.1.1.3
integer and real division is the relevant idea. Integer division gives 3 because the quotient is truncated to a whole number; real division gives 3.4. Integer division returns a whole-number quotient, while real division retains a fractional result.
Watch for: Do not describe Arithmetic operations in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
04Relational operations in a programming language
Specification reference: 4.1.1.4
inequality is the relevant idea. The condition is true because the two strings differ. A not-equal comparison is true when its operands have different values.
Watch for: Do not describe Relational operations in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
05Boolean operations in a programming language
Specification reference: 4.1.1.5
grouped Boolean expression is the relevant idea. The bracketed OR is true and true AND true is true, so access is granted. Parentheses make the intended evaluation order explicit when NOT, AND, OR or XOR are combined.
Watch for: Do not describe Boolean operations in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
06Constants and variables in a programming language
Specification reference: 4.1.1.6
named constant maintenance is the relevant idea. Change MAX_UPLOAD_MB once; duplicated numeric literals risk inconsistent edits. A named constant centralises a fixed value so a required change is made once rather than at every use.
Watch for: Do not describe Constants and variables in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
07String-handling operations in a programming language
Specification reference: 4.1.1.7
substring is the relevant idea. Extracting from the first position for four characters gives 'COMP'. A substring operation extracts a contiguous part of a string using a start position and a length or end position.
Watch for: Do not describe String-handling operations in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
08Random number generation in a programming language
Specification reference: 4.1.1.8
A random index can select one element from a collection when each valid index is given the intended probability. Generate one of the eight valid indexes and access that element; including an invalid ninth index would cause an error.
Watch for: Do not describe Random number generation in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
09Exception handling
Specification reference: 4.1.1.9
cleanup is the relevant idea. Use guaranteed cleanup or a managed-resource construct so the file is closed on both the normal and exceptional paths. Cleanup code should release resources whether the protected operation succeeds or raises an exception.
Watch for: Do not describe Exception handling vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
10Subroutines (procedures/functions)
Specification reference: 4.1.1.10
reuse is the relevant idea. Place the checksum logic in one subroutine and call it in all three workflows so one corrected implementation is reused. A well-defined subroutine can be called from many places, reducing duplicated code and inconsistent fixes.
Watch for: Do not describe Subroutines (procedures/functions) vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
11Parameters of subroutines
Specification reference: 4.1.1.11
Passing required data as parameters makes dependencies explicit and permits the same subroutine to operate on different values. Accept the dataset as a parameter so each call states which values are processed and tests do not depend on hidden global state.
Watch for: Do not describe Parameters of subroutines vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
12Returning a value or values from a subroutine
Specification reference: 4.1.1.12
return-path completeness is the relevant idea. Add a return such as 'Fail' on the other path; otherwise some calls have no defined result. Every reachable path of a value-returning subroutine should supply a valid result or explicitly signal failure.
Watch for: Do not describe Returning a value or values from a subroutine vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
13Local variables in subroutines
Specification reference: 4.1.1.13
local variables as good practice is the relevant idea. Move the counter into the routine that owns the loop so unrelated code cannot alter it. Using local variables limits unintended side effects and makes a subroutine's dependencies easier to reason about.
Watch for: Do not describe Local variables in subroutines vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
14Global variables in a programming language
Specification reference: 4.1.1.14
global scope is the relevant idea. A global declaration can make that one state visible to the handlers, subject to the language's scope rules. A global variable is declared outside individual subroutines and can be accessible to multiple parts of a program.
Watch for: Do not describe Global variables in a programming language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
15Role of stack frames in subroutine calls
Specification reference: 4.1.1.15
stack frame is the relevant idea. The caller's frame remains on the call stack while a new frame for the callee is pushed above it. Each active subroutine call is represented by a stack frame containing the information needed for that invocation.
Watch for: Do not describe Role of stack frames in subroutine calls vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
16Recursive techniques
Specification reference: 4.1.1.16
A recursive call must make progress toward a reachable base case; otherwise recursion continues until resources are exhausted. The argument moves away from zero, so the base case is not reached and the recursion does not terminate normally.
Watch for: Do not describe Recursive techniques vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
17Programming paradigms
Specification reference: 4.1.2.1
object-oriented paradigm is the relevant idea. Modelling Account objects encapsulates each balance with the operations allowed to change it. Object-oriented programming organises software around objects that combine state with behaviours defined by classes.
Watch for: Do not describe Programming paradigms vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
18Procedural-oriented programming
Specification reference: 4.1.2.2
Structured decomposition improves readability, testing, reuse and team development by establishing clear modules and interfaces. Dividing it into specified modules allows parallel work and focused tests while reducing interference between changes.
Watch for: Do not describe Procedural-oriented programming vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
19Object-oriented programming
Specification reference: 4.1.2.3
encapsulation is the relevant idea. Keep balance private and change it through checked deposit and withdrawal methods. Encapsulation keeps an object's state with its methods and restricts direct access so valid operations control changes.
Watch for: Do not describe Object-oriented programming vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
20Data structures
Specification reference: 4.2.1.1
operation-driven choice is the relevant idea. A stack models the required last-in, first-out operation more directly than a queue. A suitable data structure is selected by the operations and performance required, not merely by the amount of data.
Watch for: Do not describe Data structures vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
21Single- and multi-dimensional arrays
Specification reference: 4.2.1.2
two-dimensional array is the relevant idea. Use a Boolean array with row and column indexes; the pair identifies one seat. A two-dimensional array stores same-type elements addressed by a pair of indexes, often representing rows and columns.
Watch for: Do not describe Single- and multi-dimensional arrays vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
22Fields, records and files
Specification reference: 4.2.1.3
A binary file stores non-text byte patterns in a format understood by the program, which may be more compact but not human-readable. A binary format can preserve the required byte representation without converting every value to display characters.
Watch for: Do not describe Fields, records and files vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
23Abstract data types and data structures
Specification reference: 4.2.1.4
static structure is the relevant idea. Its fixed allocation gives simple indexed storage but leaves most slots unused. A static structure has a fixed capacity decided before use, which makes storage predictable but can waste space or become full.
Watch for: Do not describe Abstract data types and data structures vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
24Queues
Specification reference: 4.2.2.1
priority queue is the relevant idea. It is removed first; jobs of equal priority may then be served in arrival order. A priority queue removes an item according to priority rather than solely by arrival time, with a defined rule for equal priorities.
Watch for: Do not describe Queues vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
25Stacks
Specification reference: 4.2.3.1
pop is the relevant idea. C is returned and removed, leaving B as the new top. Pop returns and removes the top item, so it must not be applied to an empty stack.
Watch for: Do not describe Stacks vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
26Graphs
Specification reference: 4.2.4.1
vertices and edges is the relevant idea. Represent each person as a vertex and each friendship as an edge between the relevant vertices. A graph consists of vertices, also called nodes, connected by edges or arcs that represent relationships.
Watch for: Do not describe Graphs vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
27Trees (including binary trees)
Specification reference: 4.2.5.1
rooted tree is the relevant idea. Model the top directory as the root; contained directories are descendants linked through parent–child relationships. A rooted tree designates one vertex as the root and defines parent–child relationships away from it.
Watch for: Do not describe Trees (including binary trees) vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
28Hash tables
Specification reference: 4.2.6.1
A hash table can give fast average key lookup but does not inherently store keys in sorted order and its worst case degrades with collisions. Hash lookup alone does not provide that order; collect and sort the keys or use an ordered structure.
Watch for: Do not describe Hash tables vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
29Dictionaries
Specification reference: 4.2.7.1
dictionary representation is the relevant idea. Use learner ID as the dictionary key so retrieval does not require scanning every record. A dictionary is appropriate when access is naturally by a meaningful key rather than by a consecutive numeric position.
Watch for: Do not describe Dictionaries vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
30Vectors
Specification reference: 4.2.8.1
vector is the relevant idea. Use the 2-vector [2, 3]; order matters because [3, 2] is a different displacement. A vector is an ordered list of values drawn from the same field and can represent a point, direction or mapping from indexes to values.
Watch for: Do not describe Vectors vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
31Simple graph-traversal algorithms
Specification reference: 4.3.1.1
breadth-first graph traversal is the relevant idea. Using a queue, visit A, enqueue B and C, then visit B and C before D and E. Breadth-first traversal visits all currently discovered vertices at one distance level before vertices at the next level.
Watch for: Do not describe Simple graph-traversal algorithms vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
32Simple tree-traversal algorithms
Specification reference: 4.3.2.1
An explicit stack can replace recursive call frames when a depth-first tree traversal is implemented iteratively. Push nodes whose subtrees remain to be processed; pop the next node and push children in the order needed to reproduce pre-order.
Watch for: Do not describe Simple tree-traversal algorithms vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
33Reverse Polish and infix transformations
Specification reference: 4.3.3.1
Reverse Polish form is the relevant idea. The Reverse Polish form is A B + because both operands appear before the addition operator. Reverse Polish notation places each operator after its operands, removing the need for precedence parentheses.
Watch for: Do not describe Reverse Polish and infix transformations vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
34Linear search
Specification reference: 4.3.4.1
not-found result is the relevant idea. Three comparisons find no match, so the algorithm returns a not-found value rather than a valid index. A linear search can report absence only after every candidate position has been checked.
Watch for: Do not describe Linear search vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
35Binary search
Specification reference: 4.3.4.2
empty-interval termination is the relevant idea. Terminate with not found; calculating another midpoint would access an interval that no longer exists. When the lower bound passes the upper bound, no candidate positions remain and the target is absent.
Watch for: Do not describe Binary search vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
36Binary tree search
Specification reference: 4.3.4.3
A reasonably balanced binary search tree has logarithmic height, so each comparison can move down one of relatively few levels. A root-to-leaf search needs at most about ten comparisons because 1,023 = 2^10−1 for a full ten-level tree.
Watch for: Do not describe Binary tree search vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
37Bubble sort
Specification reference: 4.3.5.1
quadratic worst case is the relevant idea. Many swaps occur across roughly n passes of up to n comparisons, giving O(n²) time. Bubble sort performs a quadratic number of adjacent comparisons in the worst case, making it unsuitable for large lists.
Watch for: Do not describe Bubble sort vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
38Merge sort
Specification reference: 4.3.5.2
time complexity is the relevant idea. There is one additional division level, while each level processes all items, consistent with O(n log n). Merge sort performs O(log n) division levels and O(n) merging work per level, giving O(n log n) time.
Watch for: Do not describe Merge sort vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
39Dijkstra's shortest-path algorithm
Specification reference: 4.3.6.1
Dijkstra's greedy finalisation is valid for non-negative edge weights and can give a wrong result when a reachable negative edge exists. Do not rely on standard Dijkstra for this graph; its assumption that fixed distances cannot later decrease is violated.
Watch for: Do not describe Dijkstra's shortest-path algorithm vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
40Problem-solving
Specification reference: 4.4.1.1
logical completeness is the relevant idea. The boundary case is uncovered, so the logic is incomplete; add an equality-inclusive branch. A solution must cover all permitted cases, including boundary combinations, and produce one consistent result for each.
Watch for: Do not describe Problem-solving vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
41Following and writing algorithms
Specification reference: 4.4.1.2
Pseudo-code algorithms combine sequence, assignment, selection and iteration to express control flow independently of one programming language. Use assignment for the initial total, iteration over items and selection before the update.
Watch for: Do not describe Following and writing algorithms vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
42Abstraction
Specification reference: 4.4.1.3
generalisation is the relevant idea. Both can be generalised as kinds of Vehicle, with specialised properties retained in their own categories. Abstraction by generalisation groups objects with common characteristics into an is-a-kind-of hierarchy.
Watch for: Do not describe Abstraction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
43Information hiding
Specification reference: 4.4.1.4
essential interface is the relevant idea. Callers use the operations without depending on how the index or storage is maintained. Information hiding exposes what a component does through an interface while concealing internal details that users do not need.
Watch for: Do not describe Information hiding vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
44Procedural abstraction
Specification reference: 4.4.1.5
procedure call is the relevant idea. The call communicates the method's purpose while the detailed validation steps remain in the procedure definition. A procedure call names the required operation without repeating its internal sequence at the point of use.
Watch for: Do not describe Procedural abstraction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
45Functional abstraction
Specification reference: 4.4.1.6
Two function implementations are interchangeable to callers when they satisfy the same observable input–output contract. The faster implementation can replace the slower one without changing caller logic because the abstraction's behaviour is preserved.
Watch for: Do not describe Functional abstraction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
46Data abstraction
Specification reference: 4.4.1.7
data abstraction is the relevant idea. Users work with set behaviour without knowing whether storage is a hash table or tree. Data abstraction defines a collection of values and permitted operations while hiding how those values are represented.
Watch for: Do not describe Data abstraction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
47Problem abstraction and reduction
Specification reference: 4.4.1.8
problem abstraction is the relevant idea. Abstract depots as vertices and roads as weighted edges, revealing a shortest-path problem. Problem abstraction removes domain-specific detail to reveal the computational structure that determines a solution.
Watch for: Do not describe Problem abstraction and reduction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
48Decomposition
Specification reference: 4.4.1.9
integration risk is the relevant idea. Integration tests expose the unit mismatch; the interface contract must state and enforce one unit. Components that work separately can still fail when combined if assumptions at their interfaces are inconsistent.
Watch for: Do not describe Decomposition vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
49Composition
Specification reference: 4.4.1.10
composition is the relevant idea. Compose the four components so each output becomes the next component's valid input. Composition constructs a larger solution by combining smaller procedures, functions, data abstractions or systems through their interfaces.
Watch for: Do not describe Composition vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
50Automation
Specification reference: 4.4.1.11
model data structure is the relevant idea. Represent each lane's waiting vehicles with a queue that supports arrival and removal operations. Data structures encode the model so the algorithm can access and update its state during execution.
Watch for: Do not describe Automation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
51Finite state machines with and without output
Specification reference: 4.4.2.1
finite state machine is the relevant idea. Represent the two conditions as states and each input-dependent change as a labelled transition. A finite state machine has a finite set of states and changes state according to the current state and input symbol.
Watch for: Do not describe Finite state machines with and without output vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
52Mathematics for regular expressions
Specification reference: 4.4.2.2
A subset may equal its containing set, a proper subset must omit at least one member, and union, intersection and difference combine memberships in defined ways. A∩B={2,3} contains shared members and A\B={1} contains members in A but not B.
Watch for: Do not describe Mathematics for regular expressions vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
53Regular expressions
Specification reference: 4.4.2.3
A regular expression describes the set of all strings generated or matched by its operators, not one execution path. Every accepted string starts with a and is followed by zero or more a or b symbols, so a, aa and abba match but b does not.
Watch for: Do not describe Regular expressions vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
54Regular language
Specification reference: 4.4.2.4
The regex and FSM views are equivalent in expressive power, but one may make matching patterns or operational state changes easier to inspect. Use an FSM diagram for the operational trace while retaining that a regex could describe the same regular language.
Watch for: Do not describe Regular language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
55Backus–Naur Form and syntax diagrams
Specification reference: 4.4.3.1
formulating a simple rule is the relevant idea. Use <S> ::= x | x<S>; the first alternative terminates and the second adds another x. Recursive BNF productions can describe arbitrarily nested or repeated grammatical structure.
Watch for: Do not describe Backus–Naur Form and syntax diagrams vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
56Comparing algorithms
Specification reference: 4.4.4.1
time–space trade-off is the relevant idea. The table increases space use but can reduce time by avoiding recomputation. An algorithm may use extra memory to reduce repeated computation, so the best choice depends on both resource constraints.
Watch for: Do not describe Comparing algorithms vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
57Mathematics for understanding Big O notation
Specification reference: 4.4.4.2
dominant growth is the relevant idea. The n² term dominates as n grows, so T has quadratic growth despite the lower-order terms. For large n, the highest-growth term determines the broad complexity class and constant multipliers do not change that class.
Watch for: Do not describe Mathematics for understanding Big O notation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
58Order of complexity
Specification reference: 4.4.4.3
polynomial nested-loop time is the relevant idea. The body executes n×n=n² times, so the algorithm is O(n²). A fixed number of full nested loops can produce polynomial complexity such as O(n²).
Watch for: Do not describe Order of complexity vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
59Limits of computation
Specification reference: 4.4.4.4
Physical computers represent only finite states and bounded-precision values, so some ideal mathematical computations must be approximated or bounded. The infinite expansion cannot be stored completely; the program must retain a finite approximation.
Watch for: Do not describe Limits of computation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
60Classification of algorithmic problems
Specification reference: 4.4.4.5
tractable problem is the relevant idea. It is tractable under this definition because n³ is polynomial, even though very large instances may still be slow. A problem is classed as tractable when it has an algorithm with polynomial or better time complexity.
Watch for: Do not describe Classification of algorithmic problems vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
61Computable and non-computable problems
Specification reference: 4.4.4.6
Computability claims must identify the exact input domain and required output because changing the problem can change whether a total algorithm exists. It solves that restricted finite-control problem, not the unrestricted termination problem for all programs.
Watch for: Do not describe Computable and non-computable problems vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
62Halting problem
Specification reference: 4.4.4.7
Halting problem is the relevant idea. That claim is the universal Halting problem, which is unsolvable by an algorithm for all program–input pairs. The Halting problem asks whether an arbitrary program will eventually stop when run with a particular input.
Watch for: Do not describe Halting problem vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
63Turing machine
Specification reference: 4.4.5.1
universal model of computation is the relevant idea. Interpreting that description to reproduce the encoded machine's steps illustrates universal computation and the stored-program idea. Turing machines provide a formal model of what is computable, and a Universal Turing machine can simulate any encoded Turing machine on encoded input.
Watch for: Do not describe Turing machine vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
64Natural numbers
Specification reference: 4.5.1.1
infinite set is the relevant idea. The claim is false because 1000=999+1 is also natural, and the same reasoning applies to any proposed greatest value. The natural-number set is infinite because every natural number n has another natural number n+1.
Watch for: Do not describe Natural numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
65Integer numbers
Specification reference: 4.5.1.2
integer arithmetic closure is the relevant idea. 7−12=−5 is integer, but 7/2=3.5 is not, so integer division is not closed in general. Adding, subtracting or multiplying two integers always produces an integer, though division need not.
Watch for: Do not describe Integer numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
66Rational numbers
Specification reference: 4.5.1.3
non-zero denominator is the relevant idea. No: division by zero is undefined and fails the rational-number definition. Division by zero does not define a rational number, so b must be non-zero in a/b.
Watch for: Do not describe Rational numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
67Irrational numbers
Specification reference: 4.5.1.4
pi is the relevant idea. The stored value is rational and finite; it approximates π but cannot contain its complete irrational expansion. π is an irrational real number, so any finite decimal used by a program is an approximation.
Watch for: Do not describe Irrational numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
68Real numbers
Specification reference: 4.5.1.5
Although ℝ contains infinitely many values, a finite-bit computer format represents only a finite subset or approximations of real values. That is impossible with finitely many bit patterns; rounding or restricted range and precision are unavoidable.
Watch for: Do not describe Real numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
69Ordinal numbers
Specification reference: 4.5.1.6
order dependence is the relevant idea. A file can be second under one ordering and fifth under the other because ordinal position is relative to the chosen order. An object's ordinal position depends on the ordering rule applied to the set.
Watch for: Do not describe Ordinal numbers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
70Counting and measurement
Specification reference: 4.5.1.7
measurement precision is the relevant idea. The stored real value is an approximation within the measurement resolution, not an exact mathematical length. A measured real value is recorded to finite precision determined by the instrument and representation.
Watch for: Do not describe Counting and measurement vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
71Number base
Specification reference: 4.5.2.1
base notation is the relevant idea. 100₂=4₁₀ because its weights are powers of two, while 100₁₀ is one hundred. A subscript or explicit label identifies the base; without it, the same digit string can represent different values.
Watch for: Do not describe Number base vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
72Bits and bytes
Specification reference: 4.5.3.1
unused patterns is the relevant idea. There are 32 patterns, leaving 32−20=12 patterns available for invalid or future codes. When 2^n exceeds the required state count, some bit patterns remain unused or can be reserved.
Watch for: Do not describe Bits and bytes vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
73Units
Specification reference: 4.5.3.2
unit-label accuracy is the relevant idea. The exact binary label is 1 MiB; 1 MB formally means 1,000,000 bytes. A storage value is ambiguous or misleading if a decimal name is used for a binary quantity without stating the convention.
Watch for: Do not describe Units vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
74Unsigned binary
Specification reference: 4.5.4.1
decimal to fixed-width unsigned binary is the relevant idea. 19=16+2+1, so the eight-bit representation is 00010011₂. A decimal value is expressed as a sum of powers of two and padded with leading zeros to the required unsigned width.
Watch for: Do not describe Unsigned binary vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
75Unsigned binary arithmetic
Specification reference: 4.5.4.2
checking binary arithmetic is the relevant idea. 6×5=30 and 11110₂=16+8+4+2=30, so the binary product is consistent. Converting operands and result to decimal provides an independent check, while still showing the required binary working.
Watch for: Do not describe Unsigned binary arithmetic vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
76Signed binary using two's complement
Specification reference: 4.5.4.3
signed overflow is the relevant idea. 7+3=10 exceeds the maximum 7; the stored bits 1010 appear negative, signalling overflow. Two's-complement overflow occurs when adding two values with the same sign produces a stored result with the opposite sign.
Watch for: Do not describe Signed binary using two's complement vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
77Numbers with a fractional part
Specification reference: 4.5.4.4
simplified floating point is the relevant idea. 0.101₂=0.625; multiplying by 2^3 gives 0.625×8=5. A simplified binary floating-point value represents a two's-complement mantissa scaled by a power of two given by a two's-complement exponent.
Watch for: Do not describe Numbers with a fractional part vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
78Rounding errors
Specification reference: 4.5.4.5
When more fractional bits are required than the format provides, the value is rounded or truncated to an available bit pattern. The encoding selects one permitted neighbour according to its rounding rule, so stored and exact values differ.
Watch for: Do not describe Rounding errors vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
79Absolute and relative errors
Specification reference: 4.5.4.6
magnitude comparison is the relevant idea. Relative errors are 1/1000=0.001 and 1/2=0.5, so the second approximation is proportionally much worse. The same absolute error is less significant relative to a large exact value than to a small one.
Watch for: Do not describe Absolute and relative errors vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
80Range and precision
Specification reference: 4.5.4.7
Fixed-point arithmetic can be simpler and faster on suitable hardware, while floating point trades complexity for range and relative precision. A scaled fixed-point integer can avoid floating approximation and fit the known range, subject to overflow checks.
Watch for: Do not describe Range and precision vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
81Normalisation of floating-point form
Specification reference: 4.5.4.8
negative normalised mantissa is the relevant idea. Its first two bits are 10, so it uses the available precision and is normalised. A normalised negative two's-complement fractional mantissa begins 10; leading 11 bits are redundant sign extension.
Watch for: Do not describe Normalisation of floating-point form vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
82Underflow and overflow
Specification reference: 4.5.4.9
overflow is the relevant idea. The result overflows because no available exponent can scale the mantissa to that magnitude. Floating-point overflow occurs when a result's magnitude requires an exponent greater than the maximum representable exponent.
Watch for: Do not describe Underflow and overflow vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
83Character form of a decimal digit
Specification reference: 4.5.5.1
digit character code is the relevant idea. Store code 53, binary 00110101 in eight bits, when the symbol '5' is required. A decimal digit stored as a character uses the coding system's bit pattern for the symbol, not the pure binary value of the digit.
Watch for: Do not describe Character form of a decimal digit vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
84ASCII and Unicode
Specification reference: 4.5.5.2
Unicode is the relevant idea. Using the agreed Unicode code point identifies the same abstract character on both platforms. Unicode assigns code points to characters from many writing systems and symbol collections to support consistent international text.
Watch for: Do not describe ASCII and Unicode vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
85Error checking and correction
Specification reference: 4.5.5.3
parity limitation is the relevant idea. Parity may remain even, so the error can pass undetected and parity alone cannot correct it. A single parity bit detects any odd number of flipped bits but can miss an even number and cannot identify the erroneous bit.
Watch for: Do not describe Error checking and correction vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
86Bit patterns, images, sound and other data
Specification reference: 4.5.6.1
sound bit patterns is the relevant idea. They are consumed twice as quickly, changing duration and pitch because the interpretation timing is wrong. Digital sound interprets successive bit groups as sampled amplitude values at a specified rate and resolution.
Watch for: Do not describe Bit patterns, images, sound and other data vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
87Analogue and digital
Specification reference: 4.5.6.2
analogue data is the relevant idea. The physical pressure is analogue because its value is not restricted to a finite set of levels. Analogue data varies continuously over a range and can take intermediate values between any two measured values.
Watch for: Do not describe Analogue and digital vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
88Analogue-to-digital conversion
Specification reference: 4.5.6.3
analogue-to-digital converter is the relevant idea. The ADC samples the voltage and outputs numeric codes the digital system can store and process. An ADC samples an analogue input and quantises each sample to one of the available digital codes.
Watch for: Do not describe Analogue-to-digital conversion vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
89Bitmapped graphics
Specification reference: 4.5.6.4
bitmap metadata is the relevant idea. Header and metadata bytes can explain the difference even without compression. A bitmap file may store metadata such as width, height, colour depth and other format information in addition to pixel data.
Watch for: Do not describe Bitmapped graphics vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
90Vector graphics
Specification reference: 4.5.6.5
vector objects is the relevant idea. Store three object descriptions with their properties instead of colour values for every display pixel. A vector graphic represents an image as a list of geometric objects rather than a fixed grid of pixels.
Watch for: Do not describe Vector graphics vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
91Vector graphics versus bitmapped graphics
Specification reference: 4.5.6.6
bitmap scaling is the relevant idea. No new captured detail exists; estimated pixels make edges less crisp than a comparable vector design. Enlarging a bitmap beyond its original pixel dimensions requires interpolation and can reveal pixelation or blur.
Watch for: Do not describe Vector graphics versus bitmapped graphics vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
92Digital representation of sound
Specification reference: 4.5.6.7
quality–size trade-off is the relevant idea. Its uncompressed sample count and file size both double. Higher rate or resolution can capture more detail or reduce quantisation error but increases data size in direct proportion.
Watch for: Do not describe Digital representation of sound vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
93Musical Instrument Digital Interface (MIDI)
Specification reference: 4.5.6.8
MIDI event messages is the relevant idea. A note-on message can record pitch, channel and velocity; a later note-off message ends the note. MIDI represents musical performance instructions as event messages rather than storing sampled audio waveforms.
Watch for: Do not describe Musical Instrument Digital Interface (MIDI) vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
94Data compression
Specification reference: 4.5.6.9
Lossy compression discards selected information to achieve greater reduction and cannot reconstruct the exact original. Controlled loss may be acceptable if visible quality remains sufficient, but repeated editing or scientific use may not tolerate it.
Watch for: Do not describe Data compression vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
95Encryption
Specification reference: 4.5.6.10
Encryption applies a cipher and key to plaintext to produce ciphertext; decryption with the required key recovers plaintext. M is plaintext, C is ciphertext, and the cipher's keyed transformation is encryption rather than compression.
Watch for: Do not describe Encryption vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
96Relationship between hardware and software
Specification reference: 4.6.1.1
Whether something is described as hardware or software depends on whether it is the physical component or encoded instructions, even when they work as one device. The chips and memory are hardware; the firmware instructions stored in them are software.
Watch for: Do not describe Relationship between hardware and software vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
97Classification of software
Specification reference: 4.6.1.2
software attributes and suitability is the relevant idea. It is unsuitable despite speed because compatibility is an essential requirement. Choosing software considers required functions, performance, compatibility, usability, security, support and cost.
Watch for: Do not describe Classification of software vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
98System software
Specification reference: 4.6.1.3
translator is the relevant idea. A compiler, interpreter or assembler performs the relevant translation path. A translator converts program code from one representation or language into another form that can be executed or further processed.
Watch for: Do not describe System software vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
99Role of an operating system
Specification reference: 4.6.1.4
resource-allocation trade-off is the relevant idea. The OS can reduce or schedule the backup's I/O so the interactive process remains responsive. OS resource management balances responsiveness, throughput, fairness and priority among competing processes.
Watch for: Do not describe Role of an operating system vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
100Classification of programming languages
Specification reference: 4.6.2.1
machine code is the relevant idea. It may not execute because opcodes and instruction formats are processor specific. Machine code consists of binary instructions in the processor's specific instruction set and can be executed directly by that processor.
Watch for: Do not describe Classification of programming languages vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
101Types of program translator
Specification reference: 4.6.3.1
assembler is the relevant idea. The assembler encodes its opcode and operands into the corresponding machine instruction. An assembler translates assembly-language mnemonics and symbolic operands into machine-code instructions for a target processor.
Watch for: Do not describe Types of program translator vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
102Logic gates
Specification reference: 4.6.4.1
An edge-triggered D-type flip-flop stores the D input value on the active clock edge and holds that value until another active edge. The stored Q output retains the value captured at the edge rather than following D continuously.
Watch for: Do not describe Logic gates vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
103Using Boolean algebra
Specification reference: 4.6.5.1
Distributive and absorption identities can remove redundant terms while preserving every truth-table output. By absorption, A OR (A AND B)=A; when A is true the result is true, and when A is false both terms are false.
Watch for: Do not describe Using Boolean algebra vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
104Internal hardware components of a computer
Specification reference: 4.7.1.1
The processor executes instructions and operates on data held in registers and main memory, while main memory stores active programs and data. Its instructions and working data are loaded into main memory so the processor can fetch and execute them.
Watch for: Do not describe Internal hardware components of a computer vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
105The stored-program concept
Specification reference: 4.7.2.1
Because instructions are encoded bit patterns in memory, software can be loaded, copied and changed without rewiring the processor. Loading a different stored instruction sequence changes its behaviour while the hardware remains the same.
Watch for: Do not describe The stored-program concept vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
106The processor and its components
Specification reference: 4.7.3.1
General-purpose registers hold operands and intermediate results; the status register holds condition flags used by later instructions. The ALU sets the zero flag in the status register, and the branch tests that flag to decide whether to jump.
Watch for: Do not describe The processor and its components vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
107The fetch–execute cycle and the role of registers
Specification reference: 4.7.3.2
During execute, the processor performs the decoded operation, which may use the ALU, registers, memory or I/O and update flags or PC. The ALU adds the register values, stores the specified result and updates status flags before the next cycle.
Watch for: Do not describe The fetch–execute cycle and the role of registers vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
108The processor instruction set
Specification reference: 4.7.3.3
An instruction set is the collection of machine operations and encodings implemented by a processor family. The processor cannot decode them correctly, so source must be translated for its instruction set or emulated.
Watch for: Do not describe The processor instruction set vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
109Addressing modes
Specification reference: 4.7.3.4
Immediate addressing avoids a separate operand memory read but can encode only values that fit the operand field. It cannot include that constant directly in this format; it must obtain it through memory, multiple instructions or another supported mechanism.
Watch for: Do not describe Addressing modes vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
110Machine-code and assembly-language operations
Specification reference: 4.7.3.5
compare and conditional branch is the relevant idea. The branch loads PC with target because the comparison found equality. COMPARE updates status flags from an operand comparison, and a conditional branch changes PC only when its tested condition is true.
Watch for: Do not describe Machine-code and assembly-language operations vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
111Interrupts
Specification reference: 4.7.3.6
interrupt service routine is the relevant idea. The ISR reads or buffers the code and acknowledges the device before returning. An ISR is the code that identifies or handles the event, communicates with the device or system and clears the interrupt condition.
Watch for: Do not describe Interrupts vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
112Factors affecting processor performance
Specification reference: 4.7.3.7
clock speed is the relevant idea. The higher GHz value alone cannot prove which completes the workload faster. Higher clock speed provides more cycles per second, but performance also depends on work per instruction, architecture, memory and heat limits.
Watch for: Do not describe Factors affecting processor performance vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
113Input and output devices
Specification reference: 4.7.4.1
RFID is the relevant idea. RFID can read suitable tags through packaging and may read several in range, unlike a line-of-sight barcode scan. RFID uses radio communication between a reader and a tag carrying an identifier or data, often without line of sight.
Watch for: Do not describe Input and output devices vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
114Secondary storage devices
Specification reference: 4.7.4.2
A hard disk stores magnetised patterns on rotating platters and uses moving heads, offering high capacity but mechanical latency and vulnerability to shock. An HDD may suit it, while access time and mechanical failure risk require backup planning.
Watch for: Do not describe Secondary storage devices vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
115Individual, social, legal and cultural issues and opportunities
Specification reference: 4.8.1
legislative challenge is the relevant idea. Legislators face definitions, jurisdiction, enforceability, proportionality and future-proofing challenges; technical and affected-party evidence is needed. Digital technology changes faster than many legal processes, crosses jurisdictions and creates trade-offs between innovation, rights, enforcement and unintended consequences.
Watch for: Do not describe Individual, social, legal and cultural issues and opportunities vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
116Communication methods
Specification reference: 4.9.1.1
Parallel transmission sends several bits simultaneously over separate lines and can suit short internal paths, but line count and skew grow with distance. An eight-line parallel path can transfer the word at once when the short distance keeps timing aligned.
Watch for: Do not describe Communication methods vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
117Communication basics
Specification reference: 4.9.1.2
protocol is the relevant idea. Communication fails because physical connection alone is insufficient; they need a shared protocol. A protocol is an agreed set of rules for communication, including message format, meaning, sequencing, timing and error handling.
Watch for: Do not describe Communication basics vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
118Network topology
Specification reference: 4.9.2.1
star-link failure is the relevant idea. Other host links remain intact, so only that workstation loses connectivity. In a physical star, one host-link failure normally isolates that host, while failure of the central device can disrupt the whole star.
Watch for: Do not describe Network topology vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
119Types of networking between hosts
Specification reference: 4.9.2.2
central management is the relevant idea. Changing the centrally managed account can affect all clients consistently. Client–server design supports central accounts, backup, security policy and resource control, but requires server capacity and administration.
Watch for: Do not describe Types of networking between hosts vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
120Wireless networking
Specification reference: 4.9.2.3
SSID is the relevant idea. The common SSID identifies the service set and can support movement between its access points subject to configuration. An SSID names a wireless network so clients and administrators can distinguish the intended service set.
Watch for: Do not describe Wireless networking vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
121The Internet and how it works
Specification reference: 4.9.3.1
A URL identifies a resource and can contain a fully qualified domain name; DNS resolves the domain name to an IP address used for routing. DNS resolves example.org, then the client connects to the resulting address and requests the specified resource path.
Watch for: Do not describe The Internet and how it works vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
122Internet security
Specification reference: 4.9.3.2
A firewall can filter packet fields, proxy application connections and use stateful inspection to judge packets in the context of established traffic. A stateful firewall can reject it because its connection table contains no matching established session.
Watch for: Do not describe Internet security vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
123TCP/IP
Specification reference: 4.9.4.1
MAC address is the relevant idea. The router frames it with the destination interface's MAC address for delivery on that LAN. A MAC address identifies a network interface for local link-layer delivery and is used within the current local network segment.
Watch for: Do not describe TCP/IP vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
124Standard application-layer protocols
Specification reference: 4.9.4.2
FTP is the relevant idea. Anonymous access can serve downloads, while non-anonymous credentials control upload permissions. FTP transfers files between an FTP client and server and can permit anonymous or authenticated access according to server policy.
Watch for: Do not describe Standard application-layer protocols vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
125IP address structure
Specification reference: 4.9.4.3
host identifier is the relevant idea. They require different valid host identifiers so their complete IP addresses are distinct on that subnet. The host-identifier part distinguishes an interface within the network identified by the prefix.
Watch for: Do not describe IP address structure vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
126Subnet masking
Specification reference: 4.9.4.4
mask consistency is the relevant idea. They disagree about which destinations are on-link, causing misdirected traffic; correct the configuration to the designed prefix. A valid routing design must apply the intended mask consistently; using a different prefix length changes the network/host boundary.
Watch for: Do not describe Subnet masking vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
127IP standards
Specification reference: 4.9.4.5
reason for IPv6 is the relevant idea. The 128-bit IPv6 space supplies enormously more unique addresses than 32-bit IPv4. IPv6 was introduced principally to overcome IPv4 address exhaustion and support long-term Internet growth, alongside protocol improvements.
Watch for: Do not describe IP standards vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
128Public and private IP addresses
Specification reference: 4.9.4.6
A private IP address is intended for internal networks and is not routed across the public Internet as a destination. Internet routers do not route that private destination globally; NAT commonly represents its outbound traffic with a public address.
Watch for: Do not describe Public and private IP addresses vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
129Dynamic Host Configuration Protocol
Specification reference: 4.9.4.7
DHCP purpose is the relevant idea. DHCP provides compatible settings without requiring manual entry for that device. DHCP automatically supplies hosts with network configuration such as an IP address, subnet mask, default gateway and DNS server.
Watch for: Do not describe Dynamic Host Configuration Protocol vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
130Network Address Translation
Specification reference: 4.9.4.8
Network Address Translation changes address information as packets cross a gateway and records a mapping between internal and external flows. The gateway replaces the private source with a public-facing address and remembers how to translate the reply back.
Watch for: Do not describe Network Address Translation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
131Port forwarding
Specification reference: 4.9.4.9
Ordinary outbound NAT creates temporary mappings from internal connections, while port forwarding is a configured rule for selected inbound traffic. The browser uses a dynamic NAT mapping; the server connection needs the preconfigured forward.
Watch for: Do not describe Port forwarding vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
132Client–server model
Specification reference: 4.9.4.10
CRUD operations map conceptually to Create, Retrieve, Update and Delete, commonly using POST→INSERT, GET→SELECT, PUT→UPDATE and DELETE→DELETE in the AQA model. Send a PUT request to the appropriate resource so the server performs the update operation.
Watch for: Do not describe Client–server model vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
133Thin-client versus thick-client computing
Specification reference: 4.9.4.11
thin client is the relevant idea. The server performs most work, allowing simpler client hardware and central administration. A thin client performs limited local processing and relies heavily on a server for applications, computation or storage.
Watch for: Do not describe Thin-client versus thick-client computing vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
134Conceptual data models and entity–relationship modelling
Specification reference: 4.10.1
entity identifier is the relevant idea. Use memberId as the identifier and underline it in the entity description. An entity identifier is the attribute or attribute combination that uniquely distinguishes each entity occurrence.
Watch for: Do not describe Conceptual data models and entity–relationship modelling vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
135Relational databases
Specification reference: 4.10.2
relation is the relevant idea. Each row is a course tuple and each column is an attribute such as courseId or title. A relational database stores data in relations, commonly represented as tables of rows and named attributes with defined domains.
Watch for: Do not describe Relational databases vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
136Database design and normalisation techniques
Specification reference: 4.10.3
first normal form is the relevant idea. Move phone occurrences to separate rows or a related table so each stored attribute value is atomic. A relation in first normal form has atomic values and no repeating groups within a row.
Watch for: Do not describe Database design and normalisation techniques vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
137Structured Query Language
Specification reference: 4.10.4
DELETE is the relevant idea. Referential rules may reject deletion; remove or appropriately cascade dependent rows according to the designed policy. DELETE removes rows matching its condition and may be restricted by related foreign-key references.
Watch for: Do not describe Structured Query Language vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
138Client–server databases
Specification reference: 4.10.5
A record lock can prevent conflicting transactions from updating the same record simultaneously until the holder commits or releases it. B waits or is rejected until A completes, preventing both from writing from the same stale state.
Watch for: Do not describe Client–server databases vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
139Big Data
Specification reference: 4.11.1
fact-based model is the relevant idea. Add a new fact without redesigning every existing row, retaining provenance and individual assertions. A fact-based model stores each fact as one small assertion rather than forcing every item into one wide fixed row.
Watch for: Do not describe Big Data vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
140Function type
Specification reference: 4.12.1.1
type-compatible composition is the relevant idea. The composition is type-safe only when f's B values lie in g's accepted domain C. A function result can feed another function only when its result type is accepted by the next function's domain.
Watch for: Do not describe Function type vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
141First-class object
Specification reference: 4.12.1.2
Treating behaviour as a value lets reusable control patterns such as mapping, filtering and sorting accept different operations without duplicating traversal logic. Pass a different transformation function to one map implementation rather than write two loops.
Watch for: Do not describe First-class object vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
142Function application
Specification reference: 4.12.1.3
For a mathematical/functional mapping, the same function applied to the same argument denotes the same result, aiding substitution and reasoning. Both applications give 10, so either occurrence can be replaced by 10 in the expression.
Watch for: Do not describe Function application vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
143Partial function application
Specification reference: 4.12.1.4
Partial application returns another function until all required arguments have been supplied; full application returns the declared final result. The expression is not yet an integer product; it is a function waiting for the second integer.
Watch for: Do not describe Partial function application vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
144Composition of functions
Specification reference: 4.12.1.5
composition associativity is the relevant idea. Regrouping does not change their execution order or result, which supports modular pipeline construction. Function composition is associative when types align: h∘(g∘f) and (h∘g)∘f apply f, then g, then h.
Watch for: Do not describe Composition of functions vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
145Functional-language programs
Specification reference: 4.12.2.1
Functional programs favour results derived from inputs without mutating shared state, making calls easier to reason about and distribute. Neither depends on a shared counter, so their results can be combined without race-dependent state changes.
Watch for: Do not describe Functional-language programs vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
146List processing
Specification reference: 4.12.3.1
recursive list processing is the relevant idea. Compute 2+sum([5,7])=2+5+sum([7])=2+5+7+sum([])=14. A recursive list algorithm processes the head and applies itself to the tail, making progress toward the empty-list base case.
Watch for: Do not describe List processing vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
147Analysis
Specification reference: 4.13.1.1
data model is the relevant idea. Create a model linking Learner and Course through Enrollment with identifiers and required attributes. Analysis identifies the real-world entities, attributes, relationships, inputs and outputs that the solution must represent.
Watch for: Do not describe Analysis vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
148Design
Specification reference: 4.13.1.2
algorithm design is the relevant idea. Write and trace an unambiguous algorithm covering each threshold and boundary before coding. Design specifies the steps, conditions, iteration and error handling that transform inputs into required outputs.
Watch for: Do not describe Design vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
149Implementation
Specification reference: 4.13.1.3
Implementation translates designed algorithms into executable code without changing their intended control flow or boundaries. The code must use an equivalent stopping condition so it does not omit the final valid element or access index n.
Watch for: Do not describe Implementation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
150Testing
Specification reference: 4.13.1.4
Intended users perform or inform acceptance testing to judge whether the delivered system meets agreed requirements in realistic use. Acceptance fails because technical component correctness does not prove the system meets its specification and user task.
Watch for: Do not describe Testing vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
151Evaluation
Specification reference: 4.13.1.5
Evaluation distinguishes evidence-backed achievement from opinion and recognises trade-offs or unresolved risks. Use user task results, accessibility checks and requirement measures; personal preference is not sufficient evaluation evidence.
Watch for: Do not describe Evaluation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
152Purpose of the project
Specification reference: 4.14.1.1
The most important skill assessed is the ability to create a programmed solution to the chosen problem or investigation. Strong presentation cannot replace the central evidence: a functioning programmed solution that demonstrates technical skill.
Watch for: Do not describe Purpose of the project vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
153Types of problem or investigation
Specification reference: 4.14.1.2
A suitable project concerns a field the student already knows or is in a position to research sufficiently. The proposal is risky because the learner cannot yet understand or find out enough about the field to define a realistic problem.
Watch for: Do not describe Types of problem or investigation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
154Project documentation structure
Specification reference: 4.14.1.3
The project is assessed as Analysis, Documented design, Technical solution, Testing and Evaluation, in that presentation order. Use the five AQA section headings in the required order so the evidence can be located and marked reliably.
Watch for: Do not describe Project documentation structure vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
155Determining a level
Specification reference: 4.14.2.1
level descriptors is the relevant idea. Keep the level match, then use the quality within that level to choose a mark above its midpoint. Each level-of-response descriptor represents the typical overall performance around the middle of that level's mark range.
Watch for: Do not describe Determining a level vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
156Determining a mark
Specification reference: 4.14.2.2
AQA-standardised exemplar work can be used to decide whether the student's work is at the same, a better or a worse standard. Use that comparison as evidence for a lower mark within the level, not as a replacement for applying the descriptor.
Watch for: Do not describe Determining a mark vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
157Analysis marking criteria
Specification reference: 4.14.3.1
Requirements should arise through dialogue with intended system users or, for an investigation, recipients of its outcomes. The analysis lacks the user dialogue required to justify that the objectives reflect genuine stakeholder needs.
Watch for: Do not describe Analysis marking criteria vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
158Documented design marking criteria
Specification reference: 4.14.3.2
Documented design is assessed on how clearly it communicates the intended or actual structure, not merely on naming technologies used. The technology list is insufficient because it does not articulate how the key parts form the solution.
Watch for: Do not describe Documented design marking criteria vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
159Completeness of the technical solution
Specification reference: 4.14.3.3.1
Completeness should be judged by mapping implemented, working behaviour to the documented requirements rather than by counting screens or lines of code. The number of screens is not the criterion; the evidence shows only partial requirement coverage.
Watch for: Do not describe Completeness of the technical solution vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
160Techniques used in the technical solution
Specification reference: 4.14.3.3.2
Within the selected techniques level, the exact mark reflects descriptor coverage, coding style and the effectiveness of the solution. They need not receive the same mark because proficiency, coding quality and effectiveness determine position within the band.
Watch for: Do not describe Techniques used in the technical solution vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
161Example technical skills
Specification reference: 4.14.3.4.1
Group C examples include one-dimensional arrays, simple data types, a single-table database, linear search, simple calculations and non-SQL table access. The demonstrated techniques match the illustrative Group C level of demand.
Watch for: Do not describe Example technical skills vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
162Coding styles
Specification reference: 4.14.3.4.2
Excellent coding style uses modules or subroutines with appropriate interfaces through which their inputs, outputs and responsibilities are clear. Give the module an explicit parameter and result interface so its dependencies are visible and controlled.
Watch for: Do not describe Coding styles vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
163Testing marking criteria
Specification reference: 4.14.3.5
planned or fully explained representative tests is the relevant idea. Volume alone is not the aim; select representative tests and explain how they establish the required behaviour. Testing evidence may be produced during or after coding; tests should either be planned in a test plan or fully explained alongside carefully selected representative evidence.
Watch for: Do not describe Testing marking criteria vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
164Evaluation marking criteria
Specification reference: 4.14.3.6
Level 1 evaluation is the relevant idea. This superficial assessment of a small part of the outcome fits Level 1. Level 1 Evaluation earns 1 mark when only some outcomes are assessed and the treatment is superficial, with no worthwhile independent feedback.
Watch for: Do not describe Evaluation marking criteria vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
165Project tasks that are not of A-level standard
Specification reference: 4.14.4
If the chosen task is not of A-level standard, it is first marked against the normal criteria and then adjusted as AQA specifies. Apply the descriptor to the evidence first, then make the required downward adjustment for the task's insufficient demand.
Watch for: Do not describe Project tasks that are not of A-level standard vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
166Analysis documentation
Specification reference: 4.14.5.1
Where possible and necessary, the Analysis should report modelling that will inform design, such as a graph/network or entity-relationship model. An entity-relationship model would make the analysed structure explicit for the later database design.
Watch for: Do not describe Analysis documentation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
167Design documentation
Specification reference: 4.14.5.2
The design should identify important dependencies such as numerical, scientific or visualisation libraries, a relational database or a web framework. Name the library and explain its role because the structure and feasibility of the solution rely on it.
Watch for: Do not describe Design documentation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
168Technical-solution documentation
Specification reference: 4.14.5.3
Particularly difficult code should be explained, and listings should be divided into labelled sections that support navigation. Label and explain the function's non-obvious logic so the assessor can judge its purpose and technical quality efficiently.
Watch for: Do not describe Technical-solution documentation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
169Testing documentation
Specification reference: 4.14.5.4
Testing documentation should record the actual outcome and include sampled evidence such as before-and-after screenshots where appropriate. It is planning evidence only; add actual outcomes and representative execution evidence to show the solution was tested.
Watch for: Do not describe Testing documentation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
170Evaluation documentation
Specification reference: 4.14.5.5
The evaluation should discuss realistic improvements that could be made if the problem or investigation were revisited. Identify a specific evidenced weakness and propose a feasible improvement whose benefit and implementation are credible.
Watch for: Do not describe Evaluation documentation vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
171Assessment-objective breakdown for the NEA
Specification reference: 4.14.6
the complete NEA objective total is the relevant idea. Recalculate 12+42+8+4=66; adding the 9 AO2 marks gives the correct overall total of 75. Across the 75-mark NEA, AO2 contributes 9 marks and AO3 contributes 66 marks: 12 AO3a, 42 AO3b and 12 AO3c.
Watch for: Do not describe Assessment-objective breakdown for the NEA vaguely. Trace the algorithm, data or system state precisely and test boundary or failure cases.
No matching topics. Try another search.
The details, when you need them.
Your exact course
AQA · A Level · Computer Science · 7517
Version 1.6, 31 July 2023; current August 2026
Source checked: 2026-08-30. The current official specification controls assessment requirements and option choices.
Can parents and students try LearningP before signing up?
Yes. This page offers three original questions from three different skills on this exact course. Each answer has an explanation, followed by a sample heatmap showing what was correct and what to revisit. No account is needed, and taster answers are not saved.
What does the three-question heatmap tell a parent?
It shows the outcome of these three answers and gives a specific skill to discuss or practise next. It is not a full assessment, a mastery score or a grade prediction. Broader practice over time is needed to understand progress.
What does the AQA A Level Computer Science route cover?
LearningP currently maps 171 assessed areas for specification 7517. The visible topic map below is derived from the verified route; the current official specification remains controlling.
How many LearningP questions support this route?
The verified source bank contains 1710 original LearningP question records for this route. Every mapped area meets the current publication minimum and passed the latest blocker and review audit.
Does LearningP reproduce official exam questions?
No. LearningP uses official specifications and assessment materials to map content and demand, while its practice questions and explanations are independently authored.
Can this page predict an exam grade?
No. LearningP reports practice evidence, coverage, strengths and gaps. It does not guarantee or automatically predict examination outcomes.
Where should current assessment information be checked?
Use the official AQA specification and assessment-resource pages linked on this page, together with information supplied by the learner’s school.