Guide to non-exam assessment documentation study guide

The central chain of reasoning

A strong NEA document forms a connected chain: the Analysis defines the problem and measurable objectives; the Design explains the structure and dependencies intended to meet those objectives; the Technical solution shows the implementation; Testing provides representative evidence that requirements have been achieved; Evaluation assesses the outcome against its requirements and uses independent feedback to identify realistic improvements.

When revising, ask whether each stage answers a different question. Analysis answers: what is the problem, who is it for, how was it researched and what must be achieved? Design answers: how will the solution or investigation be structured, and what will it rely on? The Technical solution answers: how has the design been implemented and presented so that a third party can understand it? Testing answers: which carefully selected tests demonstrate robustness, thoroughness and achievement of requirements? Evaluation answers: how well did the outcome meet its requirements, what did independent feedback indicate, and what could realistically be improved?

Applying the requirements

Suppose an objective is written as a numbered requirement. First check that it has one purpose and enough detail to be unambiguous. Then identify the design element that addresses it: this might be an algorithm, data structure, database relation, SQL statement, interface element or stated dependency. Next identify a representative test with test data, an expected outcome and an actual outcome. This reasoning prevents the documentation from presenting objectives, design and tests as unrelated lists.

If the problem can be represented by a graph, network or entity–relationship model, consider whether that model is possible and necessary for the Design stage. The model should inform the design rather than appear as irrelevant decoration. Similarly, if the solution relies on a numerical or scientific package library, a data visualisation package library, a particular relational database or a web design framework, the design should communicate that reliance clearly.

Judging technical presentation

Do not judge a program listing only by whether code is present. Consider whether meaningful identifiers make the purpose of data and operations understandable, whether the code is well structured, and whether comments are used where explanations are particularly necessary. An overview guide should make relevant executables, data filenames or URLs, database names and pathnames findable. Clearly labelled code sections help a third party navigate the listing and discern its quality and purpose.

Constructing testing evidence

A test table should be selective and balanced. For each chosen test, identify the purpose, test data, expected outcome and actual outcome. Explain why the sample is representative of the requirements and how the evidence demonstrates robustness of the complete or nearly complete solution, or thoroughness of the investigation. Recording every possible test is not the stated emphasis; carefully selected evidence is more useful when it demonstrates the important requirements clearly.

Evaluation and feedback

Evaluation is more than describing what the outcome does. Compare the outcome with its requirements and obtain independent feedback on how well those requirements were met. If feedback was produced during prototyping, present and reference it so it can be located easily. Explain which feedback was taken into account and why. A useful improvement is realistic and connected to the identified shortcoming, rather than an unsupported list of additional features.

Self-check questions

1. Can you state the specific problem, the intended user or client and the research carried out without relying on unstated background?
2. Are all objectives numbered, measurable, single-purpose and unambiguous?
3. Can you explain why a problem model is possible and necessary, or why it is not relevant?
4. Can a third party understand the design, algorithms, data structures, database relations and dependencies?
5. Can a third party locate and understand the program listings and run the solution if desired?
6. Does each selected test include data, an expected outcome, an actual outcome and a purpose where needed?
7. Does the evaluation use independent feedback, discuss how it was considered and identify realistic improvements?

A final review should trace every objective through the design, implementation, testing evidence and evaluation. Missing links usually indicate that the analysis is not fully scoped, the design is insufficiently communicated, the testing sample is not representative or the evaluation has not assessed the outcome against its requirements.