F160 + F161: AAQ Computing Revision Notes

Cambridge Advanced National in Computing (AAQ)  ·  Spec-aligned, updated from source

Topic 1 - Types of software

1.1  Programs vs applications

A program is a set of instructions that performs a specific, individual task. It may have no user interface (e.g. a background OS process) and is written in a language like Python or Java.

An application is made up of one or more programs, designed to be user-friendly and help users complete tasks. Examples: Microsoft Word, Chrome, Instagram.

Program characteristics
Performs a specific function or set of functions.
May have no user interface.
Can be reused as a sub-program in multiple applications.
Translated into a format the computer understands and then run.
Application characteristics
Designed to meet user requirements.
Has a user interface (menus, buttons, etc.).
May be designed for a specific OS (e.g. iOS app).
May involve multiple programs working together.

Devices: desktops/laptops, consoles, smart TVs, smart speakers, smartphones, AR/VR devices, and embedded systems (washing machines, cars).

1.2  Operating systems

Network OS (NOS)
Manages network resources. Centralised user and data management. Supports remote access. Example: Windows Server.
Open OS
Open-source: code is freely viewable, modifiable and distributable. Example: Linux. Good for low-cost or custom deployments.
Proprietary OS
Owned by a company. Source code is hidden. Requires a licence. Examples: Windows, macOS, iOS. Required when targeting specific hardware.

Justify OS choice based on the client scenario, e.g. building an iOS app = must use proprietary; museum terminal = open OS (customisable and low cost).

1.3.1  Application types (8 types)

Communication Educational Entertainment Games Lifestyle Productivity Protection & utility Web browsers
Communication
Simple UI, supports text/audio/video, requires network, end-to-end encryption, presence awareness.
Educational
Learning milestones, interactive quizzes, multiple content formats, progress tracking, age-appropriate.
Protection & utility
Runs in background, event-driven (scans/alerts), requires frequent updates, low resource use.
Web browsers
Displays HTML/CSS/JS, HTTPS support, bookmarks, tabs, history, customisable via extensions.

1.3.2  Software categories (5)

Open (open-source)
Free to view, modify and distribute. Promotes collaboration and customisation. Examples: Linux, LibreOffice.
Closed (proprietary)
Company owns the source code. Maintains control and generates profit. Examples: Microsoft Office, Windows.
Shareware
Closed software distributed free on a trial basis. Often has limited features or a time limit. Users buy the full version later. Example: WinRAR.
Freeware
Closed software that is completely free to use with no restrictions. Developer still retains control of the code. Examples: VLC, Adobe Reader.
Embedded
Built into specific hardware to perform dedicated tasks. Not traditional software installed by the user. Examples: washing machine controller, microwave.

1.3.3  Software types (3)

Off-the-shelf
Pre-made and ready to use. Designed for a general audience. Fast to deploy and cost-effective. Not customised for a specific user. Example: Microsoft Word.
Custom off-the-shelf (COTS)
Pre-built like off-the-shelf, but configurable via plugins, add-ons or modules. Balances speed of deployment with some personalisation.
Bespoke
Built specifically for one organisation or user. Exact fit for their requirements. More expensive and takes longer to develop. Examples: hospital patient management, air traffic control.

Justify choice against the client scenario, e.g. dental surgery bookings = bespoke (unique needs); general office = off-the-shelf (cost-effective).

Topic 2 - Software development models

2.1  Seven development models

Waterfall (traditional)
Linear, sequential phases, each completed one at a time before moving on. Requires all requirements to be clearly defined at the start. Best for stable, well-defined projects with fixed requirements.
Rapid throwaway prototype
Quickly creates temporary prototypes to explore ideas and gather user feedback. Prototypes are discarded after helping refine requirements. Good when user needs are initially unclear.
Incremental
System is developed in small, manageable sections. Each part is designed, built and tested individually. Allows early partial deployment and handles changing requirements over time.
Evolutionary prototype
An initial prototype is continuously improved based on user feedback until it becomes the final system. Unlike throwaway, the prototype is never discarded. Ideal when requirements are expected to change.
RAD (Rapid Application Development)
Focuses on quickly building software through iterative development and frequent user feedback. Uses reusable components and time-boxing. Best for fast deadlines where requirements can evolve.
Spiral
Combines iterative development with risk management. Cycles through: plan → risk assess → build/test → evaluate. Each loop addresses risks early. Ideal for complex, high-risk projects.
Agile
Iterative and flexible. Progresses in small usable chunks called sprints. Relies on frequent stakeholder collaboration and adapts to changing requirements. Named after the 2001 Agile Manifesto (Utah ski resort).

Throwaway vs evolutionary: both use prototypes, but throwaway discards them after gathering feedback; evolutionary refines the prototype until it becomes the final product.

2.2  Phases of software development

Seven phases that interact and iterate (e.g. testing may reveal design issues, requiring you to return to the design phase).

1. Planning
Includes requirements gathering and feasibility analysis. Sets clear goals, identifies resources (time, money, people, tools), and checks whether the project is viable.
2. Design
Architecture, UI layout and data structures are planned. Translates requirements into a technical blueprint.
3. Construction / creation
The actual coding and building of the system takes place.
4. Testing
Verifies functionality, finds bugs and ensures the system meets requirements.
5. Implementation
Deploying the system. Three methods:
Phased: rolled out in stages.
Parallel: old and new systems run simultaneously until the new one is trusted.
Big bang (crash): old system replaced all at once.
6. Documentation
User guides, technical documentation and manuals are created.
7. Maintenance
Ongoing updates, bug fixes and adaptations. Some systems require maintenance for decades; US air traffic control towers still run Windows 95 in places.

Topic 3 - Planning development projects

3.1  Importance of planning

Advantages of planning
Sets clear goals and direction for the project.
Identifies required resources (time, money, people, tools).
Better organisation, as team members know their roles.
Improves time management via deadlines and milestones.
Disadvantages of planning
Planning itself takes time and can delay the start of development.
Plans may become outdated if requirements unexpectedly change mid-project.
Consequences of NOT planning
Missed deadlines and overrunning costs due to poor estimates.
Unclear goals leading to confusion and delays.
Risk of delivering an unusable or incomplete product.

Planning considerations (things that must be evaluated in the planning phase):

Budget, timescales, team/human resources, available hardware and software, scalability requirements, security needs, and legislation compliance.

Three types of legislation to be aware of (you don't need specific law names):

  • Copyright: protecting original work from unauthorised use.
  • Data protection: how personal data must be handled and stored. Breaches can result in fines up to £17.5m or 4% of global turnover.
  • Electronic communication: rules around sending digital messages, cookies and electronic marketing.

3.2  Project planning tools (6)

Arrow diagram
Tasks represented as arrows connected in sequence. Shows task order and dependencies. Identifies the critical path: the longest sequence of dependent tasks, which determines the minimum project completion time.
Critical path analysis (CPA / CPM)
Identifies the sequence of tasks that determines the shortest possible project duration. Highlights tasks that cannot be delayed without affecting the timeline. Helps prioritise resources.
Flowchart
Standard symbols showing the sequence of steps and decision points. Used both as a planning tool (here in Topic 3) and as an HCI design diagram (Topic 5). Makes complex processes easy to communicate.
Gantt chart
Displays tasks on a horizontal timeline with start and end dates. Shows dependencies, overlaps and progress at a glance. Invented by Henry Gantt in the 1910s; notably used on the Hoover Dam.
PERT chart
Network diagram mapping tasks, dependencies and timelines. Uses three time estimates per task: optimistic, most likely and pessimistic. Useful for complex projects and identifying the critical path.
SWOT analysis
Strengths & Weaknesses = internal (controllable).
Opportunities & Threats = external (outside control).
Guides decision-making by highlighting advantages, weaknesses to address and potential risks.

Topic 4 - Application design scoping

4.1  Gathering client requirements (9 methods)

Document analysis
Review existing documents (manuals, reports, policies) to understand the current system and identify requirements.
Focus groups
Gather a small group of users or stakeholders to discuss needs, expectations and ideas together. Good for qualitative depth.
Interviews
Ask stakeholders structured or open-ended questions one-to-one. Collects detailed, specific requirements. Time-consuming but rich data.
Meetings
Clients and developers come together to share information, clarify requirements and make decisions collaboratively.
Observation
Watch users as they perform real tasks to see how they actually interact with the current system. Reveals issues users may not report themselves.
Problem reports
Use logged issues and complaints from an existing system to identify weaknesses and inform new requirements.
Questionnaires
Distribute structured forms with questions to a wide group quickly. Good for quantitative data. Less depth than interviews.
Shadowing
Follow a user throughout their normal working day to gain deeper insight into workflows and real-world needs.
Suggestion analysis
Review client or user-submitted ideas and feedback (e.g. suggestion boxes, feedback forms) to shape requirements.

4.2  Client requirement specifications

A client requirement specification formally documents exactly what the system must do and how it must operate. Know all elements:

Purpose of new system
Why the new system is needed and what problem it solves.
Functional requirements
What the system must do: the features, behaviours and functions it must perform.
Non-functional requirements
How the system must perform, e.g. speed, reliability, scalability, security, usability. Not what it does, but how well it does it.
Process constraints
Restrictions on how the system must operate, e.g. must use a specific programming language, must integrate with existing software.
Current system deficiencies
Problems or limitations with the existing system that the new system must address.
Data formats
How data is structured, stored and transferred within the system.
Client-defined constraints
Budget, timescales, integration requirements, hardware/software limitations, and data storage location (local/onsite, cloud, or physical storage devices).
Version and source control
How changes to code and documents are tracked and managed. Ensures the team works from the correct version and can roll back if needed.

4.3  Decomposition methods (4)

Decomposition breaks complex problems into smaller, manageable parts, making development easier to plan, understand and implement. Reduces errors and improves efficiency.

Abstraction
Simplify a problem by ignoring irrelevant detail and focusing only on what matters. Used in the early design/planning stages and when managing complexity in large systems or creating reusable components.
Pattern recognition
Identify similarities or recurring trends in problems or requirements. Allows reuse of existing solutions. Used during planning and analysis when dealing with similar tasks, inputs or outputs.
Top-down modularisation
Break the system down from a general overview into its most specific parts. Start at the big picture and drill down into detail.
Bottom-up modularisation
Build the system starting from the small, detailed components and combine them upwards into larger subsystems.
Parsing requirements
Systematically break down and analyse client requirements into actionable tasks or functions. Used at the start of a project to ensure a shared understanding between the development team and the client.

Top-down = start broad, go specific. Bottom-up = start specific, build up. Abstraction = filter out irrelevant detail. Parsing = break requirements into actionable tasks.

Topic 5 - Human-Computer Interface (HCI)

5.1.1  Types of human-computer interaction

Audio
Users interact via voice commands. Used in smart speakers (Alexa, Siri), accessibility features, in-car systems and hands-free devices.
Gesture / body movement
Hand waves, head turns or full body movements control the application. Used in AR/VR devices, gaming (Kinect) and some touchless kiosks.
Touch
Users interact by tapping, swiping, dragging or pinching directly on a screen. Used in smartphones, tablets, ATMs and self-service kiosks.
GUI (graphical user interface)
Visual interface using windows, icons, menus and buttons. Mouse and keyboard driven. Intuitive and accessible for general users. The most common interaction type for consumer software.
CLI (command-line interface)
Users type text commands into a terminal or shell. No graphical elements. Powerful and fast for expert users. Steeper learning curve and not suitable for general consumers.

GUI vs CLI: GUI is accessible, visual, and suited to general users. CLI is powerful, efficient for experts, but has a steep learning curve and no visual interface.

5.1.2  Types of device

Know the characteristics of each device type that uses application software and how those characteristics influence which HCI types are appropriate.

Desktop
Large screen, high processing power, wired network connection. Suitable for complex, resource-intensive applications. Not portable.
Laptop
Portable version of desktop. Battery powered. Wi-Fi and Bluetooth. Balances portability with processing power.
Smartphone
Highly portable. Touch input. GPS, camera, microphone. 4G/5G and Wi-Fi. Suited to mobile apps and on-the-move access.
Tablet
Larger touch screen than smartphone. Wi-Fi and optionally cellular. Good for media, education and productivity apps.
Games console
Dedicated gaming hardware with high graphics capability. Connected to TV via HDMI. Also used for streaming, social features and browsing.
Smart TV
Large screen connected to the internet. Supports streaming and browser-based apps. Limited input options (remote control).
Smart speaker
Primarily audio interaction via voice commands. No visual interface in most cases. Used for music, smart home control and information.
AR / VR / MR devices
Augmented, Virtual and Mixed Reality headsets. Gesture, body movement and audio interaction. Used for immersive apps, training and gaming.

5.2  Visual design considerations

Colour
Defines the visual appearance: backgrounds, buttons, icons, text. Must consider colour blindness (approximately 1 in 12 men are affected). Do not rely on colour alone to convey meaning; include text or icons too.
Interaction
How users control or respond to the system through input methods: clicking, tapping, swiping, typing or speaking.
Location hierarchy
The placement and organisation of interface elements based on importance. The most important elements should be placed in the most prominent positions.
Messages - help
Guidance provided to the user during normal use, e.g. tooltips, hints, instructions. Helps users understand how to use the application without needing external support.
Messages - error
Feedback shown when something goes wrong, e.g. invalid input or failed action. Should clearly explain what went wrong and how to fix it, without technical jargon.
Typography - style
Choice of font typeface. Should be appropriate for the audience and brand, e.g. sans-serif for readability on screen, serif for formal documents.
Typography - size
Font size affects readability and accessibility. Larger text for users with visual impairments or for headings. Consistent sizing creates clear visual hierarchy.

5.3  HCI design documents and diagrams (4)

Data flow diagrams (DFDs)
Shows how data moves through a system: where it comes from, where it goes, and how it is processed. Does not show decision logic or sequencing.
Level 0: context diagram, high-level overview.
Level 1: more detailed breakdown of individual processes.
Flowcharts
Standard symbols showing sequence of steps and decisions users may take. Used for both project planning (3.2) and as an HCI diagram to show user journeys through the application.
Visualisation diagrams
Graphical representations showing the layout, structure and appearance of an interface. Traditionally drawn in pencil; now often digital mockups shared with the team and clients for feedback.
Wireframe diagrams
Basic visual guides showing structure and layout only, with no styling, no colours, no branding. Used early in the design process to plan the UI layout before visual design begins.

Wireframe = structure only, no styling. Visualisation diagram = shows what it will look like. DFD = data flow, not logic or decisions. Flowchart = step-by-step sequence and decision paths.

Topic 6 - Job roles & communication skills

6.1  Job roles in application development (7)

Application designer
Designs the overall structure and layout of software applications. Creates the blueprint that guides the development team, ensuring the software performs required tasks efficiently and logically.
Mobile application designer
Designs apps specifically for mobile platforms (iOS or Android). Focuses on touch-sensitive interfaces, responsive layouts and ensuring usability on smaller screens.
Project manager
Oversees the entire software development process. Keeps the project organised, on schedule and within budget. Ensures all team members work efficiently towards shared goals.
Systems analyst
Gathers and analyses user and business requirements. Identifies possible improvements or entirely new system solutions. Ensures the final software solves the right problem.
Systems designer
Translates requirements into detailed technical system designs. Specifies data structures, system architecture and technical constraints. Ensures the system functions correctly and efficiently in practice.
User experience designer (UXD)
Focuses on how users interact with the application. Researches user behaviour through testing and feedback. Aims to make the software pleasant and efficient to use, reducing errors and frustration.
User interface designer (UID)
Designs the visual elements of the interface: buttons, menus, icons and overall layout. Makes the application visually appealing and easy to navigate, creating a strong first impression.

UXD = how it feels to use (research, testing, behaviour). UID = how it looks (visual design). Systems analyst = requirements gathering. Systems designer = technical architecture.

6.2  Communication skills (5)

Appropriate language
Tailor vocabulary, tone and technical detail to suit the audience. Use technical terminology with developers; plain, jargon-free language with clients and non-technical stakeholders.
Verbal
Spoken communication. Includes articulation, tone, pace and active listening. Used in meetings, interviews, presentations and daily team communication.
Non-verbal
Body language, facial expressions, gestures, posture, eye contact and appearance. Important during client meetings and presentations, as it conveys confidence and professionalism.
Questioning techniques
Open questions: broad answers, explore ideas.
Closed questions: yes/no, confirm specific facts.
Probing questions: explore detail further.
Clarifying questions: check understanding is correct.
Written
Emails, reports, documentation, messages and code comments. Requires clarity, accuracy and professionalism. Used by all roles throughout the development process.

Topic 1 - Application software considerations

1.1  Application platforms

The spec defines three application platforms. Know the uses, advantages and disadvantages of each.

AR / VR / MR applications
Uses: educational (virtual field trips, anatomy), instructional (training simulations, step-by-step guidance overlaid on real world), research (data visualisation, scientific modelling).
Advantages: immersive, hands-on learning without real-world risk. Disadvantages: expensive hardware, can cause discomfort, development complexity.
Websites
Types: e-commerce (online shopping), informative (news, wikis, corporate sites), educational (online courses, revision tools), social media (Facebook, X, Instagram).
Advantages: accessible on any browser, no installation, easy to update. Disadvantages: requires internet, may be slower than native apps, security risks (spoofing).
Computer games
Software designed for entertainment and interactive play. Can run on multiple platforms (PC, console, mobile). Advantages: wide audience, high engagement. Disadvantages: high development cost, hardware requirements, age-appropriate concerns (PEGI ratings).

Note: the spec's platform categories are AR/VR/MR, Websites, and Computer games. "Mobile app" or "desktop app" are NOT platform categories. Those are devices (1.2), not platforms.

1.2  Devices

Know the characteristics, advantages and disadvantages of each device that application platforms run on.

Desktop
High processing power, large screen, wired networking. Suitable for resource-intensive apps. Not portable.
Laptop
Portable, battery-powered. Balances power and portability. Wi-Fi and Bluetooth. Suitable for on-the-go use.
Tablet / hybrid
Touch screen, portable, Wi-Fi and optional cellular. Hybrids have detachable keyboards. Good for media and education apps.
Console
Dedicated gaming hardware with high graphics. Connected to TV. Also used for streaming and social features.
Server
High performance, runs 24/7. Hosts applications and data for multiple clients. Not used directly by end users.
Smart devices
Connected IoT devices such as smart TVs, smart speakers, and smart fridges. Limited processing, often voice or touch controlled.
Haptic
Devices that provide tactile feedback (vibration, force). Used in VR controllers, surgical simulators. Enhances immersion and interaction realism.
Wearables
Smartwatches, fitness trackers, smart glasses. Small screen or no screen. Sensor-based. Used for health monitoring, notifications and AR overlays.

1.3  Storage locations

On-site storage: physical storage at the organisation's own location.

File servers
Dedicated computers that store and share files across a network. Central management of files for multiple users. Accessible within the local network.
NAS (Network Attached Storage)
Storage device connected to a network. Multiple users access shared files simultaneously. Less complex than SAN. Used for file sharing in small-medium organisations.
SAN (Storage Area Network)
High-speed dedicated network of storage devices. Used in enterprise environments for large-scale, high-performance data storage.
SSD (Solid State Drive)
Fast read/write, no moving parts; durable and quiet. Higher cost per GB than HDD. Used in modern devices for OS and applications.
Portable storage
USB drives, external hard drives. Convenient for transferring data. Easy to lose and a security risk if unencrypted.

Cloud storage: data stored on remote servers accessed via the internet. Two things to know: locations and types.

Cloud storage locations:

Public cloud
Shared infrastructure managed by a third party (e.g. AWS, Google Drive). Low cost, highly scalable. Less control over security. Data is on shared infrastructure.
Private cloud
Dedicated infrastructure for one organisation. High security and control. More expensive. Used by organisations with sensitive data (NHS, banks, schools).
Hybrid cloud
Combination of public and private. Sensitive data in private cloud; general data in public. Flexible and cost-effective.
Community cloud
Shared between organisations with similar requirements (e.g. government bodies, NHS trusts). More control than public, cost shared across the community.

Cloud storage types:

File storage
Stores data as files in a hierarchy of folders. Simple, familiar structure. Good for documents, images. Example: Google Drive, Dropbox.
Object storage
Stores data as objects with metadata and a unique ID. Highly scalable. Ideal for large amounts of unstructured data (images, videos, backups). Example: AWS S3.
Block storage
Divides data into fixed-size blocks, each with its own address. Very fast; used for databases and virtual machines where performance is critical.
Elastic / scalable storage
Automatically scales capacity up or down to match demand. Pay for what you use. Ideal for applications with unpredictable or growing storage needs.
Cloud-based database services
Managed database hosted in the cloud (e.g. AWS RDS, Azure SQL). No need to manage physical hardware. Scalable and accessible remotely. Advantages: reduced admin, automatic backups.

The spec distinguishes cloud storage locations (private/public/hybrid/community) from cloud storage types (file/object/block/elastic/database). Know both sets separately.

Topic 2 - Data and flow in application software

2.1  Data formats and data types

Data formats: how data is structured and encoded for storage or transmission:

ASCII
Encodes basic Latin characters as numbers (0–127). Simple and widely compatible. Limitation: only 128 characters, with no support for non-Latin languages or special symbols.
Unicode
Extension of ASCII that supports over 140,000 characters across all world languages and symbols. UTF-8 and UTF-16 are common encodings. Advantage: universal language support. Disadvantage: larger file size than ASCII.
CSV
Plain text format where rows are records and fields are separated by commas. Simple and widely supported (Excel, databases). Disadvantage: no data types or formatting, can't handle commas in data without quoting.
Fixed width
Each field occupies a fixed number of characters. No delimiter needed. Fast to parse. Disadvantage: inflexible, as it can't exceed the allocated width and wastes space for shorter values.
JSON
Text-based, human-readable, key-value pairs. Lightweight, scalable, language-independent. Widely used in web APIs. Disadvantage: no support for comments, slightly less efficient than binary.
XML
Uses custom tags to structure data. Human and machine readable, self-describing. Used in config files and data exchange. Disadvantage: verbose, with larger file sizes and slower parsing than JSON.

Data types: the kind of value a variable stores in a program:

Boolean
Stores only two values: true or false (or 1/0, yes/no). Used for conditions and flags. Example: isLoggedIn = true.
Character (char)
Stores a single character such as a letter, digit or symbol. Example: grade = 'A'. Different from String which stores multiple characters.
Date
Stores a calendar date (and sometimes time). Format varies (DD/MM/YYYY, ISO 8601). Used for timestamps, scheduling, age calculations.
Integer (int)
Stores whole numbers: positive, negative or zero. No decimal point. Example: score = 42. Efficient and fast for counting and indexing.
Real (float / double)
Stores numbers with decimal points. Used for calculations requiring precision. Example: price = 9.99. Can have floating-point rounding errors.
String
Stores a sequence of characters (text). Example: name = "Jack". Most flexible data type. Can include letters, numbers and symbols, but mathematical operations can't be performed directly on it.

2.2  Data flow

Data vs information: data is raw, unprocessed facts (e.g. "42", "Liverpool"). Information is data that has been processed and given context and meaning (e.g. "42 students are enrolled at Liverpool campus"). Data is converted to information by processing it: sorting, calculating, combining with other data.


Types of input data that flow into an application:

Number
Numeric input: login codes, answers, quantities.
Text
String input: names, passwords, search queries.
Movement
Gesture/motion input: controller movements, mouse tracking, AR gestures.
Audio
Voice commands, microphone input for speech recognition.
Image - static
Still photographs, scanned documents, QR codes.
Image - moving
Video streams, webcam feeds, screen recordings.

Black box concept: a model where the system's internal processing is hidden. Only inputs and outputs are visible to the user. Data flows in, is processed internally, then flows out as information, or flows to storage. Used to diagrammatically represent data flow without showing the internal logic.

The three flows: flow in (input data enters the system), flow to storage (data saved to on-site or cloud), flow out (information produced as output: number, text, audio, image, movement).

2.3  Data states

At rest
Data stored in a fixed location (hard drive, database, USB drive, cloud storage). Not being accessed or moved. Risk: physical theft, unauthorised access. Mitigations: encryption at rest, access controls, physical security.
In use
Data actively being processed (in RAM or CPU). An open file, active session, data being viewed in an application. Risk: memory scraping, session hijacking. Mitigations: 2FA, session timeouts, access rights.
In transit (in motion)
Data actively moving between locations, across a network or internet. Risk: interception (man-in-the-middle), packet sniffing. More susceptible to attacks than at rest. Mitigations: encryption in transit (TLS/HTTPS), TCP integrity checking, VPNs.

Topic 3 - APIs and protocols

3.1  Application Programming Interfaces (APIs)

An API sets the rules enabling one application to communicate with another, defining how requests and responses are structured. Role: enables communication between a server and application; transfers data between systems; increases security by controlling access.

API types:

Public (open)
Available to any developer. Promotes third-party integration. Risk: IP exposed, harder to control misuse. Example: Google Maps API, Twitter API.
Private (internal)
Only for the internal development team. Protects intellectual property and back-end data. Full testing before going live. NDA implied. Reduces risk of IP leaks.
Partner
Shared with specific trusted business partners under agreement. More controlled than public, more open than private. Used for B2B integrations.
Composite
Combines multiple API calls into a single request. Reduces round trips to the server. Useful for complex operations that need data from several services simultaneously.

API architectures:

REST (Representational State Transfer)
Most widely used. Uses standard HTTP methods (GET, POST, PUT, DELETE). Stateless: each request is independent. Lightweight, scalable, works with JSON/XML. Used by most modern web APIs.
SOAP (Simple Object Access Protocol)
Uses XML messages. More rigid and complex than REST. Has built-in error handling and security standards (WS-Security). Used in enterprise/financial/healthcare systems where security and reliability are critical.
RPC (Remote Procedure Call)
Allows a program to execute a function on a remote server as if it were local. Simpler than REST for specific actions. Used when you need to trigger a specific process remotely. gRPC is a modern version.

REST = flexible, lightweight, widely used. SOAP = strict, XML-based, enterprise-grade security. RPC = calling a remote function directly.

3.2  Protocols and the TCP/IP stack

A protocol is a set of rules governing how data is transmitted and received. The spec lists nine protocols to know:

HTTP / HTTPS
Governs how web pages are requested and delivered. HTTPS adds TLS encryption. Application layer.
FTP
File Transfer Protocol: transfers files between client and server. Authenticates with username/password. Application layer.
SMTP
Simple Mail Transfer Protocol: sends email from client to server and between servers. Application layer.
POP (POP3)
Post Office Protocol: retrieves email from server to device. Typically downloads and deletes from server. Application layer.
SNMP
Simple Network Management Protocol: monitors and manages network devices (routers, switches, servers). Application layer.
TCP
Transmission Control Protocol: connection-oriented, guarantees delivery and correct sequence of packets. Used where reliability matters (web, email). Transport layer.
UDP
User Datagram Protocol: connectionless, fast, no delivery guarantee. Used where speed matters and some loss is acceptable (video streaming, gaming, VoIP). Transport layer.
ICMP
Internet Control Message Protocol: error reporting and diagnostics. Ping uses ICMP to test connectivity. Internet layer.
IP
Internet Protocol: logical addressing and routing of packets. Every device has an IP address. Works with TCP. Internet layer.

TCP/IP stack - 4 layers (top to bottom):

4. Application layer
Closest to the user. HTTP, FTP, SMTP, POP, SNMP operate here. Handles high-level communication between applications.
3. Transport layer
Manages end-to-end communication. TCP and UDP here. Handles segmentation, reassembly, flow control and reliability.
2. Internet layer
Handles logical addressing and routing. IP and ICMP here. Determines the best path for data across the network.
1. Network access layer
Physical transmission: hardware, cables, Wi-Fi. Converts data to electrical/optical/radio signals.

The spec says "does not include OSI model": only the 4-layer TCP/IP stack is needed, not the 7-layer OSI model.

Topic 4 - Application software security

4.1  Security threats and mitigations

Threats to application security (spec says no need for detailed workings; know the risk each poses):

Hacking
Unauthorised access to a system. Risk: data theft, corruption, system takeover.
Malware
Malicious software (viruses, ransomware, spyware, trojans). Risk: data theft, file corruption, system damage, ransom demands.
DoS / DDoS
Denial of Service / Distributed DoS: floods a server with traffic to make it unavailable to legitimate users. Risk: service disruption.
Botnets
Network of compromised devices controlled remotely. Used to carry out DDoS attacks, send spam, or mine cryptocurrency. Risk: device takeover, being used in attacks without owner's knowledge.
Malicious spam
Unwanted emails containing malicious links, attachments or phishing attempts. Risk: malware installation, credential theft.
Out of date software / hardware / firmware
Unpatched systems have known vulnerabilities. Risk: attackers exploit known weaknesses that have been fixed in newer versions but not applied.
Lack of supplier support
When software reaches end-of-life, the vendor stops releasing security patches. Risk: vulnerabilities go unpatched permanently.

Physical security mitigations:

Biometrics
Fingerprint, facial recognition, iris scan. Unique to the individual, so hard to forge.
Cable locks
Physical cables securing devices to desks to prevent theft.
Cameras
CCTV monitoring of server rooms and access points. Acts as deterrent and evidence.
Locks
Physical locks on server rooms, equipment cabinets and buildings.
RFID / swipe cards
Restrict physical access to buildings or server rooms to authorised personnel only.
Safe
Secure physical storage for backup media, access tokens, or sensitive documents.

Digital security mitigations:

Access rights / permissions
Restrict what users can see or do. Principle of least privilege: users only have access they need for their role.
Anti-malware
Detects, quarantines and removes malicious software. Must be kept up to date.
Backup
Regular copies of data stored separately (on-site and/or off-site). Ensures data can be recovered after ransomware, hardware failure or accidental deletion.
Cryptography / encryption
Converts data into unreadable ciphertext. Encryption at rest: protects stored data. Encryption in transit: protects data moving across a network (TLS/HTTPS).
Firewalls - software
Software running on a device that monitors and filters incoming/outgoing traffic based on rules. Installed on individual computers or servers.
Firewalls - hardware
Dedicated physical device protecting an entire network. Sits between the network and the internet. More robust than software-only solutions.
Two-Factor Authentication (2FA)
Requires a second form of verification beyond a password (e.g. code sent to phone). Ensures authentic access even if a password is compromised. Creates an audit log.

The spec says "does not include details of specific threats or the specific workings of mitigations": focus on the risk each threat poses and how each mitigation protects against it.

Topic 5 - Operational considerations

5.1  Testing

Test plan structure: know all fields:

Test number
Unique identifier for each test.
Test type
The category of test (e.g. normal, extreme, erroneous).
Test description
What is being tested and why.
Purpose
The goal of the test: what it aims to verify.
Procedure
Step-by-step instructions for carrying out the test.
Test data
The specific input values used.
Expected result
What the system should do if working correctly.
Actual result
What the system actually did when the test was run.
Remedial action required
What needs to be fixed if the actual result didn't match expected.
Retest result
The result after remedial action has been applied and the test repeated.

Types of test data:

Normal
Valid data that should be accepted without errors. Tests correct operation. Example: entering age 25 in a field that accepts 18–65.
Extreme (boundary)
Data at the very edge of acceptable values, both valid and just outside. Tests the limits. Example: entering 18, 65, 17 and 66 for an 18–65 field.
Erroneous
Data that should be rejected (wrong type or clearly invalid). Tests that error handling works. Example: entering "abc" in a numeric age field.

Types of testing:

Technical testing
Carried out by developers. Tests internal code, functionality, performance and security. Examples: fuzz testing (inputting random/invalid data to find crashes), load/stress testing (testing at high usage to find performance limits), migration testing (testing after moving data/systems). Advantages: finds bugs early, ensures code quality. Disadvantages: time-consuming, costly, developers may miss their own errors.
User testing
Testing by end users. Alpha = internal. Beta = external before release. Finds usability issues technical testing may miss. Advantages: realistic real-world feedback. Disadvantages: users may not cover all scenarios, subjective feedback.

5.2  Types of application software installation

Clean install
Fresh installation with no previous version. Removes old files and settings. Stable and uncluttered. Takes longer than an upgrade.
Upgrade
Installs a newer version over an existing one. Preserves user settings and data. Quicker. Risk of carrying over old issues or conflicts.
Repair / modify
Fixes corrupted installation files or adds/removes individual components without a full reinstall.
Remote install
Installed on a device from a remote location by an administrator. No physical access needed per device. Useful for large organisations.
Unattended (silent) install
Automated: no user interaction required. Configured in advance and runs silently. Ideal for deploying across many devices simultaneously.
Cloud download / install
Downloaded and installed from the internet/cloud. Always gets latest version. No physical media. Requires internet connection.
Create ghost / image and deploy
A complete system image (snapshot) is deployed to many devices at once. Sets up identical configurations quickly. Used in schools and large organisations.
Mobile install
Installation via an app store (App Store, Google Play) on a mobile device. Managed through the platform's store, which handles updates automatically.
Network install
Software installed over a local network from a central server rather than physical media or internet. Used in corporate environments for controlled, consistent deployment.

The spec says "does not include completing software installations": you need to know the process, advantages/disadvantages and when to use each type, not how to physically do it.

5.3  Policies

Know the purpose and content of each policy that must be considered when developing and deploying application platforms.

Application user guide
Documentation provided to end users explaining how to install, set up and use the application. Must include technical requirements (minimum hardware/software specs). Helps users get started and reduces support requests.
Acceptable Use Policy (AUP)
Defines rules for how employees/users may use the organisation's IT systems. Covers permitted and prohibited activities, consequences of misuse. Protects the organisation legally.
Backup(s)
Policy defining how often data is backed up, where it is stored, and how it can be restored. Ensures data can be recovered after failure, deletion or ransomware. Should include off-site or cloud copies.
Codes of practice
Professional standards and guidelines for behaviour, covering how developers handle user data, write secure code, and interact with clients. Not legally binding but sets professional expectations.
Staying safe online
Guidance for users on how to stay secure, e.g. not clicking suspicious links, using strong passwords, recognising phishing. Reduces human-error-based security incidents.
Use of information
Policy governing how data collected by the application is used: what it's used for, who can access it, how long it's kept. Must comply with DPA/UK GDPR. Linked to privacy notices.

Topic 6 - Legal considerations

6.1  Legislation and the ICO

For F161 you must know specific Acts by name, their main purpose, what compliance requires, the impact of non-compliance, and how they relate to each other. The spec says "does not include knowing the detailed content": know the purpose and obligations, not every clause.

Data Protection Act (DPA) / UK GDPR
Sets out principles, rights and obligations for processing personal data. Key obligations: only collect data you need, keep it accurate and secure, don't retain longer than necessary, allow individuals to access their data.
Non-compliance: fines up to £17.5m or 4% of global turnover, reputational damage, enforcement notices.
Enforced by the ICO.
Computer Misuse Act (CMA) 1990
Makes it illegal to: (1) access a computer system without authorisation, (2) access a system with intent to commit further offences, (3) modify computer material without permission (e.g. installing malware, deleting files).
Non-compliance: criminal prosecution, imprisonment, fines.
Privacy and Electronic Communications Regulations (PECR)
Regulates electronic communications marketing. Must get consent before: sending marketing emails/texts, placing non-essential cookies on websites, making automated calls.
Relationship to DPA/UK GDPR: PECR works alongside UK GDPR. UK GDPR sets the standard for how consent must be obtained; PECR specifies when consent is required for electronic communications.
Non-compliance: ICO fines up to £500,000.
Freedom of Information Act (FOIA) 2000
Gives the public the right to request information held by public authorities (government, NHS, schools, councils). Must respond within 20 working days. Only applies to public sector organisations.
Non-compliance: ICO enforcement, mandatory disclosure orders, reputational damage.

ICO - Information Commissioner's Office
The UK's independent authority that upholds information rights and enforces data protection law. Role: investigates complaints, audits organisations, issues guidance, enforces DPA/UK GDPR and PECR, and issues fines for non-compliance.

Key relationship to know: PECR requires consent for electronic marketing; UK GDPR defines what valid consent looks like. They work together. Both are enforced by the ICO.