📚 WJEC GCSE Computer Science Case Study Mastery | WJEC GCSE 计算机案例分析实战演练
Success in the WJEC GCSE Computer Science Unit 2 case study questions demands more than just knowing the theory – you need a structured approach to analysing scenarios, identifying key requirements, and proposing realistic solutions. This article breaks down a proven method for tackling any case study, complete with practical examples, common pitfalls to avoid, and step-by-step guidance that mirrors real examiner expectations. Whether you are preparing for a mock or the actual written paper, these techniques will help you turn a seemingly complex business scenario into a clear, high-scoring answer.
在 WJEC GCSE 计算机科学单元二的案例分析题中取得高分，需要的不仅仅是理论知识——你必须掌握一套结构化的方法，才能准确分析情景、识别关键需求并提出切实可行的解决方案。本文拆解了一套经过实战验证的解题策略，配有实例、常见错误警示以及贴合考官评分思路的逐步指导。无论你是在准备模考还是正式笔试，这些技巧都能帮你在看似复杂的商业场景中理清思路，写出高分答案。
1. Understanding the Case Study Format | 理解案例分析题的出题模式
WJEC Unit 2 presents you with a real-world scenario, typically involving a small-to-medium business, a school, a charity, or a local service that needs a digital solution. The question paper embeds technical specifications, user requirements, and operational constraints within a narrative. Your job is not to guess what the examiner wants, but to extract the clues hidden in the text. Expect to see multiple sub-questions that test your ability to propose hardware, software, data structures, algorithms, testing strategies, and evaluation criteria.
WJEC 单元二会呈现一个真实情景，通常是中小型企业、学校、慈善机构或本地服务需要数字化解决方案。试卷会在叙述中嵌入技术规格、用户需求和运营约束。你的任务不是猜测考官想听什么，而是提取隐藏的线索。你会看到若干子问题，考察你能否提出合理的硬件、软件、数据结构、算法、测试策略和评估标准。
2. Scenario Deconstruction in 5 Minutes | 五分钟情景拆解法
Before you write a single sentence, spend five minutes reading the scenario with a highlighter (if allowed) or by underlining keywords. Identify three core elements: Who – the stakeholders and their technical ability; What – the core problem that needs solving; and Why – these as bullet points in the margin. For example, a scenario about a vet clinic may say, "e receptionist currently books appointments in a paper diary and often double-books slots." = receptionist (low IT skills); What = automated booking; Why = eliminate double-booking.
在动笔前，先花五分钟用荧光笔圈画（如允许）或划线关键词。找出三个核心要素：Who——利益相关者及其技术能力；What——待解决的核心问题；Why——期望带来的好处（如加快处理、改善客户体验、减少错误）。用要点写在页边。例如，关于兽医诊所的情景可能写道：“接待员目前在纸质日记中预约，经常重复预约。” 立刻标注：Who = 接待员（IT 技能弱）；What = 自动预约；Why = 消除重复预约。
3. Feasibility First: Technical, Economic, Legal | 可行性先行：技术、经济与法律
A top-tier answer always addresses feasibility before diving into design. The WJEC mark scheme rewards candidates who demonstrate awareness of whether a solution is technically possible (e.g., does the hardware exist?), economically viable (can the client afford it?), and legally compliant (does it respect GDPR/data protection?). If the scenario mentions a limited budget, you must propose cost-effective tools – consider open-source software like LibreOffice or cloud-based storage instead of expensive licensed suites. Mentioning the Data Protection Act 2018 and GDPR explicitly often pushes an answer into the top band.
高分答案总会在进入设计之前先讨论可行性。WJEC 评分标准青睐那些能体现出对方案技术上是否可行（如硬件是否具备）、经济上是否可行（客户能否负担）、以及法律上是否合规（是否遵守 GDPR/数据保护规定）有所认知的考生。如果情景提到预算有限，你必须提出高性价比的工具——考虑使用 LibreOffice 等开源软件或云存储，而非昂贵的授权套件。明确提及《2018 年数据保护法案》和 GDPR 往往能将答案推上高分档。
4. Stakeholder Requirements Gathering | 利益相关者需求收集
You are not expected to interview anyone, but you must show how you would collect requirements. Use recognised techniques: interviews (good for detailed views), questionnaires (reach many people quickly), observation (see actual workflow, discover hidden steps), and document analysis (examine existing paper forms or spreadsheets). Select the method that fits the context. For a busy restaurant manager, observation during quiet hours might be more practical than a questionnaire. Always justify your choice with a brief reason linked to the scenario.
你不需要真的去采访谁，但必须展示你会如何收集需求。使用公认的技术：访谈（适合获取详细观点）、问卷（快速覆盖大量人群）、观察（发现实际工作流程中的隐藏步骤）和文档分析（查看现有纸质表格或电子表格）。选择与情景匹配的方法。对于忙碌的餐厅经理，在非高峰时段进行观察可能比问卷更实际。始终用结合情景的简短理由来证明你的选择。
5. Designing the Input-Process-Output Model | 设计输入-处理-输出模型
Draw a simple IPO chart before writing your response – it helps even if the exam does not require a diagram. In the vet clinic example:
| Input | Process | Output |
|---|---|---|
| Pet owner name, contact, pet species, preferred date/time | Check availability, store appointment, prevent double-booking, send confirmation | Appointment summary, email/SMS reminder, daily schedule for vet |
This mental model ensures your proposed solution covers all data flows. Explicitly link every data field you mention to a specific process and output – examiners look for coherence.
在写答案前先画一张简单的 IPO 图表会有帮助——即使考试不要求图表。在兽医诊所的例子中：输入是宠物主人姓名、联系方式、宠物种类、首选日期/时间；处理是检查可用性、存储预约、防止重复预约、发送确认；输出是预约摘要、邮件/短信提醒、兽医的每日排程。这种思维模型能确保你提出的方案覆盖所有数据流。你提到的每个数据字段都要明确关联到某个具体的处理和输出——考官看重的是连贯性。
6. Data Structures and Storage Decisions | 数据结构与存储决策
Every case study needs you to specify appropriate data structures. At GCSE level, this usually means choosing between a flat-file database, a relational database, or a simple array/list. Use a relational database (with tables, primary keys, and foreign keys) when data items are clearly linked – for instance, in a library system, separate tables for Members, Books, and Loans prevent redundancy and update anomalies. Describe the structure: "The Member table will have MemberID (primary key), Name, Email. The Loans table will contain LoanID (primary key), MemberID (foreign key), BookID (foreign key), DateOut, DateDue." Mention validation rules like presence check, length check, and format check to show depth.
每个案例分析题都要求你指定合适的数据结构。在 GCSE 层面，这通常意味着在平面文件数据库、关系型数据库或者简单数组/列表之间作出选择。当数据项之间存在明确关联时，使用关系型数据库（包含表、主键和外键）——例如，在图书馆系统中，会员表、图书表和借阅表相互独立，可以避免冗余和更新异常。要描述结构：“会员表将包含 MemberID（主键）、姓名、电子邮箱。借阅表包含 LoanID（主键）、MemberID（外键）、BookID（外键）、借出日期、应还日期。” 提到存在性检查、长度检查和格式检查等验证规则，体现深度。
7. Choosing Algorithms and Logic | 算法与逻辑的选择
You do not need to write full code, but you must demonstrate algorithmic thinking. Common requirements include searching (linear vs binary search), sorting (bubble vs insertion sort), and validation routines. State clearly: "Since the appointment slots are sorted by time, a binary search algorithm can quickly locate available slots, operating with O(log n) efficiency, which is much faster than a linear search for large datasets." Even better, sketch a pseudocode snippet for a key operation such as checking for double-bookings. Use consistent indentation and meaningful variable names like available_slots[] and requested_slot.
你不需要写出完整代码，但必须展现算法思维。常见要求包括搜索（线性搜索与二分搜索）、排序（冒泡排序与插入排序）以及验证程序。要清晰陈述：“由于预约时段已按时间排序，二分搜索算法可以快速定位空闲时段，运行效率为 O(log n)，处理大数据集时远比线性搜索快。” 如果能写出关键操作的伪代码片段，比如检测重复预约，那就更好了。使用一致的缩进和有意义的变量名，如 available_slots[] 和 requested_slot。
8. Testing: Normal, Erroneous, and Boundary Data | 测试：正常、错误与边界数据
WJEC expects you to propose a test plan, not just say "test it works." Use a table with five columns: Test ID, Description, Test Data, Expected Result, Actual Result (leave Actual blank unless told otherwise). Always include three data types:
- Normal: "Enter a valid future date for an appointment, e.g., 15/07/2025."
- Boundary: "Attempt to book the last slot of the day, e.g., 17:00–17:30."
- Erroneous: "Enter a date in the past, e.g., 01/01/2020."
Connect each test to a specific validation rule you described earlier. This shows systematic thinking.
WJEC 期待你提出测试计划，而不仅仅是“测试它是否工作”。使用包含五列的表格：测试编号、描述、测试数据、预期结果、实际结果（留空，除非另有要求）。务必包含三种数据类型：正常（输入一个有效的未来日期，如 15/07/2025）、边界（尝试预约当天最后一个时段，如 17:00–17:30）和错误（输入过去的日期，如 01/01/2020）。将每个测试与你先前描述的特定验证规则关联起来，这体现了系统性思维。
9. Implementation and Changeover Strategies | 实施与切换策略
When discussing how to roll out the solution, avoid vague answers. Pick between direct changeover (high risk, suitable for non-critical small-scale systems), parallel running (safest, runs old and new together), pilot (test in one branch first), and phased (gradual rollout, low risk but longer). Justify with context: "For the vet clinic, parallel running is recommended because appointment data is critical; running both paper diary and digital system for two weeks allows staff to verify accuracy without risking missed appointments.". Mention training needs and backup procedures – these show real-world awareness.
在讨论如何推出解决方案时，避免含糊不清的答案。在直接切换（高风险，适合非关键小规模系统）、平行运行（最安全，新旧系统同时运行）、试点（先在单个分点测试）和分阶段（逐步推出，风险低但耗时）之间作出选择。用情境来佐证：“对于兽医诊所，推荐平行运行，因为预约数据至关重要；同时运行纸质日记和数字系统两周，可以让员工验证准确性，又不会冒遗漏预约的风险。” 提及培训需求和备份程序——这体现出对现实环境的认知。
10. Evaluation Against Success Criteria | 对照成功标准进行评估
Evaluation is often the highest-mark section. Do not just say "the solution works." Refer back to the original objectives you extracted from the scenario. Create a simple success criteria table:
| Success Criterion | How Met | Evidence |
|---|---|---|
| Reduce double-bookings to zero | Automated uniqueness check on time slot | Test logs show no duplicate entries over 50 bookings |
| Send automatic reminders 24 hours before | Scheduled script runs daily | Confirmation emails triggered correctly in test |
This structured approach impresses examiners and ensures you cover all aspects of the client's needs.
评估往往是分值最高的部分。不要只说“方案能工作”。要回溯你从情景中提取的初始目标。制作一张简单的成功标准表：成功标准（如将重复预约降至零）、如何满足（自动检查时段唯一性）、证据（测试日志显示 50 次预约中无重复）。这种结构化的方法能让考官眼前一亮，并确保你覆盖了客户需求的方方面面。
11. Common Mistakes That Lose Marks | 导致失分的常见错误
Even strong candidates slip up on predictable pitfalls. Avoid these: (1) Ignoring the budget – proposing high-end servers for a small charity. (2) Vague hardware descriptions – saying “a computer” instead of “a desktop with an i5 processor, 8 GB RAM, SSD, and barcode scanner.” (3) Omitting legal references – failing to mention GDPR when storing personal data. (4) No validation on data entry – leaving forms vulnerable to junk input. (5) Confusing testing with debugging – testing finds errors; debugging fixes them. Keep a checklist of these in your revision notes and tick them off mentally during the exam.
即使实力很强的考生也会在可预见的陷阱上丢分。避免这些：忽视预算——为小型慈善机构推荐高端服务器；硬件描述含糊——说“一台电脑”而不是“配备 i5 处理器、8 GB 内存、固态硬盘和条码扫描器的台式机”；遗漏法律依据——存储个人数据时未提及 GDPR；无数据输入验证——导致表单容易收到垃圾输入；混淆测试与调试——测试是发现错误，调试是修正错误。在你的复习笔记中列出这些要点，并在考试时在心里逐项对照。
12. A Full Practice Walkthrough | 完整实战演练示例
Imagine this condensed scenario: "SunnyDays Nursery cares for 40 children aged 1–4. Parents currently submit emergency contact changes on paper slips. Staff often misplace them, leading to outdated records. The owner wants a digital solution on a £200 budget, using existing tablets." Your answer should flow: feasibility (low cost needed, tablets available -> a simple web form with cloud spreadsheet); data structure (single table with ChildID, Name, ParentName, EmergencyContact, MedicalNotes); inputs (web form fields); processes (update record, log timestamp); outputs (updated contact list printable as PDF); testing (boundary: very long phone numbers, erroneous: alphabetical in phone field); and evaluation (measure how often outdated contacts occur after one month). This structured narrative mirrors band 5–6 responses.
设想一个精简的情景：“SunnyDays 托儿所照看 40 名 1 至 4 岁的儿童。家长目前用纸条提交紧急联系人变更。员工经常弄丢纸条，导致记录过时。负责人希望在 200 英镑预算内，利用现有平板电脑，建立数字化解决方案。” 你的答案应这样展开：可行性（需要低成本，已有平板 → 使用简单的网页表单搭配云电子表格）；数据结构（单表，包含 ChildID、姓名、家长姓名、紧急联系人、医疗备注）；输入（网页表单字段）；处理（更新记录、记录时间戳）；输出（可打印为 PDF 的最新联系人列表）；测试（边界：很长的电话号码，错误：电话号码字段输入字母）；评估（一个月后衡量联系人信息过时的发生频率）。这种结构化的叙述与 5–6 分档次的答案相符。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图