📚 Case Study Analysis in Practice: WJEC Year 13 Computer Science | WJEC Year 13 计算机案例分析实战演练
In WJEC A Level Computer Science, the Component 1 exam is built around a pre-release case study that tests your ability to analyse, design, and critically evaluate a software system. This practical guide walks you through each stage of the case study process, from extracting requirements to evaluating the final solution, equipping you with the structured approach needed to excel in the exam.
在 WJEC A Level 计算机科学中，Component 1 考试围绕一份预发布案例研究展开，考查你分析、设计和批判性评估软件系统的能力。这份实战指南带你走完案例分析过程的每个阶段，从提取需求到评估最终解决方案，为你提供在考试中脱颖而出的结构化方法。
1. Deconstructing the Pre-release Material | 拆解预发布材料
Before you start modelling, you must fully understand the scenario. Read the document at least three times: first for the overall narrative, second to highlight all entities, data flows and constraints, and third to annotate explicit and implicit requirements. Look for keywords such as ‘must’, ‘should’, ‘real-time’, ‘secure’ and ‘accessible’.
在开始建模之前，你必须彻底理解场景。至少阅读材料三遍：第一遍把握整体叙述，第二遍标出所有实体、数据流和约束条件，第三遍注释显性和隐性需求。注意“必须”“应当”“实时”“安全”“可访问”等关键词。
Create a high-level summary table that maps each paragraph of the case study to the relevant part of the system development lifecycle. For example, legacy system details might relate to migration constraints; current manual processes hint at automation requirements. This initial mapping prevents you from overlooking critical details later.
创建一份高层总结表，将案例研究的每一段映射到系统开发生命周期的相关部分。例如，遗留系统的细节可能与迁移约束相关；当前的手动流程暗示了自动化需求。这种初始映射可以防止你随后忽略关键细节。
2. Requirements Engineering and Classification | 需求工程与分类
Translate the narrative into clearly defined functional and non-functional requirements. A functional requirement describes what the system must do, such as ‘Allow customers to check order status online’. A non-functional requirement specifies how the system performs, e.g. ‘The system shall handle 1000 concurrent users with a response time of ≤2 seconds’.
将叙述转化为明确定义的功能性和非功能性需求。功能性需求描述系统必须做什么，例如“允许客户在线查询订单状态”。非功能性需求指定系统如何运行，例如“系统应能处理1000个并发用户，响应时间≤2秒”。
| Functional Requirements (功能需求) | Non-Functional Requirements (非功能需求) |
|---|---|
| Generate monthly sales reports | Reports must be generated within 5 seconds |
| Authenticate users via password | Passwords must be encrypted using AES-256 |
Use a traceability matrix to connect each requirement to a stakeholder goal and a later design component. This will help you answer evaluation questions and demonstrate thorough analytical thinking in your exam script.
使用可追溯性矩阵将每个需求与利益相关者目标以及后续设计组件关联起来。这将帮助你回答评估类问题，并在考卷中展示缜密的分析思维。
3. Stakeholder Identification and Analysis | 利益相关者识别与分析
List all individuals, groups, or external systems that interact with your proposed solution. Typical stakeholders include end users, system administrators, management, regulatory bodies, and external partners. For each, note their role, the benefits they expect, and any concerns they might raise.
列出与你提议的方案交互的所有个人、群体或外部系统。典型的利益相关者包括终端用户、系统管理员、管理层、监管机构和外部合作伙伴。对于每个利益相关者，注明其角色、期望的利益以及可能提出的关切。
Power–interest grids or RACI matrices can be extremely effective in the exam. For instance, a finance director may have high power and high interest, requiring regular reporting features, while a casual user might have low power but high interest, demanding an intuitive interface. Demonstrating this awareness scores highly on evaluation criteria.
权力–利益方格或 RACI 矩阵在考试中可能非常有效。例如，财务总监可能权力高、利益高，因此需要定期报表功能；而普通用户可能权力低但利益高，要求直观的界面。展示这种洞察能在评价标准上获得高分。
4. Data Flow Modelling (DFD) | 数据流图建模
Begin with a Level 0 context diagram that represents the entire system as a single process bubble connected to external entities. Label each data flow clearly with descriptive names such as ‘Order Details’, ‘Invoice’, and ‘Payment Confirmation’. Ensure every external entity is represented by a terminators (square).
从第0层上下文图开始，整个系统表示为一个单一过程气泡，连接外部实体。用描述性名称清楚地标记每条数据流，如“订单明细”“发票”和“付款确认”。确保每个外部实体都用终结符（方框）表示。
Decompose the context diagram into a Level 1 DFD that shows the major sub-processes, data stores, and flows between them. For example, process 1.0 ‘Process Order’ might read from a ‘Customer’ data store and write to ‘Order’ data store. Maintain consistent numbering and check for balancing errors: all flows entering and leaving the parent process must appear on the child diagram.
将上下文图分解为第1层 DFD，显示主要的子过程、数据存储及其之间的流动。例如，过程1.0“处理订单”可能从“客户”数据存储读取并写入“订单”数据存储。保持一致的编号并检查平衡错误：进入和离开父过程的所有数据流都必须在子图上出现。
5. Entity-Relationship Diagrams and Data Modelling | 实体关系图与数据建模
Design an ERD to model the data that the system will store and manipulate. Identify all entities (e.g., Customer, Product, Order) and define their attributes. Underline primary keys and mark foreign keys with (FK). For a relationship like ‘Customer places Order’, indicate cardinality: one customer places zero or many orders – a one-to-many relationship.
设计 ERD 来建模系统将要存储和处理的数据。识别所有实体（如客户、产品、订单）并定义其属性。在主键下加下划线，用 (FK) 标记外键。对于“客户下订单”这类关系，要标明基数：一个客户下零或多个订单——即一对多关系。
Avoid many-to-many relationships by resolving them into link entities. If students enrol on courses, create an Enrolment entity containing StudentID and CourseID as a composite primary key. This not only normalizes your data model but also demonstrates your understanding of relational database design principles to the examiner.
避免多对多关系，将其分解为关联实体。如果学生选修课程，就创建一个包含 StudentID 和 CourseID 作为复合主键的 Enrolment 实体。这不仅使你的数据模型规范化，还能向考官展示你对关系型数据库设计原理的理解。
6. Algorithm Design and Pseudocode | 算法设计与伪代码
Turn business rules into structured algorithms. Use pseudo-code that follows a consistent style: capitalise keywords like IF, THEN, ELSE, WHILE, ENDWHILE, ENDIF. Always initialise variables and include meaningful comments. For example, to apply a loyalty discount:
将业务规则转化为结构化算法。使用风格一致的伪代码：关键字大写，如 IF、THEN、ELSE、WHILE、ENDWHILE、ENDIF。始终初始化变量并包含有意义的注释。例如，应用忠诚度折扣：
INPUT totalSpent
IF totalSpent ≥ 500 THEN
discount ← 0.05
ELSE
discount ← 0
ENDIF
finalPrice ← totalSpent × (1 − discount)
For critical processes, provide a flowchart or a trace table in addition to pseudocode. A trace table with columns for variable values at each step can prove that your algorithm works correctly for boundary conditions, which is highly rewarded in WJEC mark schemes.
对于关键过程，除伪代码外还要提供流程图或跟踪表。一个显示各步骤变量值的跟踪表可以证明你的算法在边界条件下运行正确，这在 WJEC 评分方案中能获得高度认可。
7. User Interface Prototyping and Usability | 用户界面原型设计与可用性
Sketch a low-fidelity wireframe for the main screens, such as a login page or dashboard. Label all components (buttons, text fields, navigation bars) and explain their purpose. Base your design on Nielsen’s heuristics: for instance, providing clear error messages when a user enters an invalid input respects the ‘error prevention’ and ‘visibility of system status’ principles.
为主要界面（如登录页或仪表板）绘制低保真线框图。标签所有组件（按钮、文本字段、导航栏）并说明其用途。根据 Nielsen 启发式原则进行设计：例如，当用户输入无效信息时提供清晰的错误消息，这符合“错误预防”和“系统状态可见性”原则。
Link prototypes to earlier requirements. If the case study stresses ‘ease of use for elderly users’, specify larger font sizes, high contrast colours, and minimal clutter. Always justify design decisions: never simply state ‘I used a button’ – explain why that button is positioned and sized as it is.
将原型与早期需求联系起来。如果案例研究强调“便于老年人使用”，就要指定较大的字号、高对比度颜色和尽量简洁的界面。始终论证设计决策：不要仅仅说“我使用了一个按钮”——要解释该按钮为何如此布置和设计。
8. Testing Strategy and Test Case Design | 测试策略与测试用例设计
A comprehensive test plan is essential. Structure your test cases using a table with columns: Test ID, Test Description, Input Data, Expected Outcome, Actual Outcome (completed after hypothetical testing). Include at least one test case for each functional requirement identified earlier.
全面的测试计划至关重要。使用如下列构成表格来构造测试用例：测试ID、测试描述、输入数据、预期结果、实际结果（在假设测试后填写）。为前面识别的每个功能性需求至少包含一个测试用例。
| Test ID | Input Data | Expected Outcome |
|---|---|---|
| T1 – normal age | age = 25 | Accepted, eligibility granted |
| T2 – lower boundary | age = 18 | Accepted |
| T3 – below boundary | age = 17 | Rejected with error message ‘Too young’ |
Discuss testing strategies: white-box testing for an algorithm that calculates discounts (statement and branch coverage) and black-box testing for the login module. Mention user acceptance testing (UAT) to confirm the system meets the stakeholder’s needs described in the case study. This holistic view impresses examiners.
讨论测试策略：对计算折扣的算法采用白盒测试（语句覆盖和分支覆盖），对登录模块采用黑盒测试。提及用户验收测试（UAT）以确认系统满足案例研究中描述的利益相关者需求。这种全局观给考官留下深刻印象。
9. Security, Legal and Ethical Implications | 安全、法律与伦理影响
Case studies often involve personal or sensitive data. Identify relevant UK legislation: the Data Protection Act 2018 (incorporating GDPR) requires that data be processed lawfully, fairly and transparently; the Computer Misuse Act 1990 makes unauthorised access illegal. Explain how your design complies – e.g., by implementing role-based access control and encrypting data at rest.
案例研究经常涉及个人或敏感数据。识别相关的英国法律：2018年数据保护法（包含 GDPR）要求数据以合法、公正和透明的方式处理；1990年计算机滥用法将未经授权的访问定为非法。说明你的设计如何合规——例如，通过实施基于角色的访问控制和静态数据加密。
Highlight ethical considerations beyond legal compliance. If the system uses an AI-based recommendation engine, discuss potential bias and the digital divide. For an online booking system, consider ensuring accessibility for users with visual impairments (screen reader compatibility) and those without high-speed internet. Such depth demonstrates maturity in your analysis.
强调超出法律合规的伦理考量。如果系统使用基于 AI 的推荐引擎，讨论潜在的偏见和数字鸿沟。对于在线预订系统，要确保视障用户（屏幕阅读器兼容）和没有高速互联网的用户的可访问性。这种深度分析展示了思维的成熟度。
10. Evaluation and Critical Review | 评估与批判性回顾
Critically evaluate the solution you have proposed against the original requirements. Did you meet all functional requirements? Are there any trade-offs, such as choosing strong encryption over performance? Be honest about limitations: perhaps your DFD Level 1 did not model a backup process, but you can recommend adding it in a future iteration.
根据原始需求批判性地评估你提出的解决方案。是否满足了所有功能性需求？是否存在任何权衡，比如为了强力加密而牺牲性能？要诚实面对局限性：也许你的 DFD 第1层没有建模备份过程，但你可以建议在后续迭代中增加。
Use a SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) to structure your evaluation. Strengths might include a modular design; weaknesses could be reliance on third-party APIs. Opportunities: potential for mobile app expansion; Threats: rapidly changing regulatory environment. This strategic perspective aligns with WJEC’s top-band evaluation criteria.
使用 SWOT 分析（优势、劣势、机会、威胁）来组织评估。优势可能包括模块化设计；劣势可能是依赖第三方 API。机会：扩展为移动应用的潜力；威胁：快速变化的监管环境。这种战略视角符合 WJEC 最高评分等级的评价标准。
11. Exam Technique and Revision Tips | 考试技巧与复习贴士
In the exam, allocate your time proportionally to the marks. Section B questions often build on the pre-release; annotate the case study insert before reading the questions. Underline the command words: ‘describe’ requires facts, ‘explain’ needs reasons, ‘evaluate’ demands balanced pros and cons, and ‘design’ expects a concrete output like a diagram or pseudocode.
在考试中，按分数比例分配时间。Section B 的题目通常建立在预发布材料的基础上；在读题前先对案例研究插页进行注释。在指令词下划线：“describe”需要陈述事实，“explain”需要说明理由，“evaluate”要求权衡利弊，“design”则期待具体的产出，如图表或伪代码。
Practice past papers under timed conditions, especially drawing DFDs and ERDs quickly but neatly. Create a reference sheet of common notations, SQL commands, and pseudocode structures. In the answer booklet, use headings, labelled diagrams, and clear handwriting to make your responses easy for the examiner to navigate.
在计时条件下练习历年真题，尤其是快速而整洁地绘制 DFD 和 ERD。制作一份常用符号、SQL 命令和伪代码结构的参考表。在答题册中，使用标题、带标签的图表和清晰的书写，让你的回答便于考官浏览。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导