Represent the design of a data exchange using data exchange diagrams, IPO tables and pseudocode to communicate how data moves and is processed between systems

What this dot point is asking

Before building a prototype, you must design it and communicate that design clearly. QCAA expects you to represent a data exchange with recognised design tools: a data exchange diagram showing how data flows between systems, IPO tables breaking each component into inputs, processing and outputs, and pseudocode for the exchange algorithms. These tools turn a requirements list into a buildable, traceable design, and they are the artefacts markers assess in IA3 design and IA1-style proposals.

Data exchange diagrams

A data exchange diagram is a visual model of how data moves between the systems in your solution. It shows each system as a box, the data flowing between them as labelled arrows, and the direction and trigger of each exchange. It answers, at a glance, who sends what to whom and in what order. A good diagram names the data (member record, test result), the format (JSON), and the protocol (HTTPS), so a reader understands the exchange without reading the code. It is the data-exchange equivalent of an architecture overview and orients every other design artefact.

IPO tables

An IPO (input, process, output) table breaks a component of the solution into three columns:

• Input: every piece of data or action the component needs.
• Process: the steps it performs, written as pseudocode following consistent rules.
• Output: every result the component produces.

IPO tables force you to think through each component completely before coding and make the design easy to check against requirements.

Pseudocode for exchange algorithms

The processing in an IPO table is expressed as pseudocode, using the same sequence, selection and iteration conventions as the algorithms dot point. For a data exchange the typical algorithm structure is: build or receive the payload, send or parse it, check the response or validate the data, handle errors, and confirm. Writing this in pseudocode lets you trace the logic, including the failure paths, before committing to a language.

BEGIN ReceiveRecord
    INPUT payload
    SET record TO ParseJSON(payload)
    IF record IS valid AND IntegrityVerified(record) THEN
        Store(record)
        OUTPUT statusResponse("200 OK")
    ELSE
        LogError(record)
        OUTPUT statusResponse("400 Invalid")
    END IF
END ReceiveRecord

How the tools fit together

The three tools form a chain. The data exchange diagram gives the big picture of systems and flows. Each component in the diagram gets an IPO table that defines its inputs, processing and outputs. The processing in each IPO table is detailed as pseudocode that you can desk check. Requirements flow into the diagram, the diagram into IPO tables, the tables into pseudocode, and the pseudocode into code, so every line of the prototype traces back to a requirement.

Other useful representations

Depending on the solution you may also use a data dictionary (defining each data item, its type and validation), a structure of the JSON or XML schema being exchanged, and test data tables. These complement the core three tools and strengthen the design folio by making the data and its rules explicit.

How this appears in assessment

IA3 assesses your design as well as your built prototype, and these tools are how the design is communicated and judged. The external exam can ask you to interpret or complete an IPO table or a data exchange diagram, or to write pseudocode for an exchange step. Practise producing all three from a requirements list and keeping them consistent with one another.