A-Level Computer Science NEA Project Ideas
The NEA is worth 20% of your final grade on OCR (H446) and AQA (7517) A-Level Computer Science, and for most students it decides the final grade more than any single written paper. Most lists of project ideas online are ten vague suggestions with no explanation of why they score well. This one maps every idea to the real mark scheme, written by a tutor who is also a working software engineer, not just someone who has read the specification.
What the NEA actually is, and what it isn't
The non-exam assessment is a substantial programming project you plan, build, and document over the course of the year. Your teacher marks it first, and the exam board moderates a sample afterwards. This guide is specifically about the OCR and AQA UK-board NEA. If you're on Cambridge International A-Level (9618) or Cambridge IGCSE (0478/0984), your assessment works differently and none of the mark-scheme numbers below apply directly to you. Jump to the note on Cambridge International and IGCSE for the honest version of what applies to you instead.
Two things worth saying plainly before the list of ideas. The project has to be your own original work, and not only because getting caught means a mark of zero and an uncomfortable conversation with your exams officer. In the UK, under the Skills and Post-16 Education Act 2022, it is a criminal offence to commercially write, or even advertise writing, someone else's coursework for them. That isn't a rule people quietly bend, and it's why you won't find a working engineer offering to build your NEA for you, me included. What I can do, and what genuinely helps, is teach you how to pick a project that scores well and structure it so a moderator can follow your own work. That's what the rest of this page is about.
What the mark scheme actually rewards
Almost nobody explains why certain projects score well, because it means actually reading the assessment objectives rather than the topic list. The two boards weight things differently, and that difference should change how you spend your time.
OCR H446 Programming Project, 70 marks
| Strand | Marks | What it actually means |
|---|---|---|
| Analysis | 10 | Marks for identifying a real stakeholder, gathering genuine requirements from them, and turning those requirements into measurable success criteria you can test against later. |
| Design | 15 | Marks for showing the data structures, algorithms, and overall architecture you actually intend to build, in enough detail that someone else could follow it. |
| Developing the coded solution | 25 | The single biggest strand. Marks for a working, evidenced build: screenshots, code extracts, and testing carried out throughout development, not bolted on at the end. |
| Evaluation | 20 | Marks for judging your own solution honestly against the success criteria from Analysis, and for a believable account of what you would do differently. |
| Total | 70 |
AQA 7517 Non-Exam Assessment, 75 marks
| Strand | Marks | What it actually means |
|---|---|---|
| Analysis | 9 | A concise account of the problem, the stakeholder, and the requirements. AQA explicitly expects this to be brief, not padded. |
| Documented design | 12 | The plan for the technical solution: data structures, algorithms, and how the pieces fit together, again expected to be concise. |
| Technical solution | 42 | More than half of the entire NEA. This is the actual working program, assessed directly, which is why AQA rewards building over writing about building. |
| Testing | 8 | Evidence that you tested the solution properly against realistic and edge-case data, not just the happy path. |
| Evaluation | 4 | A short, honest judgement of the finished solution against the original requirements. Small weighting, so keep it tight rather than padded. |
| Total | 75 |
Read the two tables side by side and a real pattern shows up. OCR spreads its marks fairly evenly across the whole project lifecycle: Analysis and Design together are worth 25 of 70 marks, and Evaluation alone is worth 20, nearly a third of the total. Most students under-invest in evaluation because it feels like an afterthought once the code works, but on OCR it is worth roughly as much as the coding itself. AQA is closer to the opposite. Technical solution alone is 42 of 75 marks, well over half, so most of your AQA marks come from the working program, not the write-up. That also means Testing and Evaluation together are only 12 marks, so don't over-polish those sections at the expense of building something that actually works.
Ten NEA project ideas that are actually scoped right
Each of these is genuinely buildable in the time you have, and each comes with the real risk to watch for, because an idea that sounds good in a list and an idea that survives contact with a deadline are often not the same thing.
A library or media catalogue with loans and reservations
Catalogues books, games, or equipment for a school club or small collection, tracks who has what out and for how long, and flags overdue items.
Mark-scheme fit and risk: A safe, well-scoped choice on both boards: the requirements are easy to gather from a real stakeholder, your librarian or a club leader, and the logic maps onto operations examiners recognise. The risk is doing it so plainly that Evaluation has nothing to say, so build in one feature with a genuine design decision, such as search across multiple fields or a waiting list for popular items.
Data structures and techniques: Dictionaries or hash maps for fast lookup by ID, a queue for a reservation waiting list, file or lightweight database storage for persistence.
Stock control for a small shop or school tuck shop
Tracks inventory levels, records sales, and automatically flags items that need reordering.
Mark-scheme fit and risk: Strong Design marks on both boards because reorder logic is a real algorithm, not plain data entry. The risk is treating it as a database exercise and forgetting that moderators want to see coded logic, not a database front end pretending to be a program.
Data structures and techniques: Arrays or lists of stock records, sorting for reports, threshold-based alert logic, basic file I/O or an embedded database.
A revision timetable generator with clash detection
Given a list of exams, revision sessions, and a student's free time, produces a timetable that avoids double-booking and prioritises weaker subjects.
Mark-scheme fit and risk: A good Analysis opportunity because the stakeholder can genuinely be you or a classmate, with natural, testable success criteria: no clashes, every subject covered a minimum number of times. The risk is scope: full timetable optimisation is a hard constraint-satisfaction problem. Cap it at greedy scheduling with priority weighting, and say plainly in your write-up that you chose not to attempt a full optimiser.
Data structures and techniques: Lists of time slots, sorting by priority, constraint checking with nested loops or a simple greedy algorithm.
An encryption and decryption toolkit
Implements a couple of classical ciphers, Caesar and Vigenere, plus one simplified modern technique such as a small-prime RSA demonstration, with a clean interface to encode and decode messages.
Mark-scheme fit and risk: Directly touches the Security topic, which examiners like seeing connected to the NEA, and gives genuine Analysis material because you can compare each cipher's strengths and weaknesses with real evidence. The risk is attempting real-world-strength RSA: the marks don't reward cryptographic depth, and the maths can swallow the project. Keep the modern cipher deliberately simplified and say so honestly.
Data structures and techniques: String manipulation, modular arithmetic, arrays for key handling. No exotic data structures are needed here, and that's fine: this project earns marks on correctness and clarity, not complexity for its own sake.
A two-player game with a searching AI opponent
Something like Connect 4, noughts and crosses, or simplified draughts, played against a computer opponent that actually searches ahead rather than picking randomly.
Mark-scheme fit and risk: Popular for good reason. Implementing minimax, with or without alpha-beta pruning, is exactly the kind of build-and-test evidence OCR's Developing strand and AQA's Technical solution reward, and it produces an obviously testable, demoable product. The risk is scope creep into a polished GUI with animations. Keep the interface simple, even text-based is fine, and spend the saved time on the AI's depth and the design of its evaluation function, which is where the marks actually sit.
Data structures and techniques: Trees (the game tree), recursion, a 2D array for board state, and a position-scoring function.
A maze generator and pathfinding visualiser
Generates a random maze and shows a chosen algorithm, breadth-first, depth-first, or A*, finding a way through it, ideally letting the user compare more than one algorithm on the same maze.
Mark-scheme fit and risk: A strong Design and Analysis project because comparing algorithms gives measurable evaluation criteria, steps taken, nodes visited, time, instead of the vague 'I think it works well' most students fall back on. The risk is that maze generation itself quietly becomes half the project, so timebox it and treat generation as a supporting feature.
Data structures and techniques: A graph representation of the maze, queues and stacks for breadth-first and depth-first search, a priority queue for A*.
A personal budget tracker with categorised reports
Records income and spending, assigns categories, and produces simple summaries: spend per category per month, a running balance.
Mark-scheme fit and risk: A relatable stakeholder, yourself, a parent, or a club treasurer, and reporting naturally invites aggregation and simple charting that reads well in a write-up. The risk is that this idea is easy to make too thin. Plain data entry with a couple of totals will not earn strong marks under Developing or Technical solution on either board. Add at least one feature with real logic: recurring transactions, budget alerts, or a simple spending forecast.
Data structures and techniques: Dictionaries keyed by category, date-based sorting and filtering, aggregation functions for the reports.
A sports league or fixture manager
Takes a list of teams, generates a fixture list, records results, and calculates a league table with correct tie-break rules.
Mark-scheme fit and risk: League table logic, points, goal difference, head-to-head, is a genuinely non-trivial sorting and validation problem, giving real substance to Design and Developing sections, and the domain is easy to explain clearly in a write-up. The risk is that full round-robin fixture generation can get fiddly. A simplified single round is a legitimate, honestly-declared scope decision if you are short on time, not a weakness, as long as you say so in Evaluation.
Data structures and techniques: Arrays or lists of team records, custom sort logic for tie-breaks, nested loops for fixture generation.
A markdown-to-HTML note converter
Parses a simplified markdown syntax, headings, bold text, lists, links, written by the user, and converts it into valid HTML.
Mark-scheme fit and risk: Appeals to examiners because it demonstrates parsing and string processing rather than wiring up a database, and every feature you add is a clean, testable unit, exactly the incremental evidence that scores well under Developing the coded solution or Technical solution. The risk is trying to support the entire markdown specification. Pick six to eight elements and document the ones you left out, that's evidence of good scoping, not a gap.
Data structures and techniques: String tokenising and pattern matching, and, if you want to go further, a simple tree structure for nested elements. A flat, line-by-line approach is a perfectly legitimate, honestly-scoped choice too.
A booking or reservation system with clash detection
Manages bookings for a resource with limited capacity, a club minibus, a music practice room, a small clinic's appointment slots, and prevents double-booking.
Mark-scheme fit and risk: Clash detection is real logic, comparing time ranges rather than checking for an identical slot, which gives you a proper algorithm to design and test, and an easy-to-find stakeholder, a teacher or club committee, strengthens your Analysis section with real, evidenced requirements. The risk is scaling this up to multiple resource types at once. Keep it to a single resource; multi-resource scheduling is a genuinely hard problem that will eat the time you need for testing and evaluation.
Data structures and techniques: Lists of time-ranged bookings, interval-overlap checking, sorting by date and time.
How a working engineer would scope this differently
Build the smallest thing that works, then grow it
The biggest difference between a project that scores well and one that doesn't isn't ambition, it's sequencing. Professional software gets built the same way: a thin, ugly, end-to-end version first, input, some processing, output, then features layered in one at a time. Students who build outward instead, all the interface first, or all the data model first, tend to hit the deadline with several half-finished features and nothing that runs. Both mark schemes reward evidence of a working solution, not evidence of effort spent.
Pick something you can test end to end
This matters more than picking something that sounds impressive on paper. A simple project you can honestly test with ten meaningful cases and show the real outputs will outscore an ambitious one where only three features can be properly tested. AQA gives testing its own 8-mark strand, and OCR folds it into Developing the coded solution, but on both boards a moderator can tell the difference between a test table produced at the end and one that clearly drove real fixes during development.
Basic version control isn't optional
You don't need anything elaborate. A private repository with regular, honestly described commits gives you a real backup the day your laptop dies, and a timestamped record of your own progress, exactly the kind of evidence that supports the originality declaration you sign at the end. It also makes Evaluation easier to write, since you can look back at what actually changed and why, instead of reconstructing a plausible story from memory two days before the deadline.
Structure the write-up to be easy to mark well
In Analysis, name a real stakeholder and list requirements as testable success criteria, then reference those same criteria again in Evaluation, so a moderator sees the loop close. In Design, show the actual data structures and algorithms you used, not a generic flowchart. If your design section doesn't already reveal the technical decisions your code makes, the moderator has to go hunting for them inside your code instead, and that rarely works in your favour.
If you're on Cambridge International A-Level or Cambridge IGCSE
Everything above is specific to the OCR and AQA non-exam assessment, a teacher-marked coursework component. If you searched your way here from Cambridge International or Cambridge IGCSE, the mark-scheme numbers above don't apply to you, and it's worth being upfront about why rather than quietly implying otherwise.
Cambridge IGCSE Computer Science (0478 and 0984) has no coursework component at all. Your grade comes entirely from two written exam papers. If a teacher has mentioned a "project," it's worth checking whether they mean an internal school exercise rather than anything Cambridge itself marks.
Cambridge International AS & A Level Computer Science (9618) doesn't have an NEA either. Instead, the practical programming paper is built around pre-release material: Cambridge publishes it several weeks before the exam, you prepare and test a program against it in advance, then sit a written paper based on that preparation under exam conditions. The underlying skills overlap with everything above, decomposing a problem, choosing sensible data structures, testing properly, but nothing is submitted as coursework, and the mark-earning event is the written exam. If that's you, spend your preparation time genuinely understanding the pre-release material and rehearsing the kind of program it's likely to ask for, not picking a "project idea" the way an OCR or AQA student would.
Need a second pair of eyes on your NEA?
I tutor Computer Science one-to-one across Cambridge International, IGCSE, OCR and AQA, and NEA support is exactly this: helping you scope your project sensibly, reviewing your own code and write-up against the mark scheme, and catching the mistakes above before a moderator does. I don't write projects for students, for the reasons explained earlier, but if you want someone who has actually shipped software professionally to look at your plan before you commit months to it, get in touch.