Criterion E and the video

The video and Criterion E come at the end of the project, and both look back at the success criteria you set in Criterion A. The video shows the moderator that the product does what the documentation claims and that you tested it; the evaluation judges how far the product met each criterion and what should be improved. A weak video can undermine Criterion D, and an evaluation that ignores the success criteria cannot reach the top band of E, however good the product is.

The examples use the sample project from the other IA pages: a practice-room booking system for a school music department, with success criteria SC1 to SC8 (book a free slot, refuse clashes, a weekly limit of 3 hours, check-in and release of no-shows, room blocks, a weekly report, rejection of invalid input, and a day grid that loads in under 2 seconds with 2,000 bookings). The project, its results and the client's comments are invented for teaching.

The video

What the video must do

The video has no criterion of its own. It is evidence for Criterion D: the moderator uses it to judge how much of the product works (from "very limited" to "fully functional") and to see examples of the testing you describe in the documentation.

Two consequences follow. A feature that never appears in the video gives the moderator no evidence that it works, so it cannot count fully towards "fully functional". And because the video shows examples of testing, you choose which tests to show: the ones that prove the most, such as a boundary case, an invalid input being rejected, and the efficiency result.

Planning a script

Write a script before recording. Order it by success criterion, so the moderator can tick off SC1 to SC8 in the same order as Criterion A, and give each segment a time budget. The script outline for the booking system fits eight success criteria into 4 minutes 50 seconds.

The timeline of the script shows the same plan at a glance. The four shaded segments exist mainly to show boundary, invalid or efficiency tests; the SC4 segment also contains a wrong-code test and a boundary check-in.

Some behaviour takes too long to show in real time. The no-show release in SC4 happens 10 minutes after a booking starts, which would use a third of the video. Show it honestly but quickly: prepare a booking whose start time is already 10 minutes in the past, or run the product with a test clock, and say on screen what you did. The moderator needs to see the behaviour, and needs to know how the shortcut works so the evidence can be trusted.

Recording it well

Make the video easy to follow in one viewing, without pausing.

• Readable screen: record at a normal resolution with the browser zoomed so text is legible; close other windows and notifications.

• Prepared data: set up test accounts, bookings and a test week in advance, so each segment starts in the right state. Never show real students' names or data; use invented test data, which keeps to the ethical guidelines on confidentiality.

• Label each segment: a short caption or a spoken sentence naming the success criterion and test ID ("SC3, test T9: the weekly limit") links what the moderator sees to the test table in Criterion D.

• Narration is optional: nothing in the requirements asks for a voice-over, but a few words per segment, or captions, make the evidence much easier to follow. Don't read code or long explanations aloud.

• Record in segments: record one success criterion at a time and join the clips, so a mistake means re-recording 30 seconds, not five minutes.

• Check the file: watch the exported file to the end, check its length and format, and make sure the text is readable at the size it plays.

Criterion E: evaluation

Criterion E is worth 4 marks, with about 400 recommended words. It must be consistent with the problem specification and success criteria in Criterion A: you evaluate the product you planned to build, against the criteria you set.

The two bands differ only in their command terms.

• States the extent: says whether each criterion was met. "SC3 was met. SC4 was partly met."

• Evaluates the extent: weighs the evidence for each criterion (test results, the video, client feedback), considers how well it was met and under what conditions, and reaches a judgement. "SC4 was partly met: check-in works (T10 and T12, video 2:30), but in the client trial the release ran up to 70 seconds late twice, missing the 1-minute target."

• Describes improvements: says what could be added or changed. "Add email reminders."

• Justifies improvements: gives reasons for each improvement, tied to a shortfall or to feedback, with how it would be done and what it would achieve.

Evaluating each success criterion

Work through the success criteria one at a time, in the order of Criterion A. For each one, give a judgement (met, partly met or not met), the evidence for it, and anything that qualifies it. A table keeps this compact, and the prose after it carries the evaluation.

The evidence thread for SC3 shows where each piece of evidence comes from: the criterion from A, the planned test from C, the result from D, the moment in the video, and the judgement in E.

The sample evaluation table for the booking system uses the same test IDs as Criterion D.

The table records the evidence, and the prose after it carries the judgement. Spend the 400 words on the criteria where there is something to judge: SC4 deserves a paragraph (why the release was late, how much it matters to the client), while SC1 needs only a sentence.

Using client feedback

Feedback from the client is evidence that only the client can give: whether the product suits the real situation. Collect it in a structured way at the end of acceptance testing, with one or two questions per success criterion ("Was the 3-hour limit the right size?", "Did the weekly report match what you needed for department planning?") and a space for anything else. Keep the responses, with the client's consent, and quote or summarise them in E next to the criterion they concern.

Client feedback also feeds the improvements. In the sample project, the head of music said that students did not notice when a block cancelled their booking until they next signed in. SC5 was met as written, but the feedback shows a weakness the success criterion didn't anticipate, which is the kind of point an evaluation should make.

Justifying improvements

Improvements should come out of the evaluation, not from a list of features that would be nice to have. Each justified improvement answers four questions: what the improvement is, which shortfall or feedback it addresses, how it would be done, and what it would achieve or cost.

Extensibility is where Criterion E connects back to the structure you justified in Criterion D. The booking system keeps its rules in separate functions and its data in a relational database, so a new rule (for example, allowing longer bookings for students preparing for a recital) means one new function and one new column, not a rewrite. Saying why an improvement would be easy or hard to make, based on the product's design, is part of justifying it.

The second paragraph of the strong answer also shows extensibility in action: the improvement is easy because the release rule is already a separate, tested function.

Fitting E into 400 words

With eight success criteria, 400 words is about 50 words a criterion if spread evenly, so spread them unevenly. Criteria that were met cleanly need a sentence pointing to the evidence (or a row in the table). Criteria that were partly met, or where client feedback raised a problem, need a paragraph each. Two or three justified improvements, each tied to one of those paragraphs, are better than a list of eight undeveloped ones.

Checklist

• To do:

  My video is one file, in a common format, no longer than five minutes (I aimed for about 4:45).

• To do:

  It shows the running product, not slides or code, ordered by success criterion.

• To do:

  Every feature behind every success criterion appears working.

• To do:

  It shows examples of testing, including boundary and invalid input and the efficiency test, labelled with test IDs from Criterion D.

• To do:

  Anything sped up (a test clock, a prepared booking) is explained on screen.

• To do:

  Only test data appears; no real person's data.

• To do:

  My evaluation goes through every success criterion from Criterion A: met, partly met or not met.

• To do:

  Each judgement points to evidence: test results, video times and client feedback.

• To do:

  My words go mostly to criteria that were partly met or raised a problem.

• To do:

  Each improvement is tied to a shortfall or to feedback, says how it would be done, and weighs its cost.

• To do:

  E is consistent with D's test table and with the video.