4.14.3.2, 4.14.5.2 - Documented project design

Communicating the solution's structure

Documented design explains how the key aspects of a solution or investigation are structured, rather than forcing a reader to reverse-engineer its source code.

Start from the objectives and identify the responsibilities needed to achieve them. A fictional sports-club system might separate membership records, session bookings and reports. Explain how these parts exchange data and which part enforces capacity. A diagram may show relationships; prose should explain what the relationships mean. A box labelled “booking” with no account of its inputs, results or constraints conveys little.

For an investigation, design the programmed experiment: which inputs or conditions vary, what remains controlled, which operations are measured and how results are stored and compared. Explain how the design answers the investigative question. The communication method should suit the task; every project does not need the same collection of diagrams.

You may describe how the solution will be structured or how it is structured. An iterative project can revise its design when implementation evidence changes a decision. Keep the account consistent with the actual solution and record the reason for important revisions. A beautiful obsolete diagram can mislead a reader about the current system.

Data, algorithms and interfaces

Explain the representations and important operations that turn a structural overview into a usable design.

A data dictionary describes stored items, types, meaning and constraints. For a session record, SessionID identifies a session, capacity is a positive integer, and start time has an agreed representation. Explain relations or collections, keys and relevant links where they are used. Do not merely paste a database schema without explaining why the model supports the objectives.

For important behaviour, use precise prose, pseudocode or another appropriate technical notation. A booking decision must account for whether the member exists, whether the session has places, whether a booking already exists and what is changed on success. The description must specify relevant order and outcomes so that a reader can distinguish a rejected request from a stored booking. This lesson concerns communicating those decisions; route-specific lessons teach implementation in the chosen programming language.

Document interfaces between responsibilities. State inputs, returned values, preconditions and effects. “CreateBooking takes a MemberID and SessionID; returns a new BookingID on success or a defined failure result; successful use stores exactly one booking” is substantially clearer than “CreateBooking does bookings”. Explain failure behaviour instead of leaving a caller to guess.

Where a user interface is relevant, describe how users choose inputs, trigger operations and interpret feedback. Annotated sketches or actual screen images may communicate this; AQA accepts actual screen shots for relevant UI design. A screenshot still needs an explanation of significant behaviour. A button's appearance alone does not show how duplicate bookings are prevented.

Dependencies and justified decisions

A reader needs to know what the design relies on and why those choices suit the problem.

State significant dependencies: a relational database, a web framework, a numerical/scientific library, a plotting package, a particular data format or external hardware. Describe what each supplies and how the solution uses it. “Uses a library” conceals whether it provides a minor utility or the core operation being investigated. Distinguish your own programmed decisions from functionality supplied elsewhere, and acknowledge external material.

Justify choices using requirements and constraints. A relational store may suit persistent linked member/session/booking data with integrity rules; an in-memory structure may suit a small controlled investigation whose inputs are regenerated each run. Neither choice is universally superior. A relevant reason describes the effect on the actual problem.

Document assumptions and risks that a later stage needs to check. If a framework is relied upon to perform validation, specify the validation required and verify that it actually does so. If an external data source may be unavailable, explain the agreed failure behaviour or test fixture. Record interfaces and dependencies clearly enough that a third party can understand the design without installing and exploring every component first.

Articulation and evidence quality

Design quality is the clarity and completeness of the communicated structure, not the number of diagrams or pages.

In the formal documented-design grid, Level 4 (10–12) communicates all or almost all key aspects; Level 3 (7–9) communicates most; Level 2 (4–6) communicates some; Level 1 (1–3) leaves the structure so unclear that a reader must rely on the programmed solution. These are best-fit descriptions, not independent marks for including particular document types.

Use a suitable combination of diagrams, prose, algorithms, SQL, data structures, database relations and technical notation where relevant. Select representations for their explanatory purpose. A relationship diagram can show data links, while prose explains a consistency rule; a precise operation description can show the booking decision, while a screen sketch explains the user's interaction. Repeating identical information in all three forms adds volume without adding understanding.

Read the design as a third party: can you identify the major parts, the data they use, the important decisions, the interfaces and the dependencies? Can you trace a core objective to the responsible behaviour? Are important exceptions explained? Fix omissions that would force a reader to guess. Do not write unnecessary detail for functions irrelevant to the scope.

The centre applies the official grid to assessed work. The following questions check your understanding using explicit original formative point rubrics; they do not award design-section NEA marks.