Guide to non-exam assessment documentation revision notes

Purpose of the documentation

The non-exam assessment should communicate the problem or investigation, the proposed design, the technical solution, the testing process and the evaluation. A third party should be able to understand the purpose, structure and quality of the work.

Analysis

Analysis defines the problem before the solution is designed. Begin with a clear statement describing the problem area and the specific problem being solved or investigated. Explain how the problem was researched, identify for whom it is being solved or investigated, and provide enough background for a third party to understand it.

The objectives should be presented as a numbered list. Each objective should be measurable, appropriate and specific. An appropriate objective is single-purpose and detailed enough to avoid ambiguity. Objectives should cover all required functionality of the solution or all relevant areas of an investigation. For example, an objective should identify one clearly testable requirement rather than combining several unrelated requirements in one statement.

Where it is possible and necessary, model the problem to inform the Design stage. Suitable models may include a graph or network model of connections, or an entity–relationship model. A fully scoped analysis researches the problem thoroughly, defines the problem clearly, omits nothing relevant to later stages, gives unambiguous objectives and includes necessary modelling.

Design

The Design section explains how the key aspects of the solution or investigation are structured and what the design relies on. The detail and format should be appropriate to the task. A combination of diagrams and prose may be clearer than either alone. Relevant design material can include algorithms, SQL, data structures, database relations and pseudo-code. If the design relies on particular libraries, a relational database or a web design framework, this should be stated. Where a user interface is relevant, screen shots of actual screens can communicate the design.

The important distinction is that Analysis states what problem and requirements exist, while Design explains how the planned solution will meet them. The design should be clear enough for a third party to follow the intended structure before examining the implementation.

Technical solution

Provide program listings that demonstrate technical skill. Listings should be appropriately annotated and self-documenting. Self-documenting code uses meaningful identifiers and well-structured code, reducing the need for comments. Present the code so that a third party can discern its quality and purpose.

An overview guide can identify executables, data filenames or URLs, database names and pathnames, allowing a third party to run the solution or investigation if desired. Particularly difficult code sections should be explained. Divide the listing into clearly labelled sections so that it is easy to navigate. This presentation is connected to the structured approach used during development.

Testing

Testing evidence should be structured, for example in a table. Select representative samples that demonstrate the robustness of the complete or nearly complete solution, or the thoroughness of the investigation, and show that requirements have been achieved. The aim is not to record every possible test and outcome, but to provide a balanced sample.

For each test, explain the test performed and its purpose where this is not self-evident. Record the test data, expected outcome and actual outcome. Evidence may include sampled before-and-after screen shots. A useful test record therefore connects a requirement or purpose to input data, an expected result and observed evidence.

Evaluation

Evaluation considers how well the outcome meets its requirements. Obtain independent feedback about how well the outcome meets those requirements and discuss the feedback. Feedback may be generated during prototyping; if it is used, present and reference it so that it can be found easily, and explain how and why it was taken into account. Finally, discuss realistic improvements that could be made if the problem or investigation were revisited.

Common errors

• Giving background information without clearly defining the specific problem.
• Writing objectives that combine several purposes or cannot be measured.
• Describing an interface without explaining the underlying structure or dependencies.
• Providing code without meaningful identifiers, structure or navigation guidance.
• Listing many tests without selecting representative evidence or stating expected outcomes.
• Evaluating the outcome without independent feedback or without discussing realistic improvements.
• Treating testing as a list of results rather than explaining the purpose and relationship to requirements.