Computer science IA structure: sections, criteria and word count

At a glance

The structure, section by section

1. First page

Required by the IB (the total word count goes on the first page) · No criterion (formal requirement) · Outside the word count

A working title and the total word count.

1. Enter a working title.
2. Let the counter insert the total word count.
3. Recheck the number after your final edit.

2. Problem specification

Required by the IB (the documentation has 1 section per criterion, 5 in all) · Criterion: Problem specification

About 300 words: the problem scenario, measurable requirements, numbered success criteria, and the area of computing the solution uses.

1. Describe the problem and who or what it affects.
2. Turn each need into a measurable requirement.
3. Number your success criteria and make each one testable.
4. Explain which area of computer science your solution uses and why.
5. Confirm you have the skills, hardware, software and data access.
6. Get consent from everyone involved before you start.

3. Planning

Required by the IB · Criterion: Planning

About 150 words: a decomposition of the problem and a dated plan linked to the success criteria.

1. Break the problem into sub-problems and draw them as a diagram.
2. Link each part to its success criteria.
3. Build a dated plan for design, development, testing and evaluation, as a Gantt chart or an Agile plan.
4. Note any research you need, such as libraries to learn.

4. System overview

Required by the IB · Criterion: System overview

About 150 words: the system model with the UI design, an algorithm for each component, and the testing strategy.

1. Draw the system model: its components, how they relate and interact, and the user interface.
2. Write an algorithm for each component as a flowchart, pseudocode or plain language.
3. Draft a test table with test data and the expected outcome for each success criterion, including invalid input.
4. Check that a third party could build the product from this section.

5. Development

Required by the IB · Criterion: Development

About 1,000 words: the justified structure, key techniques shown in commented code excerpts, and testing for correctness, reliability and efficiency.

1. Justify the overall structure of the product.
2. Explain each key technique with a short commented excerpt.
3. Point each excerpt to its place in the full listing.
4. Evaluate the implementation choices you made.
5. Describe and justify your tests for correctness, reliability and efficiency.
6. Note where the video shows each test.

6. Evaluation

Required by the IB · Criterion: Evaluation

About 400 words: how far each success criterion was met, with evidence, and justified improvements.

1. Judge each success criterion against your test results.
2. Explain any partial result.
3. Propose realistic improvements.
4. Justify each improvement.

7. References

Required by the IB (the guide sets the minimum elements of each entry) · No criterion (not marked) · Outside the word count

Every source, library and piece of reused code.

1. Log each source and library when you first use it.
2. Credit any code you reused or adapted.
3. Give the author, date, title and pages where they apply.
4. Add access dates for online sources.
5. Use 1 style throughout.

8. Video

Required by the IB (the video is 1 of the 3 files you submit) · Criterion: Development · Outside the word count · Submitted separately

A separate file of at most 5 minutes that shows the product's full functionality and examples of your testing.

1. Plan the video against your success criteria.
2. Show every function working.
3. Show selected tests, including invalid input.
4. Narrate or caption what each test shows.
5. Trim it to 5 minutes or less.
6. Export it as MP4.

9. Appendices

Required by the IB (the full source code goes in the appendices PDF, which is not marked) · Criterion: Development (source code) · Outside the word count · Submitted separately

The full source code and other material the documentation refers to, such as consent records and sample data.

1. Export the complete source code.
2. Label it so your excerpts can point to it.
3. Add the other material you refer to.
4. Keep marked content in the documentation.

What counts toward the limit

Counts every word of the documentation except code excerpts, code comments and diagrams, the 3 exclusions the guide states. The guide is silent on headings, tables, captions and references, so headings, table text and captions count here and the reference list does not.

The limit: 2,000 words for the documentation, plus a video of at most 5 minutes. The 2027 guide states no rule on going over.

Graphs and visuals

• Decomposition diagram (structure chart or hierarchy) Drawn, very common
  Tree layout; the guide says decomposition is best shown as diagrams.
• Gantt chart, Agile plan or dated task table Drawn, very common
  Both chart types are named in the guide; link each task to the success criteria.
• System model diagram (UML class, ER, component or architecture) Drawn, very common
  Components and their connections, including the UI design; the diagram type depends on the product.
• UI wireframes and mock-ups Drawn, very common
  Part of the system model.
• Algorithm flowcharts or pseudocode Drawn, very common
  Plain language, flowchart or pseudocode are all accepted.
• Test table (test data, expected outcome, actual result) Table, very common
  Covers correctness, reliability and efficiency, and invalid input.
• Code excerpts Image, very common
  Commented, readable and pointed to the full listing; excluded from the word count, so add them as images.
• Screenshots of the running product Image, common
  Supporting evidence in Development; the video is the main evidence of functionality.
• Data-flow diagrams Drawn, occasional
  Not named in the 2027 guide.
• Efficiency chart (timings against input size) Plotted, occasional
  Testing for efficiency is required; charting it is optional.

The frequencies are our estimates, from what the IB guide expects and what teachers advise. We did not count them in marked work.

Citations

The IB prescribes no style; each entry needs the author, date, title, page numbers where they apply and an access date for online sources, and reused code, images, graphs and data must be credited.

The workspace keeps your sources and writes the bibliography in APA 7th to start with. You can switch to MLA 9th, Chicago author-date, Chicago notes (footnotes) or Harvard at any point.

Pitfalls

• Choose a problem complex enough for the course, and write the code yourself, using libraries only as techniques.
• Write success criteria you can measure, and carry them through Planning, Development and Evaluation.
• Write the system overview so that a third party could build the product from it.
• Test efficiency and unexpected input as well as correctness, and include the full source code in the appendices, since Development cannot reach full marks without it.
• Keep the video to 5 minutes, and show every function and selected tests as well as the interface.

The workspace is free with an account, and it never writes or rewrites your text. What we will and will not do with your coursework →

Sources

• Subject brief: DP computer science, first assessment 2027
• Computer science updates
• IB, "Read curriculum updates" (page last updated 24 March 2026)
• Computer science guide, first assessment 2027 (IB; published Feb 2025)
• Computer science guide, first examinations 2014 (IB)
• Diploma Programme Assessment procedures 2025 (published Sept 2024; updated Nov 2024, Feb 2025, May 2025)

The IB documents behind this page, checked 29 October 2026. The linked ones are on ibo.org; the others are IB documents we read in copies hosted elsewhere, so we name them without a link. Everything above is in our own words: the official wording is in your subject guide, which your coordinator can give you. LimeAdmissions is independent of the International Baccalaureate Organization, which has not endorsed this page. Every coursework structure →