Criterion A: Problem specification

Marks: 4 • Recommended words: 300

Criterion A is where you define the problem. Everything else in the IA flows from this section – your plan, system model, chosen techniques, and final evaluation all reference back to what you wrote here. Three things must be in the problem specification:

A problem scenario that describes the problem in terms of measurable solution requirements.
A set of success criteria that are measurable outcomes indicating a successful product.
An explanation of the computational context – the area of computing your solution sits in.

The 2027 syllabus does not require a named external client. Pick a problem that interests you personally: something you use, something you observed, something from another subject, or a general computing problem you want to solve.

1. The problem scenario

The problem scenario is a clear description of the problem including measurable solution requirements. It should make it obvious to the reader what the product is for and how you will know whether it works.

Write it so that:

A reader who knows nothing about your topic can understand the problem after one paragraph.
The requirements you list are measurable – “users must be able to filter items by category” is measurable; “the system must be easy to use” is not.
The description relates to something in the real world, in another field of knowledge, or in current computing.

Example (good)

A weekly meal-planning problem for a single-household vegetarian cook. Currently the cook writes menus on paper, re-copies recipes weekly, and regularly runs out of ingredients mid-week because the shopping list is compiled by scanning recipes manually. A computational solution needs to: generate a shopping list from a selected set of recipes; flag ingredient shortages against a pantry inventory; and let the cook swap recipes in and out of the weekly plan and regenerate the list automatically.

Counter-example (avoid)

I want to build a system to help people plan their meals better. The system should be easy to use, fast, and look nice. It should help users save time and reduce food waste.

This says what the student wants the user to feel, not what the system needs to do. Nothing here is testable – “easy to use” is opinion; “save time” is unmeasurable without a baseline; “reduce food waste” is a claim about the user’s behaviour, not the system’s behaviour. Examiners read this as outline-level work and place it in the lower band.

2. Success criteria

Success criteria are the measurable outcomes you derive from the solution requirements. They tell the examiner – and you – what a working product looks like.

Each success criterion should be:

Specific – one clear feature or behaviour.
Measurable – passing or failing is unambiguous.
Achievable within 35 hours, your skill level, and your chosen tools.
Relevant to a requirement in the scenario.
Testable – you can describe test data that will prove it met or not met.

The 2027 guide does not prescribe a number of success criteria. The right number is the smallest number that fully covers your problem requirements – often this lands around 5–8 for a moderate-scope IA, but legitimate IAs exist with as few as 4 or as many as 10. Too few and the product is under-specified; too many and you run out of room in Criterion D’s 1,000 words to justify techniques for each.

Example success criteria (for the meal planner)

The user can add, edit and delete recipes, each with a name, cuisine tag, and ingredient list with quantities.
The user can select recipes into a weekly plan with one slot per day.
The system generates a shopping list aggregating ingredients across all planned recipes.
The system compares the shopping list against a stored pantry inventory and marks items already in stock as not needing purchase.
The user can swap one recipe in the plan for another and the shopping list updates immediately.
Recipes, pantry items and weekly plans persist between sessions.
The user can export the shopping list as a plain-text file.

Every success criterion should have an obvious test. If you cannot say “to test this, I would do X and expect Y,” the criterion is too vague – rewrite it.

3. The computational context

The computational context is the specific area of computing you are using to solve the problem. Explain, in a sentence or two, why the choice makes sense.

Examples of computational contexts:

Stand-alone desktop application with local file persistence – suitable when the user works offline and owns their data.
Web application backed by a database – suitable for multi-device access or multi-user scenarios.
Interactive simulation – suitable when the point is to model a system whose behaviour the user wants to explore.
Mobile application – suitable when location, camera, or always-with-you access is the key requirement.
OOP program with a GUI – suitable when the domain maps cleanly onto classes and the user drives interaction through a visual interface.

Tie the choice back to the scenario: why does this context fit this problem, given the users, the data, and the constraints?

Mark bands

Marks	Level descriptor
0	The response does not reach the standard described below.
1–2	The response: outlines a problem scenario; states limited success criteria; outlines the nature of the solution in a computational context.
3–4	The response: describes the problem scenario in terms of its measurable solution requirements; states appropriate success criteria; explains the choice of computational context for the solution.

The step from 1–2 to 3–4 is the step from outlines/states to describes/explains. Concretely:

Outlines a problem scenario – you say what the problem is, but the requirements are general or not measurable.
Describes … in terms of measurable solution requirements – every requirement can be tested against the finished product.
States limited success criteria – the criteria do not cover the requirements fully, or several are vague.
States appropriate success criteria – each criterion is specific, measurable, and maps to a requirement.
Outlines the nature of the solution – you name the computational context but do not justify it.
Explains the choice of computational context – the reader understands why this context fits the problem.

Word count and formatting

Recommended word count: 300 (excluding excerpts of code, comments and diagrams).
Put the overall documentation word count on the first page of the PDF.
Suggested filename inside the single-PDF documentation: a section heading “Criterion A: Problem specification”.

How Criterion A feeds the rest of the IA

Your success criteria from Criterion A are used in every later section:

Criterion B (Planning) – Your plan’s chronology addresses the requirements of the success criteria.
Criterion C (System overview) – Your system model covers the features needed to meet each success criterion; your testing strategy aligns with the success criteria.
Criterion D (Development) – Your video demonstrates functionality against each success criterion; your chosen techniques implement the features they describe.
Criterion E (Evaluation) – You evaluate the product against each success criterion in turn and justify improvements where gaps were found.

Vague or poorly-chosen success criteria here cost you marks across four other criteria. Spend the time.