Choosing a problem and a client

What a good IA problem looks like

The problem you choose sets a ceiling on every later mark. A problem with no real logic in it cannot produce algorithms worth designing in Criterion C or techniques worth evaluating in Criterion D, however well you write about it. A problem that is far too large ends with a product that only partly works. The best IA problems sit between the two: big enough to need several algorithms that you design yourself, small enough to finish, test and evaluate in the time you have.

Four checks decide whether an idea is worth taking further. The problem should be of personal interest and real; it should need genuine algorithmic thinking, not just storage; it should be feasible with your skills, tools, data and time; and it should meet the ethical guidelines. An idea that fails a check can usually be rescued by narrowing it, widening it or approaching it from a different angle.

The order of the checks matters. Interest comes first because you will work on the project for months, and a problem you care about is easier to specify in detail. Complexity comes before feasibility because it is easier to cut a rich problem down to size than to add depth to a thin one.

A real problem of personal interest

The IB asks for a problem of your own choosing and of personal interest. You can apply any topic in computer science that interests you, and it does not have to relate directly to the course content. Good problems usually come from a place where you can watch the problem happen and talk to the people who have it.

Working with a client

Many students build their product for a particular person who has the problem. That person is usually called the client.

The current IA criteria do not mention a client, and the task does not require one: the problem only has to be of your own choosing and of personal interest. A client still helps in three ways. They describe the problem in their own words, which gives Criterion A real requirements instead of guesses; they can agree what counts as success, which makes the success criteria harder to argue with; and they can try the finished product, which gives Criterion E evidence that is not just your own opinion.

You can also be your own user, for example in a revision tool for yourself. Then you need to work harder at objectivity: write success criteria that a stranger could test, and find other people to try the product before you evaluate it.

Every person involved in developing the solution must give consent before any investigation begins, and that includes interviews and observations of the client. Ask your teacher how your school records it.

Enough complexity and innovation

The IB asks for a problem that needs a software solution complex enough for a Diploma Programme course, and enough innovation for you to show organisation, algorithmic thinking and the ability to code your own algorithms. The teacher support material gives more detail on complexity; your teacher has it and can tell you whether an idea is enough. The table gives a practical way to judge an idea yourself. It is advice based on what the criteria reward, not an official list.

A product that only creates, reads, updates and deletes records (often shortened to CRUD) is the most common way to fall short. Almost every useful system does those four things, so they are not wrong to include. They simply leave nothing for Criterion C's algorithms or Criterion D's techniques to show, unless the problem adds rules on top.

Innovation in the IA sense is about your own design work, and an idea that already exists elsewhere can still qualify. Booking systems are common, yet this one is designed for a particular department's rules (30-minute slots, a weekly limit, a check-in code on the door), and the student has to work out how those rules are enforced. A product shaped closely around one client's problem gives you design decisions to explain in every later criterion.

Choosing a computational context

Once you have a problem, you choose the kind of software that will solve it. The IB calls this the computational context, and Criterion A's top band asks you to explain why you chose it.

The context should follow from the problem, not the other way round. Students who start with "I want to make a mobile app" often struggle to find a problem that needs one; students who start with the problem can usually explain the context in two sentences, which is exactly what Criterion A rewards.

Feasibility: skills, tools, data and time

The IB states that you should have the technical skills, the hardware and software, and access to the data that your problem needs. A problem that fails on any of these is risky, however good it looks on paper.

A useful habit before committing is to build a small prototype of the riskiest part in the first week or two. For the booking system, that means one web page that saves a booking to a database and refuses an overlapping one. If that works, the rest is more of the same; if it does not, you have found out early, while changing the plan is still cheap.

Feasibility also means cutting the scope to fit. The booking system deliberately leaves out signing in with the school's own accounts: that would need the written consent of the system's owner, access the student does not have, and time the project cannot spare. Leaving a feature out on purpose, and saying why in Criterion A, is a sign of good planning.

Ethics

Every IA must follow the IB's ethical guidelines, and a product that breaks them is not acceptable, however good its code. The rules exist because IA products often handle data about real people.

1. Consent first. Get consent from the people who will be involved in developing the solution before any investigation starts: interviews, observations, surveys and testing.

2. Written consent for existing systems. Get written consent from the owner of any existing system you use or change, for example a school website, a learning platform or a network you test.

3. Secure storage. Store all data you collect securely so that it stays confidential.

4. Single use. Use the data you collect only for your computational solution, and for nothing else without explicit permission.

5. Original data. Wherever possible, use original data or collect it yourself. The IB words this one as a recommendation; the first four are rules.

For the booking system, these rules become practical decisions. Development uses invented students, not real names and IDs. Passwords are stored only as hashes, so even a copy of the database does not reveal them. The client trial uses a server provided by the school's IT department, with its written consent, and the trial data is deleted at the end. Schools also follow local health and safety practice for any research linked to the IA.

Products that are not acceptable

Some products fail no matter how complex they are, because there is not enough of your own coded work in them: products made only of copied code, websites built from a template that fixes their structure and layout, sample products shipped with software (the IB names the Northwind database supplied with Microsoft Access), copied games without major documented changes, and apps made with drag-and-drop builders without code. Frameworks, engines and libraries are allowed. When you use one, the logic that solves your problem must still be designed and written by you, and the library must be acknowledged.

Writing the proposal

Before you start Criterion A you will usually write a short proposal for your teacher. The IB lists the initial proposal among the evidence a teacher can use to check that the final work is yours. A good proposal answers the four checks in a few lines each, so your teacher can see at once whether the idea will work.

Checklist

• To do:

  My problem is real, of personal interest, and described with evidence of what goes wrong now.

• To do:

  I can name at least two rules, calculations or processes that my product must carry out (not only storing and showing data).

• To do:

  I have a client or real users, or a plan for objective testing if I am my own user.

• To do:

  I have chosen a computational context because it fits the problem, and can explain why in two sentences.

• To do:

  I have the skills, hardware, software and data the problem needs, or a short plan to get them.

• To do:

  I have built, or planned, a small prototype of the riskiest part.

• To do:

  I know who must give consent, and written consent for any existing system I use.

• To do:

  My data will be stored securely, used only for the IA, and invented or original wherever possible.

• To do:

  My product will not rely on templates, copied code, sample products or no-code builders.

• To do:

  I have written a proposal that covers problem, client, context, algorithms, data, risks and consent.