Marking criteria exam tips

Exam tips

• Link every judgement to the criteria

  When selecting a level or mark range, refer explicitly to scope, measurable objectives, coverage, dialogue with intended users, and the usefulness of the problem model.

  These are the features used to distinguish levels 1, 2, and 3, so criterion-linked justification is stronger than a general statement about quality.

• Match both coverage and clarity

  When selecting a level, consider how many key aspects are described and whether the solution structure can be understood from the design itself.

  The criteria distinguish levels by the extent of articulation and, at Level 1, by whether understanding the structure requires looking directly at the programmed solution.

• Use the extent of completion to choose the level

  First decide whether the system meets some, many, or almost all relevant requirements. Then select the corresponding level and mark range.

  The three levels are distinguished by the amount of the solution or investigation that has been completed.

• Separate level selection from exact-mark selection

  First identify the best-matching level from the demonstrated technical demand and proficiency. Then decide the precise mark using band achievement, coding style quality and solution effectiveness.

  The criteria describe level selection and exact-mark decisions as related but distinct stages.

• Classify the complete feature

  When assigning a group, name the specific data structure, algorithm, file organisation or model being used.

  The table contains examples at several levels, so broad statements such as 'the project uses algorithms' do not show which technical skill has been demonstrated.

• Use the exact characteristic in evaluation answers

  When judging a program, name the relevant characteristic and connect it to evidence from the program.

  This shows that the classification is based on the supplied coding-style criteria rather than on a general opinion about code quality.

• Link evidence to the criteria

  When describing testing evidence, explicitly connect it to the requirements, robustness and extent of testing.

  Clear links help demonstrate why the evidence supports a particular level rather than merely showing that tests were performed.

• Use a requirement-by-requirement evaluation

  Check every requirement explicitly, then explain any unmet requirement rather than ignoring it.

  The higher levels require full or nearly full consideration of how well the outcome meets all of its requirements.