Criterion C: System overview
Criterion C is the design of your product. The IB guide says it should include a system model with the key components, their relationships, the rules governing their interaction and the user interface, the algorithms those components need, and a testing strategy, with enough clarity “to enable a third party to recreate the product”.
What you need to produce
- A system model: diagrams of the components, how they connect, how data is stored and the user interface
- Algorithms for the components: flowcharts, pseudocode or structured natural language
- A testing strategy that aligns with the success criteria, usually a test-plan table
Word budget
About 100 counted words. Diagrams (including all the text inside them and their captions) and pseudocode are not counted, so draw the system model and write the algorithms as flowcharts or pseudocode rather than describing them in prose; see the diagram examples. Design and test-plan tables are typically not counted either (IB FAQ), as long as their cells are short entries; a cell of extended writing (more than about ten words) counts. See how words are counted and allocated.
Subsections
| Subsection | Words (plan) | Suggested range | Main evidence |
|---|---|---|---|
| C1 System model | 35 | 20–45 | mainly diagrams, not counted |
| Diagram selection guide | – | – | teaching material: choose your system-model artefacts |
| C2 Algorithms | 30 | 20–45 | mainly flowcharts and pseudocode |
| C3 Testing strategy | 35 | 15–50 | test-plan table with short cells, not counted |
Each subsection below has the same seven parts: purpose, what to include, suggested length, a worked example, supporting evidence, lessons from the IB exemplars and a completion checklist. Labels show where each piece of guidance comes from:
Official level descriptors for Criterion C (best-fit marking)
| Marks | Level descriptor (IB Computer Science guide) |
|---|---|
| 0 | The response does not reach a standard described by the descriptors below. |
| 1–2 | outlines a limited system model identifies algorithms for the components of the system model identifies a testing strategy for at least one success criterion |
| 3–4 | constructs a system model that is not complete constructs algorithms for the components of the system model that lead to partial functionality of the product outlines a testing strategy that aligns with at least three success criteria |
| 5–6 | constructs a complete system model constructs algorithms for the components of the system model that enable the product to perform describes a testing strategy that aligns with the success criteria |
1 Purpose
Show the components of the system, how they are connected and how the user interacts with it, completely enough that someone else could rebuild the product.
2 What to include
- IB requirementA system model consists of diagrams that include the components of the system and how they are connected. It includes the design of the user interface.
- IB requirementA complete system model (5–6) covers all the components. The IB notes a complete model “does not include the algorithms”: those belong in C2.
- IA GuideUse several diagram types (for example use-case, class/UML, UI wireframes, data or file flow).
- IA GuideModel your core output too, not just the input screens.
- IA GuideLabel every diagram correctly (do not call a class diagram a “use-case diagram”).
- Teaching tipChoose artefacts with the five-question selection guide below; one good diagram per question is usually enough.
- Teaching tipUse the same names everywhere: components in the decomposition (B1), modules in the diagrams and files in your code.
3 Suggested length
About 30–50 counted words (planning allocation 40). The diagrams do the work and are not counted. Use a few words to say what each diagram shows. Captions that label or identify a diagram are not counted.
4 Worked example
The model shows who uses PracticePal (C1), how its parts connect (C2), how data is stored (C3) and the interface, including outputs and error messages (C4).
Scroll sideways to see the whole diagram.
Scroll sideways to see the whole diagram.
Scroll sideways to see the whole diagram.
Scroll sideways to see the whole diagram.
5 Supporting evidence (to be added to your appendix)
PracticePal's model also includes a site map, structure chart, booking state diagram and validation and error-message table.
Choose from the selection guide. For a typical database-backed app: a use-case diagram, an architecture diagram or site map, an ERD with schema, and annotated wireframes. For a game: a state diagram, an event–action table and screen designs. Browse the diagram examples.
6 Lessons from the IB exemplars
From the IA Documentation Guide's analysis of real, examiner-graded IB Computer Science IAs.
- A single diagram put a project in the lowest band; top scorers used 3+ diagram types.For your IA: Answer several of the five design questions, each with the artefact that suits your solution.
7 Completion checklist
Ticks are saved in this browser only, so you can use the list while you draft.
Your system model and algorithms should answer five questions about your design. Under each question are the kinds of documentation that can answer it, with a worked example of each.
IB requirement In the IB's terms, questions 1–4 and the interaction diagrams of question 5 (data flow, sequence, state) make up the system model; flowcharts, pseudocode, decision tables and query designs are the algorithms (C2).
1What does the system do and for whom?
Show the services your system provides and who can use each one. This is the outside view: no screens, no code, just actors (people or other systems, including a clock) and what they can do. It is the quickest way for an examiner to check your design covers every success criterion.
Suitable documentation
- Use-case diagram: actors, the use cases they start, the system boundary, and «include»/«extend» for shared or optional behaviour.
- User roles and permissions table: which role can view, create, change or delete what. Essential when you have logins or admin features.
Choosing for your solution
Most solutions with more than one kind of user benefit from a use-case diagram. If there is only one user and no login (a single-player game, a data-analysis tool), a short list of features linked to success criteria may be enough, and your effort is better spent on questions 4 and 5.
What useful design evidence looks like
- Each use case is a verb phrase (“Book a slot”), not a screen name.
- Every success criterion can be traced to at least one use case; label them with SC numbers if it helps.
- Automatic behaviour (timers, scheduled jobs) appears, with a clock as the actor.
Revise on this site: B1.1.1 problem specification
2What parts make up the system?
Show the main components, what each one is responsible for and how they connect. Pick the artefact that matches how your solution is actually built: modules and functions for procedural code, classes for object-oriented code, screens for a website, services for anything that talks to an external API.
Suitable documentation
- Architecture diagram: client, server, database, external services and the protocols between them.
- Site map or screen navigation diagram: every screen and how the user moves between them, by role.
- Module/function structure chart: for procedural solutions: which function calls which, with the data and flags passed.
- UML class diagram: for OOP solutions: classes, attributes, methods and relationships with multiplicities.
- Component dependency diagram: which module or package depends on which; useful for larger multi-file projects.
- API request/response specification: the interface between your components or with an external service: method, URL, inputs, outputs, errors.
Choosing for your solution
One or two of these is usually right. A Flask or Node web app: architecture + site map. A Python program made of functions: structure chart. A Java or C# program: class diagram. An app calling a weather or payment API: architecture + API specification.
What useful design evidence looks like
- Each component has a clear responsibility (one line is enough).
- Connections are labelled: what is sent, in which direction, using what (HTTPS, SQL, a function call).
- Names match your decomposition in B1 and your code files.
Revise on this site: B3.1.2 class designs · B3.2.4 composition and aggregation · B2.3.4 functions and modularisation · A2.2.2 servers
3How is data organised and stored?
Show both kinds of data: what is stored permanently (database, files, cloud store) and the data structures your program uses while it runs. Document the technology you actually use: a relational database, a document database, a JSON tree and a CSV file each need a different diagram.
Suitable documentation
- ERD and relational table schemas: entities, keys and relationships (crow's foot), then the tables with primary and foreign keys.
- Collection/document diagram: for document databases such as Cloud Firestore: collections, document IDs, fields, subcollections and references.
- JSON tree diagram: for Firebase Realtime Database: one tree of keys, the paths to values and what is nested where.
- File structure and file format specification: folders and files, and the exact layout of any file your program reads or writes.
- Data dictionary: every field: name, type, size, validation and an example.
- Data structure diagrams: linked lists, 1D and 2D arrays, queues, stacks, sets, dictionaries/maps, trees and graphs used in memory.
Choosing for your solution
Firestore or Realtime Database? They are both Firebase products but organise data differently. Cloud Firestore stores documents (sets of fields) inside collections; a document can contain subcollections, and queries run over a collection. Firebase Realtime Database stores one large JSON tree; every value has a path such as /roomStatus/P5/state, and you design by choosing keys and nesting so that each screen reads one branch. Draw the model of the one you use; a Firestore diagram for a Realtime Database project (or the other way round) misrepresents your design.
What useful design evidence looks like
- Keys and identifiers are shown: primary/foreign keys, document IDs, JSON keys.
- Types and validation are given for fields (in the diagram or a data dictionary).
- You explain at least one decision: why a link table, why a subcollection, why a queue instead of a list.
Revise on this site: A3.2.2 ERDs · A3.2.4 tables · A3.2.6 3NF · A3.4.1 database models · B2.2.2 arrays and lists · stacks · queues · linked lists · BSTs · sets · file processing
4How does the user interact with the system?
Show the interface, what the user can do on it, what feedback they get, and what happens when they enter something invalid. The IB guide says the system model includes the design of the user interface, and the IA Guide says to model the outputs, not only the input screens.
Suitable documentation
- GUI wireframes: the layout of each important screen, drawn before you build it.
- Annotated screen designs: wireframes with numbered notes linking parts of the screen to success criteria.
- Input validation and error-message table: every input, its rule, valid and invalid examples and the exact message shown.
- User journey diagram: the steps a user takes to complete a task, across screens.
- Command-line interaction examples: for text-based programs: a sample session with prompts, input and output, including errors.
- Conversation flows for chatbots: what the bot asks, how replies are handled and how it recovers from unexpected input.
Choosing for your solution
Graphical apps and websites: annotated wireframes of the key screens (not every screen) plus a validation table. Command-line tools: example sessions. Chatbots and voice interfaces: a conversation flow. Games: screen designs plus the controls (often clearer as an event–action table, see question 5).
What useful design evidence looks like
- Outputs are designed too: results, confirmations, reports, error messages.
- Annotations explain behaviour (“greyed out when the slot is taken”), not just labels.
- Every input has a validation rule and a planned message.
Revise on this site: B2.1.3 exception handling
5How does the system process information?
Show your algorithms, the rules they apply, how parts interact over time and how the system responds to events. This is where the IB's “algorithms for the components of the system model” live, together with the rules governing how components interact.
Suitable documentation
- Algorithm flowcharts: the logic of one algorithm with decisions and loops.
- Pseudocode: the same logic in structured text; often clearer for longer algorithms.
- Data flow diagrams: where data comes from, which process changes it and where it is stored.
- Sequence diagrams: the messages between user, interface, server and database, in time order.
- State transition diagrams: the states an object or game can be in and the events that move it between them.
- Decision tables: every combination of conditions and the action for each, for rule-heavy logic.
- Event–action tables: for event-driven programs and games: each event and what the program does.
- Function specifications: name, parameters, return value, preconditions and postconditions.
- Function composition / data transformation diagrams: for functional solutions: data flowing through a pipeline of pure functions.
- SQL query design tables: the purpose, inputs, query logic and expected output of each significant query.
Choosing for your solution
Every algorithm you describe in Criterion D must appear here first. Choose the format that makes each one clearest: a flowchart for branching logic, pseudocode for longer procedures, a state diagram for anything with modes or a lifecycle, a sequence diagram when timing between components matters, SQL query designs when the database does the work.
What useful design evidence looks like
- The algorithm is detailed enough to code from and is not copied code.
- Each one is linked to the success criteria it delivers.
- The key rule is stated once in plain words (for example “two bookings overlap when each starts before the other ends”).
Revise on this site: B1.1.4 flowcharts · searching · sorting · SQL queries · SQL aggregates
Practical selection guide
Start from how your solution is built, then add whatever else your success criteria need.
| If your solution is… | Start with… |
|---|---|
| Procedural solution (functions and modules) | Structure chart, function specifications, algorithm designs |
| Object-oriented solution | Class diagram (the relevant classes), sequence diagrams for key interactions |
| Functional solution | Function composition / data transformation diagrams, function specifications |
| Event-driven application or game | Event–action table, state diagram, screen designs |
| Relational database | ERD, table schemas, data dictionary, SQL query designs for significant queries |
| Cloud Firestore | Collection/document structure: fields, document IDs, subcollections and references |
| Firebase Realtime Database | JSON tree: keys, paths and nested values |
| External APIs or serverless functions | Architecture diagram, request/response specifications, sequence diagrams |
| Website or web app | Site map, wireframes, validation table |
| Command-line tool or chatbot | Example sessions or conversation flow, plus algorithm designs |
Artefacts that are often confused
| These two… | …are different because |
|---|---|
| ERD vs class diagram | An ERD models stored data: entities, attributes, keys and cardinality. A class diagram models program code: classes with attributes and methods, visibility and relationships such as inheritance. A Booking table and a Booking class can both exist, but they are drawn differently. |
| Data flow diagram vs flowchart | A DFD shows where data goes between external entities, processes and data stores, with no order or decisions. A flowchart shows the order of steps in one algorithm, with decisions and loops. |
| Site map vs deployment architecture | A site map shows screens and navigation as the user experiences them. An architecture diagram shows where the software runs and how machines and services communicate. |
| Decomposition (B) vs structure chart (C) | A decomposition breaks the problem into tasks for planning. A structure chart shows the program's modules, which calls which and the data passed. |
1 Purpose
Show how each component will work, in a form that is detailed enough to code from, before you write the code.
2 What to include
- IB requirementConstruct algorithms for the components of the system model that enable the product to perform (5–6). They can be natural language, flowcharts or pseudocode.
- IA GuideUse pseudocode, flowcharts or an indented list, not full code yet.
- IA GuideEvery algorithm that appears in Criterion D must appear here first.
- Teaching tipStart with the algorithms that carry your success criteria: rules, calculations, searches, sorting, scheduling, scoring, validation. Simple page navigation does not need an algorithm.
- Teaching tipWrite the key rule once in plain words (for example the overlap rule) so the examiner can check your logic quickly.
- Teaching tipIf your solution relies on database queries, a SQL query design table counts as algorithm design.
3 Suggested length
About 20–45 counted words (planning allocation 30). The flowcharts and pseudocode are the evidence and are not counted; the words say which algorithm covers which success criteria.
4 Worked example
Figure C5 and the pseudocode describe make_booking (SC4–SC6); offer_next (SC7) and the no-show job (SC8) follow. The significant SQL queries are in a query design table.
Scroll sideways to see the whole diagram.
FUNCTION make_booking(student, room, start, loud)
// SC4–SC6: every check must pass before anything is saved
end ← start + 30 minutes
IF NOT valid_slot(start) THEN RETURN "Invalid time"
IF room_blocked(room, start, end) THEN RETURN "Room is blocked"
IF overlapping_bookings(room, start, end) > 0 THEN
RETURN "Slot taken" // the page then offers the waiting list (SC7)
END IF
IF bookings_in_week(student, week_of(start)) ≥ 3 THEN RETURN "Weekly limit reached"
IF loud THEN
FOR EACH n IN neighbours[room] // dictionary: room → set of rooms
IF loud_bookings(n, start, end) > 0 THEN RETURN "Noise clash with " + n
END FOR
END IF
BEGIN IMMEDIATE TRANSACTION // lock first, so two requests cannot both pass
repeat the overlap check
INSERT booking(student, room, start, end, loud, "confirmed")
COMMIT, or ROLLBACK and RETURN "Slot just taken" if the insert fails
RETURN booking
END FUNCTION
overlap rule: booking A overlaps B when A.start < B.end AND B.start < A.endPROCEDURE offer_next(room, slot) // SC7, called when a booking is cancelled or released
entry ← first WAITING entry for (room, slot) ORDER BY joined_at // queue: first in, first out
IF entry = NULL THEN RETURN // nobody waiting: the slot simply becomes free
entry.state ← "offered"; entry.offered_at ← now
send offer to entry.student (link expires in 15 minutes)
END PROCEDURE
PROCEDURE every_5_minutes(now) // run by the scheduler
FOR EACH booking WHERE status = "confirmed" AND start + 10 min < now AND NOT checked_in
booking.status ← "no_show"; offer_next(booking.room, booking.start) // SC8
FOR EACH entry WHERE state = "offered" AND offered_at + 15 min < now
entry.state ← "expired"; offer_next(entry.room, entry.slot) // SC7
END PROCEDURE5 Supporting evidence (to be added to your appendix)
- PracticePal's significant SQL queries (Q1 overlap, Q2 weekly count, Q3 loud neighbours, Q4 usage report) are in its SQL query design table.
- Flowchart and pseudocode example · SQL query design table · sequence diagram (for interactions over time) · state diagram, decision table and event–action table.
- Revise flowchart symbols on B1.1.4.
6 Lessons from the IB exemplars
From the IA Documentation Guide's analysis of real, examiner-graded IB Computer Science IAs.
- Building a feature in D that was never modelled here gets penalised.For your IA: Before you submit, list every algorithm you describe in D and check it appears in C.
7 Completion checklist
Ticks are saved in this browser only, so you can use the list while you draft.
1 Purpose
Plan, before development, how you will show that each success criterion is met and that the product copes with unexpected or incorrect input.
2 What to include
- IB requirementDescribe a testing strategy that aligns with the success criteria (5–6); “at least three” only reaches 3–4.
- IB requirementThe testing strategy is a systematic approach to evaluating whether the solution works as intended. It should check that code functions correctly and handles unexpected or incorrect inputs. A table of proposed test data and expected outcomes is suggested.
- IA GuideOne row per success criterion at least: test → expected result.
- IA GuideInclude NORMAL, EXTREME (boundary) and ABNORMAL (invalid) data.
- Teaching tipPlan how you will test things that are hard to do by hand: timing, two users at once, large data (efficiency). Criterion D asks for correctness, reliability and efficiency.
- IB FAQThe criteria look for evidence of your testing strategy, not all of the testing itself. The teacher support material suggests test tables for a few major algorithms; full testing can go in your appendix if you need to refer to it.
- IB FAQTables used for a testing strategy are typically not counted, but extended writing in a table is. Keep each cell to a short entry (data, expected result, SC code) and put explanations in prose.
- Teaching tipRefer to success criteria by code (SC4), never by their text, so cells stay short.
- Teaching tipKeep the actual results for your appendix; Criterion D justifies the testing of each technique.
3 Suggested length
About 15–50 counted words (planning allocation 35) of prose around the test-plan table. The table is not counted while every cell is a short entry; a cell of more than about ten words counts as extended writing. Keep cells to data and expected results, never explanations.
4 Worked example
Each success criterion has at least one test, with normal, extreme and abnormal data. Timing and simultaneous bookings are tested with scripts.
| Test | SC | Data | Input | Expected |
|---|---|---|---|---|
| T1 | SC1 | Normal | correct login | week grid shown |
| T2 | SC1 | Abnormal | wrong password; student opens /admin | error message; 403 |
| T3 | SC2 | Normal | P5, this and next week | 5 × 20 slots, correct states |
| T4 | SC3 | Normal | book a free slot | ≤ 3 taps; < 2 s |
| T5 | SC4 | Extreme | 12:30 next to 12:00 | accepted |
| T6 | SC4 | Abnormal | same slot twice at once, ×200 | one booking each time |
| T7 | SC5 | Extreme | 3rd, then 4th booking (incl. Sunday) | 3rd accepted; 4th refused |
| T8 | SC6 | Normal, abnormal | loud next to loud; quiet | loud refused; quiet accepted |
| T9 | SC7 | Normal | join queue; booking cancelled | first offered; passes on after 15 min |
| T10 | SC8 | Extreme | no check-in at +9 and +11 min | kept; then released as no-show |
| T11 | SC9 | Normal | block P3, 9–13 Nov | bookings cancelled; students emailed |
| T12 | SC10 | Normal, extreme | busy week; empty week | correct counts; 0% |
| T13 | all | Abnormal | room “P9”; 03:00; text as date | message, not error page |
| T14 | SC2, SC4 | Efficiency | 2,400 bookings; 30 at once | grid < 0.5 s; booking < 1 s |
5 Supporting evidence (to be added to your appendix)
- A test-plan table like the one above. Its actual results, with screenshots and test output, go in your appendix; Criterion D justifies the testing of each technique, and the video shows examples.
- Validation rules for inputs belong in the validation and error-message table; the abnormal tests check them.
6 Lessons from the IB exemplars
From the IA Documentation Guide's analysis of real, examiner-graded IB Computer Science IAs.
- “Normal data only” testing was the single most repeated criticism across every exemplar.For your IA: Every criterion that takes input needs extreme and abnormal tests as well as normal ones.
7 Completion checklist
Ticks are saved in this browser only, so you can use the list while you draft.
A worked example of each design artefact, grouped by the five design questions in the selection guide. Choose the ones that suit your solution: nobody needs all of them.
1. What does the system do and for whom?
2. What parts make up the system?
3. How is data organised and stored?
4. How does the user interact with the system?
5. How does the system process information?
Often confused: ERD vs class diagram · data flow diagram vs flowchart · site map vs architecture. See the comparison table.
Criterion C worked examples: word total
| Subsection | Planning allocation | Worked example (counted words) |
|---|---|---|
| C1 System model | 35 | 26 |
| C2 Algorithms | 30 | 27 |
| C3 Testing strategy | 35 | 22 |
| Total | 100 | 75 |
The fictional PracticePal documentation uses 75 of the 100 counted words planned for Criterion C. Across all five criteria it stays within 2,000; see the budget table.