Criterion E: Evaluation

Marks: 4 • Recommended words: 400

Criterion E is where you look back at the finished product and say honestly how well it met the problem specification. Two things must be in the evaluation:

An evaluation of the extent to which each success criterion was met.
Improvements to the product, with the reasoning behind them.

The evaluation must be consistent with the problem specification and success criteria in Criterion A. Both halves of the criterion reference back to A. Clear success criteria give you a firmer basis for evaluation.

Pair the table with evaluation. A two-column table summarising whether each success criterion was met can sit at the top of this section, but the 3-4 descriptor asks you to evaluate “the extent to which the success criteria were met”, and ticks alone only state it. Explain how far each criterion was met, which inputs exposed limitations, how those limitations affect the user, and how the criteria compare with one another.

1. Evaluating against the success criteria

Go through the success criteria from Criterion A one at a time. For each, say:

Extent. Was it met fully, partially, or not at all?
Evidence. What in the product, testing results, or video shows this?
Why. What about the implementation led to this outcome?

A two-column table is a common format, but the upper band’s command term is evaluates, and ticks or one-word answers only state the result. Add the reasoning, either in a wider table column or in a short section of prose after the table.

Example table (meal planner)

Success criterion	Met?	Evidence
SC1: CRUD recipes	Fully	Tests 1-3 passed; video 00:45-01:15 demonstrates add, edit, delete
SC2: Weekly plan assignment	Fully	Test 4 passed; video 01:15-01:40
SC3: Shopping list aggregation	Fully	Test 5-6 passed; video 02:10-02:40
SC4: Pantry comparison	Partially	Aggregation works (tests 5-6), but unit conversion (grams vs. kilograms) not implemented; edge cases in test 7 revealed mismatch
SC5: Swap recipe live update	Fully	Test 8 passed; video 02:40-03:00
SC6: Persistence between sessions	Fully	File-save test 9 passed; video 03:00-03:15 shows close-and-reopen
SC7: Export shopping list to text	Not met	Not implemented (deprioritised in favour of fixing SC4 mismatch)

Then the prose does the evaluation:

Five of the seven success criteria were fully met, SC4 was partially met and SC7 was not implemented. The pantry comparison works correctly when both recipe ingredients and pantry items use the same unit, but fails when a recipe specifies grams and the pantry tracks kilograms. This was uncovered late during testing (test 7) and was deprioritised in favour of correctness for the other cases, but it undermines SC4 in any realistic use. SC7 (text export) was dropped when time ran short; the core meal-planning workflow was preserved at the cost of the export feature.

What counts as evidence

Test outcomes from your testing strategy, including failures.
Video timestamps showing specific functionality.
Screenshots or short code excerpts placed in the documentation itself. The appendices are not used as evidence for awarding marks, so put the evidence you rely on in the documentation or the video.

Client or user feedback is not required by the current syllabus, but genuine feedback (if you gathered any) can add evidence to the evaluation. Discuss it in the evaluation itself; feedback placed only in the appendices is not used as evidence.

Do not invent feedback. Presenting feedback you did not actually collect is fabricating data, which the IB’s Academic integrity policy treats as academic misconduct. If you include genuine feedback, say honestly when and how you collected it.

2. Improvements to the product

For each improvement:

State what the improvement is: concrete and specific.
Justify why. What problem in the evaluation does it address? Does it close a success-criterion gap, handle a real edge case, or extend the product in a user-motivated way?
Keep it realistic in scope, technology, and complexity. Recommending “add network multiplayer” to a single-user desktop app reads as unrealistic.

The IB guide does not specify a minimum number of improvements. The 3-4 descriptor asks you to justify “improvements to the product”, so put your words into a few well-justified improvements rather than a long list of generic ones.

Example (meal planner)

Add unit-conversion handling in pantry comparison. The partial failure of SC4 is traceable to a single assumption that all quantities are in the same unit. Adding a unit-normalisation layer (kg → g, L → ml) before comparison would close the gap. This is a targeted fix: the pantry and recipe data structures already store quantity-unit pairs, so only the comparison function needs to change.

Implement the shopping-list export (SC7). The export format is straightforward (aggregated list, one ingredient per line with quantity and unit). The underlying data is already computed; only the file-writing and a file-picker dialog need to be added. Estimated effort ~1-2 hours, based on comparable file I/O elsewhere in the project.

Compare this to a vague version:

The program could be made better by adding more features.

It is neither specific nor justified: it does not describe a particular change, let alone justify one.

Template for writing a justified improvement

If improvements are not coming out specific enough, work through this scaffold for each one. Then write the prose; do not submit the scaffold itself.

What is being evaluated? (Feature, functionality, or algorithm.)
Which SC does it relate to?
What specifically went wrong or fell short? (Cite evidence: a test case, a video timestamp, a user observation.)
What is the suggested improvement? (Concrete and bounded: “add unit conversion in the comparator” beats “improve pantry comparison”.)
Why is this improvement necessary? (What harm does the current behaviour cause? Which SC does the change close out?)
How would it work? (Brief technical sketch, e.g. “normalise quantities to a base unit before comparison”, not a full re-implementation.)
What is the trade-off or cost? (Estimated effort, performance, complexity.)

A two- to three-sentence improvement that covers points 3 to 7 above gives reasons for the change, which is what the 3-4 descriptor’s “justifies improvements to the product” asks for. A one-sentence “add X” only names the change, even if X is a good idea.

What “trivial” looks like in practice

A trivial improvement names no specific change and links to no success criterion. Trivial improvements share a shape:

“Make the interface prettier.” (Aesthetic claim, no SC linkage.)
“Add more features.” (Unbounded, no specific feature named.)
“Improve the user experience.” (Subjective, no concrete change.)
“Add more colours / better fonts.” (Surface polish, not problem-solving.)
“Re-promising an SC that was never implemented.” If the IA listed an SC in Criterion A but never built it, an “improvement” that only says “add it now” names the gap without justifying anything. If an unbuilt SC is worth listing, give reasons the way the SC7 example above does: why it matters, what it builds on, and what it would take.

If one of these phrases appears in your improvements, replace it with a specific change you can justify.

Mark bands

Marks	Level descriptor
0	The response does not reach a standard described by the descriptors below.
1-2	The response: states the extent to which the success criteria were met; describes improvements to the product.
3-4	The response: evaluates the extent to which the success criteria were met; justifies improvements to the product.

The two command-term shifts from 1-2 to 3-4 drive everything:

States → evaluates: 1-2 says “SC4 was partially met.” 3-4 says how partially, which specific inputs caused the partial result, what the impact on the user would be, and how this compares to the other criteria.
Describes → justifies: 1-2 says “I would add a text export.” 3-4 says why the text export matters for the problem, what evidence from testing or evaluation motivates it, and what the trade-offs of implementing it would be.

Word count and formatting

Recommended word count: 400. The guide excludes only code excerpts, comments and diagrams from the word count; tables are not on the list, so assume prose inside your evaluation table counts.
Keep the table entries to a word or short phrase per cell, and invest the 400 words in the prose that does the analysis and justification.
Suggested section heading in the single-PDF documentation: “Criterion E: Evaluation”.

Common pitfalls

Relying on ticks alone. The upper band asks you to evaluate, so add the reasoning behind each result, in the table or in prose.
Generic improvements. “Add more features” or “improve the UI” do not justify anything. Every improvement must be specific, motivated by something in the evaluation, and realistic.
Disagreeing with your own test results. Check that your evaluation agrees with the results reported in Criterion D, and explain any limitations those results reveal.
Over-claiming fulfilment. If a success criterion was only partially met, say so. The video and your test results show how far each criterion was met, so a claim they do not support weakens the rest of your evaluation.
Client feedback without analysis. Quoted feedback does not count as evaluation unless you analyse what it means for the product.

More pitfalls to check

“SC stated as met” instead of evaluated. At 1-2 the response states “the extent to which the success criteria were met”; at 3-4 it evaluates it. If your prose only repeats what the table already shows, add the reasons and evidence behind each result.
A trivial improvement in the list. It names no specific change, so there is nothing to justify. Replace it with a change tied to a success criterion; “Make the UI prettier” is a typical example of what to replace.
An improvement that re-promises an unbuilt SC. Re-stating an SC that was listed in A but never delivered names the gap without justifying a change. If you list it, give the reasons, as the SC7 example above does.
An unevaluated SC. The 3-4 descriptor asks you to evaluate “the extent to which the success criteria were met”. Give every SC from Criterion A its own evaluation, with enough reasoning and evidence to show how far it was met.
Inherited vagueness from Criterion A. If A’s SC were vague, E inherits the vagueness. A precise evaluation needs precise SC to evaluate against; the fix lives in A, not here.