A-Level Computer Science NEA Project Ideas
Pick a project with a genuinely hard algorithm at its centre: a game with a searching opponent, a route finder, an emulator, a scheduler. On AQA, the techniques you implement decide 27 of the 75 marks on their own. On OCR, 15 of the 70 are for evidence that you tested while building. Eleven ideas that clear that bar are below, and five popular ones that quietly do not.
Junaid Khalid, software engineer and Computer Science tutor · Reviewed September 2026
I ran every code block on this page before publishing it. Judge the rest of the advice by the code.
I have also read both specifications and both sets of marking criteria closely, and I have not marked an NEA and am not a moderator. Where this page says what the criteria state, that is quoted. Where it says what tends to happen, that is my judgement as an engineer.
while frontier:
cost, node = heapq.heappop(frontier)
if node == goal:
return cost
if cost > best_cost[node]:
continue # without this, settled nodes get re-expanded
for nxt, step in neighbours(node):
new_cost = cost + step
if new_cost < best_cost.get(nxt, float("inf")):
best_cost[nxt] = new_cost
came_from[nxt] = node
heapq.heappush(frontier, (new_cost + heuristic(nxt), new_cost, nxt))heapq has no decrease-key operation, so the standard approach is to push a second, cheaper entry for a node and ignore the stale one when it surfaces. Delete that continue and your search re-expands nodes it has already settled, and it still finds the right path on a 10 by 10 maze. If you have not met A* yet, that is fine, and it is idea 02 below. The shape of the mistake is the part worth taking: code that passes every test you thought to write, and quietly does the wrong thing at a size you never tried.The short version
- Choose for the algorithm, not the app. A grade tracker and a to-do list are two of the most recommended NEA ideas online, and both are a database behind a form.
- AQA students: read Table 1 first. The Group A list in AQA's own guidance governs a 27-mark section. Group B work tops out at 18 of those 27, Group C at 9.
- OCR students: there is no Group A. OCR publishes no difficulty table. Its top bands reward evidenced iterative development, and its language appendix asks for a graphical interface.
- Prove the hard part in week six. Write a throwaway version of your most difficult function before you commit. Changing project in October costs two weeks. Changing in February costs a grade.
- Cambridge International 9618 and IGCSE 0478 have no NEA at all. If that is your syllabus, none of the marks below apply to you.
The NEA is the coursework programming project, worth 20% of the A-Level on both OCR H446 and AQA 7517. On Cambridge International or Cambridge IGCSE, here is what you sit instead.
Where the marks actually are
“Worth 20% of your grade” is true on both boards and tells you nothing you can act on. What changes your decision is how the marks inside it are distributed.
OCR marks the programming project out of 70, spread fairly evenly across analysis, design, development and evaluation. AQA marks it out of 75 and puts 42 of them on the technical solution alone.
| Stage | OCR H446 | AQA 7517 | What the published criteria ask for |
|---|---|---|---|
| Analysis | 10 | 9 | A real stakeholder, requirements gathered from an actual conversation with them, and success criteria specific enough that each one could later be tested and either met or missed. |
| Design | 15 | 12 | The data structures, algorithms and structure of the solution you intend to build, written down in enough detail that a competent programmer could build it from your document. |
| Building it | 25 | 42 | OCR splits this into iterative development of a coded solution (15) and testing to inform development (10). AQA splits it into completeness of solution (15) and techniques used (27). |
| Testing | included above | 8 | AQA marks testing as its own section. OCR distributes the same evidence across development (10) and evaluation (5), which is a different instruction wearing the same word. |
| Evaluation | 20 | 4 | A judgement of the finished solution against the original success criteria. The single largest gap between the two boards sits on this row. |
| Total | 70 | 75 | Both worth 20% of the A-Level. |
Scroll the table sideways
Both boards subdivide their largest section, and the subdivisions are where the real instructions live. OCR's 25 development marks are 15 for iterative development of a coded solution and 10 for testing to inform development. Its 20 evaluation marks are 5 for testing to inform evaluation and 15 for evaluation of the solution. Add those together and 15 of OCR's 70 marks are for evidence that you tested while you were building, which is not something you can assemble in the last fortnight. AQA's 42-mark technical solution is 15 for completeness of solution and 27 for techniques used, and those 27 are the largest single block of marks in either specification.
That difference should change what you do with your time. On AQA, more than a third of the whole NEA turns on how technically demanding your code is and how completely you built it, while testing and evaluation together are 12 marks. On OCR, evaluation alone carries 20 marks against AQA's 4. An OCR student who builds something excellent and writes it up thinly loses considerably more than an AQA student doing exactly the same thing.
AQA also applies a penalty that is easy to miss. If the problem itself is judged not to be of A-Level standard, the mark is adjusted down by two marking levels in every section except the technical solution. Choosing something too easy therefore reaches back and takes marks off the write-up you did well.
What “hard enough” actually means
On AQA there is a published answer to this, below. On OCR there is not, and your part of this section starts here.
On AQA this is written down. The techniques-used section has three levels. Level 3, which is 19 to 27 of those 27 marks, asks for techniques demonstrating technical skill equivalent to those listed in Group A of Table 1. Level 2 is the same wording with Group B and tops out at 18. Level 1 is Group C and tops out at 9.
A project whose hardest technique is Group C can be beautifully built and immaculately written up and still lose up to 18 raw marks on that one section. That is 24% of the entire NEA, decided before you write a line of code, by the choice you made in September.
AQA Group A, as AQA describes it
| Data model | Algorithms |
|---|---|
| Complex data model in a database, for example several interlinked tables | Cross-table parameterised SQL, aggregate SQL functions, a generated DDL script |
| Hash tables, lists, stacks, queues, graphs, trees, or structures of equivalent standard. Files organised for direct access | Graph or tree traversal, list operations, linked list maintenance, stack and queue operations, hashing |
| A complex scientific, mathematical, robotics, control or business model | Recursive algorithms, advanced matrix operations, mergesort or a similarly efficient sort, complex user-defined algorithms such as optimisation, minimisation, scheduling or pattern matching |
| Complex user-defined use of object-oriented programming: classes, inheritance, composition, polymorphism, interfaces. A complex client-server model | Dynamic generation of objects, server-side scripting with request and response objects, calling parameterised web service APIs and parsing the JSON or XML that comes back |
Scroll the table sideways
Two caveats matter as much as the list itself. AQA says that Table 1 contains examples chosen to illustrate the level of demand, and that the use of alternative algorithms and data models is encouraged. It is not a checklist to be farmed. And AQA says the mark must be determined by what is seen in the program code, because a student might plan a sophisticated algorithm and not fully implement it, or overstate what they did in a discussion. Both sentences point the same way: build the hard thing, do not describe it.
Group A lists hashing. A Python dictionary is a hash table that somebody else implemented, so reaching for one means you have used the technique without demonstrating it.
class HashTable:
def __init__(self, capacity=64):
self.slots = [None] * capacity
self.used = 0
def _index(self, key):
i = hash(key) % len(self.slots)
while self.slots[i] is not None and self.slots[i][0] != key:
i = (i + 1) % len(self.slots) # linear probing
return i
def put(self, key, value):
i = self._index(key)
if self.slots[i] is None:
self.used += 1
self.slots[i] = (key, value)
if self.used / len(self.slots) > 0.7: # clusters make probes long
self._resize()CREATE INDEX idx_loan_open ON loan (member_id, returned_on);
SELECT b.title, l.due_on, COUNT(r.reservation_id) AS waiting
FROM loan AS l
JOIN book AS b ON b.book_id = l.book_id
LEFT JOIN reservation AS r ON r.book_id = b.book_id
WHERE l.member_id = ? AND l.returned_on IS NULL
GROUP BY b.title, l.due_on
ORDER BY l.due_on;EXPLAIN QUERY PLAN before and after creating it, and put both outputs in your evaluation. Mine goes from scanning the loan table to searching idx_loan_open.OCR publishes no equivalent, so do not assume symmetry
There is no OCR Group A. No difficulty table, no minimum technique list, no mark ceiling tied to complexity. Plenty of advice online quietly assumes the boards mirror each other and it is wrong. What OCR does publish is a requirement that the task be non-trivial with a substantial coded element, a closed list of acceptable languages in the H446 specification covering Python, the C family, Java, Visual Basic, PHP and Delphi, and one line in that same appendix that catches people out: OCR states there that all tasks completed in all languages need to have a suitable graphical interface.
So the advice you will read elsewhere that a text-based interface is fine, which is reasonable enough on AQA, is a problem on OCR. Budget the interface as real work rather than an afternoon at the end, and check the current wording with your teacher, because appendices get revised between specification versions and this is one that changes what you build.
OCR's top development band is about process rather than cleverness. Its wording asks for evidence of each stage of the iterative development process related back to the breakdown of the problem from analysis, prototype versions at each stage, a well structured and modular solution, code annotated for future maintenance, appropriately named variables and structures, validation on all key elements, and review at all key stages. Read that as a description of ordinary professional practice, because that is what it is, and it is the reason a commit history matters more on OCR than the cleverest function you write.
Everything in this section is the published wording of the two specifications, which you can check against the two documents linked above. The paragraph about what to do with it is mine.
Five ideas that quietly cap your grade
You will find these five on most lists of NEA ideas, and every one of them is a data-entry application: create a record, list the records, edit a record, show a total. They are pleasant to build, they demo well to a stakeholder, and they contain almost no assessable computer science. OCR's own project setting guidance points students towards complex games, simulations and automated scheduling instead.
| The idea | Why it caps you | What rescues it |
|---|---|---|
| Student grade tracker | Store, list, edit, average. The hardest technique in it is a loop and a division. | Make the prediction the project: fit a trend to past marks per topic, or schedule revision time across topics under a fixed hourly budget. |
| To-do list with deadlines | A list with a date field and a sort the language already provides. | Make the scheduling the project: dependencies between tasks, priorities, and a solver that says what to drop when the week does not fit. |
| Inventory or stock control | Forms over a table, plus one threshold comparison for the reorder alert. | Add reorder optimisation over lead times and demand history, which is a genuine constrained-minimisation problem with a defensible design decision inside it. |
| E-commerce product catalogue | Search and filter, which the database does for you the moment you write a WHERE clause. | Build the search yourself: an inverted index, tokenising and stemming, and ranking by term frequency. Then compare your results against the database version. |
| Library or appointment booking | Insert a row, then check whether an identical slot already exists. | Interval overlap rather than equality, a waiting list with a reallocation policy on cancellation, and a defensible answer for what happens to a partial booking. |
Scroll the table sideways
The machine learning wrapper
Calling a library's fit and predict is three lines, and the difficulty sits inside somebody else's package. This is a risk rather than a rule, and it is fixable: Group A includes complex user-defined algorithms, so a machine learning project reaches the top level perfectly well when you are the one who wrote the algorithm. There is an honest version of it below.
The framework project
A modern web framework will handle your routing, your database access, your templating and your login, and what is left of your own computer science can be very little. Again, a risk rather than a rule, since a web application with a genuinely hard engine behind it is a fine project. The diagnostic question is simple: which file contains the hard part? If the honest answer is that none of them do, change the project rather than the framework.
Eleven NEA project ideas, with the hard part named
Each of these has a specific algorithm or data structure at the centre, which is what makes it markable. The mistake I name for each one is the mistake I would expect, not one I have watched you make.
About the week figures
They are my estimate from building software professionally, not a board figure, and they cover the engine only: the algorithm and the data structures, at roughly six hours a week alongside three other A-Levels. Two things sit outside them. Add three to four weeks if you are on OCR, because of the graphical interface its language appendix asks for. Add more if the technique is new to you, since I am estimating at the speed of somebody who has written this kind of code before. Compare them against the 26-week schedule further down, where they map onto the build phases rather than the whole project.
The ones I would choose to get a good grade with the least risk. Each has a hard core that is thoroughly documented, so when you get stuck at 11pm in January you will find someone who has been stuck in the same place.
A two-player game with a searching opponent
Connect 4, draughts or Othello, played against a computer that looks several moves ahead rather than picking a legal move at random.
The search is easy to write and hard to make good. Minimax means assuming your opponent always picks their best reply, and alpha-beta pruning means skipping branches that cannot change the answer. Plain minimax on Connect 4 at depth seven is in the region of a few hundred thousand positions, and in Python that is slow enough to feel broken. The work goes into alpha-beta pruning, and pruning only pays off if you try the best move first, so move ordering matters as much as the search itself. The other half of the difficulty is the evaluation function: deciding what a position is worth when the game is not over yet. There is no correct answer, which is precisely why it is worth design marks.
def negamax(board, depth, alpha, beta):
if depth == 0 or board.is_over():
return board.score_for_player_to_move()
for move in board.moves_best_first():
board.play(move)
score = -negamax(board, depth - 1, -beta, -alpha)
board.undo(move)
if score >= beta:
return beta # the opponent would never allow this line
alpha = max(alpha, score)
return alphaboard.undo(move) has to restore the position exactly, and moves_best_first() is what makes the pruning worth having: search the centre columns of a Connect 4 board first and you cut the tree by an order of magnitude at the same depth. Count nodes visited with and without ordering, and your evaluation section has a number in it instead of an adjective.Structures it forces
The game tree via recursion, a two-dimensional array or a bitboard for the position, and a hash table as a transposition cache if you take it further.
Where it usually goes wrong
Building the interface first. A polished board with animations and a random-move opponent scores badly on both boards. The second one is subtler: forgetting to undo the move after the recursive call, which corrupts the position silently and produces an opponent that plays well at depth two and nonsense at depth five.
My time estimate
5 to 7 weeks
A route finder over a real network
Shortest path across something that exists: an underground map, your school bus routes, the footpaths across a campus, with more than one cost worth optimising.
Dijkstra is a page of code. What makes this an A-Level project is everything around it: getting real data into a graph, and modelling interchange and waiting time as edge weights rather than pretending every hop costs the same. Add A* with a straight-line-distance heuristic and you can measure nodes expanded against Dijkstra on the same query, which turns your evaluation into evidence. The heuristic must never overestimate the remaining distance, and explaining why that condition is what keeps the answer optimal is a genuine design justification rather than a description.
Structures it forces
A weighted graph as an adjacency list, a priority queue backed by a binary heap, and a dictionary of best-known costs per node.
Where it usually goes wrong
The stale heap entry in the code at the top of this page. After that, the most common error is modelling stations as nodes while ignoring that the thing which actually costs a passenger time is changing line, so a four-change route comes out cheaper than a direct one and the output looks plausible enough to go unchallenged.
My time estimate
4 to 6 weeks
A spaced-repetition revision scheduler
Flashcards where the software decides what you see today, using a real published scheduling algorithm rather than a fixed rota.
The algorithm, if you implement a real one. Leitner boxes on their own are too simple to carry a project. Something in the SM-2 family keeps an ease factor per card and adjusts the next interval from how you graded your recall, which gives you per-card state, a review queue ordered by due date, and one genuinely hard question: what do you do when 400 cards are due and the student has 20 minutes? There is no right answer, so you have to choose a policy and defend it. That is what a design section is for.
Structures it forces
A priority queue keyed on due date, per-card state records, and persistence that survives the program being closed mid-session.
Where it usually goes wrong
Recomputing the entire due list on every keystroke, which is invisible at 50 cards and unusable at 5,000. The other one is storing the next review as a fixed date rather than as an interval plus a history, which means the moment you change the algorithm every card's past becomes unusable and you cannot show a before-and-after in your evaluation.
My time estimate
4 to 5 weeks
The best assessable difficulty per hour spent, mostly because the hard part is small and self-contained rather than spread across the whole program. One of them doubles as revision for the fetch, decode, execute cycle on Paper 1.
An emulator for a small instruction set
A working processor in software: memory, an accumulator, a program counter, and an assembler that turns text with labels into instructions you can execute.
Being honest about the fetch, decode, execute cycle. Everything else starts as a dictionary lookup. The difficulty arrives with branching, because a branch writes to the program counter and suddenly the order in which you increment it decides whether your processor works at all. Then you add an assembler with labels, which needs two passes, because a forward jump refers to an address you have not calculated yet. That two-pass requirement is a real algorithmic insight, and it is unusually easy to explain clearly in a write-up.
OPS = {
"LDA": lambda vm, arg: vm.set_acc(vm.value(arg)),
"ADD": lambda vm, arg: vm.set_acc(vm.acc + vm.value(arg)),
"STA": lambda vm, arg: vm.store(arg, vm.acc),
"BRZ": lambda vm, arg: vm.jump(arg) if vm.acc == 0 else None,
"HLT": lambda vm, arg: vm.halt(),
}
def run(vm):
while not vm.halted:
opcode, operand = vm.memory[vm.pc] # fetch
vm.pc += 1 # increment BEFORE executing
OPS[opcode](vm, operand) # decode and executevm.pc += 1 sits between fetch and execute deliberately: a branch writes to vm.pc while it executes, so incrementing afterwards overwrites the jump. Adding an instruction means adding one entry to OPS and never touching the loop again, which is the modular structure OCR's top development band asks for, in a form you can point at.Structures it forces
A dictionary as the opcode table, a list as memory, a symbol table for labels, and a stack once you add subroutine calls.
Where it usually goes wrong
Incrementing the program counter after executing the instruction instead of before, so every branch lands one instruction late. I ran that version while writing this page. It runs off the end of memory and crashes rather than quietly returning a wrong answer, which at least makes it findable in an afternoon rather than a fortnight.
My time estimate
3 to 5 weeks
An automated timetable or exam scheduler
Given sessions, rooms or slots, and a set of clashes to avoid, produce a valid timetable, and say clearly when no valid timetable exists.
Constraint satisfaction, and the fact that the obvious search will not finish. Assigning slots left to right and backtracking on failure is correct and unusably slow. Choosing the most constrained session first, the one with the fewest legal slots remaining, changes the shape of the search entirely. I ran both versions over 40 random instances while writing this page: 271 recursive calls in total with the ordering heuristic against 2,099 without it, and on the worst single instance four calls against 467. That is the kind of measured before and after an evaluation section is asking for, and almost nobody supplies it.
def schedule(sessions, slots, assigned):
remaining = [s for s in sessions if s not in assigned]
if not remaining:
return assigned
# Most constrained first: the session with the fewest legal slots left.
session = min(remaining, key=lambda s: len(legal_slots(s, slots, assigned)))
for slot in legal_slots(session, slots, assigned):
assigned[session] = slot
result = schedule(sessions, slots, assigned)
if result is not None:
return result
del assigned[session] # undo: this is the backtrack
return Nonemin(...) is the entire optimisation, and del assigned[session] is the backtrack: leave it out and the function still returns answers, they are just wrong. OCR names automated scheduling and timetabling in its project setting guidance as a suitable problem type, so it is a shape the board has already sanctioned.Structures it forces
Recursion with an explicit undo, sets for the remaining legal slots per session, and a graph if you model clashes as edges, because a timetable is graph colouring wearing a hat.
Where it usually goes wrong
Leaving out the undo, so a failed branch leaves a partial assignment behind and every later result is wrong in a way that looks random. The second is declaring that no solution exists when the search merely ran out of patience. Those are different claims, and only one of them is defensible in an evaluation.
My time estimate
5 to 7 weeks
A simulation you can check against reality
An agent-based or cellular model of something real: the queue at a GP surgery, illness spreading through a school year, traffic at a junction, predator and prey on a grid.
Choosing what to model is easy and validating it is hard, which is exactly where the marks are. A simulation that produces attractive output nobody can check is worth very little. Pick something with a known answer for at least one simple case, because a single-server queue has one from queueing theory, then show your simulation converging on that number and argue about why it wobbles. The second difficulty is performance: checking every agent against every other agent is quadratic, so somewhere around a few thousand agents you are forced into a spatial grid or a quadtree to keep it interactive. AQA's Group A names a complex scientific or mathematical model directly, and this is the row it means.
Structures it forces
A two-dimensional grid or a spatial hash for neighbour queries, a priority queue of events if you go event-driven rather than tick-based, and arrays of agent state.
Where it usually goes wrong
Running one trial and reporting it as a finding. A simulation is stochastic, so a single run tells you almost nothing. Run fifty with different seeds and report a mean and a spread, which is ten extra lines and converts your evaluation from an impression into evidence. Fixing the seed permanently has the same problem wearing a disguise: stable output that only looks trustworthy.
My time estimate
4 to 6 weeks
A Wordle-style solver
The solver rather than the game: software that chooses the guess which will tell it the most, then narrows the candidate list from the feedback it gets back.
Scoring a guess before you make it. For each candidate guess you partition the remaining answers by the feedback pattern each would produce, then prefer the guess whose worst-case or average partition is smallest. With a five-letter word list in the low tens of thousands, comparing every guess against every possible answer runs into the hundreds of millions of pattern computations, so the naive version is too slow and you are forced into precomputing the pattern matrix or reducing the candidate set. Being pushed into that optimisation, and measuring what it bought you, is the project.
Structures it forces
Sets for candidate filtering, a dictionary mapping feedback pattern to bucket, and a precomputed two-dimensional array of guess against answer.
Where it usually goes wrong
Getting the repeated-letter rule wrong. The feedback for duplicate letters is genuinely fiddly, and a solver with a subtly wrong pattern function narrows to zero candidates and looks broken rather than wrong. Write that one function against a table of hand-checked cases before you write anything else in the project.
My time estimate
3 to 4 weeks
Higher ceiling, and a real chance of arriving at the deadline with something that does not run. I would only take one of these if you are already comfortable debugging your own code without someone sitting next to you.
A parser and evaluator for a small language
Turn text into a tree, then do something with the tree: a spreadsheet formula engine, a calculator with variables and functions, or a markdown to HTML converter.
Recursion that is not optional. A tokeniser is straightforward. Turning a stream of tokens into a tree that respects operator precedence and brackets needs either recursive descent or the shunting-yard algorithm, and understanding why precedence cannot be handled by a flat left-to-right scan is the insight the whole project rests on. Once you have a tree, evaluating it is a recursive walk, which lands squarely in AQA's Group A and also happens to be the cleanest code you will write all year.
Structures it forces
An abstract syntax tree built from node objects, a stack if you take the shunting-yard route, and a dictionary for variables and function names.
Where it usually goes wrong
Trying to handle precedence with nested conditionals over string positions. It works for two plus three times four, and collapses on the first bracket. The other reliable trap is forgetting that unary minus and binary minus are different operators that happen to share a character.
My time estimate
5 to 7 weeks
Encrypted messaging over sockets
Two or more clients talking through a server, with keys exchanged over the connection rather than agreed in advance.
Two hard things at once, which is why this sits in the third group. Sockets mean concurrency, so you need threads or asynchronous I/O and you will meet genuine race conditions. Key exchange means modular exponentiation and understanding why Diffie-Hellman is safe to perform in public, which is satisfying to implement with small primes. Use small primes deliberately and say so plainly: the project demonstrates the mechanism, and claiming it is a security product is the fastest way to lose credibility in an evaluation.
Structures it forces
A dictionary of connected clients keyed on socket, an outbound queue per client, and modular arithmetic for the exchange itself.
Where it usually goes wrong
Assuming one send equals one receive. TCP is a stream, so two messages arrive glued together or one arrives in halves, and you need a length prefix or a delimiter to recover the boundaries. Almost every first chat client works perfectly until two messages are sent quickly, which is also the last thing anyone tests.
My time estimate
6 to 8 weeks
A classifier with the maths written out by hand
Supervised learning on a small public dataset, handwritten digits or iris measurements or spam messages, with the learning algorithm written by you rather than imported.
This is the honest version of the machine learning project, and it is difficult for a reason that has little to do with the maths being hard. k-nearest neighbours is about fifteen lines and a legitimate place to start. A two-layer network trained by gradient descent is perhaps eighty, and the real problem is that when it fails to learn you get no error message, only a loss that sits still. Debugging that means checking your gradients numerically against a finite-difference approximation, which is the most useful technique in the whole project and one almost nobody is taught. Get it working and you can write a sentence no wrapper project can: you know your derivatives are correct because you tested them.
Structures it forces
Matrices as nested lists or arrays, a training loop with explicit forward and backward passes, and a test split kept strictly away from training.
Where it usually goes wrong
Testing on the training data, which produces a wonderful accuracy figure that means nothing at all. After that, comparing against a library implementation, quietly finding yours is worse, and not reporting it. Report it. A paragraph explaining why your version trails the library by three percent, and what the library does differently, is stronger evidence of understanding than a matching number would have been.
My time estimate
6 to 8 weeks
A recommender over a real dataset
Given ratings from a small real dataset, predict what someone would like, and be able to explain why the prediction came out that way.
Sparsity, and resisting the library. Collaborative filtering is cosine similarity between rating vectors, which is a handful of lines, but real rating matrices are almost entirely empty and the naive similarity gets dominated by users who have rated three things. Handling that honestly, with a minimum-overlap threshold and shrinkage towards the mean, is the actual work. The other half is evaluation: hold ratings back, predict them, and report a real error figure rather than showing three recommendations that look plausible.
Structures it forces
A sparse matrix as a dictionary of dictionaries, a similarity cache, and a heap to pull the top n neighbours without sorting everything.
Where it usually goes wrong
Importing a library, calling fit, and having no algorithm of your own. Group A does include complex user-defined algorithms, so this route can reach the top level. What decides it is whether the similarity function is yours.
My time estimate
5 to 7 weeks
A schedule that survives three other A-Levels
Twenty-six weeks, which is roughly September to March. This is my estimate rather than a board requirement. Boards normally need internally assessed marks by the middle of May, and your school's internal deadline will be earlier than that, so work backwards from your teacher's date rather than the board's.
| Phase | Weeks | What must exist by the end of it | What it protects |
|---|---|---|---|
| Choose and check | 2 | A named stakeholder who has agreed to talk to you, meaning a real person who would use the thing and is not you: a teacher, a club secretary, a parent, the school librarian. Plus a one-page problem statement your teacher has read and signed off. | Analysis, and the right to change your mind cheaply |
| Analysis | 3 | Requirements from a real conversation, turned into numbered success criteria that each could be tested and either met or missed. | OCR 10, AQA 9, plus every later section that refers back |
| Design and a spike | 3 | Data structures and algorithms written down, plus a throwaway 50-line program that proves the hardest part is possible for you. | OCR 15, AQA 12 |
| Thin end-to-end build | 3 | An ugly version that takes input, does the hard thing badly, and produces output. Committed to version control. | OCR iterative development, AQA completeness of solution |
| Feature by feature | 8 | One feature at a time, each with its test written before you move on, each committed with a message that says what changed and why. | The largest block of marks on either specification |
| Hard freeze | 2 | No new features. Bug fixes, input validation, and interface work only. On OCR this is also when you make the GUI presentable. | OCR validation and structure wording, AQA completeness |
| Testing and evaluation | 3 | The full test table run against the finished build, and an evaluation written against the original numbered criteria. | OCR 20, AQA 12 |
| Slack | 2 | Nothing at all. This is the fortnight that absorbs flu, mock exams and a laptop that dies in February. | All of it |
Scroll the table sideways
The spike in weeks six to eight is the most useful row on that table and the one nobody does. Before you commit five months, write the throwaway version of your hardest function and run it. If your minimax cannot search to depth four in under a second, or your parser falls over on the first bracket, you have learned that in October rather than February. Switching project in October costs you two weeks. Switching in February costs you a grade.
How to write it up so the marks are findable
A document where nothing refers to anything else is the most common way good work loses marks. Number your requirements in analysis, then use those numbers in design, in testing and in evaluation, so that the loop visibly closes and nobody has to go looking.
| Requirement | Success criterion, written to be testable | Test | The evaluation sentence it earns |
|---|---|---|---|
| R4. The librarian must not be able to double-book a practice room. | No booking is accepted whose time range overlaps an existing booking for the same room. Two bookings that touch exactly at 10:00 are accepted. | T4.1 to T4.6, six boundary cases including the two that touch, one fully contained, and one that encloses the existing booking. | “R4 met. T4.3 failed initially because I compared start times for equality rather than testing for range overlap. Fixed in commit 4a1c8e, retested, all six cases pass.” |
Scroll the table sideways
The test column is worth doing properly, because it is where the two boards agree. Write the cases as data rather than as prose, and generate the table in your document from the same list your program runs.
CLASH_CASES = [
# label, start, end, expect a clash?
("identical slot", "09:00", "10:00", True),
("touching, no overlap", "10:00", "11:00", False),
("fully contained", "09:15", "09:45", True),
("straddles the end", "09:45", "10:15", True),
("ends exactly at start", "08:00", "09:00", False),
("encloses the booking", "08:00", "11:00", True),
]
def clashes(a_start, a_end, b_start, b_end):
return a_start < b_end and b_start < a_endWhat an exemplar is worth, and where to find a real one
Both boards produce exemplar candidate work with examiner commentary, and much of it sits in the teacher-facing part of their websites rather than the public one. Ask your teacher to show you the board's own exemplar with the commentary still attached. The commentary is the valuable half, because it says why a section scored what it scored, and no finished project can tell you that by itself.
What does not help, and carries a real risk, is a stranger's complete NEA from a public repository. Reading one to see how a document is laid out is a different act from having it open beside you while you write, and the second is hard to stop once started. Published projects also get found, and a moderator who recognises a project is the worst possible reader for yours.
Take the shape rather than the sentences, and the shape is already on this page: numbered requirements, a design section that names its actual data structures, a test table generated from the code it tests, and an evaluation that answers the criteria you started with.
Two habits, both unromantic
Use version control. A private repository with honest commit messages gives you a backup for the day your laptop dies, a timestamped record of your own work supporting the declaration of authenticity you sign, and the raw material for the iterative development evidence OCR asks for by name.
Keep a decisions file from week one. One text file, and every time you choose between two approaches or hit a dead end, two lines: what you chose and why. By March that file is your design justification and half your evaluation, already written in your own words. The entries about dead ends are worth more than the flattering ones, because a project with no abandoned approaches reads like a project nobody thought about.
Frequently asked questions
What are some good NEA project ideas for A-Level Computer Science?
The ones that score well have a hard algorithm at the centre rather than a database behind a form: a game with a searching opponent, a route finder over real network data, an emulator for a small instruction set, an automated timetable scheduler, a parser for a small language, a simulation you can validate against a known result, and a classifier whose maths you wrote yourself. The five you will find on most lists online, grade trackers, to-do lists, inventory systems, product catalogues and booking forms, are weaker, because the hardest technique in each of them is a loop and a sort.
How do you get an A* in A-Level Computer Science?
Treat the NEA and the written papers as two separate problems. The NEA is 20% of the qualification and the only component you work on all year with feedback, which makes it the most controllable marks in the course. The other 80% is two written papers, and timed past papers with the mark scheme open afterwards are the only thing that reliably moves those. A perfect NEA does not rescue weak papers.
What are the AQA Group A skills and how many do I need?
Group A is a table of example techniques in AQA's NEA guidance, and reaching Level 3 on techniques used, which is 19 to 27 of those 27 marks, asks for technical skill equivalent to it. AQA states that the table is a set of examples rather than a checklist, and that alternative algorithms and data models are encouraged. AQA also states that the mark must be determined by what is seen in the program code. So what matters is whether the hardest thing in your program sits at that level, and whether you built it well enough to show proficiency, not how many rows you can list in your design section.
Are there example NEA projects or exemplars I can look at?
Both boards produce exemplar candidate work with examiner commentary, and much of it sits in the teacher-facing part of their websites rather than the public web. Ask your teacher to pull the board's exemplar with the commentary still attached, because the commentary is the useful half: it explains why each section scored what it did. Avoid working from a stranger's complete NEA out of a public repository, and take the shape of an exemplar rather than its sentences.
Can I use AI to help with my NEA?
Ask your teacher, because the policy that binds you is set by your centre under the JCQ document Instructions for conducting non-examination assessments (GCE & GCSE specifications), not by anyone else's blog. The line that matters is authorship: the work has to be yours, and you sign a declaration saying so. Using an assistant to explain recursion, which you then implement yourself, is a different act from having it produce your solution, and code you cannot explain out loud is a liability in any conversation about your own project.
Should I tell my teacher I have a tutor?
Yes, and it is worth doing early. Your teacher marks your NEA before the board moderates it, and the JCQ rules ask them to be satisfied the work is your own, which they can only do if they know what help you had. Telling them is what makes the help usable, because a teacher who knows a tutor is reviewing your design against the criteria can tell you where they disagree with it. Keeping it quiet is what turns ordinary support into a question nobody can answer at submission.
When is the A-Level Computer Science NEA deadline?
The one that matters is the internal deadline your school sets, and it is earlier than the board's. Exam boards normally need internally assessed marks by the middle of May, commonly 15 May, with the exact date published each year. OCR and AQA each publish their own key dates, so check the one for your board and then work backwards from your teacher's date.
Does Cambridge International 9618 or IGCSE 0478 have an NEA?
No, neither has coursework, and a fair number of people arrive here on the wrong syllabus. Cambridge IGCSE Computer Science 0478 and 0984 are assessed entirely by two written papers, Computer Systems and Algorithms, Programming and Logic. Cambridge International AS and A Level 9618 has four externally assessed components: Papers 1 and 3 are theory, Paper 2 is a written problem-solving paper answered in pseudocode where you are not required to write program code, and Paper 4 is a practical of two hours thirty minutes taken on a computer, where you paste your listings and screenshots into a Cambridge evidence document and work missing from it earns nothing. There is no pre-release material on 9618 either, so if someone has told you there is, they are probably thinking of the older 9608 syllabus. The boards and topics I cover include all four of them.
How many hours does an NEA actually take?
My estimate, from building software professionally rather than from any board document, is 120 to 180 hours across roughly 26 weeks, which is about six hours a week alongside three other A-Levels. The projects in group three sit at the top of that range or above it. The total matters less than the distribution, because iterative development is something you need evidence of having done, and a development history spanning eight months cannot be assembled at the end.
Where a second pair of eyes actually helps
Four things, and nothing beyond them: pressure-testing your idea before you commit five months to it, checking your design against the criteria your board publishes, debugging code that you wrote, and reading your write-up against the mark scheme. The most useful hour is the one before you have chosen.
Sessions are one-to-one over Zoom at £60 an hour, across OCR H446, AQA 7517, Cambridge International 9618 and Cambridge IGCSE 0478 and 0984, and the first conversation is a free introductory call. Bring your idea, or bring three and we will work out which one you can actually finish.
On how many hours this should be, my honest answer is fewer than you might expect. The NEA is a project you have to write yourself, so paying someone to sit through it with you would be both expensive and against the point. Where an outside pair of eyes changes the outcome is at three moments: choosing, once the design is drafted, and once before you submit. Book by the hour rather than in a block, and tell your teacher you are doing it.
I do not write or supply projects, for anyone, at any price. Under sections 27 and 28 of the Skills and Post-16 Education Act 2022 that is a criminal offence in England, and it would also mean signing a false declaration of authenticity.