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.

Before you write: is the problem the right size?

The 2027 guide expects a project that pushes you beyond standard classroom exercises without becoming unmanageable in 35 hours. Two failure modes to avoid:

Too ambitious. Requires skills beyond the course (frustration, half-implemented features, SC you can no longer meet). Whole-school timetabling, real-time multiplayer networking, and full hotel-booking systems with conflict detection usually fall here.
Too trivial. A template-based website with minor changes, a basic calculator, or a replication of a freely-available product (e.g. a currency converter that competes with xe.com). A records app that only adds, edits, deletes, and saves data, with no searching, sorting, or other processing, falls here too: that is data storage, not computational thinking. Examiners explicitly describe this category as “barely more than an academic exercise” and mark it accordingly.

A good IA problem demands decomposition, algorithm design, data handling, and user interaction because of the problem itself, not because of polish. If the only reason your project is complex is because you added more features, the scope is wrong.

To pressure-test scope, ask:

Could a non-CS student build a working version with a no-code tool? (If yes, the computational depth is missing.)
Does the problem require at least one non-trivial algorithm or data structure to solve?
Do my success criteria fit in 35 hours given my current skill level?

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.

Sentence stems if you’re stuck

If the scenario is hard to start, try one of these openings and edit yourself away from them:

The problem I aim to solve is…
Many people who [do X] currently struggle with [Y] because [Z]…
Existing solutions for [problem] are unsuitable for [audience] because…

Then test the result against four questions:

Who is the target audience? (Even if it is “you”, say so.)
What are the limitations of existing solutions?
What would success look like from the user’s point of view?
What requirements can I phrase as something the product must do, with measurable behaviour?

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 to 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?

Guiding questions for the computational context strand

This is the strand examiners most commonly flag as “generic”, including in IAs scoring in the upper band. To push it into full marks, write a paragraph that answers most of the following:

What kind of solution makes sense for this problem (web, desktop, mobile, database-driven, simulation)?
What languages or tools are usual for this kind of problem, and why?
What are the trade-offs of the alternatives I considered?
Can my chosen tools actually deliver every success criterion? (e.g. does my UI library support the interactions I planned?)
Do I have the skills and the resources (hardware, libraries, time) to use them?
How does my chosen context help me meet the success criteria specifically?

A computational context that only names the language (“It’s a Java program”) is the typical “generic” verdict. The strand rewards explanation of why this fit this problem, not just naming the tools.

For a networking project, the context should discuss networking; for a database project, it should discuss data modelling; for a simulation, it should discuss the model and its parameters. Match the depth to the domain.

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.

Where this criterion most often loses marks

The most common reasons Criterion A drops out of the upper band:

No measurable requirements in the scenario. A well-written scenario still drops to the lower band if its requirements are not testable. Two or three concrete, measurable requirements push you into the upper band.
Success criteria that do not describe a complete solution. If the SC list misses core functionality your product needs, the strand is “limited”, and that limitation then leaks into B, C, D, and E.
Success criteria listed but never implemented. SC that appear in A but never show up in the video or evaluation cost marks twice.
A computational context that reads as “generic”. Naming the language is not the same as explaining why it fits this specific problem. This is the most common mark loss in this strand, even for otherwise strong IAs.
A problem the assessment treats as trivial. Replicating a freely-available product, cloning a well-known game, or building a template-driven website with cosmetic changes is treated as “an academic exercise” regardless of code quality. See Common mistakes for how to test whether your problem has genuine computational depth.

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.