Top-Band Guide

A walk-through of all nine NEA sections with the criteria that earn marks in the top band of each, written directly from the WJEC mark scheme. Use the left-hand navigation to jump straight to the section you’re working on.

The full raw mark allocation is 5 + 10 + 15 + 10 + 5 + 25 + 5 + 10 + 15 = 100. Section maxes are shown next to each heading.

If you’re sizing up your own problem before you start, read the Sample Task — Nanthouse Surgery first; it shows the scope expected of an A Level candidate. For worked submissions, see the Exemplars.

Discussion (5 marks)

The Discussion is short but gate-keeps the rest of the project: if you pick a problem with limited scope here, the moderator will cap your marks in Investigation, Design and Software Development too. Get this right and you unlock the full mark range across the whole NEA.

Top band (4–5 marks) — all five criteria below.

What the top band looks like

1. Identified a substantial problem that provides sufficient scope for the full range of marks.
2. Provided a full description of the broad aims using appropriate subject-based technical vocabulary.
3. Identified the possible limitations of a solution and described these in detail using appropriate technical language.
4. Fully considered feedback from others and used it to refine understanding of the problem and proposed solution.

How to hit each criterion

A substantial problem. Compare your problem to the Nanthouse Surgery sample task: multiple user roles with different permissions, at least four or five linked data structures, distinct processes beyond simple CRUD. If your problem can be solved with a single table and a couple of forms, it is not substantial enough. Re-scope before you continue.

Full description with technical vocabulary. Don’t write “I am going to make an app for the surgery.” Use language that signals you understand what you’re proposing:

“The system will provide role-based access control for three user groups, maintain a normalised relational data store, and automate scheduled notifications for appointment reminders and missed-appointment follow-ups.”

Use the right words: normalisation, relational database, role-based access, validation, referential integrity, modular decomposition, exception handling.

Limitations — in detail, with technical language. Don’t just list constraints — explain why they limit the solution:

• “The system will not integrate with the NHS Spine, so prescription data must be entered manually — this introduces transcription error and means audit trails cannot be cross-referenced with national records.”
• “All authentication is local; two-factor authentication is out of scope, so the credential store is the single weakest link.”

Feedback that refined your understanding. The phrase “fully considered” and “refine understanding” is doing a lot of work. Record who you talked to, capture what they said (quotes, meeting notes), then explicitly show what you changed as a result. A single emailed conversation is not enough.

Common ways marks are lost

• Choosing a problem that’s too small — caps you at band 1.
• Listing aims without explaining them.
• Naming limitations without describing them (“data security” is a topic, not a limitation).
• “I spoke to my client and they thought it was a good idea” — no evidence of feedback influencing the project.

See it in practice

Exemplar 4 — Discussion (70/80) vs Exemplar 5 — Discussion (52/80). Read them side-by-side: where exemplar 4 analyses, exemplar 5 describes.

Investigation (10 marks)

This is where you earn the right to design a solution. You’re proving that you’ve looked carefully at the existing situation, understood what stakeholders need, and turned that into measurable objectives.

Top band (8–10 marks) — eleven criteria. This is the longest list on the whole NEA.

What the top band looks like

1. Made full use of a range of appropriate methods to investigate the existing system.
2. Completed a thorough investigation of the current system.
3. Carried out extensive desk-based research into existing solutions and identified the best features to include.
4. Described the involvement of all stakeholders and their requirements.
5. Fully analysed the data collected for input.
6. Analysed in detail the processing carried out by the existing system.
7. Given full consideration to all current system outputs.
8. Fully considered and explained the limitations of the current system.
9. Produced a working specification that clearly summarises the purpose of the project.
10. Explained, with technical justification, the methods to be used in the solution.
11. Detailed a range of objectives that include success criteria and define the required performance.

How to hit each criterion

A range of investigation methods. The plural matters — use at least three of: interview with the end user, questionnaire for wider stakeholders, observation of the existing process, and document analysis (paper forms, screenshots). Evidence each method — photos of forms, the actual questionnaire, the transcript of the interview. Moderators want to see it.

Thorough investigation + desk-based research. Investigate the current system in depth, then research existing commercial solutions. Don’t just screenshot competitors — call out specific features and say which you’ll borrow.

All stakeholders, all roles. In Nanthouse Surgery there are at least: practice manager, doctors, nurses, receptionists, therapists, patients. For each stakeholder list their role today, their needs in the proposed system, and what they can’t do today that they want to do tomorrow.

Inputs, processes, outputs — fully analysed. Build three tables:

Do the same for every key process (booking, cancellation, invoice, reminder) and every output.

Limitations of the current system — explained. Not “the system is slow” but: “Appointments are stored in a paper diary kept on reception. This creates a single point of failure — if the diary is mislaid the entire day’s schedule is lost — and prevents concurrent booking from multiple workstations.” Cause → effect.

A working specification. Short, numbered, says exactly what the system will and will not do. Treat it as a contract with the end user.

Methods with technical justification. For each major design decision, name the method and the reason:

• “I will use a relational database (SQLite) because the data has multiple linked entities and referential integrity is essential.”
• “The UI will be built with Tkinter because it ships with the standard library and runs on the surgery’s existing Windows estate without extra install steps.”

Objectives with success criteria. Each objective must be measurable. Bad: “The system will be fast.” Good: “Booking a new appointment from a blank form to confirmation screen will complete in ≤ 3 seconds on the practice’s existing hardware.” Aim for 8–12 objectives — they become the spine of your Testing and Evaluation sections.

Common ways marks are lost

• Only interviewing one person.
• Listing existing commercial systems without saying which features you’ll adopt.
• Vague “the system will be user-friendly” objectives — unmeasurable.
• Forgetting to investigate the current system because you’re keen to design the new one.
• Putting design decisions (data structures, algorithms) here rather than in Design.

See it in practice

Exemplar 4 — Investigation vs Exemplar 5 — Investigation — note the breadth of methods, stakeholder coverage, and the measurable objectives in exemplar 4.

Design (15 marks)

The Design section is the blueprint for your solution. The top band’s defining phrase is “in sufficient detail for implementation by a competent third party” — if another A Level student could not pick up your designs and build the system without asking you questions, you are not yet in the top band.

Top band (11–15 marks) — nine criteria.

What the top band looks like

1. Described and justified the breaking down of the problem into sub-problems and the links to objectives.
2. Fully identified and described the data to be input to and output from the system.
3. Designed in detail the inputs and outputs.
4. Given full consideration to the reasons for the data in the outputs.
5. Fully described all required files/data structures and methods of access.
6. Fully described the validation routines.
7. Identified all processes needed for a comprehensive solution.
8. Fully explained the relationships between data and processes/programs.
9. Fully described the processing routines using a recognised convention, in sufficient detail for implementation by a competent third party. Interconnection between programs and files clearly shown.

How to hit each criterion

Decomposition with justification. Produce a structure chart / hierarchy diagram showing how the system breaks into modules. For each module, write one or two sentences linking it back to a specific objective from Investigation:

“Module: BookingManager — supports objective 4 (book/cancel/move appointments for any of the three appointment types).”

Don’t just present the chart — explain why you broke the problem down this way.

Inputs and outputs — in detail. For every screen / form / report: a drawn or mocked-up design (annotated wireframe), a list of every field with type/length/default/source, and where the data flows next.

Reasons for the data in outputs. For each output (letter, invoice, on-screen report) explain why each field is on it. The patient’s DOB on an appointment letter — is it needed? Why?

Files / data structures, fully described. Top-band design includes a complete data dictionary (every table/class/file with every field, type, length, constraints, PK, FK), an ER diagram with cardinality, normalisation to 3NF, and methods of access (sequential? indexed? B-tree? SQL with which indexes? — justify each).

Table patient {
  patient_id int [pk]
  first_name varchar
  last_name varchar
  dob date
  postcode varchar
}

Table therapist {
  therapist_id int [pk]
  full_name varchar
  therapy_type varchar    // acupuncturist, nutritionist, ...
  hourly_rate decimal
}

Table appointment {
  appointment_id int [pk]
  patient_id int [ref: > patient.patient_id]
  staff_id int            // FK to either doctor OR therapist via staff_type
  staff_type varchar      // "doctor" | "therapist"
  appt_type varchar       // "in_surgery" | "online" | "therapy"
  start_time datetime
  duration_minutes int
}

Table treatment_session {
  session_id int [pk]
  appointment_id int [ref: > appointment.appointment_id]
  notes text
  cost decimal            // copy of rate × duration at booking time
}

Validation routines, fully described.

Cover presence, type, format, range, length, lookup/existence as applicable.

All processes identified. Walk through every objective and list the processes needed to satisfy it. The Nanthouse brief explicitly lists “enter patient details”, “book appointment”, “cancel appointment”, “send reminder”, “send missed-appointment letter”, “calculate cost”, “prepare invoice” — each must appear in your process list.

Data ↔ process relationships, fully explained. A data-flow diagram (DFD) showing which process reads/writes which data store, plus prose explaining what each process does to which data.

Processing routines — third-party implementable. For your core algorithms, write pseudocode or flowcharts detailed enough that someone else could code them. Booking with clash detection, the reminder send loop, invoice calculation, the access-control check. Then make the interconnection visible — a diagram showing which routine accesses which file/table, with what operation.

Common ways marks are lost

• Wireframes drawn for the home screen only — not every screen.
• Data dictionary missing data types or constraints.
• Validation list that says only “presence check” for every field.
• Algorithms described in English prose only, no recognised convention.
• ER diagram with no cardinality / no normalisation evidence.

See it in practice

Exemplar 4 — Design for full data dictionary and annotated screen designs. Exemplar 1 — Design (Word) includes both an overview and a full design document.

Prototype (10 marks)

The Prototype is not the whole system — it is a deliberately chosen slice that you build, evaluate and then refine. The top-band candidates are the ones who explain their choice of slice and who critique their own prototype honestly.

Top band (8–10 marks) — five criteria.

What the top band looks like

1. Justified the choice of areas in the prototype and explained the reasons for omitting the rest.
2. Created a comprehensive range of screens and outputs for the chosen areas.
3. Created a functioning system that carries out all chosen processes using realistic data and fulfils requirements for data output and storage.
4. Evaluated the functioning and justified the good features.
5. Described the shortcomings and made specific suggestions for improvement.

How to hit each criterion

Justified choice — and justified omissions. Pick a vertical slice that touches every part of the architecture (a screen, a process, a data store) for one or two key user journeys. Then explain:

• Why these areas? Usually the highest-risk or most-uncertain parts of the design. (“Booking with clash detection across three appointment types is the riskiest algorithm — if this doesn’t work the system fails its primary purpose.”)
• Why not the others? (“Invoice generation depends on appointment data — once booking is proven, invoices are mechanical.”)

A prototype that “does a bit of everything” usually loses marks here.

Comprehensive range of screens and outputs. For the slice you picked, build every screen and output it needs. Not just the booking form — the confirmation screen, the printable confirmation, the failure message. Screenshot all of them.

Functioning system with realistic data. Functioning means it runs and does what it claims, not mock-ups. Realistic data means plausible patient names, dates, costs — not “test1, test2, test3”. Screenshot the data store after a run to prove persistence.

Evaluation — with justification. For each design choice, state why it works:

“The booking confirmation displays the appointment in a colour matching the type (blue = in-surgery, green = online, amber = therapy). The end-user confirmed this matched the convention they already use on the paper diary.”

Shortcomings with specific suggestions. Top-band candidates list real limitations and propose specific fixes that you’ll then carry into Post-Prototype Refinement:

• “Currently the clash check is O(n) over all appointments. With > 1000 appointments per week this becomes noticeable. Refine by indexing on (date, slot).”
• “Validation messages are shown after submit. Refine to real-time validation as the user types.”

Common ways marks are lost

• A prototype that’s just mock-ups, not functioning code.
• Sample data of “asdfasdf” / “test 1” instead of realistic records.
• Evaluation that says only “it works well” with no shortcomings.
• Shortcomings listed but no suggested fix.
• Choosing an easy slice (login screen) rather than the risky core.

See it in practice

Exemplar 4 — Implementation (includes the prototype) and Exemplar 1 — Prototype, Exemplar 2 — Prototype — different scopes, useful comparison.

Post-Prototype Refinement (5 marks)

Only 5 marks but easy to lose because students often skip past feedback. The top band rewards feedback that came in, you took seriously, and your design changed (or you explain why it shouldn’t).

Top band (4–5 marks) — eight criteria.

What the top band looks like

1. Obtained feedback from a competent third party.
2. Fully described the feedback and explained the implications for the re-design.
3. Re-considered and re-structured input and output facilities as necessary.
4. Given full consideration to the need for additional data.
5. Given full consideration to all required files/data structures in light of additional data.
6. Given full consideration to additional processes and fully described any new relationships.
7. Fully described all processing routines using a recognised convention.
8. Fully refined with detailed design — or justified instances where suggestions have been discounted.

How to hit each criterion

Feedback from a competent third party. “Competent” matters. The end user counts. Another A Level Computer Science student counts. Your dog does not. Capture: who they are and why they qualify, when and how the review took place, what you showed them.

Feedback described in full, with implications. Don’t just list comments — for each piece of feedback explain what it means for the design:

Feedback: “The booking screen shows all therapists at once which is overwhelming once we add more.”

Implication: The design assumed a small fixed list, but the brief states therapists will be added over time. The booking UI needs a filter/search before the list, and the data model must support a configurable “active” flag on therapists.

Restructuring inputs, outputs, data, processes — fully. This is the “before and after” part. For each affected area: show the original design, show the refined design, explain why the change is necessary. Cover inputs/outputs, data structures, processes, and relationships (update ER diagram and DFD if a new table/process appears).

Updated processing routines. Re-write the pseudocode for any algorithm that changed. Keep the same recognised convention as your original Design.

Discounting suggestions — with justification. Not all feedback should be acted on. The top band specifically rewards explaining why:

“The end user suggested adding an SMS gateway integration. This was discounted from scope because (a) it requires a paid third-party service the practice has not yet procured, and (b) the existing reminder requirement specifies email or text — email alone satisfies the objective. Logged as a future enhancement.”

Common ways marks are lost

• Feedback section that is one paragraph of “they liked it, no changes needed.”
• Changes listed but no original-vs-refined comparison.
• New processes added without updating the relationship diagrams.
• Suggestions rejected silently — no explanation of why.

See it in practice

Exemplar 1 — Post-Prototype Refinement, Exemplar 2, Exemplar 3 — see the explicit before/after of design changes.

Software Development (25 marks)

The biggest single section of the NEA — 25 marks — and the one that separates the top of band 3 from band 4. This is the only section with four bands, not three: WJEC have given themselves room to distinguish the very best work.

Top band (band 4: 19–25 marks) — eleven criteria.

What the top band looks like

1. Taken full account of the revised detailed design and refined the prototype in light of feedback.
2. Produced a functioning solution to a highly demanding problem that meets most of the objectives (better solutions meet almost all).
3. Used and fully exploited the programming facilities of the language.
4. Demonstrated a sound understanding of the appropriate tools and techniques.
5. Created a well-structured data model — better candidates normalise to 3NF.
6. Produced a solution that is well-structured and modular, makes good use of local variables and minimises global variables.
7. Written code that is fully self-documenting and well-structured, with annotation that lets a competent third party maintain it.
8. Made use of complex user-defined routines — better candidates use recursive algorithms effectively.
9. Evidenced effective validation for all key components — better candidates create efficient exception handling.
10. Fully documented the variables and actual data structures used.
11. Included evidence of the completed user interface, with a full description of features that make it fit for audience and purpose.

How to hit each criterion

Take full account of the revised design. The code must match the refined designs, not the original ones. If anything changed during coding, update the design first, then write the code.

Highly demanding problem, most objectives met. This is set up by your Discussion and Investigation. To meet “almost all objectives” your final code should implement every “must” objective from the Investigation list, handle the multi-role permission requirements, and process realistic volumes of data. Cross-reference each completed feature back to the objective number when you submit.

Fully exploit the language. Show you’re using more than basics. In Python: classes and inheritance, comprehensions and generators, context managers (with blocks), decorators, well-chosen standard-library modules (datetime, sqlite3, dataclasses, enum, typing), and your own exception classes where the domain has distinct failure types. In a typed language: generics, interfaces, enums, sealed/record types.

Sound understanding of tools and techniques. When you use a non-trivial technique, comment why:

# Booking clash detection uses an interval-tree style scan over
# appointments indexed by (date, slot). O(log n + k) per check
# where k is the count of overlapping slots — chosen over the
# naive O(n) loop because the practice can have > 1000
# appointments in a busy week.

Well-structured data model — normalised to 3NF. This is the band 4 differentiator on the data side. Show your tables alongside the normalisation argument. Eliminate repeating groups (1NF), partial dependencies (2NF), transitive dependencies (3NF). Document referential integrity constraints.

Modular structure, local over global. One file per logical module. Functions short and named. Pass data as parameters — resist global. Where shared state is unavoidable, encapsulate in a class or context manager. A grep for global returning zero hits is a good sign.

Fully self-documenting + annotated. Identifier names that explain themselves (appointment_clash_exists, not flag1). Docstrings on every non-trivial function. Section comments above tricky blocks explaining the why, not the what.

Complex user-defined routines — and recursion. The mark scheme explicitly rewards recursive algorithms at the top. Find one or two genuine places they belong — hierarchical data, tree-structured menus, divide-and-conquer scheduling. Don’t shoehorn recursion where iteration is clearer.

Effective validation + exception handling. Validation at every boundary — UI input, function arguments, database constraints. Exception handling wraps it: custom exception types for distinct domain failures, try/except blocks that catch specific exceptions (no bare except:), user-facing errors translated from technical errors at the UI layer.

Variables and data structures documented. Keep your data dictionary up to date with what you actually built.

Completed UI with descriptions. Screenshots of every screen of the finished UI. For each, a paragraph saying what the user does there and what specific design choices make it fit for audience and purpose (font size for older receptionists, keyboard shortcuts for the busy front desk, colour conventions matching the existing paper system).

Common ways marks are lost

• Code that compiles and runs but the design document still shows the original prototype layout.
• One giant file with global state — band 2 ceiling no matter how clever the algorithm.
• No recursion, no inheritance, no comprehensions — “I used Python” but only as procedural BASIC.
• Validation only on the “happy path” — missing boundary or invalid-type cases.
• Bare except: clauses that swallow errors silently.
• Variables called x, temp, flag.

See it in practice

Exemplar 4 — Implementation (70/80) is your best reference for what band 4 actually looks like. Compare directly with Exemplar 5 — Implementation (52/80) to see where structure thins out. Exemplar 2 — Software Development is a separate written software-development write-up.

Developmental Testing (5 marks)

This is the testing you do while building, not the final system test. It rewards the bug logs and screenshots you capture as you go — so start collecting from day one of Software Development, not retrospectively.

Top band (4–5 marks) — two criteria.

What the top band looks like

1. Provided evidence of comprehensive testing at each stage of development.
2. Provided evidence of all problems encountered and fully justified and evidenced the actions taken to overcome them.

How to hit each criterion

Comprehensive testing at each stage. Keep a developmental test log as a running diary. For each significant feature you build, record: the date and what you were trying to achieve, the test inputs and expected result, the actual result with a screenshot or console snippet, whether it passed or failed. “At each stage” means as you build — moderators look for entries dated across many sessions, not all in one chunk at the end.

Problems + justified, evidenced actions. For every bug, record:

The mark scheme phrase is “fully justified and evidenced” — so don’t just say “I fixed it.” Say:

• Justified: “I refactored the validation into a single function rather than copying it into the second screen, because duplication would mean the next bug-fix would need to be applied in two places.”
• Evidenced: A screenshot of the re-run test passing, or a pasted log line showing the error is gone.

Workflow tip

Set up a testing/ folder in your project from day one. Drop a screenshot in every time something works or breaks, named YYYY-MM-DD-feature-pass.png or …-bug-symptom.png. Add a one-paragraph note to a running markdown log. You will have earned the marks before you wrote them up.

Common ways marks are lost

• All test log entries dated within the last two days — clearly retrospective.
• Bug entries with only “fixed it” and no explanation.
• No screenshots — just text descriptions.
• A single test log entry for a multi-module system.

See it in practice

Exemplar 4 — Testing (covers developmental & system testing) — note the dated progression. Exemplar 1 and Exemplar 2 have separate developmental-testing write-ups.

Testing (10 marks)

Distinct from developmental testing — this is the final, planned system test that proves the finished solution meets the requirements. Top-band work is planned in advance, broad in coverage, varied in data and analytical in commentary.

Top band (8–10 marks) — four criteria.

What the top band looks like

1. Produced a comprehensive plan for testing all areas of the system.
2. Made use of a wide range of appropriate testing methods.
3. Made use of test data including typical, extreme and invalid data where appropriate.
4. Presented all results with detailed and informed commentaries and included specific suggestions to refine the system.

How to hit each criterion

A comprehensive plan. Build a test plan table before you start executing. Each row is one test, and the plan as a whole should cover every objective from Investigation:

For a project at Nanthouse-scale, expect 30–50+ tests.

Wide range of methods. Use more than one technique:

• Black-box — testing against the spec.
• White-box — testing specific code paths.
• Functional — does this feature do the right thing?
• Boundary / edge — what happens at the limits?
• Stress / volume — what about with 10,000 patients?
• Usability — observed end-user test against the UI.
• Acceptance — final sign-off against the agreed requirements.
• Regression — re-run earlier tests after late changes.

Use the right method for each test, not “black-box” on every row.

Typical, extreme and invalid data. For input-heavy tests, three rows per field is a useful pattern:

The mark scheme specifically names typical, extreme and invalid — make sure your evidence ticks all three.

Detailed, informed commentaries + refinement suggestions. Don’t just list “Pass / Fail”. For each test write a few sentences explaining what the result tells you, the implication if it failed (link to the bug-fix in your developmental testing log), and a specific suggestion for refinement where appropriate:

“T07 passed: the system correctly rejected an invalid date. However the error message (‘Invalid input’) is not specific enough — a receptionist correcting the entry wouldn’t know which field failed. Suggested refinement: per-field inline messages.”

Common ways marks are lost

• Test “plan” is a list of “I tested everything” with no expected results.
• Only typical data — no invalid or edge cases.
• All tests use the same method (everything black-box).
• Pass/Fail only — no commentary.
• “Suggestions to refine” missing entirely.

See it in practice

Exemplar 4 — Testing (70/80) vs Exemplar 5 — Testing (52/80) — read in parallel to spot where planning or commentary thins out.

Evaluation (15 marks)

The Evaluation is 15 marks — equal to Design, and far bigger than most students treat it. It is not a summary of the project; it is a critical, analytical review of (a) the system you built, (b) yourself as a developer, and (c) the process you went through. The mark scheme also assesses quality of written communication here — so spelling, grammar and precision of technical vocabulary matter.

Top band (11–15 marks) — six criteria.

What the top band looks like

1. Produced a detailed evaluation of the effectiveness of the programming language and justified the tools and techniques used.
2. Compared and contrasted the completed system with similar commercially available systems.
3. Identified good features and shortcomings of the completed solution and described significant potential improvements.
4. Evaluated their own strengths and weaknesses in the design and development.
5. Described specific changes of approach that would be adopted in future.
6. Produced a well-structured and clearly expressed review. Specialist terms used with ease and accuracy. Work is error-free.

How to hit each criterion

Effectiveness of language + tools, with justification. For each major technology choice (language, framework, library, database), evaluate what it did well, where it constrained you, and whether a different choice would have served better:

“Python’s sqlite3 was effective for storing patient and appointment data: zero configuration, file-based storage suitable for a single-practice deployment, and full SQL support for join-heavy reporting queries. It was less effective at the integration boundary: I had to hand-roll mapping between rows and domain objects, which a heavier ORM like SQLAlchemy would have handled. For a project of this scale I would still choose sqlite3 over a server-based RDBMS because the deployment story is simpler.”

Compared and contrasted with commercial systems. Return to the commercial systems you covered in Investigation. For each feature of your system, compare to the commercial equivalent: who does it better, why, and what would it take to close the gap? Be honest. The commercial system probably wins on polish and scale — but you may win on fit for this end user.

Good features, shortcomings, significant improvements. For each:

• Good features — list with reasons they work (not just “the UI is nice”; “the colour-coded appointment list reduces visual scanning time for receptionists, which the end user identified as a key need”).
• Shortcomings — be honest. The moderator can find them anyway; you score better by identifying them yourself.
• Significant improvements — “significant” rules out micro-tweaks. Propose changes that would meaningfully change capability or usability: SMS gateway integration, multi-site deployment, audit-trail extension, offline mode, accessibility for screen readers.

Your own strengths and weaknesses. This is about you, not the project:

• Strength: “I scoped the data model carefully in Design — choosing 3NF early meant the relational queries in Implementation were straightforward and I avoided a costly mid-project refactor.”
• Weakness: “I underestimated how long the testing write-up would take. I had functioning code three weeks before the deadline, but the test plan took two weeks longer than planned because I hadn’t kept the developmental test log up to date.”

Specific changes for next time. The phrase is “specific changes of approach”. For each weakness, name the concrete change:

“Next time I will keep a structured developmental test log from day one — a single markdown file with date-stamped entries — rather than catching up retrospectively. This would have given me roughly an extra ten days at the end.”

Quality of written communication. This is the only section where the mark scheme explicitly assesses prose:

• Well-structured: headings that follow the criteria, signposted clearly.
• Specialist terms used with ease: normalisation, validation, modular decomposition, referential integrity, exception handling, third normal form, role-based access. Use naturally — but only where they fit, not as decoration.
• Error-free: spelling, grammar, punctuation. Run a spell-check; read it aloud; ask someone to proof it.

Common ways marks are lost

• Evaluation that summarises what you did rather than critiquing it.
• “Improvements” that are micro-tweaks (change a colour) rather than significant.
• Self-evaluation written in vague positives — “I worked hard, I learned a lot.”
• Specialist terms used incorrectly (mixing up validation and verification, calling everything an “algorithm”).
• Spelling and grammar errors — explicitly capped by criterion 6.

See it in practice

Exemplar 4 — Evaluation (70/80) for the tone: critical, specific, technical. Compare directly with Exemplar 5 — Evaluation (52/80) to see where evaluation slips into description.