Skip to content

The example project: PracticePal

The fictional project behind every worked example in the deep dives. Reading this first is optional.

The project at a glance

All the main worked examples come from one fictional project, so you can see how requirements, design, development, testing and evaluation connect.

The problem

  • A school music department books six practice rooms on a paper sheet.
  • Double bookings, unused rooms and drummers practising next to each other.
  • The head of music spends time settling disputes.

The solution

  • A web app in Python with Flask, and an SQLite database.
  • Booking rules: no clashes, 3 per week, no loud bookings next to each other.
  • Waiting list (a queue), automatic no-show release, room blocks and a usage report.
Illustrative only. The people, observations, test results and feedback in PracticePal are invented to show the level of detail and reasoning expected. Do not copy its wording or structure as a template: your documentation must describe your own problem, evidence and decisions. Where another technology needs a different example (Firestore, Realtime Database, OOP, a chatbot), the page says it is an alternative scenario.
See PracticePal's 10 success criteria

How the deep dives use it

Each criterion has its own deep-dive page: exactly what to write, how many words, a worked example, diagram examples where they apply, real examiner lessons and a checklist. Every subsection on those pages has the same seven parts: purpose, what to include, suggested length, a worked example with its word count, supporting evidence, lessons from the IB exemplars and a completion checklist.

Choose a criterion to start: A · B · C · D · E, or go back to the deep dives overview.