AQA A-Level Computer Science (7517)

## Learning Outcomes

- Understand how the NEA documentation is structured and why the technical solution carries most of the marks
- Identify what to include in analysis, documented design, testing and evaluation
- Explain the difference between **completeness of solution** and **techniques used**
- Recognise what **self-documenting code** and appropriate annotation look like in a program listing
- Avoid common mistakes involving authenticity, weak evidence and overlong documentation
- Apply a practical structure for presenting an NEA write-up clearly for a third-party marker

## AQA A-Level Computer Science (7517) Syllabus

For the AQA A-Level Computer Science (7517), you are expected to understand the documentation and evidence required for the computing practical project, with a focus on the following syllabus points:

- Know that the **Non-Exam Assessment (NEA)** is Component 3 and is worth **20%** of the A-level
- Identify the five assessed sections: analysis, documented design, technical solution, testing and evaluation
- Recall the mark allocation of **75 marks** in total, including **42 marks** for the technical solution
- Explain the difference between **completeness of solution** and **techniques used** within the technical solution
- Understand what evidence is needed to show that a system was designed, programmed, tested and evaluated properly
- Know that documentation should be concise and support the code rather than replace it
- Understand authenticity requirements, including acknowledgement of outside materials and completion of the **Candidate Record Form (CRF)**

## Test Your Knowledge

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, look more closely at that area during your revision._

1. How many marks are available for the technical solution in the NEA?
2. What is the difference between analysis and documented design?
3. Why is a long report not the same as a high-scoring NEA?
4. What does self-documenting code mean?
5. What must be acknowledged if you used outside help, internet sources or AI tools?

## Introduction

The **computing practical project** is the NEA for AQA A-level Computer Science. It is a substantial programming project in which you either solve a realistic problem for a real end user or investigate a specific area of computing with guidance from a supervisor. Although the project includes documentation, the most heavily rewarded part is still the actual programmed solution.

This matters because many students make the same mistake: they spend too long polishing the write-up and not enough time improving the code. AQA’s structure makes the priority clear. Documentation must help a third party understand what you built, why you built it and how well it works. It is not there to hide a weak solution.

> **Key Term: Non-Exam Assessment (NEA)**
> The programming project for AQA A-level Computer Science, assessed internally and worth 20% of the final qualification.

## What the documentation is trying to prove

The documentation in the NEA has one main job: to provide clear evidence of your development process and your finished solution. A teacher or moderator should be able to read it and understand the problem, the planned design, the implemented program, the testing process and the final judgement on success.

![Computing practical project sections and mark allocation across analysis, documented design, technical solution, testing, and evaluation.](https://static.pastpaperhero.com/images/aqa-a-level-computer-science-7517-computing-practical-project-nea-documentation-guide_00.png)

_Project evidence is organised into analysis, documented design, technical solution, testing, and evaluation, with the largest weighting assigned to implementation._

The five assessed sections are:

- analysis
- documented design
- technical solution
- testing
- evaluation

The mark breakdown is:

- **Analysis: 9**
- **Documented design: 12**
- **Technical solution: 42**
- **Testing: 8**
- **Evaluation: 4**

This breakdown tells you how to allocate your time. The technical solution is worth more than all the other sections combined. That means advanced planning and clear evidence matter, but marks come mainly from working code that solves the problem effectively.

> **Key Term: technical solution**
> The actual programmed product and the evidence showing the quality, range and success of the programming techniques used.

A useful way to think about the write-up is that it should support the code, not compete with it. If your report is very long but the code is basic, incomplete or copied, the marks will still be low. If your code is strong, but the documentation does not explain requirements, design choices or testing clearly, you may lose avoidable marks.

Students often blur sections together. For example, they describe a screen layout in the analysis, paste pseudocode into the evaluation, or test requirements before they have stated them. That weakens the structure. A better approach is to ask one question for each section:

- **Analysis:** What problem am I solving, for whom, and what must the system do?
- **Documented design:** How will I build it?
- **Technical solution:** What did I actually build in code?
- **Testing:** Does it work as intended?
- **Evaluation:** How successful was it, and what should change next?
  > **Test Tip:** If a paragraph could fit equally well into three different sections, it is probably too vague. Make each section answer a different question.

### Analysis and documented design

The **analysis** section explains the problem before you start building the final system. A strong analysis does not just describe a general topic such as “I am making a booking system.” It should identify the real user or client, the current problem, and the exact requirements the solution must meet.

A strong analysis usually includes:

- the nature of the problem
- the intended end user or client
- required inputs
- expected outputs
- processing needed
- constraints such as time, hardware, skills or data availability
- success criteria or measurable objectives
  > **Key Term: analysis**
  > The stage where the problem is defined, user needs are identified, and clear requirements and success criteria are set.

Why does this matter? Because everything later depends on it. Testing is only meaningful if you know what you were trying to achieve. Evaluation is only convincing if you can compare the final system against earlier objectives. If your analysis says only “the system should be user-friendly,” that is too vague to test or evaluate well. A better objective would be “the user should be able to add, edit and search records through a menu-driven interface without editing raw files directly.”

The **documented design** section is different. It is not about why the project is needed; it is about how the solution will be structured. This is where you show decomposition, algorithms, data structures, interface layouts, file structures, database plans or class relationships, depending on the kind of project.

> **Key Term: documented design**
> The section that shows how the system will be built, including decomposition, algorithms, data structures and interface or data design where relevant.

A strong design section often includes:

- decomposition into modules or components
- pseudocode or flowcharts for key algorithms
- data structures such as lists, dictionaries, arrays, records or classes
- screen layouts for the user interface
- file or database structure where relevant
- explanations of design decisions

Here is the distinction students often miss:

- **Analysis** says, “The user needs to search bookings by date.”
- **Documented design** says, “I will implement this using a date field, validated input, and a search function that filters records.”

That distinction matters because analysis is about requirements; design is about implementation planning.

Design should also be realistic. If your design shows a huge object model, multiple APIs and a complex database, but the final code is much simpler, the design looks disconnected from the real project. Markers want evidence of genuine planning, not decorative diagrams.

> **Test Tip:** Use design evidence only where it helps a third party understand implementation. Ten pages of pseudocode for trivial functions is weaker than two pages of well-chosen algorithms for the hard parts.

### Technical solution and program listing evidence

The technical solution is the largest section because AQA is assessing programming skill, not report-writing skill. This section is judged in two ways:

- **Completeness of solution** — **15 marks**
- **Techniques used** — **27 marks**
  > **Key Term: completeness of solution**
  > How fully the finished program meets the requirements identified in the analysis.
  >
  > **Key Term: techniques used**
  > The range, appropriateness and successful implementation of programming methods shown in the coded solution.

These are not the same thing. A complete solution might meet almost every requirement but use only straightforward techniques. A technically ambitious project might include advanced methods, but if major requirements are unfinished, marks for completeness will fall.

A simple comparison makes this clearer.

Project A:

- fully working quiz system
- stores results, validates input, generates reports
- code is neat but technically modest

Project B:

- attempts AI pathfinding, database networking and procedural map generation
- some advanced code works
- key user features are broken or unfinished

Project A may score better for completeness. Project B may have stronger techniques if the advanced parts are genuinely implemented. Top marks usually require both: a working system and suitably demanding programming.

This is why choosing the right project matters. A project that is too easy limits your techniques marks. A project that is too ambitious may collapse before completion.

The program listing must help a third party follow the code. AQA expects it to be **appropriately annotated and self-documenting**.

> **Key Term: self-documenting code**
> Code written with clear identifiers, sensible structure and readable logic so that its purpose can be understood without excessive comments.

Self-documenting code usually includes:

- meaningful variable names such as `customerRecord` instead of `x1`
- sensible function names such as `calculateTotalCost()`
- consistent indentation
- modular structure
- named constants instead of unexplained literal values
- comments only where they add value

Poor practice:

- commenting every line
- using vague names
- pasting huge code blocks without labels
- including code that the student cannot explain

Better practice:

- divide the listing into clearly labelled sections
- briefly annotate difficult algorithms
- include an overview guide naming files, executables, databases or pathnames where needed
- explain unusual implementation choices

Students often think “annotated” means “heavily commented.” That is not true. Too many comments can make the listing harder to read and can suggest you are explaining around code rather than writing readable code.

For example, compare these two approaches.

Poor style:

- variable `a`
- comment: `# this variable stores the score`
- repeated many times

Better style:

- variable `playerScore`
- no comment needed unless the logic is unusual

This matters because strong code style is part of proving that you understand your own solution.

### Testing, evaluation and authenticity

Testing must show that the system works as specified. A claim such as “I ran the program and it worked” is not enough. Good testing evidence links directly back to requirements and covers a representative sample of the system.

> **Key Term: testing**
> The process of running planned checks on a program to compare expected outcomes with actual outcomes and identify faults.

A strong testing section should include:

- an overview of the testing strategy
- test data, including **normal**, **boundary** and **erroneous** cases where relevant
- expected outcomes
- actual outcomes
- evidence such as screenshots, printouts or video
- fixes or changes made after failures
- whole-system tests as well as tests of individual functions
  > **Key Term: boundary data**
  > Test values at the edge of the allowed range, used to check whether validation and processing work correctly at limits.

Suppose a booking system accepts bookings for 1 to 8 seats.

- **Normal data:** 4 seats
- **Boundary data:** 1 seat and 8 seats
- **Erroneous data:** 0 seats, 9 seats, text such as “four”

This matters because many faults appear at limits, not in ordinary cases. If you test only normal input, you may miss validation errors or crashes.

Testing should also prove resilienceness. For example, if a file is missing, does the program fail safely? If a user enters the wrong type, does validation catch it? These are the sorts of checks that show the system is reliable rather than just functional under ideal conditions.

The **evaluation** section is short in marks but still valuable. It should return to the original objectives and judge the finished system honestly.

> **Key Term: evaluation**
> A reasoned judgement of how well the finished system meets its original objectives, supported by evidence and user feedback.

A good evaluation should:

- copy or restate the original objectives
- explain whether each objective was met
- judge how effectively it was met
- include real user or supervisor feedback
- discuss limitations
- suggest realistic future improvements

A weak evaluation says, “The project went well and I would add more features.” A strong evaluation says, “The search function met the requirement for filtering by surname and date, but the export feature was incomplete because CSV output failed when records contained commas. User feedback also showed that the menu wording was unclear, so clearer prompts would improve usability.”

That level of detail shows evidence-based judgement.

Authenticity is a separate but critical issue. If the code is not clearly your own work, technical solution marks can be reduced heavily, even if the documentation looks good. This is why acknowledgements matter.

> **Key Term: Candidate Record Form (CRF)**
> The formal NEA authentication document signed by the student and teachers, used to confirm authenticity and declare materials used.

You must acknowledge outside materials not already credited in the work itself. That includes:

- books
- websites
- tutorial code
- internet information
- software tools
- **artificial intelligence (AI) tools**

Do not assume that changing variable names in borrowed code makes it yours. A marker may still detect that the logic is tutorial-derived or beyond your demonstrated understanding. Good project logs, dated progress evidence and testing videos can help support authenticity, but they are supporting evidence, not separate marked sections.

> **Test Tip:** If you cannot explain a section of your own code line by line, do not include it as if it were fully yours. Unclear ownership is a serious risk in the NEA.

## Key Point Checklist

_This article has covered the following key knowledge points:_

- The **NEA** is Component 3 of AQA A-level Computer Science and is worth 20% of the qualification
- The five assessed sections are analysis, documented design, technical solution, testing and evaluation
- The total mark allocation is **75**, split as 9, 12, 42, 8 and 4
- The technical solution is divided into **completeness of solution** and **techniques used**
- Analysis defines the problem, user, requirements, inputs, outputs, processing, constraints and success criteria
- Documented design shows how the system will be built through decomposition, algorithms, data structures and interface or data plans
- Program listings should be appropriately annotated and **self-documenting**, not overloaded with unnecessary comments
- Testing should include normal, boundary and erroneous data, plus expected and actual outcomes
- Evaluation should judge the finished system against original objectives and include real user or supervisor feedback
- Documentation should be concise and relevant because marks depend mainly on the quality of the coded solution
- Authenticity is essential, and outside materials including **AI tools** must be acknowledged
- The **Candidate Record Form (CRF)** must be completed and signed correctly for assessment

## Key Terms and Concepts

- Non-Exam Assessment (NEA)
- technical solution
- analysis
- documented design
- completeness of solution
- techniques used
- self-documenting code
- testing
- boundary data
- evaluation
- Candidate Record Form (CRF)


Computing Practical Project - NEA documentation guide