Define the problem — Explain the actual problem or investigation, its context, current limitations and intended beneficiaries before proposing a technology. A fictional workshop service might struggle to distinguish full, available and cancelled sessions; that is more useful than saying it needs an app. State what the problem is and why a programmed solution or investigation is appropriate.
Intended users and dialogue — Establish requirements through relevant interaction with intended users or recipients of investigation outcomes. Interviews, observation, questionnaires and prototype feedback can reveal different evidence, each with limits. In an authentic project, record actual relevant dialogue rather than inventing quotations or treating the developer's assumptions as user approval.
Functional and quality requirements — Functional requirements describe what the system must do; quality requirements describe relevant conditions such as response, accessibility or reliability. Define a measurable context: return a workshop search within a stated time on declared test data/hardware, rather than simply make it fast. A chosen number needs justification from the user's task rather than arbitrary precision.
Specific success criteria — Write objectives that can later be tested or evaluated, with clear inputs, outputs and conditions. For example, reject a second current booking for the same learner/workshop pair and explain the reason to the operator. A list of technologies to use is not the same as a list of user outcomes to achieve.
Scope and constraints — State included functions, exclusions, data availability, time, hardware and relevant access restrictions. Separate an essential correct booking calculation from an optional visual theme. A manageable demanding scope is preferable to a broad unimplemented promise; narrowing scope must still leave appropriate technical opportunity and a useful coherent problem.
Model the relevant world — Use abstraction to represent important entities, relationships, states and rules while omitting irrelevant detail. A Booking model may need current/cancelled status and constraints on duplicate associations, but not the user's favourite colour. Explain assumptions and where the model departs from reality so later tests do not silently certify the wrong problem.
Investigation questions — An investigation needs a clear question, justified experimental method, suitable evidence and a programmed contribution. Comparing two path-finding approaches requires specified inputs, correctness checks and relevant performance measures, not just a chart with unspecified machine conditions. The recipient's information needs still matter when there is no conventional booking-style end user.
Feasibility and evidence — Check early whether necessary data, tools and technical methods are accessible within authorised conditions. A small prototype can expose a critical dependency before detailed polishing. Do not base a project on assumed permission to collect private records or a service that has not been shown to supply the required data.
Design, interfaces and iterative development
Design before and during construction — Plan the important model, data structures, algorithms, modules and human interface so another competent person can understand the intended solution. Design can be refined as evidence emerges; it need not be a once-only document frozen before any code. Keep documentation consistent with the actual final structure and explain material revisions.
Data structure choice — Choose structures to support required operations and relationships, considering correctness, access patterns and resource costs. A dictionary keyed by learner identifier can support lookup; an ordered event list can preserve history. Merely naming an advanced structure does not show its suitability, and unnecessary complexity can make a useful system harder to reason about.
Algorithm specification — Describe significant algorithms with clear inputs, outputs, preconditions, steps and relevant exceptional cases. Use readable pseudocode, flow or structured explanation suited to the algorithm. An unexplained screenshot of code is not a substitute for a design that communicates the intended method before relying on implementation details.
Module responsibilities — Divide a solution into cohesive parts with clear responsibilities and documented interfaces. For example, parsing input, calculating available capacity and displaying feedback can be separate modules. Pass needed values explicitly, define returned results/errors and limit unnecessary coupling rather than making every module read and write the same changing globals.
Interface contracts — Specify parameter types, result meaning, error behaviour and ownership/mutation assumptions. A capacity function can accept a nonnegative capacity and count and return availability or a defined invalid-state result. A name such as Validate does not establish which rules it checks, whether it changes data or how callers recognise failure.
Human interface design — Design the workflow around the task, including labels, input formats, meaningful errors, keyboard use, readable structure and appropriate visual alternatives. A polished screen cannot compensate for a misleading action or inaccessible essential control. Test the relevant interaction with users; an attractive mock-up alone is not evidence of effective operation.
Prototype purpose — A prototype tests a question, such as whether a search workflow is understandable or an algorithm can meet a deadline. It can be partial and may later be replaced. State what was learned and what remains unimplemented; a clickable screen with no underlying validation is not a fully working data service.
Iterative improvement — Use feedback and tests to revise requirements, design and implementation where needed. Record meaningful decisions and their effects instead of producing a diary of every keystroke. Iteration does not mean avoiding planning or never reaching a stable evaluated version; it means using evidence to improve the solution coherently.
Critical path in this specification — AQA uses critical path to mean the part on which a working system or complete investigation result depends. Tackle the central uncertain algorithm/data access early rather than perfecting peripheral decoration first. This usage should not be confused with claiming every project must include a formal scheduling-network calculation.
Implementation, debugging and technical explanation
Translate design into working code — Implement models as appropriate data structures and algorithms as executable operations, keeping the stated contracts and constraints visible. Code should solve the actual problem rather than merely demonstrate isolated language features. Useful comments explain purpose, assumptions or non-obvious reasoning instead of repeating every assignment in prose.
Readable structure and style — Use meaningful names, consistent layout, suitable modularisation and appropriately limited scope. Avoid unexplained magic numbers, literal values whose purpose is unclear and would be better expressed as named constants, and repeated logic that can diverge when edited. A technical solution is assessed for appropriate effective skill and coding quality, not simply length or the largest number of techniques named.
Syntax, runtime and logic faults — A syntax/compile error prevents valid translation under the language rules; a runtime fault occurs during execution; a logic fault gives unintended behaviour despite executable code. Some runtime conditions can be anticipated and handled. A program that compiles is not thereby correct, and catching every exception without a useful response can hide a defect.
Reproduce and isolate a defect — Record the smallest useful failing input, expected behaviour and observed behaviour. Trace relevant state or use breakpoints (places to pause execution) and watch values (variables monitored while paused or stepping) to locate the first departure from the intended invariant. Changing several unrelated lines and seeing one example pass makes the cause uncertain and can introduce new faults.
Trace and justify — Use a trace table or annotated state sequence to explain how an algorithm behaves, including selection, loops and data changes. Relate correctness to preconditions, progress and invariants where appropriate. One successful trace is evidence for that input; a general argument explains why the method handles its whole stated domain.
Efficiency and fair measurements — Discuss resource use as a function of relevant input size and distinguish asymptotic reasoning from measured elapsed time. Compare methods under controlled inputs/hardware and repeated runs where needed, reporting uncertainty. A fast result for one tiny example does not establish a better growth rate or universal performance advantage.
Errors and data boundaries — Validate at appropriate input boundaries, preserve useful error information and avoid partial corrupt changes. For a file import, distinguish malformed records, inaccessible paths and valid empty data under the declared specification. Define whether the operation rejects the whole input or accepts valid parts with a report; do not let accidental exception behaviour decide the policy.
Versioned evidence and dependencies — Keep a recoverable local history or suitable snapshots, identify external libraries/data and record relevant versions and licences. This supports reproduction and honest attribution rather than proving correctness by itself. A revision resource's sample code is a teaching example; a learner's assessed submission must satisfy the centre's current authenticity and assistance rules.
Test selection, expected results and user acceptance
Testing purpose and limits — Testing seeks errors and gathers evidence about specified behaviour. Passing selected cases does not prove the absence of all defects. Choose cases because they challenge requirements, branches and boundaries rather than because a predetermined large count looks impressive.
Test plan and oracle — For each meaningful case, state the requirement, input/setup, expected result and reason for selection before relying on observed output. The oracle is the method or evidence used to decide the correct result. Repeating the implementation's same faulty formula in the expected-result calculation can make a wrong program appear to pass.
Normal data — Normal tests represent typical valid use within the permitted domain. If a booking quantity must be an integer from 1 through 5 inclusive, quantity 3 is a suitable normal case. This does not replace tests of limits or invalid categories; define the rule before labelling a value normal.
Boundary data — Boundary tests exercise values at and near relevant transitions. For an allowed integer quantity 1 through 5 inclusive, test 1 and 5 as valid, 0 and 6 as adjacent invalid values, and explain the distinction. Boundary is about location relative to the rule; a case can also be erroneous because it lies just outside the permitted domain.For the explicitly inclusive integer domain 1 through 5, inputs 1 and 5 are valid boundary values, 3 is typical valid interior data, and 0/6 are adjacent invalid boundary cases. Nonnumeric input checks a different invalid category. Boundary position and validity are separate classifications; this is not a universal domain for every booking problem.
Erroneous data — Erroneous tests supply invalid values or situations, such as nonnumeric input, a disallowed negative, a duplicate booking or an inaccessible file under the stated task. Specify the expected safe response and any unchanged data. An invalid input should not be called handled merely because the program crashes without explanation.
Empty, repeated and stateful cases — Test no records, one record, duplicate identities, repeated actions and relevant operation sequences as the system requires. A cancellation followed by rebooking may expose a state bug invisible in an isolated insert. Reset or document initial state so results from one test do not accidentally contaminate the next.
Unit and integration checks — A unit check targets a defined component; an integration check targets communication or shared assumptions between parts. A parser and calculator can each pass local examples but disagree about whether capacity includes cancelled bookings. Select tests that cross the actual contracts rather than testing every module only in isolation.
Regression after correction — After a justified change, rerun the relevant failing case and checks likely to be affected, including important previously working behaviours. Record the defect, correction and evidence of its effect. Repeating every expensive test without a reason is not inherently stronger than a relevant planned regression set, while skipping known affected behaviour leaves a real gap.
Actual versus expected evidence — Record the observed result honestly, including failures and unresolved issues, and link useful evidence to the requirement. Screenshots can support visible interactions but cannot prove hidden data integrity by themselves. A test table filled with pass before execution is not evidence and should never be presented as actual testing.
Acceptance and user feedback — Acceptance concerns whether the solution meets the intended user's relevant requirements in practice. Obtain actual meaningful feedback and use it in evaluation; developer approval is not automatically user acceptance. AQA expects evidence of user feedback, not a fabricated detailed record of tests supposedly carried out by the user.
Evaluation, project scope and authentic evidence
Evaluate against objectives — Return to each measurable objective and explain whether, how and with what evidence it is met. Distinguish fully met, partially met and unmet requirements. An honest limitation can guide a useful improvement; repeating the feature list or asserting it works perfectly does not evaluate its suitability.Illustrative traceability for one fictional duplicate-booking requirement: user need, measurable objective, design/implementation, independently expected test and evidence-based evaluation. The arrows link evidence and meaning; they do not mandate a rigid one-pass development process or certify an actual learner project.
Use feedback critically — Relate user comments to actual tasks and tests, noting limitations of a small or unrepresentative feedback group. A preference for a colour differs from evidence that an essential operation fails. Resolve contradictions with further appropriate checks rather than deleting inconvenient feedback or claiming one positive comment establishes every quality requirement.
Specific improvements — Propose feasible changes tied to identified limitations, affected users and likely trade-offs. Replace make it better with a defined correction, evidence needed and its priority. Separate fixing an unmet essential requirement from adding an optional enhancement; neither should be falsely reported as already implemented.
Choosing a suitable project — A project or investigation should be sufficiently understood or researchable, personally manageable and capable of demonstrating appropriate A-level technical skill. AQA allows varied problem types and development tools; the examination's VB.NET route does not itself impose a universal ban on other NEA tools. Actual project choices and support should be agreed under the centre's assessment arrangements.
Technical contribution and evidence — The project assesses a programmed solution or investigation, not documentation alone. AQA allocates 75 marks overall: analysis 9, documented design 12, technical solution 42, testing 8 and evaluation 4; the technical solution divides into completeness 15 and techniques 27. These allocations describe the published scheme and are not a calculator guaranteeing a mark from a feature checklist.
Appropriate techniques and quality — Choose techniques because they fit the problem and demonstrate effective skill, then explain their implementation and suitability. Naming a database, graph or recursive function does not automatically earn a top band. Assessment considers the quality, appropriateness and proficiency of the actual solution alongside the published descriptors.
Concise documentation order — Present relevant analysis, design, technical solution evidence, testing and evaluation coherently in the assessed order while acknowledging iterative development. The reporting order does not require a rigid one-pass waterfall process. Enough precise explanation should let a reviewer understand the work without unnecessary volume or decorative repetition.
Independent work and attribution — Develop and explain the learner's own work, acknowledge external sources and assistance according to current centre/awarding rules and retain appropriate evidence of contribution. Do not submit a copied teaching fixture as an original NEA solution or invent dialogue, test runs or outcomes. Similar broad interests do not justify sharing a near-identical project within a centre.
Current administration and support — Assessment authentication, permitted assistance, evidence and submission procedures must follow the current AQA/centre instructions applicable to the learner's cohort. These notes teach transferable method and the verified published assessment structure; they do not invent a live project brief, submission date, mark award or permission to bypass supervised assessment rules.
Test yourself
50 questions · Random sets of 10. These quick checks support revision; practise longer explanations and justified judgements too.
Mr Kidman's Classroom
