IB Computer Science IA Criteria: Your Checklist to Scoring Top Marks
Clear, examiner-aligned steps for Criteria A-E, updated for 2025 - what to include, how to present it, and how the marks are earned.
What Is the IB Computer Science IA?
The Computer Science IA is a practical project where you identify a real client, define their problem, and build a working computational solution. You design it, develop it, test it, and document every stage of the process.
Key facts:
Weighting: 30% of your final grade at SL; 20% at HL
Length: Up to 2,000 words (excluding code and appendices)
Assessment: Marked across five criteria (A-E), worth 34 marks total
Requirements:
A clearly defined client problem
A fully functional software product
Written documentation explaining design, development, testing, and evaluation
A short video demonstrating the program (required for HL, recommended for SL).
Ready to take your Computer Science IA to the next level? Join a one-on-one trial session where an IB Examiner will walk you through planning, development, and evaluation - helping you clarify your structure, strengthen each criterion, and boost your final mark.
IB Computer Science IA Criteria Overview
Your Computer Science IA is marked across five criteria, worth 34 marks in total. Each one targets a different part of your project - from defining the problem to evaluating your final product.
Criterion A: Planning (6 marks)
Define the client, the problem, and the success criteria your solution must meet.Criterion B: Solution Overview (6 marks)
Present your design: Record of Tasks, diagrams, structure, and test plan.Criterion C: Development (12 marks)
Explain how you built the solution - algorithms, code, techniques, and complexity.Criterion D: Functionality (4 marks)
Demonstrate that the product works through testing and (for HL) a short video.Criterion E: Evaluation (6 marks)
Reflect on how well the final product meets the success criteria and what could be improved.
Already started your Computer Science IA and want expert feedback before you submit?
Send Your IA for review now!
IB Computer Science IA Criterion A: Planning (6 Marks)
What does strong planning include?
Criterion A is where you define the problem clearly and show that your project is grounded in a real client’s needs. Examiners want to see that you understand the context, the limitations, and what “success” will look like before you start building anything.
What examiners expect
A real client with a specific problem you can address through a computational solution.
A clear, focused problem definition that explains what the client needs and why.
Relevant context: who the client is, where the problem occurs, and any constraints you must work within.
A set of success criteria - measurable points your final product must meet. These become the backbone of your later evaluation.
What to include in Criterion A
A short introduction of your client (e.g., a teacher, small business owner, organization).
A concise description of the problem the client is facing.
A brief justification for why a software solution makes sense in this situation.
5–7 success criteria, written as clear, testable statements (e.g., “The system must allow the client to…,” “The program must generate…”).
Common mistakes
Writing a vague or overly broad problem (“the client wants a better system”).
Describing a solution before describing the actual problem.
Choosing success criteria that are too general or impossible to measure.
Not showing enough real context for the client - making the problem feel invented rather than authentic.
How to reach the top band in Criterion A (6/6)
Keep the section lean - around 400-500 words.
Make the client and their problem feel real and specific, not hypothetical.
Ensure every success criterion is measurable, realistic, and directly tied to the client’s needs.
Avoid technical detail here - save coding decisions and design choices for later criteria.
Write with clarity and intention: the examiner should understand the problem instantly.
A strong Planning section makes everything that follows easier to write - and far easier for the examiner to reward.
IB Computer Science IA Criterion B: Solution Overview (6 Marks)
What does a clear solution overview look like?
Criterion B shows that you’ve planned your system properly before building anything. Examiners want to see a structured design, a complete Record of Tasks, and a test plan that links directly to your success criteria.
What examiners expect
A Record of Tasks (RoT) documenting the major steps in your project from start to finish.
A clear design overview explaining how your solution will work.
Visual representations such as flowcharts, class diagrams, data models, wireframes, or interface sketches.
A test plan showing how you’ll verify each success criterion.
Evidence that your design is thought-through, not improvised after coding.
What to include in Criterion B
A complete Record of Tasks using the IB template - chronological, detailed, and covering planning, design, development, and testing.
Diagrams that show the structure of your program (e.g., UML class diagrams, flowcharts, ER diagrams depending on your solution).
A short written explanation of your design decisions, including data structures, algorithms, or layout choices.
A test plan listing the tests you will run, the inputs, expected outputs, and which success criteria each test addresses.
Common mistakes
Treating the Record of Tasks as an afterthought or writing it retrospectively.
Including generic diagrams that don’t actually represent the real system.
Giving design descriptions that are too vague, too short, or too technical without explanation.
Missing or weak test plans that don’t correspond to the success criteria.
Presenting beautifully drawn diagrams with no written justification.
How to reach the top band in Criterion B (6/6)
Start your Record of Tasks early and update it throughout the project - it should feel lived-in.
Choose diagrams that genuinely help explain your structure; avoid unnecessary ones.
Write short, clear descriptions of design choices so the examiner understands your reasoning.
Make your test plan directly tied to your success criteria.
Keep the whole section clean and readable - the examiner should understand your system’s structure at a glance.
A strong Solution Overview sets up your development section naturally - nothing should be surprising once you begin writing Criterion C.
IB Computer Science IA Criterion C: Development (12 Marks)
How do you show strong development work?
Criterion C is the core of your IA. This is where you explain how you built your solution - the algorithms, techniques, and decisions that turned your design into a working product. Examiners want to see evidence of genuine complexity, not surface-level coding.
What examiners expect
A clear, logical explanation of how the solution was developed.
Algorithms, data structures, and programming techniques that go beyond the basics.
Annotated code excerpts or screenshots showing important parts of the program.
Justification for the tools, language, libraries, or frameworks you chose.
Evidence that your development work reflects the problem and success criteria you defined earlier.
What to include in Criterion C
Descriptions of key algorithms (sorting, searching, parsing, processing, validation, calculations - whatever applies to your project).
Explanation of your data handling: structures used, why they were chosen, and how they support the solution.
Step-by-step development decisions, supported by short code excerpts or screenshots.
Any significant classes, functions, modules, or components and what they do.
Justification for your language (e.g., Python vs. Java), frameworks, and external libraries.
Mentions of any challenges you encountered and how you solved them (brief, factual).
Common mistakes
Code dumping - pasting too much code or including large chunks without explanation.
Showing trivial features but calling them “complex.”
Using libraries or templates without explaining the underlying logic.
Screenshots with tiny unreadable code or missing annotations.
Writing a timeline (“then I coded X, then I coded Y”) instead of explaining decisions.
Forgetting to justify why a particular technique, data structure, or algorithm was chosen.
How to reach the top band in Criterion C (12/12)
Focus on quality over quantity - choose the most important parts of your program to highlight.
Annotate code excerpts so the examiner immediately understands what each part does.
Make sure the algorithms and structures you describe match the complexity level expected for CS IA.
Connect development decisions back to the success criteria whenever it makes sense.
Keep explanations clear and specific - show understanding, not just functionality.
The examiner should be able to see the thinking behind your code, not just the final product.
Strong Development writing makes your solution feel intentional, technical, and credible - and it’s where most students earn or lose the majority of their marks.
IB Computer Science IA Criterion D: Functionality (4 Marks)
What does “proof it works” actually mean?
Criterion D is where you show your solution working. Examiners want clear evidence that your program runs as intended, meets the success criteria you defined earlier, and has been tested properly.
What examiners expect
Demonstration that the core features function correctly.
Evidence that your solution meets each success criterion.
A short, clear demonstration video (required for HL) showing real use of the system.
Screenshots, test logs, or outputs that confirm the system runs reliably.
A brief explanation of potential future extensions or improvements.
What to include in Criterion D
A short video walkthrough (2–7 minutes for HL; recommended for SL) showing your program in action.
On-screen or spoken narration explaining the features as you demonstrate them.
Specific examples of features fulfilling the success criteria you listed in Criterion A.
Evidence of testing:
test logs
validation checks
successful/failed test cases
screenshots of important outputs
A short note on how the solution could be extended or scaled beyond the current version.
Common mistakes
Videos that are too long, too fast, or unclear.
Demonstrating only the easy features and skipping the ones tied to the success criteria.
Showing the interface without showing actual functionality.
No narration or explanation, just clicking around.
Missing test evidence or only showing “perfect case” scenarios.
Forgetting to tie the demonstration back to the original problem.
How to reach the top band in Criterion D (4/4)
Keep the video focused: show the features that prove the system works, nothing more.
Make sure every success criterion appears in either the video or your test evidence.
Use readable screens and clear narration so the examiner doesn’t have to guess what’s happening.
Include a simple, honest extension idea - something realistic that improves the system.
Present evidence cleanly: labelled screenshots, short captions, logical order.
A strong Functionality section gives the examiner complete confidence that your solution is real, reliable, and genuinely solves the client’s problem.
IB Computer Science IA Criterion E: Evaluation (6 Marks)
What does real evaluation look like?
Criterion E is where you reflect honestly on your finished product. Examiners want depth - not a summary of what you built, but an assessment of how well your solution meets the success criteria and what meaningful improvements could be made.
What examiners expect
A clear evaluation of your solution against each success criterion.
Direct, relevant client or user feedback where possible.
A short discussion of the limitations you encountered.
Realistic improvements that strengthen the system (not wish-list features).
Reflection that shows awareness of what worked well - and why.
What to include in Criterion E
A point-by-point evaluation showing whether each success criterion was fully met, partially met, or not met.
A brief explanation of why each result occurred (design choices, constraints, user needs).
Any client feedback on usability, accuracy, or usefulness of your product.
Specific, grounded improvements (e.g., optimizing an algorithm, improving input validation, adding error handling).
Mention of any constraints: time, data, platform limits, technical trade-offs.
Common mistakes
Simply summarizing the program’s features instead of evaluating them.
Listing every possible limitation instead of focusing on the impactful ones.
Writing vague improvements (“make it better,” “add more features”) with no justification.
Ignoring the success criteria entirely.
Treating this section as a conclusion rather than analysis.
How to reach the top band in Criterion E (6/6)
Evaluate each success criterion directly - this is the backbone of the section.
Use client feedback strategically to strengthen your points.
Pick two or three meaningful limitations and explain them clearly.
Suggest improvements that are technically realistic and tied to the limitations you identified.
Keep your tone reflective and concise - show understanding, not over-explaining.
A strong Evaluation shows maturity: you understand your solution, its strengths, and how it could grow beyond the version you built.
Final Checklist: Before You Submit Your CS IA
Use this to catch the issues that most often cost marks. If you can tick everything here, your IA is in strong shape.
Criterion A: Planning
Is the client clearly identified and real?
Is the problem specific, focused, and grounded in context?
Do your success criteria match the client’s needs and are they measurable?
Have you avoided describing the solution before defining the problem?
Criterion B: Solution Overview
Is your Record of Tasks complete, chronological, and detailed?
Do your diagrams accurately reflect the actual system you plan to build?
Have you explained your design decisions clearly (not just shown diagrams)?
Does your test plan directly link to your success criteria?
Criterion C: Development
Have you explained how you built the solution, not just that you built it?
Do your code excerpts show meaningful algorithms or logic?
Are your annotations clear and readable?
Did you justify your tools, language, and techniques?
Is the level of complexity appropriate and well-explained?
Criterion D: Functionality
Does the video (HL) or screenshots/logs (SL) show all core features working?
Is every success criterion demonstrated with some form of evidence?
Is the video clear, steady, and easy to follow?
Have you shown at least one or two real test cases, not just ideal outputs?
Did you include a short note about potential extensions?
Criterion E: Evaluation
Have you evaluated the solution against each success criterion directly?
Is client feedback included where possible?
Did you identify a few meaningful limitations (not a long list)?
Are your proposed improvements realistic, justified, and connected to the limitations?
Is the section reflective rather than descriptive?
When each of these boxes is ticked, your IA reads as clear, complete, and aligned with what examiners reward.
FAQ: IB Computer Science IA
Do SL and HL students have different IAs?
No. The task and criteria are the same for both levels. The only difference is weighting: 30% at SL and 20% at HL.
How long should the Computer Science IA be?
Your documentation can be up to 2,000 words. Code, diagrams, references, and appendices do not count toward this limit.
What programming languages are allowed?
Any language is acceptable as long as you can justify it and produce a fully working solution. Most students use Python, Java, JavaScript, or C# - but there are no restrictions.
Do I have to submit a working product?
Yes. The IA must be a functional computational solution. If it doesn’t run or key features are missing, you can’t score well in multiple criteria.
Is the video required for HL only?
Yes - HL students must submit a short demonstration video.
SL students are not required to submit one, but clear evidence of functionality (screenshots, logs, outputs) is still expected, and a short video is strongly recommended.
What if my client is a friend or teacher?
That’s fine. Many students work with someone they already know. What matters is that the problem is real, the needs are clear, and you can gather feedback from them during development.
Need Help With Your Computer Science IA?
Whether you’re tweaking your final draft, confused about a specific criterion, or still figuring out what to build, our team can help you move forward with confidence.
We offer three levels of support depending on where you are in the process:
One-off IA Review
A detailed, criterion-based review of your draft from an IB Computer Science expert. You’ll know exactly what to refine before submitting.
Review + Feedback Session
A full written review plus a one-on-one session where we walk through your IA together, clarify examiner expectations, and help you strengthen each criterion.
IA Start Package (Brainstorm & Plan)
Not sure what to build? We’ll help you choose a strong client problem, define measurable success criteria, and set up a realistic plan for your solution and documentation.
