A Level Computer Science NEA: How to Maximise Your Marks

The Non-Exam Assessment (NEA) is worth 20% of your A Level Computer Science grade — and for many students, it’s the part they’re most anxious about. This guide, written from a marker’s perspective, explains exactly how to approach each section to maximise your marks.

Understanding What Markers Are Looking For

The NEA is not just a programming exercise. Markers assess how well you can solve a real problem — which means every section (analysis, design, implementation, testing, evaluation) must be evidence-led and linked to genuine requirements.

The most common reason students lose marks is not the quality of their code — it’s insufficient documentation, vague analysis, and a mismatch between what they said they’d build and what they actually built.

---

Choosing Your Project

This is the most important decision you’ll make. A good project choice makes every subsequent section easier.

What makes a good NEA project?

A real stakeholder with real needs. Your project needs a genuine user — a parent who runs a small business, a teacher who manages school clubs, a local sports team. Not “a user” in the abstract, but a specific person you can interview and whose feedback you can document.

Sufficient complexity. You need to demonstrate:

• Data structures beyond simple lists (e.g., dictionaries, classes, files, database)
• At least one algorithm that isn’t trivial (sorting, searching, pathfinding, etc.)
• A user interface (even a simple CLI qualifies)
• Error handling and validation

Achievable scope. This is where many students go wrong in both directions:

• Too simple: a number guessing game or basic calculator won’t score highly
• Too ambitious: a full social media platform won’t get finished

A good scope is something that takes 3–6 weeks of consistent work, produces a working product, and lets you demonstrate a range of techniques.

Proven project ideas that work well

• A stock/inventory management system for a small business
• A scheduling or booking system (sports sessions, appointments)
• A quiz/flashcard application (well-suited to database work)
• A game with save/load functionality and a scoring system
• A data analysis tool (e.g., sports performance tracker)
• A library or resource management system

---

The Analysis Section (9 marks)

The analysis is where you define what the system must do — not how it will do it.

What to include

1. Problem identification: What is the problem? Why does it need solving? What are the limitations of any current approach (e.g., spreadsheets, paper records)?

2. Stakeholder interview: Document a real conversation. Include questions you asked, and the answers you got. This is often missing entirely — and it costs marks.

3. Requirements: A numbered list of both:

   • Functional requirements: what the system must do (e.g., “The system must allow the user to add a new customer record”)
   • Non-functional requirements: how the system must perform (e.g., “The system must load within 2 seconds”, “The interface must be usable without training”)

4. Success criteria: How will you know if the system is successful? These criteria are referenced back in your evaluation.

Examiner tip: Be specific

“The system should be easy to use” is too vague — it’s not measurable. “A new user with no prior training should be able to add a stock item within 60 seconds” is measurable and demonstrates clear thinking.

---

The Design Section (15 marks)

Design is the largest section after implementation. Many students rush it — which is a mistake.

What to include

Structure charts / module decomposition: Break your solution into functions/modules and show how they relate. This doesn’t have to be beautiful — it has to be clear.

Data structures: Define every significant data structure you’ll use. If you’re using a dictionary, show the keys and value types. If you’re using a class, show the attributes and methods. If you’re using a database, show a normalised entity-relationship diagram.

Algorithm design: Write pseudocode or flowcharts for your key algorithms. Don’t just write pseudocode for trivial things — focus on the interesting/complex parts.

User interface design: Sketches or wireframes of your main screens. Show what input fields, buttons, and outputs will be present.

Test plan: Design your tests before you write the code. Include:

• Normal data tests
• Boundary value tests
• Erroneous/invalid data tests

Examiner tip: Design should lead your implementation

If your design and your final product are completely different, it suggests you designed after building. Markers can tell, and it reduces your design marks.

---

The Implementation Section (32 marks)

This carries the most marks. A working, complex program is essential.

Mark band summary (AQA)

Band	Description
1–8	Simple program, limited structure, minimal use of data structures
9–16	Some structure, basic validation, limited complexity
17–24	Good structure, range of techniques, mostly working
25–32	Complex solution, all features working, excellent code quality

How to write implementation notes

You cannot just submit your code. You must include annotated screenshots or code excerpts with commentary explaining:

• What each section of code does
• Why you made specific design decisions
• How it links to your requirements
• Any challenges you faced and how you solved them

Demonstrating complexity

To reach the higher mark bands, your program must demonstrate complex techniques. Examples:

• Object-oriented programming with inheritance
• Recursive functions
• File I/O with error handling
• Database queries (SQL)
• Data validation at multiple levels
• A non-trivial algorithm (sorting, searching)

Code quality

Good code has:

• Meaningful variable names (student_name not x)
• Comments explaining non-obvious sections
• Functions with a single, clear purpose
• Error handling using try/except

---

The Testing Section (12 marks)

Testing must be systematic. You need evidence that you actually tested your program.

What markers want to see

1. A test plan (ideally created during design, then referred back to)
2. Evidence of testing: screenshots of your program running with specific test data
3. Expected vs actual results: show what you predicted and what happened
4. Correction: when tests fail, show that you fixed the issue and re-tested

Test types to include

• Normal data: typical valid inputs
• Boundary data: values at the edge of what’s valid (e.g., minimum/maximum age, zero stock)
• Erroneous data: invalid inputs (letters where a number is expected, empty fields)
• Extreme data: very large or very small values

Common mistake

Students often only test the happy path — valid inputs that work. Markers want to see that your validation works too. Show the error message that appears when you enter “abc” in an age field.

---

The Evaluation Section (7 marks)

The evaluation is your chance to reflect critically on what you produced.

Structure your evaluation around your success criteria

Go through each criterion from your analysis and assess:

• Was it met? (Yes / Partially / No)
• Evidence from your testing that supports this
• If not fully met, why not?

What a good evaluation includes

• Stakeholder feedback: Did your stakeholder test the system? What did they say?
• Limitations: Be honest. What can’t your system do? What would you improve?
• Future development: What would the next version include?

What a poor evaluation says

“My system works well and meets all the requirements.” This tells a marker nothing. You need specifics, evidence, and genuine critical reflection.

---

Timeline

The NEA typically runs from October/November to January/February, depending on your school. A sensible schedule:

Period	Work
Weeks 1–2	Choose project, identify stakeholder, conduct interview
Weeks 3–4	Write analysis section
Weeks 5–7	Design section (all sub-sections)
Weeks 8–14	Implementation (main coding work)
Weeks 15–16	Testing (systematic, with screenshots)
Weeks 17–18	Evaluation and final write-up

Don’t leave the write-up until the end — document as you go.

---

Getting Help

NEA support is one of the main areas I specialise in. Students regularly move from the lower mark bands to the highest with targeted sessions focused on their specific project.

If you’re stuck on your analysis, struggling with a complex programming problem, or not sure how to structure your testing section — book a 1-to-1 session. A single well-focused session at the right time can make a significant difference to your final mark.