📚 Case Study Practice for CAIE Computer Science | CAIE 计算机科学案例分析实战演练
Case studies are the core of Paper 2 in CAIE IGCSE Computer Science – they test your ability to apply theoretical knowledge to realistic scenarios. This guide will walk you through a structured approach, key question types, and a full worked example to help you master the exam’s most challenging section.
案例分析是 CAIE IGCSE 计算机科学 Paper 2 的核心——它考查你将理论知识应用于实际场景的能力。本指南将带你系统梳理分析方法、常见题型，并给出一个完整的实战示例，助你攻克考试中最具挑战性的部分。
1. Understanding Case Study Requirements | 理解案例分析的要求
A case study presents a scenario, such as a business needing a new information system or an automated control process. Your task is to analyse the situation, identify user needs, propose a solution, and often write pseudocode or draw flowcharts for part of it. The examiner expects you to demonstrate problem-solving skills, not just memory of facts.
案例分析会给出一个场景，比如某企业需要一套新的信息系统或自动控制流程。你的任务是分析情境、识别用户需求、提出解决方案，并通常要为其中一部分编写伪代码或绘制流程图。考官期望你展现解决问题的能力，而不仅仅是对知识点的记忆。
To do well, always read the scenario twice. Underline key data: inputs, outputs, processes, constraints, and any mention of hardware, software, or networking. This initial breakdown prevents you from missing crucial details later when you are designing algorithms or justifying decisions.
要取得好成绩，务必将场景阅读两遍。用下划线标出关键数据：输入、输出、处理过程、约束条件，以及任何关于硬件、软件或网络的描述。这种初步的分解可以避免你在后续设计算法或解释决策时遗漏关键细节。
2. Common Question Types | 常见题型剖析
CAIE case study questions typically fall into several predictable categories: requirements analysis, solution design (including algorithms), testing, evaluation, and consideration of legal/ethical issues. You may be asked to draw a system flowchart, write pseudocode for a specific calculation, design a test plan, or suggest validation and verification methods.
CAIE 案例分析题目通常分为几类可预测的题型：需求分析、解决方案设计（包括算法）、测试、评估，以及法律与伦理问题的考量。你可能需要画系统流程图、为特定计算编写伪代码、设计测试计划，或提出验证与验证方法。
For algorithm design, questions often involve loops, conditional statements, arrays, and file handling. Be ready to iterate through records, calculate running totals, search for a value, or sort a list. Each pseudocode answer should be precise, using consistent indentation and keywords like INPUT, OUTPUT, WHILE…DO…ENDWHILE, IF…THEN…ELSE…ENDIF.
在算法设计部分，题目常涉及循环、条件语句、数组和文件处理。准备好编写遍历记录、计算累计总和、搜索数值或排序列表的伪代码。每段伪代码答案应精确，使用一致的缩进和如 INPUT、OUTPUT、WHILE…DO…ENDWHILE、IF…THEN…ELSE…ENDIF 等关键词。
3. Analysing the System Requirements | 分析系统需求
Start by listing the functional requirements: what must the system do? For example, in a library system, it must allow borrowing and returning of books, searching the catalogue, and reserving items. Then identify non-functional requirements: how fast should it respond? How secure must user data be? Is it web-based or app-based?
首先列出功能性需求：系统必须做什么？例如，在图书馆系统中，必须允许借阅和归还图书、搜索目录和预约图书。然后识别非功能性需求：响应速度要多快？用户数据必须多安全？是基于网页还是基于应用程序？
A useful technique is to draw a context diagram – a single process box labelled with the system name, surrounded by external entities (users, other systems) and data flows (e.g., ‘member details’, ‘loan record’). This clarifies the scope and boundaries of the project before you dive into detail.
一个有用的技巧是画出上下文图——一个标有系统名称的单个流程框，周围是外部实体（用户、其他系统）和数据流（例如“会员详情”、“借阅记录”）。这能在你深入细节之前明确项目的范围和边界。
4. Designing a Solution: System Flowcharts | 设计解决方案：系统流程图
System flowcharts show the overall data flow and the sequence of operations. Use standard symbols: oval for start/end, parallelogram for input/output, rectangle for process, diamond for decision. Clearly label each symbol, and ensure all paths merge logically. Avoid crossing flow lines; if necessary, use an on-page connector.
系统流程图展示整体数据流和操作顺序。使用标准符号：椭圆形表示开始/结束，平行四边形表示输入/输出，矩形表示处理，菱形表示判断。每个符号要清晰标注，并确保所有路径逻辑上汇合。避免线条交叉；如有必要，使用页内连接符。
When drawing, work from the scenario’s narrative. For a student grading system: first input marks, then validate them, calculate average and grade, then output results with error messages where needed. The flowchart must reflect every step mentioned in the requirement, including error handling and data storage.
绘制时，要遵循场景的叙述。对于学生成绩系统：首先输入分数，然后验证它们，计算平均分和等级，然后输出结果并附上必要的错误信息。流程图必须反映需求中提到的每一个步骤，包括错误处理和数据存储。
5. Writing Precise Pseudocode | 编写精确的伪代码
Pseudocode is the heart of CAIE Paper 2. Make it language-independent but structured. Use consistent naming for variables (e.g., totalMarks, studentName). For loops, state the condition clearly, and always indicate the end of a block with ENDWHILE, ENDFOR, or ENDIF. Do NOT use programming language syntax like braces or semicolons.
伪代码是 CAIE Paper 2 的核心。使之独立于具体语言但又结构清晰。变量命名要一致（例如 totalMarks，studentName）。对于循环，要清晰陈述条件，并总是用 ENDWHILE、ENDFOR 或 ENDIF 标识语句块的结束。不要使用花括号或分号等编程语言语法。
Example: Counting passes from 100 marks
COUNT ← 0
FOR i ← 1 TO 100
INPUT mark
IF mark ≥ 50 THEN
COUNT ← COUNT + 1
ENDIF
ENDFOR
OUTPUT "Passes: ", COUNT
示例：从100个分数中统计及格人数
COUNT ← 0
FOR i ← 1 TO 100
INPUT mark
IF mark ≥ 50 THEN
COUNT ← COUNT + 1
ENDIF
ENDFOR
OUTPUT "Passes: ", COUNT
6. Testing: Building a Robust Test Plan | 测试：构建健壮的测试计划
A good test plan includes normal, boundary, and erroneous data. For a field accepting age 1–120, normal data could be 45, boundary data 1 and 120, and erroneous data -5, 0, 150, and “hello”. For each test case, state the purpose, the test data, and the expected outcome. Always link back to the original requirements.
一个好的测试计划应该包括正常数据、边界数据和异常数据。比如一个接受年龄 1–120 的字段，正常数据可以是 45，边界数据 1 和 120，异常数据 -5、0、150 和 “hello”。对每个测试用例，说明测试目的、测试数据和预期结果。始终关联回原始需求。
Verification and validation are often confused: verification checks if the product is built correctly (e.g., does the code match the design?), while validation checks if we built the right product (does it meet user needs?). Use both approaches to ensure the final system is fit for purpose.
验证和确认经常被混淆：验证检查产品是否被正确构建（例如代码是否符合设计？），而确认检查我们是否构建了正确的产品（它是否满足用户需求？）。同时采用两种方法，确保最终系统适合其目的。
7. Legal, Ethical, and Security Considerations | 法律、伦理与安全考量
Case studies almost always touch on data protection. In the UK, the Data Protection Act 2018 (or GDPR) sets principles: data must be processed fairly, kept secure, and not held longer than necessary. Explain how your solution complies – for instance, by encrypting personal details, limiting access, and allowing users to view or delete their data.
案例分析几乎总会涉及数据保护。在英国，《2018年数据保护法》（或 GDPR）规定了多项原则：数据必须公平处理、安全保存，且保存时间不得超过所需。说明你的解决方案如何遵守这些规定——例如，加密个人详情、限制访问权限，并允许用户查看或删除自己的数据。
Also consider the Computer Misuse Act and copyright. If your system involves online transactions, discuss secure connections (HTTPS) and authentication. Ethical design means ensuring accessibility for users with disabilities and avoiding bias in automated decisions – all points to mention for top marks.
还要考虑《计算机滥用法》和著作权。如果你的系统涉及在线交易，应讨论安全连接（HTTPS）和身份验证。符合道德的设计意味着确保残障用户的可访问性，并在自动化决策中避免偏见——这些都是为获得高分而应提及的要点。
8. Worked Example: Online Bookshop | 实战示例：在线书店
Scenario: A local bookshop wants an online ordering system. Customers can browse books, add them to a cart, and check out. Stock must be updated automatically. Staff can add new books and view sales reports. The system must be accessible on mobile devices and handle up to 200 orders per hour.
场景： 一家本地书店想要一套在线订购系统。顾客可以浏览书籍、加入购物车并结帐。库存必须自动更新。员工可以添加新书并查看销售报告。系统必须在移动设备上可访问，并能处理每小时最多 200 个订单。
Requirements analysis: Functional – search by title/author, shopping cart, secure payment, stock update. Non-functional – mobile-responsive, process 200 orders/hour, 99.9% uptime. Legal – secure credit card details, privacy policy, right to erase data.
需求分析： 功能性——按书名/作者搜索、购物车、安全支付、库存更新。非功能性——移动端适配、每小时处理 200 个订单、99.9% 正常运行时间。法律方面——安全保存信用卡信息、隐私政策、数据删除权。
Algorithm snippet (pseudocode for checkout):
INPUT cartItems
totalPrice ← 0
FOR each item IN cartItems
IF stock[item] > 0 THEN
totalPrice ← totalPrice + price[item]
stock[item] ← stock[item] – 1
ELSE
OUTPUT item, "out of stock"
ENDIF
ENDFOR
IF totalPrice > 0 THEN
CALL processPayment(totalPrice)
OUTPUT invoice
ENDIF
算法片段（结帐伪代码）：
INPUT cartItems
totalPrice ← 0
FOR each item IN cartItems
IF stock[item] > 0 THEN
totalPrice ← totalPrice + price[item]
stock[item] ← stock[item] – 1
ELSE
OUTPUT item, "out of stock"
ENDIF
ENDFOR
IF totalPrice > 0 THEN
CALL processPayment(totalPrice)
OUTPUT invoice
ENDIF
Test plan excerpt: Test the checkout with an empty cart (expected: message “cart is empty”), with a valid item (expected: stock reduces, invoice shown), and with an out-of-stock item (expected: error message and remaining items processed).
测试计划节选： 使用空购物车结帐（预期：显示“购物车为空”消息），使用有效商品（预期：库存减少，显示发票），使用缺货商品（预期：显示错误消息，其余商品正常处理）。
9. Common Pitfalls and How to Avoid Them | 常见错误与避坑指南
One major mistake is writing pseudocode that is too close to a specific language – this can lose marks if it is not universally understandable. Another is ignoring error handling: always check for invalid inputs and show meaningful messages. Also, students often forget to initialise counters or totals to zero before loops, leading to logic errors.
一个主要错误是编写的伪代码过于接近某种特定语言——如果它不是普遍可理解的，就会失分。另一个错误是忽略错误处理：总是要检查无效输入并显示有意义的提示消息。此外，学生经常忘记在循环之前将计数器或总和初始化为零，导致逻辑错误。
In flowcharts, a missing decision label or a flow line that never reaches an end point will cost you. Finally, when discussing testing, do not just list data; explain why each type is chosen. Always refer back to the scenario to show you are applying theory to the given problem.
在流程图中，缺少的决策标注或一条从未到达终点的流程线都会让你失分。最后，在讨论测试时，不要仅列出数据；要解释为什么选择每种类型。始终回扣场景，展示你正在将理论应用于给定问题。
10. Exam Strategy and Time Management | 考试策略与时间管理
Paper 2 is 1 hour 45 minutes (CAIE 0478). Allocate roughly 10 minutes to read and annotate the pre-release material (familiarise yourself beforehand), 30 minutes for short answer questions on design and theory, 45 minutes for algorithm and flowchart tasks, and 20 minutes for testing and evaluation, leaving time for checking. Never leave a question blank – even partial pseudocode or an outline test plan can earn partial credit.
Paper 2 考试时间为 1 小时 45 分钟（CAIE 0478）。大致分配 10 分钟阅读并注解预发布材料（事先熟悉），30 分钟用于设计与理论的简答题，45 分钟用于算法和流程图任务，20 分钟用于测试与评估，并留出检查时间。绝对不要留空白——即使是部分伪代码或框架性的测试计划也能得到部分分数。
When you receive the paper, quickly skim all questions. Start with the sections you find easiest to build confidence. If stuck on a complex algorithm, move to testing or evaluation questions and return later. Use the mark allocation as a guide: a 6-mark question needs more depth than a 2-mark one.
拿到试卷后，快速浏览所有题目。从你觉得最容易的部分开始，以建立信心。如果被复杂的算法卡住，先转到测试或评估题，稍后再回来看。以分值为指导：一道 6 分的题需要比 2 分的题更深入。
11. Extending to Control and Automated Systems | 延伸至控制与自动化系统
Not all case studies are about business data processing. Some involve sensor‑based control, e.g., a greenhouse monitoring temperature, humidity, and light. For these, focus on the input‑process‑output cycle: sensors send data to a microprocessor, which compares values against pre‑set thresholds and activates actuators (heater, fan, lamp) accordingly. Continuous feedback loops are essential.
并非所有案例分析都与商业数据处理有关。有些涉及基于传感器的控制，例如监测温度、湿度和光照的温室。对于这类题目，应聚焦于输入‑处理‑输出循环：传感器将数据发送给微处理器，微处理器将数值与预设阈值比较，并相应地启动执行器（加热器、风扇、灯）。连续反馈回路至关重要。
In your answer, always state the type of sensor (temperature sensor, light sensor) and how the actuator brings about a physical change. Highlight the role of an ADC (analogue‑to‑digital converter) if applicable. The algorithm may use simple condition: IF temperature < 20°C THEN turn heater ON ELSE turn heater OFF – but with hysteresis to prevent rapid switching.
在你的答案中，始终说明传感器类型（温度传感器、光传感器）以及执行器如何引起物理变化。如果适用，强调 ADC（模数转换器）的作用。算法可能使用简单条件：IF temperature < 20°C THEN turn heater ON ELSE turn heater OFF——但需要加入迟滞以防止快速开关。
12. Bringing It All Together | 整合与应用
Mastering case studies means practising with past papers under timed conditions, then reviewing mark schemes to see exactly what examiners reward. For every system you design, ask yourself: Does it meet all stated requirements? Is the pseudocode logically correct and fully structured? Have I considered testing, security, and legal aspects? Regular practice will transform this challenging part of the exam into a confident, high‑scoring section.
掌握案例分析意味着要在限时条件下练习往年试卷，然后对照评分方案查看考官究竟给分在哪里。对于你设计的每一个系统，问问自己：它是否满足所有指定的需求？伪代码逻辑是否正确且结构完整？我是否考虑了测试、安全和法律方面？规律的练习会将这个充满挑战的考试模块，转变为你胸有成竹的高分板块。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图