OCR A Level Computer Science: Case Study Analysis Walkthrough | OCR A Level 计算机：案例分析实战演练

📚 OCR A Level Computer Science: Case Study Analysis Walkthrough | OCR A Level 计算机：案例分析实战演练

Mastering the case study section of the OCR A Level Computer Science exam is not just about memorising facts — it requires a structured, analytical approach that bridges theory and real‑world problem solving. This walkthrough guides you step by step through the key techniques you need to deconstruct any case study, from identifying stakeholder needs to evaluating ethical implications, so you can tackle the paper with confidence and precision.

掌握 OCR A Level 计算机考试中的案例分析部分，不仅需要背诵知识点，更需要一种能将理论与实际问题相结合的结构化分析方法。本文一步步带你拆解案例分析的关键技巧，从识别干系人需求到评估伦理影响，让你从容应对考试，写出精准高分的答案。

---

1. Understanding the Case Study Brief | 读懂案例分析概要

Your first step is to read the case study three times: first for overall context, second to highlight key entities, processes and constraints, and third to map explicit and implicit requirements. Circle any technical vocabulary (e.g. ‘real‑time processing’, ‘concurrent access’, ‘GDPR compliant’) because these often dictate the depth of your solution.

第一步，将案例文本读三遍：第一遍把握整体情境，第二遍划出关键实体、流程和限制条件，第三遍梳理显性和隐性需求。圈出所有技术术语（如“实时处理”“并发访问”“GDPR合规”），它们往往决定了答案的深度。

• Identify the problem domain: Is it a mobile app, an embedded system, a web‑based platform? The domain dictates the appropriate technologies.
• 识别问题域：是移动应用、嵌入式系统还是Web平台？不同领域对应不同的技术选型。
• Sketch a context diagram: Place the system at the centre, draw external entities (users, sensors, payment gateways) and label data flows. Keep it simple — a rough sketch on scratch paper reduces cognitive load.
• 绘制上下文图：将系统放在中央，画出外部实体（用户、传感器、支付网关）并标注数据流。在草稿纸上简单勾勒能减轻记忆负担。

---

2. Stakeholder Identification and Requirements Elicitation | 干系人识别与需求挖掘

Every case study revolves around people — customers, staff, managers, regulators. Explicitly list all stakeholders and what they need from the system. Distinguish between functional requirements (what the system does) and non‑functional requirements (how it performs).

每个案例都围绕“人”展开——顾客、员工、管理者、监管机构。明确列出所有干系人及其系统需求，区分功能性需求（系统做什么）与非功能性需求（系统表现如何）。

Stakeholder | 干系人	Functional Need | 功能需求	Non‑functional Need | 非功能需求
Customer | 顾客	Search products, place orders	Response time < 2 s, 24/7 availability
Warehouse staff | 仓库员工	Update stock levels	Barcode scanning accuracy 99.9%

Use the MoSCoW method (Must, Should, Could, Won’t) to prioritise. Examiners reward answers that show you can negotiate trade‑offs, not just list everything.

用 MoSCoW 法（必须/应该/可以/不要）排优先级。考官青睐那些能权衡取舍的答案，而不只是罗列清单。

---

3. Modelling with Use Case and DFD Diagrams | 用例图与数据流图建模

Visual models clarify interactions and data movement. A use case diagram shows actors and their goals; a Level 1 Data Flow Diagram (DFD) reveals how data enters, is transformed and stored.

可视化模型能让交互与数据流动一目了然。用例图展示参与者及其目标；一层数据流图揭示数据如何输入、转换和存储。

• Use case title: Verb‑noun format, e.g. ‘Place Order’. Include include‑extend relationships sparingly — only when the case study explicitly mentions optional or shared behaviour.
• 用例名称：动词‑名词结构，如“下单”。谨慎使用 include/extend 关系，仅在案例明确提到可选或共享行为时添加。
• DFD rules: Every process must have at least one input and one output data flow; data cannot move directly from one external entity to another; a data store must be connected to a process.
• DFD 规则：每个处理至少有一个输入和一个输出数据流；数据不能直接从外部实体流向另一个外部实体；数据存储必须与处理相连。

Practice converting a text narrative into a DFD. For example, ‘Customer submits order, system checks stock and sends confirmation’ becomes: Customer → (order details) → Process Order → (stock query) → Stock Data Store → (stock status) → Process Order → (confirmation) → Customer.

练习将文字叙述转化为数据流图。例如，“顾客提交订单，系统检查库存后发送确认”变为：顾客→（订单详情）→处理订单→（库存查询）→库存数据存储→（库存状态）→处理订单→（确认）→顾客。

---

4. Database Design and Normalisation | 数据库设计与规范化

When a case study involves persistent data, think entities, attributes and relationships. Draw an Entity Relationship Diagram (ERD) and then convert it to a set of normalised tables up to Third Normal Form (3NF). OCR examiners often provide a flat‑file table and ask you to normalise it.

当案例涉及持久化数据时，考虑实体、属性和关系。绘制实体关系图，然后将其转化为一组规范化的表，直至第三范式。OCR 考官常给出一个扁平文件表，要求你规范化它。

Normalisation steps: 1NF (atomic, no repeating groups) → 2NF (1NF + no partial dependencies) → 3NF (2NF + no transitive dependencies)

规范化步骤：第一范式（原子性，无重复组）→ 第二范式（1NF + 无部分依赖）→ 第三范式（2NF + 无传递依赖）

• Primary key selection: Choose a stable, unique identifier (e.g. OrderID, UserID). Avoid composite keys unless they truly represent a many‑to‑many relationship.
• 主键选择：选用稳定、唯一的标识符（如订单ID、用户ID）。除非复合键确实代表多对多关系，否则避免使用。
• SQL queries: Be ready to write SELECT, INSERT, UPDATE statements. Pay attention to JOINs — a question might ask you to retrieve data from two related tables using an INNER JOIN.
• SQL 查询：准备好编写 SELECT、INSERT、UPDATE 语句。注意 JOIN 操作——题目可能要求你用 INNER JOIN 从两个关联表中检索数据。

---

5. Selecting Data Structures and Algorithms | 选择数据结构与算法

The case study often hides clues about performance requirements. A ‘large number of users’ or ‘real‑time updates’ signals the need for efficient algorithms. Match the data structure to the use case: hash tables for fast lookups, queues for print spooling, stacks for undo functionality.

案例中往往隐藏着性能需求的线索。“大量用户”或“实时更新”暗示需要高效算法。将数据结构与用例匹配：哈希表用于快速查找，队列用于打印缓冲，栈用于撤销功能。

Requirement | 需求	Suitable Structure | 合适结构	Reason | 原因
Search product by ID	Hash table	O(1) average lookup
Display sorted sales list	Binary search tree	Efficient in‑order traversal
Manage print jobs	Queue (FIFO)	Preserves order of arrival

For algorithms, be prepared to compare linear search versus binary search, and bubble sort versus merge sort, citing time complexity with Big O notation such as O(n), O(log n), O(n²).

在算法方面，准备比较线性查找与二分查找，冒泡排序与归并排序，并用大O符号引用时间复杂度，如 O(n)、O(log n)、O(n²)。

---

6. Concurrency and Data Consistency | 并发与数据一致性

Many case studies describe multi‑user scenarios (e.g. ticket booking, online banking). You must demonstrate awareness of race conditions, deadlocks and how to mitigate them. Explain the difference between pessimistic and optimistic locking, and where each is appropriate.

许多案例涉及多用户场景（如订票、网银）。你必须展现出对竞态条件、死锁及其缓解方法的理解。解释悲观锁与乐观锁的区别及各自适用场景。

• Pessimistic locking: Locks a record as soon as a transaction begins. Suitable for high‑contention scenarios (e.g. seat reservation).
• 悲观锁：事务一开始就锁定记录。适用于高争用场景（如座位预订）。
• Optimistic locking: Checks for conflicts only at commit time using a version number. Better for low‑contention environments (e.g. updating a user profile).
• 乐观锁：仅在提交时通过版本号检查冲突。更适用于低争用环境（如更新用户资料）。

Also mention transactions with ACID properties (Atomicity, Consistency, Isolation, Durability) to maintain data integrity, especially where financial records are involved.

还可提及具有 ACID 特性（原子性、一致性、隔离性、持久性）的事务，以维护数据完整性，尤其是涉及财务记录时。

---

7. Networking and Security Considerations | 网络与安全考量

Case studies often involve a distributed system. Identify the network topology, protocols and potential vulnerabilities. If the system uses the internet, discuss HTTPS, TLS, firewalls and SQL injection prevention.

案例常涉及分布式系统。识别网络拓扑、协议和潜在漏洞。若系统使用互联网，讨论 HTTPS、TLS、防火墙和 SQL 注入预防。

• Client‑server vs peer‑to‑peer: A central server simplifies administration but creates a single point of failure. P2P is more robust but harder to secure.
• 客户‑服务器与对等网络：中央服务器简化管理但产生单点故障，P2P 更健壮但安全难度更大。
• Authentication and authorisation: Use two‑factor authentication (2FA) for sensitive roles. Role‑based access control (RBAC) ensures users see only what they are permitted to.
• 认证与授权：对敏感角色使用双因素认证。基于角色的访问控制确保用户只能访问被允许的内容。
• Data encryption: At rest (AES‑256) and in transit (TLS 1.3). If the case study references GDPR, you must mention encryption as a technical measure for data protection.
• 数据加密：静止数据（AES‑256）和传输中数据（TLS 1.3）。若案例提及 GDPR，必须将加密作为数据保护的技术措施。

---

8. Testing and Debugging Strategies | 测试与调试策略

You may be asked to design a test plan or evaluate testing approaches. Always start with normal, boundary and erroneous test data. A structured test table helps the examiner see your methodology.

你可能需要设计测试计划或评估测试方法。始终从正常、边界和错误测试数据开始。结构化测试表能让考官清晰看到你的方法。

Test Type | 测试类型	Example Input | 输入示例	Expected Outcome | 预期结果
Normal | 正常	Quantity = 5	Order accepted
Boundary | 边界	Quantity = 0, Quantity = 101 (max 100)	Rejected with error message
Erroneous | 错误	Quantity = “ten”, negative number	Data validation triggered

Mention integration testing, system testing and acceptance testing. In an agile context, highlight the role of continuous integration and automated unit tests.

提及集成测试、系统测试和验收测试。在敏捷语境下，强调持续集成与自动化单元测试的作用。

---

9. Legal, Ethical and Cultural Implications | 法律、伦理与文化影响

OCR examiners consistently reward candidates who broaden their analysis to include legal and ethical dimensions. The Computer Misuse Act, Copyright Designs and Patents Act, and GDPR are the big three. But go beyond naming them — explain how they constrain the system design.

OCR 考官一贯奖励那些能将分析扩展到法律与伦理层面的考生。《计算机滥用法》《版权设计与专利法》和 GDPR 是三大重点。但不要止步于命名，要解释它们如何约束系统设计。

• Data minimisation under GDPR: Only collect data you truly need. Could you design the system to use anonymised IDs?
• GDPR 下的数据最小化：只收集真正需要的数据。能否将系统设计为使用匿名 ID？
• Accessibility and inclusivity: Does the case study mention users with disabilities? Consider screen‑reader compatibility, colour‑blind‑friendly palettes, and keyboard navigation.
• 可访问性与包容性：案例是否提到残疾用户？考虑屏幕阅读器兼容、色盲友好配色和键盘导航。
• Cultural bias: Name fields (e.g. ‘first name’ / ‘last name’) may not fit all global naming conventions. A single ‘Full name’ field can be more inclusive.
• 文化偏见：名字字段（如“名”“姓”）可能不适用于全球所有命名习惯。使用单一“全名”字段更具包容性。

---

10. System Implementation and Prototyping | 系统实施与原型设计

Sometimes a case study asks you to recommend an implementation approach. Compare waterfall and agile methodologies in light of the requirements stability. If the requirements are likely to change, agile (Scrum) is more appropriate. Mention the value of a vertical prototype to clarify user interface expectations early.

有时案例会要求推荐实施方法。根据需求稳定性比较瀑布与敏捷方法。若需求可能变化，敏捷（Scrum）更合适。强调垂直原型的价值，可及早澄清用户界面期望。

• Waterfall: Suitable when requirements are well‑understood and unlikely to change (e.g. upgrading a legacy payroll system).
• 瀑布模型：适用于需求明确且不易变化的情况（如升级旧版工资系统）。
• Agile: Iterative delivery, regular stakeholder feedback. Works well for apps where user experience is critical.
• 敏捷方法：迭代交付、定期干系人反馈。适用于用户体验至关重要的应用。

Explain the trade‑off: agile can produce faster user value but may have less predictability in cost and timeline, which might conflict with fixed‑budget constraints mentioned in the case study.

解释权衡：敏捷能更快交付用户价值，但成本与时间线的可预测性较低，这可能与案例中提到的固定预算约束相冲突。

---

11. Writing High‑Scoring Responses | 写出高分答案的技巧

Use the P.E.E.L (Point, Evidence, Explanation, Link) structure for extended responses. In the context of computer science, ‘evidence’ can be a named algorithm, a specific protocol or a short pseudo‑code snippet. Always link back to the case study: ‘This meets the client’s need for X because…’

扩展回答采用 P.E.E.L（观点、证据、解释、联系）结构。在计算机科学中，“证据”可以是命名算法、具体协议或简短伪代码片段。务必回扣案例：“这满足客户对 X 的需求，因为……”

Example: “The system should use a hash table with open addressing (Point). This provides O(1) average search time (Evidence), which ensures that the customer’s product search remains fast even with 10⁴ records (Explanation). Therefore it fulfills the non‑functional requirement of sub‑second response (Link).”

示例：“系统应使用带开放寻址的哈希表（观点）。这提供 O(1) 平均查找时间（证据），确保即使记录数达10⁴条，客户产品搜索依然快速（解释）。因此满足亚秒响应的非功能性需求（联系）。”

• Use technical vocabulary precisely: Refer to ‘storing salted and hashed passwords’ rather than just ‘secure passwords’.
• 精确使用技术词汇：说“存储加盐哈希密码”而不仅仅是“密码安全”。
• Diagrams add value: Even a rough sketch of an ERD or DFD can earn marks. Label axes, entities, and flows clearly.
• 图表增值：哪怕一张粗略的 ERD 或 DFD 也能得分。清晰标注坐标轴、实体和数据流。

---

12. Time Management and Mock Practice | 时间管理与模拟练习

In the exam, allocate 15 minutes for reading and planning, then divide the remaining time proportionally by mark weight. For a 9‑mark question, spend about 15% of your writing time. Practise with past papers under timed conditions and self‑mark using the official mark scheme — often the difference between a grade B and an A* lies in how well you internalise the examiner’s expectations.

考试中，留出15分钟阅读与规划，然后按分值比例分配剩余时间。对于9分大题，花大约15%的写作时间。用往年试卷限时练习，并参照官方评分标准自评——B到A*的差距往往就在于你是否真正内化了考官的期望。

• Create a one‑page cheat sheet: Summarise key laws, protocols, normalisation steps, and common algorithm complexities on a single page. Review it in the last five minutes before the exam.
• 制作一页速查表：将关键法律、协议、规范化步骤和常见算法复杂度总结在一页纸上，考前五分钟浏览。
• Focus on mark allocation: If a question says ‘Describe three ways…’, give exactly three points — no more, no less. Each extra point costs time without earning additional marks.
• 关注分值提示：若题目说“描述三种方式……”，就给出恰好三点——不多不少。多余的点只会消耗时间而不会额外得分。

Remember, the best case study answers blend precise technical accuracy with genuine empathy for the user and the business context. Train yourself to think like a systems analyst, and you will not only ace the exam but also build a mindset that serves you throughout your computing career.

请记住，最优秀的案例分析答案，能把精准的技术准确性与对用户和业务语境的真挚共情融为一体。训练自己像系统分析师一样思考，你不仅能在考试中脱颖而出，更能培养一种贯穿整个计算机职业生涯的思维方式。

Published by TutorHao | Computer Science Revision Series | aleveler.com

更多咨询请联系16621398022（同微信）