A pupil-friendly guide to the 40-mark assignment: what is assessed, how the tasks fit together, what evidence to collect, and the habits that protect marks.
What the assignment is
The assignment is worth 40 marks out of the 120 marks available for the whole course.
You complete it under supervised conditions, usually over several sessions rather than one continuous block.
Everyone completes Task 1, then completes either the database task or the web task.
Task structure
You are assessed on applying computational thinking to a problem: analysing what is needed, designing a solution, implementing it, testing it, and evaluating what you produced. The exact context changes each year, but the structure below stays familiar.
Usually asks you to analyse a problem, complete or use a design, write a working program, test it with evidence, and evaluate your code.
Strong preparation: IPO analysis, structure diagrams, pseudocode, input validation with a conditional loop, standard algorithms, readable code, and specific evaluation comments.
Usually asks you to analyse a database problem, work with a data dictionary or keys, implement changes, write SQL, test queries, and explain errors or validation.
Usually asks you to analyse website requirements, edit HTML and CSS, test the result, explain JavaScript or addressing, and evaluate fitness for purpose.
How marks work
SQA marking instructions use positive marking: you gain marks for relevant skills, knowledge and understanding shown in your evidence. That means the safest strategy is to make every answer easy to mark: clear, complete, labelled, and matched to the question.
Identify inputs, processes, outputs, end-users, and functional requirements from the scenario.
Create or complete a design that could actually be implemented.
Write code, SQL, HTML, or CSS that matches the given problem and design.
Show the test data, expected result, actual result, and screenshots or output where requested.
Make specific comments about your own solution, not generic comments about all programs or websites.
| Command | What markers are looking for | Weak answer pattern |
|---|---|---|
| Identify | Name the item clearly. Keep it precise. | Writing a long sentence that never names the required thing. |
| State | Give a short, correct fact. | Adding an extra incorrect option that cancels the correct one. |
| Describe | Give a developed point, usually with detail from the context. | Giving a memorised definition with no link to the scenario. |
| Explain | Make the reason or impact clear. Use "because" thinking. | Repeating what happens without saying why it matters. |
| Evaluate | Judge your own solution using specific evidence from it. | "My code is efficient and readable" without referring to actual code features. |
Evidence checklist
The specimen task includes an evidence checklist, and the coursework instructions stress that code and screenshots must be clear and legible. Build the habit of saving and labelling evidence as you go.
| Evidence type | What good evidence looks like | Before handing in |
|---|---|---|
| Written answers | Typed or written in blue/black pen; answers match the command word. | Check every sub-question has a response. |
| Program code | Complete printout or pasted code, readable indentation, no tiny screenshots. | Label with the task number. |
| Test runs | Inputs and outputs visible together, especially for boundary and exceptional tests. | Make sure the evidence shows the result, not just the code. |
| SQL evidence | SQL statement and output/table change both visible where requested. | Do not rely on design view if SQL code is required. |
| Web evidence | Edited HTML/CSS code and browser result where requested. | Check file names and links still work. |
| Evaluation | Specific references to your own code, database, or website. | Replace generic claims with evidence-based comments. |
Marked examples from Understanding Standards
The screenshots below come from public SQA Understanding Standards assignment evidence. They are not model answers. They are useful because the commentary explains where marks were gained, where they were missed, and why the evidence mattered.
The candidate gained marks for identifying the primary key, foreign key and required field, but missed marks where the type/validation did not match the scenario closely enough.
This page is a good warning: database evidence can become very faint when pasted or printed. The marker needs to see the field, rule, code, or output being claimed.
The commentary notes that output evidence may look right, but the mark was for writing the required SQL statement. Extra selected fields, syntax errors, or missing join conditions can still lose marks.
This candidate gained marks for input, looping, validation and output evidence. The commentary also shows that missing a required design detail can still cost a mark even when much of the program works.
The commentary distinguishes planned test data from printed output. A test table should show suitable inputs and expected results; a later screenshot can prove the program actually ran.
The web commentary shows that marks are checked against specific requirements such as selectors, sizing, colours, font rules and whether CSS has been included where the task asks for it.
Using open-book conditions well
You may access permitted resources such as class notes, textbooks, programming manuals, and programs you wrote during the course. Open book does not mean you can ask someone how to solve the live task, use email or mobile phones, work with another pupil, or access assignment files outside the supervised classroom environment.
SELECT, WHERE, ORDER BY, JOIN, INSERT, UPDATE, DELETE.What recent course reports warn about
In 2025, many candidates did well on working code, but lost marks on expected output, validation design, and evaluation.
Recent reports highlight weak functional requirements, incomplete CSS rules, and difficulty with some SQL update statements.
WHERE clause.Source trail
Used for the official assignment structure, marks, timing, open-book conditions, and the skill areas assessed.
Used for task sequencing, candidate instructions, evidence expectations, and marking principles.
Used for recent candidate performance patterns and advice for future assessment preparation.
Used for open-book, supervision, reasonable assistance, plagiarism, collusion, and malpractice guidance.
Used for the candidate-response screenshots and marker-feedback summaries in the marked examples section.