Identify and specify the functional, security and data requirements of a complex data exchange problem, including the systems involved, the data exchanged and the conditions for reliable exchange

What this dot point is asking

Unit 4 Topic 2 is complex data exchange problems and solution requirements. Where Unit 3 requirements describe a single user-facing solution, here you specify the requirements of an exchange between systems: which systems, what data, in what format, over what protocol, with what security, and under what reliability conditions. This analysis defines the scope of your IA3 prototype, so getting it precise is what lets you build and evaluate a focused exchange rather than an unbounded one.

What makes an exchange complex

A complex data exchange involves more than one system passing structured data, where the systems may be built differently, owned by different parties, or separated by a network. Complexity comes from the need to agree a format, secure the data in transit, validate what arrives, handle failures, and respect privacy and legal obligations. Identifying this complexity is the first step: you state which systems take part, what role each plays (source, destination, intermediary), and why they must exchange data.

Identifying the systems and the data

Begin by mapping the participants and the payload:

• Systems: name each system, its role, and the boundary between them.
• Data: what data is exchanged, its structure and its sensitivity. Personal or financial data raises privacy and security requirements.
• Direction and trigger: is the exchange one-way or two-way, and what triggers it (a user action, a schedule, an event).

This mirrors the data exchange diagram you produce as a design tool, and it grounds every later requirement in concrete systems and data.

Functional requirements of the exchange

Functional requirements state what the exchange must do, phrased as testable behaviours:

• The source system shall send new member records to the destination within five minutes of creation.
• The destination shall acknowledge receipt with a status response.
• The system shall retry a failed transmission up to three times before alerting an operator.

Each should be specific enough to test in your prototype evaluation.

Security requirements

Because Unit 4 is about impacts, security requirements are central, not optional:

• Confidentiality: sensitive data is encrypted in transit (HTTPS/TLS) and, where stored, at rest.
• Authentication: each system proves its identity, for example with an API key or token.
• Integrity: the receiver verifies the data was not altered, using hashing or checksums.
• Authorisation: a system can only access the data it is entitled to.

Naming the threat each requirement addresses (interception, impersonation, tampering) shows genuine understanding.

Reliability conditions

Reliable exchange requires several conditions to hold together: an agreed data format and schema, an agreed protocol, validation of incoming data, and explicit error handling so a failure does not corrupt either system. Stating these as conditions turns reliability from a vague hope into testable requirements.

Constraints, privacy and scope

Constraints shape the exchange: available APIs, network limits, the platform, and crucially the legal obligations around the data (privacy law for personal information). A clear scope statement says which exchanges are included in the prototype and which are out of scope, so IA3 stays achievable. Privacy and ethical considerations are themselves requirements when personal data is involved, linking this dot point to privacy and ethics.

How this appears in assessment

IA3 begins with exactly this analysis: you investigate a complex data exchange problem and specify its requirements before designing the prototype. The external exam can ask you to identify requirements or reliability conditions for a given exchange scenario. Practise turning a described exchange into a structured requirements list covering function, data, security and reliability.