Criterion A: problem specification

What Criterion A assesses

Criterion A is the starting point of the whole IA. It carries 4 marks, the recommended length is about 300 words, and everything you write in it is used again: the success criteria from A guide the plan in B, the test plan in C, the testing in D and the judgement in E. A vague Criterion A therefore costs marks far beyond its own 4.

The criterion has two markbands. Each band has three parts, and the difference between them lies mostly in the command terms.

The IB clarifies the three terms. The problem scenario is a clear description of the problem, including its measurable solution requirements, tied to the real situation: the world around you, another field of knowledge or an issue in computing. Success criteria are measurable outcomes, derived from those requirements, that show the product has been developed successfully. The computational context is the specific area of computing chosen for the solution.

Criterion A is the IA's version of the problem specification taught in subtopic B1.1, Approaches to computational thinking. The headings differ, but the thinking is the same: say exactly what the problem is, within which limits, and how success will be judged before any design begins.

Describing the problem scenario

A good scenario answers four questions in a few sentences each: who has the problem, what happens now and what goes wrong, how you know (what the client said, what you observed), and what is in scope and what is deliberately left out. The answers should be specific to one place and one group of people. "Schools often struggle with room bookings" describes a general topic; "the music department's six practice rooms are booked on a paper sheet that is overwritten most weeks" describes a problem you can solve.

Gather the scenario from the people who have the problem. An interview with the client, a short observation of how the current system is used, or a look at the paper records gives you details that you could not have guessed, such as the fact that lessons sometimes take over a practice room at short notice. Record the source in a sentence ("in an interview, the head of music described…"), and keep notes or a recording, with consent, in case your teacher asks how the requirements were found.

Solution requirements

The top band asks you to describe the scenario "in terms of its measurable solution requirements". A requirement turns part of the problem into something the solution must do or achieve.

Requirements sit between the problem and the success criteria. The problem says what is wrong ("rooms are booked and left empty"). The requirement says what the solution must do about it ("unused bookings are released so that others can use the room"). The success criterion says how you will test it ("a booking not checked in within 10 minutes of its start is released, and the slot shows as free within 1 minute").

Requirements come in two kinds. Some describe what the product does; others describe how well it does it.

The booking system's functional requirements include booking a slot, refusing a clash, enforcing a weekly limit, releasing no-shows, blocking rooms and producing a weekly report. Each one names an action or a rule.

Non-functional requirements are where unmeasurable wording creeps in. "The system should be fast" and "the system should be secure" are non-functional, and both need a number or a test before they become useful: "the day grid loads in under 2 seconds with 2,000 bookings stored" and "passwords are stored only as salted hashes, so no password appears in the database file".

YouTube

From requirements to success criteria

Success criteria are the most reused part of the whole IA. The chain from the scenario to the later criteria shows why each one has to be measurable: every later criterion either plans for it, tests it or judges it.

What makes a success criterion appropriate

The top band asks for "appropriate" success criteria. In practice that means four things. Each criterion is measurable: it contains a number, a limit or a yes-or-no behaviour. Each is testable by a stranger: someone who has never met you or your client could run the test and agree on the result. The set covers every requirement, including the non-functional ones. And each is realistic for your skills and time, because every criterion you set has to be evaluated in Criterion E, including any you could not meet.

The table also shows a useful habit: write the boundary into the criterion. "Back-to-back bookings are allowed" tells the tester exactly what should happen at the edge, and it tells you, before you code, that the clash test must treat 10:30 as the end of one booking and the start of the next, not as an overlap.

How many success criteria

The guide sets no number. A practical range is about six to ten for a typical IA: enough to cover every requirement, few enough that each can be planned, tested and evaluated within the word limit. Ten criteria evaluated properly in 400 words already means about 40 words each in Criterion E. Number them (SC1, SC2, …) so that every later criterion can refer to them by label.

Explaining the computational context

The lower band asks you only to outline what kind of solution you will build. The top band asks you to explain the choice: give reasons, tied to the problem and its requirements, why this context suits it. The strongest explanations also say what you rejected and why.

A useful structure is one sentence for each important decision, each with a "because" that points back to the scenario or a requirement:

• the kind of product ("a web application, because students need to book from home on their own phones, and a browser needs no installation");

• the data storage ("a relational database, because students, rooms and bookings are linked, and the clash and weekly-limit rules are queries across many bookings");

• the language and main tools ("Python with Flask and SQLite, because Python is the language I have studied, Flask is small enough to understand completely, and SQLite needs no separate server");

• an alternative rejected ("a shared spreadsheet was rejected because it cannot refuse an overlapping entry").

You also need the skills, hardware, software and data to carry out the solution. Criterion A is the natural place to show that in a sentence, for example by noting that the trial server is provided by the school's IT department with its written consent.

A weak and a strong Criterion A

Both samples describe the same project. Read the weak one first, decide which band it fits and why, then compare it with the strong one.

The weak sample outlines a scenario with one problem and no evidence or numbers, so it fits the 1–2 band's "outlines a problem scenario". Its success criteria are limited: two describe features, two cannot be measured, and nothing covers no-shows, the weekly limit, blocks or reports. The computational context is outlined, not explained: the reasons would fit any project.

The strong sample matches every part of the 3–4 band. The scenario is described through its evidence and requirements, each requirement leads to at least one success criterion, every criterion has a number or a testable rule, and the context is explained with reasons that fit only this problem. It runs about 60 words over the recommended 300, which is acceptable as long as the whole documentation stays within 2,000: the figures per criterion are recommendations, and only the 2,000 total is a limit.

Common problems in Criterion A

Two smaller problems are common as well. The first is padding the scenario with background that the requirements never use: the history of the school or the benefits of music practice. Every sentence of the scenario should support a requirement. The second is changing the success criteria later without changing Criterion A. If testing in D shows that a criterion was unrealistic, it is better to keep it, test it honestly and discuss the shortfall in E than to rewrite A to match the product.

Checklist

• To do:

  My scenario says who has the problem, what goes wrong now, how I know, and what is out of scope.

• To do:

  I have gathered the scenario from the client or real users, with their consent.

• To do:

  I have listed solution requirements, functional and non-functional.

• To do:

  Every requirement leads to at least one success criterion.

• To do:

  Every success criterion contains a number, a limit or a yes-or-no behaviour that a stranger could test.

• To do:

  My criteria include the boundary cases I already know about.

• To do:

  My criteria describe outcomes, not features.

• To do:

  My criteria are numbered (SC1, SC2, …) so I can use the labels in B, C, D and E.

• To do:

  I have explained the computational context with reasons that fit only my problem, including one alternative I rejected.

• To do:

  Criterion A is about 300 words, and I know it will be used by every later criterion.