Exam Intelligence · 3 Official Documents Analysed

How to Score Higher in SQA Advanced Higher Computing Science ()

Evidence-based Computing Science exam guide built from official SQA course reports and marking instructions. Specialised and comprehensive study tips — specific, cited insights so you can achieve top grades.

View Past Papers

Evidence-BasedBuilt from 3 official course reports & marking instructions (2023–2025)

🚫

Top Mistakes in Advanced Higher Computing Science

The most common reasons students lose marks in Advanced Higher Computing Science , cited directly from official SQA course reports across multiple sessions.

Confusing types of testing — describing end-user or acceptance testing instead of final testing, or failing to identify the correct testing type

Flagged in all three course reports across both optional sections; one of the most persistent weak areas in the question paper · Affects: Question Paper — Section 1, Question Paper — Section 2, Question Paper — Section 3

What markers say

“Most candidates were unable to identify the correct type of testing being undertaken. Although some candidates were able to accurately name and justify the use of end user testing in question 7(g)(ii), only a few were able to accurately name and justify the use of final testing in question 7(g)(i).”
— Advanced Higher Computing Science, 2023 Course Report

“Most candidates did not get full marks for this question, with many incorrectly describing end-user or acceptance testing.”
— Advanced Higher Computing Science, 2024 Course Report

How to fix this

Learn the five distinct testing types at Advanced Higher level and when each is used: component testing (individual modules by the development team), integrative testing (combined modules to check integration), usability testing (prototype evaluated using personas), final testing (complete solution tested by the development team adopting a realistic persona and carrying out test cases), and end-user testing (carried out by actual end users — not required in the Advanced Higher project). For final testing, you must describe the persona, the test cases, and the role of the development team — not end users. In the question paper, always identify the exact type before justifying it.

Confusing maintenance types — failing to identify perfective maintenance or distinguish adaptive, corrective and perfective

Flagged in 2023 and 2024 course reports across question paper sections; candidates consistently score poorly on maintenance questions · Affects: Question Paper — Section 1, Question Paper — Section 2, Question Paper — Section 3

What markers say

“Many candidates did not identify perfective maintenance with an appropriate justification.”
— Advanced Higher Computing Science, 2024 Course Report

How to fix this

Memorise all three maintenance types with a distinguishing trigger: adaptive = changing the software to work with new or changed external environments (e.g. new operating system, new browser version, new web technology); corrective = fixing bugs or errors found after release; perfective = improving performance, efficiency or adding new features requested by users. Questions often describe a scenario — read it carefully and identify the trigger. For adaptive maintenance, look for phrases about compatibility with new technology. Never leave a maintenance question blank; justify your choice explicitly.

Submitting code or reverse-engineered code as design evidence instead of pseudocode

Flagged in all three course reports as one of the most consistent project weaknesses, particularly in software development projects · Affects: Project — Design stage

What markers say

“many candidates continue to present code, or reverse engineered code, rather than pseudocode as the design of their Advanced Higher concepts, integration and requirements.”
— Advanced Higher Computing Science, 2023 Course Report

“Many candidates who tackled software development projects continued to present pages of code, or reverse engineered code that they rewrote and presented as the design of their Advanced Higher concepts, integration and functional requirements.”
— Advanced Higher Computing Science, 2024 Course Report

How to fix this

Design must precede implementation — never write your code first and then rewrite it as pseudocode. At the design stage, use structured English or pseudocode that describes the logic of each process without language-specific syntax. For a software development project, produce a top-level design showing data flow between modules, then refine each Advanced Higher algorithm (sort, search) in pseudocode that references the 2D array or array of records/objects you will use. The SQA Reference Language counts as a programming language and earns no marks at the design stage. Markers cannot award design marks to code.

Omitting 'before' evidence when testing sort and search algorithms — only showing the sorted or found output

Flagged in all three course reports as a consistent implementation and testing weakness · Affects: Project — Implementation stage, Project — Testing stage

What markers say

“Although most candidates who implemented an Advanced Higher search and/or sort algorithm submitted screenshots to show the results of how the algorithm performed, they did not provide the 'before' evidence of the data searched or the unsorted data, which is needed to show that the algorithm worked correctly.”
— Advanced Higher Computing Science, 2024 Course Report

“Although most candidates who implemented an Advanced Higher search and/or sort algorithm did submit screenshots to show the results of the algorithm performed, many candidates did not provide the 'before' evidence of the data searched or the”
— Advanced Higher Computing Science, 2025 Course Report

How to fix this

For a sort algorithm, you must provide two screenshots: the data in unsorted order AND the data after sorting. For a binary search, you must provide a screenshot showing the full list of values being searched, plus the search result. Without the 'before' screenshot, markers cannot confirm the algorithm actually did anything — full marks are not available. Add taking these screenshots to your implementation checklist and label each one clearly in your submission.

Overly complex projects with excessive numbers of requirements that cannot be tracked across all development stages

Flagged prominently in 2024 and 2025 course reports; responsible for candidates being unable to access all project marks · Affects: Project — all stages

What markers say

“many projects were overly complex and generated an excessive number of requirements. It was extremely difficult for these candidates to ensure that each requirement was addressed appropriately at each subsequent stage of the development process.”
— Advanced Higher Computing Science, 2024 Course Report

“Some candidates continue to undertake extremely complex projects that generate an excessive number of requirements. With so many requirements, it was extremely difficult for those candidates to ensure that each requirement had been handled appropriately at each subsequent stage of the development process.”
— Advanced Higher Computing Science, 2025 Course Report

How to fix this

Keep your project lean and focused on the mandatory Advanced Higher concepts. The scope cap is 6 end-user requirements and up to 15 functional requirements (4 Advanced Higher concept + 3 integration + 4–8 additional); SQA markers apply a penalty for more than 6 end-user requirements or more than 8 additional functional requirements. Follow an agile-type approach: in the first iteration, implement only mandatory concepts, integration and input validation — just enough to generate all required evidence. This ensures every requirement can be tracked from Analysis through Design, Implementation, Testing and Evaluation. Additional features can be added in a second iteration only if time permits, and do not need full evidence coverage.

Fitness-for-purpose and maintainability evaluations lacking Advanced Higher depth — incomplete checklists, ticks instead of discussion, or wrong claims

Flagged across all three course reports in the Evaluation stage; a persistent source of lost marks · Affects: Project — Evaluation stage

What markers say

“The evaluation of fitness for purpose submitted by many candidates lacked sufficient detail at Advanced Higher level.”
— Advanced Higher Computing Science, 2023 Course Report

“many evaluations of robustness included inaccurate claims that all input had been validated when there was clear evidence in the solution that this was not the case.”
— Advanced Higher Computing Science, 2024 Course Report

“many candidates failing to acknowledge that the limited nature of their input validation meant that their solution was not robust.”
— Advanced Higher Computing Science, 2025 Course Report

How to fix this

For fitness for purpose, discuss each numbered requirement in turn — state whether it was achieved and refer to specific testing evidence. Do not use a tick table; write a sentence about each requirement. For maintainability, name the type of maintenance (adaptive, corrective or perfective) and explain which specific feature of your code (e.g. internal comments, modular structure, meaningful variable names) would make that type of maintenance easier or harder. For robustness, refer only to input validation that actually exists in your solution — never claim validation is present if testing screenshots show it was not implemented.

Confusing inheritance and polymorphism — using the terms interchangeably or failing to explain polymorphism applied to superclass arrays

Flagged prominently in 2024 and 2025 course reports; a key question paper weakness in the OOP section · Affects: Question Paper — Section 1

What markers say

“many candidates are incorrectly using the two terms interchangeably: inheritance is used to establish hierarchical relationships between classes, while polymorphism allows objects of those related classes to be treated uniformly — in essence, inheritance is primarily concerned with structure, whereas polymorphism is concerned with behaviour.”
— Advanced Higher Computing Science, 2025 Course Report

“Most candidates incorrectly stated that the method had not been defined. Only a few candidates were able to explain that the element list[8] is an object belonging to the Shape superclass, and therefore were not able to access a method that belongs to the Circle subclass.”
— Advanced Higher Computing Science, 2024 Course Report

How to fix this

Inheritance defines the class hierarchy (a Delivery class inherits fields and methods from an Order superclass). Polymorphism allows objects of different subclasses to be treated as objects of the superclass type — when stored in a superclass array, each element can only access methods defined on the superclass, regardless of which subclass the object actually belongs to. When explaining why a method cannot be called: identify the declared type of the array element (superclass), then explain that the method belongs to the subclass only and is therefore inaccessible at that point. Use the UML class diagram in the question to identify which methods are available at each level.

Omitting database implementation evidence — no initial table contents, no table structure screenshots, missing query proof

Flagged in all three course reports as a consistent implementation weakness in database projects · Affects: Project — Implementation stage

What markers say

“Most candidates who chose to implement a database, either as the main focus of their project or as the integrative component, did not indicate the initial contents of the table or tables and the data used to populate them before any queries were executed.”
— Advanced Higher Computing Science, 2023 Course Report

How to fix this

Database implementation evidence has four mandatory components: (1) structure evidence — SQL CREATE code or screenshots showing column names, data types and constraints that match your data dictionary; (2) initial values — screenshots or SQL INSERT code showing the table contents before any queries run (even an empty table must be evidenced); (3) query fitness — screenshots proving each SELECT, INSERT, UPDATE and DELETE query works correctly (INSERT evidence must show additional records; DELETE must show records removed); (4) data dictionary match — confirm that the implemented table structure matches what you designed. Label every screenshot clearly with the requirement number it evidences.

Apply what you've learned

Practice identifying these mistakes in real papers. Try a recent paper and mark yourself — you'll spot these patterns immediately.

Try 2025 All Papers

✅

What Advanced Higher Computing Science Examiners Reward

Patterns that consistently earn high marks in Advanced Higher Computing Science , based on SQA course report commentary on top-scoring answers.

Numbering requirements at Analysis and tracking every requirement through all five project stages

Course reports across all three years consistently note that candidates who numbered their requirements and tracked them through Design, Implementation, Testing and Evaluation received the highest project marks. The 2023 report states that candidates who numbered their requirements 'benefitted greatly from this when they came to create a test plan for final testing, as it ensured that none of the requirements were overlooked.'

Source: Advanced Higher Computing Science, 2023 Course Report; Advanced Higher Computing Science, 2024 Course Report; Advanced Higher Computing Science, 2025 Course Report

Using OOP terminology precisely — 'superclass', 'subclass', 'instantiate', 'overriding', 'polymorphism', 'instance variable' — when explaining code

The 2023 report notes that 'Most candidates made good use of object-oriented terminology, such as 'instantiate', 'object' and 'class' to describe the effect of the code.' Using these terms accurately in explanations consistently earns full marks in the OOP question-paper section, while vague descriptions without terminology earn partial marks.

Source: Advanced Higher Computing Science, 2023 Course Report; Advanced Higher Computing Science, 2024 Course Report

Attempting problem-solving algorithm design questions even when uncertain — partial marks are routinely available

The 2023 and 2024 reports both note that 'statistical evidence shows that most candidates receive partial marks for correct aspects of their design, even when those designs may be incomplete or do not provide a fully working solution.' Candidates who leave algorithm design questions blank miss partial marks that are consistently awarded.

Source: Advanced Higher Computing Science, 2023 Course Report; Advanced Higher Computing Science, 2024 Course Report

Producing a clear, well-defined requirements specification at Analysis — linked to higher marks across all five project stages

All three course reports note the correlation between a precise Analysis stage and strong performance throughout the project. The 2023 report states directly that 'Candidates who present a clear, well-defined list of requirements at the Analysis stage generally receive good marks in all stages of the project development.'

Source: Advanced Higher Computing Science, 2023 Course Report; Advanced Higher Computing Science, 2024 Course Report; Advanced Higher Computing Science, 2025 Course Report

Designing session variables explicitly in wireframes and navigation structures for web projects

The 2023 report advises that candidates who planned session variable use in their navigation structure and wireframes — showing which pages share data and how — consistently received higher design marks. Candidates who omitted this or presented contradictory session variable use could not gain full marks at the Design stage.

Source: Advanced Higher Computing Science, 2023 Course Report; Advanced Higher Computing Science, 2024 Course Report

Providing evaluative descriptions of testing results — noting what worked well and what did not — rather than just recording pass/fail

The 2025 report notes that candidates who provided 'evaluative descriptions of the results of testing by focusing on aspects of their solution that had worked well' and also 'highlighted aspects of the solution that perhaps did not function or operate as well as the candidates had originally intended' gained higher Evaluation marks. Honest, reflective evaluations outperform optimistic tables of ticks.

Source: Advanced Higher Computing Science, 2025 Course Report

📝

Advanced Higher Computing Science Answer Frameworks

Structured approaches for each Advanced Higher Computing Science question type, derived from SQA marking instructions requirements.

Object-oriented code explanation — effect of OOP code referencing a UML class diagram

3–5 minutes per part

Structure

Identify the class → state the method or constructor being called → use correct OOP terminology (instantiate, object, instance variable, superclass, subclass, overriding, polymorphism) → reference the UML class diagram for method availability → explain what the code does in terms of OOP concepts → if a method cannot be called, identify the declared type of the array element and explain which class the method belongs to

•Always name the class and method being discussed before explaining its effect
•Use the UML class diagram to determine which methods are accessible — superclass array elements can only call superclass methods
•Distinguish inheritance (structural hierarchy) from polymorphism (uniform treatment of related objects in behaviour)
•When asked to explain why a method cannot be called, identify the declared type of the variable, not the runtime type
•For overriding questions: state that the subclass redefines the superclass method to provide different behaviour for that subclass

Algorithm design — applying a standard algorithm (binary search, bubble sort, insertion sort) to an Advanced Higher data structure

6–10 minutes

Structure

Identify the data structure (2D array / array of records / array of objects) → name the correct algorithm → state the key distinguishing feature of this algorithm vs alternatives → write pseudocode referencing the actual data structure (not a 1D array) → indicate comparators, loop bounds, and swap/shift operations correctly → indicate the expected result

•Insertion sort: compares each element to the previous one and shifts elements right until the correct position is found — do not confuse with bubble sort (which compares adjacent pairs across the whole array)
•Binary search requires a sorted list; always state the midpoint calculation and how the search range narrows
•For 2D arrays, use correct indexing (e.g. array[row][col]) — single-dimension indexing loses marks
•Even an incomplete algorithm design earns partial marks — always attempt the question
•When applying the algorithm to an array of objects, reference the getter method to access the sort key (e.g. getPower())

SQL query with subquery and Advanced Higher operators (EXISTS, BETWEEN, HAVING, IN)

4–6 minutes

Structure

Identify the table(s) involved → state the operator required (BETWEEN, IN, EXISTS, HAVING) → construct the subquery first if EXISTS is required → write the outer query referencing the subquery → check grouping (GROUP BY before HAVING) → verify all conditions match the question requirements

•EXISTS takes a subquery as its argument — write SELECT * FROM ... WHERE ... as the subquery, then wrap it: WHERE EXISTS (subquery)
•BETWEEN is inclusive of both endpoints — use it in preference to >= and <= at Advanced Higher level
•HAVING filters groups after GROUP BY — it cannot be replaced with WHERE for aggregate conditions
•IN restricts a value to a fixed list — use it in preference to LIKE for exact matching
•For integrated questions, check whether the question requires an HTML form attribute (action, method) alongside the SQL — read the full question before writing

Project evaluation — fitness for purpose, maintainability and robustness

8–12 minutes for the full evaluation section

Structure

Fitness for purpose: reference each numbered requirement → state whether it was achieved → cite specific testing evidence. Maintainability: name the maintenance type (adaptive / corrective / perfective) → identify the specific code feature (e.g. internal comments, modular structure, meaningful identifiers) → explain how that feature aids or hinders that type of maintenance. Robustness: reference specific input validation routines implemented → cite testing results (including any failures) → be honest about validation that was not fully implemented

•Never use a tick table for fitness for purpose — write a sentence about each requirement
•Name the maintenance type explicitly before explaining it; do not describe maintenance generically
•If testing showed validation failures or missing validation, acknowledge this in the robustness discussion — false claims that 'all input is validated' cost marks
•Refer to corrective, adaptive and perfective maintenance by name — 'National 5 level' descriptions without type names score few marks
•Cross-reference your evaluation against the requirements numbered at Analysis to show you have addressed every requirement

Practice by topic

Use topical past papers to practice specific question types. Each topic collects questions from multiple years — perfect for drilling the frameworks above.

Topical Past Papers

💬

Advanced Higher Computing Science Command Words Decoded

Each command word in Advanced Higher Computing Science is a scoring instruction. Understanding what SQA markers expect is critical to earning full marks.

describe1–3 marks

State what something is or does — give features, properties or sequence of steps without requiring a reason. In code questions, describe the effect of each line or block. In project evaluation, describe what the solution does in relation to each requirement.

Common mistake

Giving an explanation (a reason or cause) instead of a description. 'Describe the use of the HAVING clause' requires you to state what the clause does in the query — not why it is better than WHERE. Check whether the question uses 'describe' or 'explain' before writing.

explain2–4 marks

Give the reason or mechanism behind something. Include a cause-and-effect link, typically using words like 'because', 'therefore' or 'which means'. In OOP questions, explain why code behaves as it does by linking to class hierarchy, overriding or polymorphism.

Common mistake

Restating what the code does without giving the reason — this is describing, not explaining. For polymorphism questions, name the concept and then explain how it applies. For testing questions, name the testing type and explain who carries it out and at which stage.

identify1–2 marks

Name or select the specific item, type, or feature required. Usually a short answer — one term or one precise phrase. In ER diagram questions, identify the weak entity. In maintenance questions, identify the type.

Common mistake

Giving a description instead of naming the specific item. 'Identify the type of maintenance' requires only the name (e.g. 'adaptive maintenance') — a definition without the name does not score the mark.

design an algorithm4–8 marks

Produce pseudocode or structured English that describes the logic of the required process. The algorithm must reference the data structure given in the question (2D array, array of records or array of objects). Language-specific syntax earns no marks.

Common mistake

Writing code in Python, Java or SQA Reference Language instead of pseudocode. Applying the algorithm to a 1D array when the question specifies a 2D array or array of objects. Leaving the question blank — partial marks are regularly awarded for correct aspects of an incomplete design.

evaluate2–4 marks

Make a judgement about the extent to which something meets a criterion, based on evidence. In project evaluation, assess each requirement against testing evidence. In question-paper feasibility questions, assess whether the proposed approach is feasible based on stated constraints.

Common mistake

Describing without judging — an evaluation must include a conclusion or assessment, not just list features. In project evaluation, a tick table with no discussion does not constitute evaluation at Advanced Higher level.

justify1–3 marks

Give reasons that support a choice or decision. State the choice first, then provide specific reasons why it is appropriate in the given context. Used in testing questions (justify the type of testing), maintenance questions and feasibility questions.

Common mistake

Providing a reason that is too generic — 'final testing is used to test the software' does not justify the choice. A justification must link the type to the specific scenario described in the question.

compare2–3 marks

Identify a similarity and/or difference between two things. Use comparative language. In algorithm questions, compare properties such as efficiency, data requirements or steps. In maintenance questions, compare the impact on the system.

Common mistake

Stating the same point twice from opposite perspectives (e.g. 'A is faster' and 'B is slower') — these are the same comparison and earn only one mark. Each mark requires a genuinely different aspect to be compared.

write the line(s)1–4 marks

Produce the correct code (in the language indicated, or in SQA Reference Language) to complete a given program segment. The code must integrate with the surrounding code provided in the question — match variable names, method names and data types exactly as given.

Common mistake

Using different variable or method names from those in the question, or failing to use a getter method to access an encapsulated instance variable. In OOP questions, check the UML class diagram for available methods before writing — do not introduce new variable names.

📐

Advanced Higher Computing Science Diagram Checklist

Incorrect diagrams in Advanced Higher Computing Science are flagged in every SQA course report. Use this checklist before every practice and in the exam.

UML class diagram (project Design stage and question paper OOP section)

Show class name, fields (with data types and visibility indicators), and methods (with return types and parameters) for each class. Show inheritance relationships with an arrow pointing from subclass to superclass. Mark overridden methods in subclasses. If designing an array of objects, include the array and indicate the search/sort method applied to it.

Common error: Submitting a UML class diagram generated automatically by a framework — this earns no marks because it does not reflect the candidate's own design decisions. The diagram must show only classes the candidate intends to implement from scratch, with all fields and methods they will code.

Entity-relationship diagram (ERD) for database projects

Use a double-edged rectangle for weak entities and a single-edged rectangle for strong entities. Show relationship participation using O (optional) and | (mandatory) on both ends of each relationship line. Label each relationship. Include all entities and ensure the ERD matches the data dictionary.

Common error: Failing to distinguish weak entities from strong entities, or using incorrect participation notation. The 2023 report notes that candidates should ensure strong and weak entities are clearly indicated and that the updated notation (double-edged rectangle for weak entities) is used.

UML use case diagram (project Analysis stage and question paper sections)

Show all actors (including external databases and files, not just human users) on the boundary of the system. Show all end-user interactions as use cases inside the system boundary. Use include relationships for mandatory sub-processes (e.g. input validation, login) and extend relationships for optional sub-processes. Each use case should correspond to a functional or end-user requirement.

Common error: Omitting external system actors such as a database actor. The 2023 report notes that candidates who used the use case diagram early at Analysis to identify end-user and functional requirements produced better requirement specifications. Do not create a use case for every low-level database query — use cases should represent user-visible tasks.

Top-level design / structure diagram showing data flow between modules (software development projects)

Show all major modules or processes as labelled boxes. Indicate data flow between modules using arrows labelled with the data passed. Include input validation modules. For each Advanced Higher algorithm (sort/search), show the data structure it operates on. For web projects, replace with a site navigation structure showing all planned pages and all links/redirects between them.

Common error: Omitting the top-level design entirely and jumping straight to algorithm pseudocode. The 2023 report states this was missing for most software development projects, and the 2025 report repeats the same finding. Without a top-level design, markers cannot award the data-flow marks.

Test plan table (project Testing stage)

Columns: requirement number, description of test, test data values (normal, extreme and exceptional for input validation), expected output (including error messages), actual output, and pass/fail. Each numbered requirement from Analysis must appear as a separate test. Screenshot evidence for each test should be placed below the test plan, labelled with the test number — not squeezed into a small screenshot column.

Common error: Combining multiple requirements into a single test, omitting test data values (especially exceptional values), not including expected error messages, or inserting screenshots into the test plan table itself (making them unreadably small). The 2025 report notes some test plans contained fewer than ten tests despite dozens of requirements.

Data structure design — 2D array or array of records/objects (project Design stage)

Show the array name, number of rows and columns (dimensions), and the data type of each field/column. For an array of objects, reference the class definition. The structure design must be consistent with the data used in the Advanced Higher algorithm pseudocode — the algorithm must reference this structure, not a 1D array.

Common error: Omitting the data structure design entirely, or designing a 1D array when the project requires a 2D array or array of objects. The 2023 report notes that 'Most candidates who tackled a software development project did not provide any indication of the intended structure of the 2D array and/or array of records.' Generic algorithms not referencing the designed data structure cannot earn full marks.

⚠️

Topics Students Struggle With Most In Advanced Higher Computing Science

These Advanced Higher Computing Science topics consistently produce the lowest scores. Prioritise these in your revision.

OOP — polymorphism and superclass array method access

The 2024 and 2025 course reports both flag that candidates consistently confuse inheritance with polymorphism and fail to explain why a method cannot be accessed via a superclass array element. The 2025 report explicitly advises that 'many candidates are incorrectly using the two terms interchangeably' and dedicates significant space to clarifying the distinction.

Affects: Question Paper — Section 1

Standard algorithms — insertion sort applied to 2D arrays and arrays of objects

The 2025 report notes that 'some candidates produced code to implement a bubble sort algorithm rather than an insertion sort', others 'incorrectly sorted the array in ascending rather than descending order', and 'a few candidates failed to use appropriate 2-D array indexing'. The 2024 report also flags that many candidates could not complete the insertion sort pseudocode.

Affects: Question Paper — Section 1, Project — Implementation stage

Testing types — distinguishing final testing, end-user testing, integrative testing and usability testing

All three course reports flag this as one of the most consistently poor areas. Candidates regularly describe end-user or acceptance testing when final testing is required, and very few can accurately justify final testing as distinct from usability testing. The 2023 report states only a few candidates could accurately name and justify final testing.

Affects: Question Paper — all sections, Project — Testing stage

SQL — subqueries with EXISTS and Advanced Higher operators (BETWEEN, HAVING, IN)

The 2024 report notes that 'many candidates did not complete the SQL query using the EXISTS operator with the subquery', and that most did not provide the HTML form action/method attributes in an integrated question. The 2025 report also notes some candidates still use National 5-level operators (>= instead of BETWEEN, LIKE instead of IN).

Affects: Question Paper — Section 2

Project design — omitting top-level data-flow design and Advanced Higher data structure design

The 2023 report states 'Most candidates did not provide a top-level design showing the intended data flow between sections of their solution, together with refinements of Advanced Higher algorithms.' The 2025 report repeats this: 'most candidates fail to include this evidence' for procedural projects, and notes OOP candidates often omit a hand-crafted UML class diagram in favour of a framework-generated one.

Affects: Project — Design stage

Project testing — test plan not comprehensive; missing normal/extreme/exceptional values for input validation

The 2023 report notes 'most candidates did not provide any details of the test data values that were needed to test the mandatory input validation' and only 'fewer still made any reference to the expected output in the form of error messages.' The 2025 report adds that some test plans covered fewer than ten tests despite having many requirements.

Affects: Project — Testing stage

Maintenance types — perfective maintenance identification and detailed evaluation of maintainability

The 2023 report states 'Descriptions of maintainability submitted by many candidates lacked sufficient detail at Advanced Higher level and bore more resemblance to responses at National 5 level.' The 2024 report flags that many candidates could not identify perfective maintenance with appropriate justification in the question paper.

Affects: Question Paper — all sections, Project — Evaluation stage

Project ongoing testing log — evidence added retrospectively and missing Advanced Higher concept coverage

The 2023 report notes 'it was clear that much of this evidence had been added retrospectively and omitted many of the important Advanced Higher concepts, integrative components and functional requirements.' The 2025 report repeats this finding, with some submissions containing no ongoing testing evidence at all.

Affects: Project — Implementation stage

Target your weak areas

The topics above are where most marks are lost. Use past papers and marking instructions to practice these specific areas until they become second nature.

Past Papers & Marking Instructions Topical Papers

Frequently Asked Questions

How is SQA Advanced Higher Computing Science assessed?

The course has two externally-marked components summing to 135 marks. The Question Paper (55 marks, 2 hours, approximately 40% of the course) consists of a mandatory Section 1 on Software Design and Development (35 marks), followed by a candidate's choice of either Section 2 Database Design and Development (20 marks) or Section 3 Web Design and Development (20 marks). Questions in the chosen optional section include mandatory integration with the other optional area. The Project (80 marks, coursework, approximately 60% of the course) is independently completed under some supervision over a notional 40 hours and covers five stages with fixed mark allocations: Analysis 10, Design 20, Implementation 30, Testing 15, Evaluation 5. Project scope is capped at no more than 6 end-user requirements and up to 15 functional requirements (4 Advanced Higher concept + 3 integration + 4–8 additional); SQA markers apply a penalty for more than 6 end-user requirements or more than 8 additional functional requirements. Grade boundaries typically require around 67 marks for a C, 79-80 for a B, and 93-94 for an A.

How was this guide built?

This guide was built by analysing all 3 official SQA Course Reports for Advanced Higher Computing Science published for the 2023, 2024 and 2025 examination diets. Every pattern, quote and recommendation is drawn directly from those documents, covering both question paper and project performance across all three years. Quotes were verified as literal substrings of the source documents.

What does the project involve, and how should I structure my evidence?

The Advanced Higher project is a software development project completed independently under the supervision of your teacher or lecturer. You must complete five stages: Analysis (UML use case diagram, requirements specification with numbered requirements, project plan), Design (data structure design, algorithm pseudocode, UI wireframes, query designs), Implementation (coded solution with ongoing testing log), Testing (comprehensive test plan with normal/extreme/exceptional data values and persona-based final testing), and Evaluation (fitness for purpose per requirement, maintainability by type, robustness linked to validation evidence). Use the official templates and evidence checklists provided by SQA. Number every page and highlight where mandatory concepts appear in your code. Keep the scope focused — aim for no more than 6 end-user requirements and up to 15 functional requirements (4 Advanced Higher concept + 3 integration + 4–8 additional). SQA markers apply a penalty for more than 6 end-user requirements or more than 8 additional functional requirements.

Which OOP concepts are tested in the question paper, and how should I approach them?

The OOP section of Section 1 tests class definitions, constructors, instance variables, encapsulation, inheritance, overriding and polymorphism. You must be able to read SQA Reference Language code alongside a UML class diagram, describe the effect of code using precise OOP terminology (instantiate, superclass, subclass, overriding), and explain why polymorphism allows objects of different subclasses to be stored in a superclass array. Critically, elements of a superclass array can only access methods defined on the superclass — not methods that belong only to a subclass. Inheritance is about structure (class hierarchies); polymorphism is about behaviour (treating related objects uniformly). These two concepts must not be used interchangeably.

What programming languages are accepted for the Advanced Higher project?

SQA does not mandate a specific programming language for the project. Any language that can demonstrate the required Advanced Higher concepts is acceptable — Python, Java, C#, JavaScript (with a server-side framework) and others have all been used. However, if you use a framework or library for any part of your solution, be aware that design evidence for framework-handled features may not be awardable: you must show your own design work for the concepts you implement. Candidates who relied heavily on frameworks often could not demonstrate their understanding of integration at the Design stage and could not earn full marks for Implementation. For Python candidates implementing arrays of objects, note that an 'empty class' used only as a record is treated as an array of records, not an array of objects — the class must include methods beyond the constructor.

Put It All Into Practice

You now know exactly what SQA markers reward and penalise. The next step is deliberate practice with real papers. We have 4 exam sessions available for Advanced Higher Computing Science — question papers, marking instructions, and course reports.

View All Past Papers Latest Session: 2025 Topical Past Papers