Criterion E: Evaluation
Criterion E judges how well the product meets the success criteria from Criterion A and what should be improved next. The IB guide says the evaluation must be consistent with the problem specification and success criteria in A.
What you need to produce
- An evaluation of every success criterion, in the same order as Criterion A, with evidence
- Justified improvements to the product, each linked to a weakness you found
Word budget
About 480 counted words of prose. An evaluation table of short entries (codes, verdicts, evidence references) is typically not counted, so E gets some of the words saved elsewhere: the marks for evaluating and justifying come from the prose around the table. See how words are counted and allocated.
Subsections
| Subsection | Words (plan) | Suggested range | Main evidence |
|---|---|---|---|
| E1 Meeting the success criteria | 300 | 260–320 | prose; the short-cell verdict table is not counted |
| E2 Improvements | 180 | 150–190 | prose |
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 E (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 | states the extent to which the success criteria were met describes improvements to the product |
| 3–4 | evaluates the extent to which the success criteria were met justifies improvements to the product |
1 Purpose
Judge honestly, criterion by criterion, how far the product meets what you set out in Criterion A, using the evidence from development and testing.
2 What to include
- IB requirementEvaluate the extent to which the success criteria were met (3–4); “states” only reaches 1–2.
- IA GuideGo through every success criterion, in the same order as Criterion A.
- IA GuideGive evidence, not just “Achieved”.
- IA GuideAn honest “partially met” beats an unconvincing “fully met”.
- Teaching tipUse the table for verdicts and evidence references; use the prose for the criteria that are partly or not met, the most important ones and an overall judgement against the problem in A1.
- Teaching tipFor anything not fully met, say what happened, why, and what the effect is on the user.
3 Suggested length
About 260–320 counted words (planning allocation 300) of prose. The evaluation table is not counted while its cells are short entries: codes, verdicts and references. Spend the words on judgement: how well the important criteria are met, why something is only partly met, and what it means for the people in your scenario.
4 Worked example
| SC | Verdict | Evidence |
|---|---|---|
| SC1 | Met | T1, T2 |
| SC2 | Met | T3 |
| SC3 | Met | T4: 3 taps, 0.4 s |
| SC4 | Met | T5, T6 |
| SC5 | Met | T7 (after fix) |
| SC6 | Met | T8 |
| SC7 | Met | T9 |
| SC8 | Partially met | T10: +12 min |
| SC9 | Partially met | T11: no email |
| SC10 | Met | T12; Appendix C |
Eight of the ten success criteria were fully met. SC4, the most important, was tested beyond the plan: 200 simultaneous attempts to double-book produced no duplicates, and in the trial week Ms Okafor reported no disputes, against 11 double bookings on the paper sheet in September.
SC3 was met on the school's oldest laptops as well as on phones: three taps, with confirmation in 0.4 seconds against a limit of 2. SC5 was only met after testing: Sunday bookings counted towards the following week until ISO weeks were used (T7), and a regression test now protects the fix.
SC7 works as specified, but the trial showed its limit: offers often expire during lessons, so one freed slot passed through three students before anyone accepted.
SC8 is partially met. No-shows are released, but because the scheduler runs every five minutes a room can stay booked until 12 minutes after the start rather than 10, which matters when lunchtime slots last 30 minutes.
SC9 is partially met. Blocking cancels bookings correctly, but the school's mail server rejects the intranet's messages, so students only see a cancellation when they next log in and may arrive for a cancelled slot.
Overall, PracticePal solves the three problems in Criterion A: clashes are impossible, unused rooms are released and loud bookings next to each other are prevented. Ms Okafor's feedback (Appendix D) says she no longer spends time settling disputes, and unused lunchtime bookings fell from 14 of 42 to 4 of 45. The two partial criteria affect convenience rather than fairness, so the product is fit for use while they are improved.
5 Supporting evidence (to be added to your appendix)
- A table with every criterion, a verdict (met, partially met, not met) and an evidence reference (test ID, video timestamp, appendix page).
- Feedback from the person in your scenario, if you have it, with their consent.
6 Lessons from the IB exemplars
From the IA Documentation Guide's analysis of real, examiner-graded IB Computer Science IAs.
- Full marks (4/4) went to a student who honestly wrote “Not achieved” for one criterion, with a real reason.For your IA: Do not inflate verdicts. Explain what fell short and why; it is evidence of evaluation.
7 Completion checklist
Ticks are saved in this browser only, so you can use the list while you draft.
1 Purpose
Propose improvements that would make the product better for its users, each justified by a weakness or evidence you actually found.
2 What to include
- IB requirementJustify improvements to the product (3–4); “describes” only reaches 1–2.
- IA GuideTie each improvement to a real weakness you found.
- IA GuideAvoid “nicer UI” or “more colour”: examiners call these trivial.
- IB FAQSuggest improvements even if the product has no problems. They can address problems found in testing, and may include expanding the success criteria to a wider range of inputs, refining the efficiency or effectiveness of a feature, or a change in requirements that the testing did not capture.
- IB FAQJustify each improvement in terms of how it meaningfully benefits the product and how feasible it is. Trivial or contrived improvements are discouraged and will not be assessed positively.
- IA GuideDo not disguise an unfinished success criterion as an “improvement”: “finish the email feature” says nothing new. A specific, justified change that fixes a weakness testing revealed is fine.
- Teaching tipThree or four well-justified improvements are better than a long list. For each: the evidence, the change, the benefit and what it would cost or need.
- Teaching tipNotice how the example handles SC8: the evaluation in E1 says what fell short; the improvement here proposes a specific change, with evidence that it is feasible.
3 Suggested length
About 150–190 counted words (planning allocation 180). Prose, because each improvement needs a justification of its benefit and feasibility; a bare bulleted list of ideas reaches “describes” at best.
4 Worked example
A shorter no-show check. Testing showed rooms released up to 12 minutes after the start (SC8). Running the job every minute would release them within 11; the log shows each run takes under 50 ms, so the cost is negligible and the change is one line.
Recurring bookings. In the trial week, 38% of bookings repeated the student's slot from the week before, because students practise around fixed timetables. A “repeat weekly” option, limited to four weeks and counted towards the weekly cap, would save rebooking every Monday without letting repeats take popular slots all term. It needs one new table and a change to the weekly count.
Priority for imminent exams. Three Grade 8 students joined waiting lists already four places long. A priority queue ordered by exam date, then joining time, would give them fairer access; it needs an exam_date field and Ms Okafor's agreement, and would also cut the chain of expired offers seen under SC7.
A server database if use grows. The load test showed SQLite's single write lock suits 140 students; if other departments adopt PracticePal, PostgreSQL would allow concurrent writes.
5 Supporting evidence (to be added to your appendix)
- The data or observation behind each improvement (a test result, usage figures, user feedback).
- If useful, a small sketch of the proposed change; it is not required.
6 Lessons from the IB exemplars
From the IA Documentation Guide's analysis of real, examiner-graded IB Computer Science IAs.
- “Make the GUI nicer” was dismissed as trivial in three separate projects.For your IA: Improve what the product does for users, and say why it matters, with evidence.
- An “improvement” that is really a missed success criterion doesn't earn credit.For your IA: Evaluate unmet criteria in E1. If you propose fixing one here, say exactly what you would change, the benefit and why it is feasible.
7 Completion checklist
Ticks are saved in this browser only, so you can use the list while you draft.
Criterion E worked examples: word total
| Subsection | Planning allocation | Worked example (counted words) |
|---|---|---|
| E1 Meeting the success criteria | 300 | 267 |
| E2 Improvements | 180 | 186 |
| Total | 480 | 453 |
The fictional PracticePal documentation uses 453 of the 480 counted words planned for Criterion E. Across all five criteria it stays within 2,000; see the budget table.