Criterion C: System overview

Marks: 6 • Recommended words: 150

Criterion C is the design section, the bridge between your plan and your build. You show the reader what the product will look like as a system: its components, how they relate, the algorithms inside each, the user interface, and how you will test that the finished product works.

Three things should be in the system overview:

A system model: diagrams showing the key components, their relationships, the rules governing their interaction, and the design of the user interface.
Algorithms for the components of the system model, presented separately from the model itself.
A testing strategy aligned to the success criteria.

Together they should give enough clarity that a third party could recreate the product from the system overview alone.

The system overview must be consistent with the problem specification in Criterion A and the planning in Criterion B. The recommended word count is only 150, and diagrams do not count towards it, so let the diagrams carry most of the detail.

1. The system model

The system model is a set of diagrams that describe the product as a system.

Important. The guide’s clarification says a complete system model does not include the algorithms for each component: the model can be complete without them, because the algorithms are presented separately (see section 2 below). Keeping the two artefacts apart also keeps each one clear: the system model says what the components are and how they relate; the algorithms say how each component does its job.

The system model must show:

The key components (e.g. modules, classes, or services).
Their relationships: which components call or depend on which others.
The rules governing their interaction: when a component is invoked, what inputs it receives, what it returns.
The user interface: layout of the screens or views the user interacts with.

Useful diagram types

Choose the diagrams that best describe your specific product. You typically need two or three, not all of these.

Diagram	What it shows	When to use it
Class diagram (UML)	Classes, their attributes, methods, and relationships (inheritance, association, composition)	OOP products: almost always appropriate
Structure chart	Top-down module hierarchy with data passing between modules	Non-OOP or procedural products
Entity-relationship diagram (ERD)	Entities, attributes, and relationships between entities	Products with a database or structured persistent data
Data flow diagram (DFD)	Processes, data stores, external entities, and how data moves	Products where the story is about transforming or routing data
System flowchart	Abstract control flow through the system as a whole	Products with a clear top-level sequence
UI wireframes / mock-ups	Layout of screens or views, labelled with controls	Every product: the system model “will include the design of the user interface”

What “a third party could recreate it” means

Someone else, such as your teacher or an IB moderator, should be able to read your system overview (plus Criterion A and B) and have a strong idea of how to build the same product themselves. That does not mean they would make identical code choices. It means:

They know what the classes / modules are and what each is responsible for.
They know what inputs and outputs each component exchanges.
They know what the user sees and what actions they can take.
They know how the algorithms work well enough to implement them.

If any of these is missing, a third party would struggle to recreate the product from your system overview.

A practical self-check: show your draft system model to a peer who is not on your project. Ask them to describe to you, in their own words, what you are building. If they cannot, the diagrams are not yet doing their job.

Completeness check before submitting

Before you call the system model done, run two checks:

Against the success criteria from Criterion A. Every SC should map to at least one component in the model. If SC4 is “pantry comparison”, there should be a pantry component or class, not just an undifferentiated “data” box.
Against the decomposition from Criterion B. Every branch of your decomposition should appear in the system model. Components that exist in your B decomposition but not in your C model signal incomplete design.

Common problems to check for in the system model:

No UI design. The guide says the system model “will include the design of the user interface”. Wireframes or mock-ups are one way to show it, and the UI is an easy part to forget.
No file or database interactions. If the product stores data, show where it is stored and how it moves between components.
Domain-specific components missing. A chat-room project that does not model the networking layer; a database project that does not model the schema; a voice-driven project that does not model the speech-recognition pipeline.

The guide describes a system model as “diagrams that include the components of the system and how they are connected”, and the model also includes the UI design. That is hard to show clearly in one diagram, so plan on two or three diagrams that cover different views.

2. Algorithms

Algorithms are presented separately from the system model and can take different forms:

Natural language: numbered steps in plain English. Works well for simple algorithms.
Flow charts: symbols for start, process, decision, end. Good for control-flow-heavy algorithms.
Pseudocode: structured steps close to real code. Good for algorithms with loops, conditions and data handling. The IB guide sets no pseudocode notation, so use one clear, consistent style, such as the conventions on the site’s Pseudocode page or a neutral Python-like form.

Each algorithm should address the individual components of the system model, not the whole product at once.

Example (pseudocode for the meal planner’s shopping-list generator)

FUNCTION generateShoppingList(weeklyPlan, pantry)
    shoppingList = empty dictionary of {ingredient: quantity}

    FOR each day IN weeklyPlan
        recipe = weeklyPlan[day]
        FOR each (ingredient, amount) IN recipe.ingredients
            IF ingredient IN shoppingList
                shoppingList[ingredient] = shoppingList[ingredient] + amount
            ELSE
                shoppingList[ingredient] = amount
            END IF
        END FOR
    END FOR

    FOR each (ingredient, amountNeeded) IN shoppingList
        IF ingredient IN pantry
            inStock = pantry[ingredient]
            IF inStock >= amountNeeded
                mark ingredient as "already in stock"
            ELSE
                shoppingList[ingredient] = amountNeeded - inStock
            END IF
        END IF
    END FOR

    RETURN shoppingList
END FUNCTION

Include algorithms for the important, non-trivial operations, not every getter and setter. The guide says algorithms “should address the individual components of the system model”, so check that each key component’s main work is covered.

Choosing the right representation

The three formats are not interchangeable; each has a niche:

Natural language works for simple linear procedures (e.g. “find the minimum of a list”). It scales badly for branching or nested logic.
Pseudocode shows each step precisely and sits close to the code you will write, which suits branching, nested and data-heavy logic. Use one consistent style. Show loops, conditionals, and function calls explicitly.
Flowcharts are useful for control-flow-heavy logic, decision trees, or where the visual layout makes the path through the algorithm clearer. They are weaker for data transformation.

For algorithms with detailed logic that a peer would need to recreate step by step, pseudocode’s precision helps. For the one or two algorithms where the visual structure carries information (e.g. a state machine, an error-handling branch), a flowchart can add clarity. Mixing formats across different algorithms is fine and often preferable to forcing everything into the same shape.

Algorithm completeness check

Each of these capabilities should be covered by at least one algorithm in your system overview:

User input and validation
Core processing (the main “work” of the product)
Storage (saving, loading); the easiest one to forget
Output (display, file export)
Authentication / authorisation, where relevant

If your product saves or loads data, check that the algorithm section covers both; they are easy to leave out.

3. Testing strategy

The testing strategy describes your systematic approach to evaluating whether the computational solution works as intended. It must:

Align with the success criteria from Criterion A.
Check that the code functions correctly on expected input.
Handle unexpected or incorrect input: edge cases, invalid data, boundary values.

The effective format is a testing strategy table:

Test #	Success criterion	Description	Test data (input)	Expected outcome
1	SC1: Recipe CRUD	Add a new recipe	Name = “Dal”, ingredients = [(lentils, 200g), (onion, 1)]	Recipe appears in the list; file saved
2	SC1: Recipe CRUD	Add recipe with invalid quantity	Name = “Dal”, ingredients = [(lentils, “-50g”)]	Validation error shown; no recipe created
3	SC3: Shopping list	Aggregate across multiple recipes	Plan = 3 recipes all requiring onion	Shopping list shows combined onion quantity
4	SC5: Plan swap	Swap one recipe	Remove recipe A from Monday, add recipe B	Shopping list updates within 1 second
5	SC4: Pantry check	Item fully in stock	Pantry has 500g lentils; needed 200g	Lentils marked “already in stock”
6	SC4: Pantry check	Item partially in stock	Pantry has 100g lentils; needed 200g	Shopping list shows 100g remaining

Include a mix of:

Typical inputs: the normal use case.
Boundary values: empty lists, maximum sizes, zeros.
Abnormal inputs: invalid types, negative numbers, malformed files.

Every success criterion from Criterion A should map to at least one test.

The testing strategy you design here is the strategy you carry forward, deploy and report on in Criterion D. If development reveals new risks, revise the strategy to cover them, and make sure Criteria C and D describe the same strategy.

Test unexpected and incorrect input, not only typical input. The guide says the testing strategy should check that code “functions correctly” and handles “unexpected or incorrect inputs”. For every SC that admits boundary or invalid inputs, plan at least one test of each in addition to its typical-input test.

Planning tests around what could go wrong

Another way to find useful tests is to start from the risks: list what is most likely to go wrong in your product, then design a test for each one. For the meal planner, a record like this could sit alongside the main table:

Risk or question	Linked SC	Setup and input	Expected result	Why this test matters
What if a recipe lists the same ingredient twice?	SC3	One recipe uses 2 cloves of garlic in the sauce and 1 clove in the topping	One garlic line showing 3 cloves	A repeated name is easy to miss when the list is built
Does exactly enough count as in stock?	SC4	200g lentils needed; pantry has 200g	Lentils marked “already in stock”	Checks the edge of the pantry comparison (`>=` rather than `>`)
What if recipe and pantry use different units?	SC4	500g rice needed; pantry has 1kg	Rice marked “already in stock”	Recipes and pantry lists often record amounts in different units
What if the weekly plan is empty?	SC3	No recipes in the plan	An empty list and a short message, with no crash	Code that loops over data can fail when there is no data
What if saving fails?	SC6	The save location is unavailable (for example, a USB drive removed before saving), then save	An error message; the plan stays open and unchanged	A failed save could otherwise lose the user’s work

The last column records why each test is worth running, which also helps when you describe the strategy.

Tests like these are chosen from what the product should do. You can also choose tests from the code itself, so that every branch of a key algorithm runs at least once (white-box testing). For the shopping-list generator in section 2, that means an ingredient that is already on the list and one that is not, an ingredient that is in the pantry and one that is not, and pantry stock that covers the amount needed and stock that does not. The Testing Strategy page explains black-box and white-box testing and how to choose test data.

Mark bands

Marks	Level descriptor
0	The response does not reach a standard described by the descriptors below.
1-2	The response: 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	The response: 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	The response: 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.

Key thresholds:

System model completeness. 5-6 requires every essential component and the UI to be in the diagrams. 3-4 means some part is missing; 1-2 is a sparse outline.
Algorithms. 5-6 means the algorithms, if implemented, would produce the required behaviour. 3-4 means they would only deliver part of the functionality. 1-2 means algorithms are named but not meaningfully described.
Testing strategy. 5-6 aligns with the success criteria (all of them); 3-4 aligns with at least three; 1-2 aligns with at least one.

Word count and formatting

Recommended word count: 150. The guide excludes excerpts of code, comments and diagrams from the word count. It does not say whether design pseudocode counts as code, so check with your teacher, and keep any prose around your algorithms short.
Tables are not on the guide’s exclusion list, so assume prose inside the testing strategy table counts toward the 2,000 words. Keep each cell to a short phrase (inputs, expected outcome), not sentences.
Suggested section heading in the single-PDF documentation: “Criterion C: System overview”.

Common pitfalls

Designing the system after you have already built it. The system overview should be consistent with the product, but it should feel like a design document, not a reverse-engineered summary. Date your drafts if you need to.
Missing the UI. The guide says the system model “will include the design of the user interface”.
Algorithms reduced to “it does X.” A reader needs enough detail to recreate the algorithm, not a one-line summary.
Testing strategy that only covers happy-path inputs. Include edge cases and abnormal data.
Testing strategy with no mapping to success criteria. Every row should cite which success criterion it tests.

More pitfalls to check

A system model with no UI design. The guide says the system model “will include the design of the user interface”. Show it in a form that suits your product, such as labelled wireframes or mock-ups of the main screens.
A single-diagram system model. It is hard for one diagram to show structure, data and the UI clearly at once. Aim for two or three diagrams showing different aspects of the product, such as its structure, data and interface.
Algorithms missing for persistence. Saving and loading are easy to forget. If your product stores data, include algorithms for both.
A testing strategy with happy-path inputs only. The guide says the testing strategy should check that code handles “unexpected or incorrect inputs”. Add boundary and abnormal inputs for each SC that can receive them.
A testing table that lists tests without justifying them. The 5-6 descriptor asks you to describe “a testing strategy that aligns with the success criteria”. A short “why this test” column, naming the SC and the kind of input each test checks, helps you describe the strategy rather than only list it.