Criterion D: Development

Marks: 12 • Recommended words: 1,000

Criterion D is the largest criterion – worth almost half the IA’s 30 marks and the only one that assesses the product itself. Criteria A, B, C and E are process-oriented; Criterion D asks what you built and how.

You support this criterion with three pieces of evidence:

The documentation (1,000 words) justifying the structure of the product, explaining and evaluating the techniques used, and describing and justifying the testing strategy.
The video (up to 5 minutes) demonstrating the product’s full functionality and giving examples from your testing.
The appendices containing the full source code, which referenced excerpts in the documentation point to.

The development must be consistent with Criterion A (problem specification), Criterion B (planning) and Criterion C (system overview) – you should be implementing the design you described, not a different product.

1. The video

The video provides evidence of the functionality of the product and examples of your testing strategy in action.

Video requirements

Length: no longer than five minutes. This is a hard limit stated in the 2027 IA guide.
Format: mp4, .avi, .wmv (or any common format).
Must demonstrate the full functionality of the product.
Must demonstrate examples of the testing strategy from Criterion C.
Must be narrated. Silent screencasts lose Criterion D marks because the examiner cannot tell what is being demonstrated or why. Talk through what you are doing as you do it.
Submitted as a separate file alongside the documentation and appendices.

What to include

Brief introduction (~15 seconds) – name of the product, the problem it solves.
Functionality demonstration (~3 minutes) – walk through every feature, narrated, with test data. Annotate on screen which success criterion is being demonstrated as you go.
Testing examples (~90 seconds) – pick a handful of rows from your testing strategy table (especially boundary and abnormal cases) and run them. Show the input, the expected outcome, and the actual result.

What to leave out

Code walk-throughs. The code goes in the appendices and the documentation. The video is about the product, not the source.
Extensibility demonstrations. Extensibility is no longer a separate assessment item in the 2027 syllabus – do not spend video time on it.
Intro animations, credits, background music. Keep it functional.

Recording tools

macOS Screenshot / QuickTime (Cmd-Shift-5) – built in, records screen with audio.
Windows Xbox Game Bar (Win+G) – built in, records screen with audio.
OBS Studio – free, cross-platform, more control than the built-ins.

Good audio matters more than good video. A decent microphone and a quiet room beat any camera.

2. Justifying the product structure

In the documentation, you must justify the structure of the product, why the structure is appropriate, and the techniques used.

The structure

Describe the high-level structure – typically the classes, modules, or services – and explain why this structure was chosen. Link the explanation back to the system model in Criterion C.

Useful questions to answer:

Why this number of components, and not fewer or more?
Why these boundaries between components?
What does each component own, and what does it not touch?
How does the structure make the product maintainable or extensible?

A one-paragraph justification tied to a class diagram from Criterion C is usually enough.

The techniques

The 2027 guide lists four categories of technique that count:

Category	What it means	Examples
Loops	Iteration constructs used for non-trivial work	`while` loops with complex exit conditions, nested iteration, iterator patterns
Data structures	Data organisations appropriate to the problem	`ArrayList`, `HashMap`, binary search tree, stack, queue, linked list
Existing libraries	Third-party or standard-library code that solves part of your problem	JavaFX for UI, JDBC for databases, JSON parsers, regex engines, CSV libraries
Integration of software tools	Combining multiple tools into a coherent product	Database + front-end + file export, REST API + local cache, file I/O + GUI + validation layer

For each important technique:

Identify the technique clearly.
Explain the choice – why this technique, given the problem and the data.
Show a referenced code excerpt in the documentation that points to the full code in the appendix.
Where appropriate, evaluate the choice – what did it gain you, what did it cost?

One complex technique well-justified scores higher than five superficial ones. Do not pile on data structures or patterns hoping quantity matters. Examiners reward depth of justification, not breadth of feature list.

Code excerpts in the documentation

Any code you show in the documentation must:

Include relevant comments explaining what the code is doing at the level a reader needs.
Be consistent in style (naming conventions, indentation, bracket placement) throughout the solution.
Be readable – meaningful identifiers, short enough to follow, with complex expressions split across lines.
Reference the full source code submitted as an appendix. The convention is to reference by class and method name – e.g. “see ShoppingList.generate() in Appendix A” – so the examiner can find the full implementation without searching the whole codebase.

Excerpts, comments and diagrams are not counted toward the 1,000-word limit – use them liberally.

3. Testing in the documentation

The testing strategy from Criterion C is deployed and reported on in Criterion D. You must:

Describe the testing strategy as it was actually carried out.
Justify its effectiveness – explain why these tests give confidence in the product.
Include testing for correctness (the product produces the right output), reliability (it handles unexpected input, edge cases, repeated use), and efficiency (it performs acceptably on realistic data sizes).
Support the description with examples in the video.

You do not need to reproduce the entire testing strategy table from Criterion C – reference it and focus on what the testing revealed about the product.

Mark bands

Marks	Level descriptor
0	The response does not reach the standard described below.
1–3	The response: constructs a product with very limited functionality; constructs a product using no appropriate techniques to implement the algorithms; states the choices made to implement the algorithms; states the testing strategy used.
4–6	The response: constructs a product that has limited functionality; constructs a product using at least one appropriate technique to implement the algorithms; outlines the choices made to implement the algorithms; states the effectiveness of the testing strategy.
7–9	The response: constructs a product that has partial functionality; constructs a product that uses some appropriate techniques to implement the algorithms; explains the choices made to implement the algorithms; describes the effectiveness of the testing strategy.
10–12	The response: constructs a fully functional product; constructs a product that uses appropriate techniques to implement the algorithms; evaluates the choices made to implement the algorithms; justifies the effectiveness of the testing strategy.

The four thresholds to watch:

Functionality: very limited → limited → partial → fully functional.
Techniques: none appropriate → at least one → some → all appropriate.
Discussion of choices: states → outlines → explains → evaluates.
Testing: states → states effectiveness → describes effectiveness → justifies effectiveness.

To land in the top band, every dimension needs to be at its top level. A fully functional product with only “states” about techniques does not get 10+.

What “fully functional” means

For the 10–12 band the rubric requires “a fully functional product.” In practice this means every success criterion from Criterion A produces working behaviour as demonstrated in the video – not just “the product runs without crashing.” A product that runs cleanly but only meets four of seven success criteria is partial functionality, not full – it sits in 7–9.

Appendices and full marks

Solutions that do not include an appendix with the full source code cannot be awarded full marks for the techniques demonstrated in Criterion D.

This is a hard rule. Always submit the appendix.

Word count and formatting

Recommended word count: 1,000 (excluding code excerpts, comments and diagrams).
Include the overall documentation word count on the first page of the full PDF.
Suggested section heading in the single-PDF documentation: “Criterion D: Development”.

Common pitfalls

Narrating what you did instead of justifying choices. The top band needs you to evaluate – say what each technique gained, what alternatives existed, and what the trade-off was.
Video longer than 5 minutes. The guide sets five minutes as a maximum – anything beyond that breaches a submission requirement.
Demonstrating code in the video. Code belongs in the documentation and appendices.
Missing the appendix with full source code. Caps you below full marks for techniques regardless of what the documentation says.
Techniques that do not match what the algorithms need. Using a HashMap when an array would do, or writing a bubble sort when a standard-library sort would be clearer, signals poor technique choice.
Testing strategy reported only as “all tests passed.” You need to say what the tests revealed – including failures you fixed – and why the strategy gave confidence in the product.