The IB Computer Science IA criteria assess the complete process of creating a computational solution, from defining a problem to evaluating the finished product. For students first assessed in May 2027, the IA is marked out of 30 across five criteria: Problem specification, Planning, System overview, Development, and Evaluation.
Many online resources still describe the older 34-mark, client-based IA. This guide explains the current CS IA mark scheme, what each criterion requires, and the evidence needed for high marks.
Check which Computer Science IA criteria apply
The IB redesigned Diploma Programme Computer Science for first assessment in May 2027. Confirm your examination session before using any rubric.
| Examination session | IA mark scheme |
|---|---|
| Up to November 2026 | Older client-based IA marked out of 34 |
| May 2027 onward | Current computational solution marked out of 30 |
Under the current course, the IA is a 35-hour individual computational solution worth 30% of the final grade at SL and 20% at HL. The assessment criteria are identical at both levels, according to the official IB Computer Science subject brief.
The current IA does not require a formal client. You identify a real-world problem, develop a software solution, and demonstrate computational thinking, algorithmic thinking, and programming.
IB Computer Science IA criteria at a glance
| Criterion | Focus | Maximum marks |
|---|---|---|
| A: Problem specification | Problem, requirements, success criteria, and context | 4 |
| B: Planning | Decomposition and development plan | 4 |
| C: System overview | System model, algorithms, interface, and testing strategy | 6 |
| D: Development | Functionality, techniques, decisions, and testing | 12 |
| E: Evaluation | Achievement and justified improvements | 4 |
| Total | 30 |
The criteria form a connected chain. Success criteria established in Criterion A should guide planning, system design, development, testing, and evaluation. Vague early decisions can therefore weaken evidence across several criteria.
Criterion A: Problem specification, 4 marks
Criterion A examines whether you define a suitable problem and translate it into measurable requirements. You must state appropriate success criteria and explain why the selected computational context suits the problem.
The computational context includes the programming language, platform, technologies, and solution type. For example, Python with SQLite might be justified when a program must run offline and store structured records persistently.
Work in the 1-2 band outlines the problem but provides limited requirements or success criteria. For 3-4 marks, describe measurable requirements, state suitable success criteria, and explain the computational context.
“The application will be easy to use” lacks an objective pass condition. A better criterion is: “A first-time user can add and retrieve a booking without instructions, and the booking remains available after the application restarts.”
Criterion B: Planning, 4 marks
Criterion B assesses how effectively you divide the problem into manageable parts and plan work connected to the success criteria. Decomposition might separate authentication, storage, validation, search, reporting, and interface components.
The 1-2 band reflects partial decomposition and a plan covering only some criteria. The 3-4 band requires reasonable decomposition and planning that addresses the project’s success criteria.
Use a structure chart, component map, or hierarchy diagram to clarify the parts. Your chronology should cover design, development, testing, and evaluation. Generic entries such as “work on code” do not demonstrate purposeful planning.
Criterion C: System overview, 6 marks
Criterion C is the technical blueprint. It requires a system model, algorithms, user-interface design, and a testing strategy clear enough for another developer to understand how the product should work.
At 1-2 marks, the model and algorithms are limited, with testing linked to at least one success criterion. At 3-4, the design would support partial functionality and testing aligns with at least three criteria. At 5-6, the model is complete, the algorithms enable the planned product, and testing aligns with the success criteria.
Useful evidence includes class diagrams, database models, navigation maps, component diagrams, data-flow diagrams, and wireframes. Present important algorithms through pseudocode, flowcharts, or precise steps, focusing on distinctive logic such as scheduling, validation, ranking, or conflict detection.
Testing plans should include normal, boundary, and invalid data with expected results. Map every success criterion to at least one proposed test.
Criterion D: Development, 12 marks
Criterion D is worth 40% of the IA marks. It assesses functionality, implementation techniques, evaluation of development choices, and the effectiveness of testing.
| Marks | Overall standard |
|---|---|
| 1-3 | Very limited functionality; choices and testing are stated |
| 4-6 | Limited functionality; at least one appropriate technique is used |
| 7-9 | Partial functionality; techniques and decisions are explained |
| 10-12 | Full functionality; choices are evaluated and testing is justified |
Command terms matter. State means identify briefly, explain requires reasons, evaluate weighs strengths and limitations, and justify supports a conclusion with evidence.
Do not submit a code dump. Select concise excerpts showing important techniques, explain their operation, and connect them to Criterion C algorithms. Appropriate techniques could include data structures, modular functions, object-oriented design, persistent storage, exception handling, APIs, or non-trivial validation. They earn credit only when they serve the problem.
Testing should address correctness, reliability, and efficiency. Show, for example, that a search returns correct records, handles an empty database safely, and remains responsive with realistic data. The video should demonstrate full functionality and examples of testing, organized around the success criteria.
Criterion E: Evaluation, 4 marks
Criterion E requires evidence-based judgments about the completed product. For 1-2 marks, achievement is stated and improvements are described. For 3-4, achievement is evaluated and proposed improvements are justified.
Address each success criterion separately:
- Give a verdict: fully met, partially met, or not met.
- Cite relevant testing or video evidence.
- Explain the result’s effect on the intended user.
- Identify limitations and propose a realistic improvement.
A limitation does not automatically reduce the mark. Superficial evaluation does. Instead of suggesting “more features,” identify a technical change and its value, such as normalized partial matching that retrieves records despite capitalization differences. The RevisionDojo evaluation guide offers an evidence-led structure.
Submission rules and word allocation
The current guide requires a documentation PDF, a separate video, and an appendix PDF.
| Component | Requirement |
|---|---|
| Documentation | Five criterion sections, maximum 2,000 words |
| Video | Maximum 5 minutes, showing functionality and testing |
| Appendix | Full source code and referenced student-created resources |
Code excerpts, comments, and diagrams are excluded from the documentation word count, which must appear on the first page. Appendices are not normally direct marking evidence, but full marks for Criterion D techniques cannot be awarded without complete source code.
Suggested allocations such as 300 words for A, 150 for B, 150 for C, 1,000 for D, and 400 for E are recommendations, not criterion limits. Only the 2,000-word total is a formal maximum.
How the IA is marked
Your teacher awards a mark for each criterion, after which IB moderation checks the school’s application of the standard. Markers assess submitted evidence, not what they assume the software can do.
A traceability table can expose missing evidence:
| Success criterion | Planned component | Technique | Test | Verdict |
|---|---|---|---|---|
| SC1 | Booking module | Conflict detection | T1-T4 | Fully met |
| SC2 | Input form | Validation | T5-T8 | Partially met |
If a success criterion lacks corresponding design, implementation, testing, or evaluation evidence, the project is probably underdeveloped somewhere.
Common mistakes that reduce IA marks
- Using the wrong syllabus: Applying pre-2027 client guidance to the current IA.
- Writing vague criteria: Using words such as fast or intuitive without measurable conditions.
- Designing after coding: Producing diagrams that merely reproduce the finished product.
- Listing technologies: Naming Python, SQL, or libraries without explaining their suitability.
- Testing only valid inputs: Ignoring boundary, invalid, empty, duplicate, or high-volume cases.
- Describing instead of evaluating: Reporting what happened without judging choices or results.
- Relying on appendices: Placing essential explanations outside the main documentation.
You can examine annotated Computer Science IA exemplars to understand the expected standard. The RevisionDojo Computer Science IA Grader can identify possible rubric gaps, although unofficial feedback does not replace your teacher’s judgment.
What if you use the pre-2027 mark scheme?
Students assessed through November 2026 use five older criteria worth 34 marks: Planning, 6; Solution overview, 6; Development, 12; Functionality and extensibility, 4; and Evaluation, 6.
That scheme requires an identified client or adviser, consultation evidence, a Record of Tasks, client-based evaluation, and attention to extensibility. Do not combine these requirements with the 2027 rubric. The RevisionDojo older-syllabus IA guide is relevant only if it matches your examination session.
Conclusion
The current IB Computer Science IA criteria reward a coherent development process, not code alone. High marks require measurable criteria, purposeful planning, reproducible design, appropriate implementation techniques, systematic testing, and evidence-based evaluation.
Make every important claim visible to the marker. RevisionDojo’s IB Computer Science resource hub, Coursework Grader, and Jojo AI can help you strengthen technical understanding and identify rubric gaps before submission.
Sources and referenced URLs
- Official IB Computer Science subject brief
- Official IB Computer Science curriculum update
- IB Computer Science programme page
- Computer Science guide, first assessment 2027
- RevisionDojo Computer Science IA evaluation guide
- RevisionDojo Computer Science IA exemplars
- RevisionDojo Computer Science IA Grader
- RevisionDojo older-syllabus Computer Science IA guide
- RevisionDojo IB Computer Science resources