📚 Case Study Practical Exercise | 案例分析实战演练
Case study analysis is a cornerstone of the CCEA Year 12 Computer Science curriculum, requiring you to apply theoretical knowledge to a realistic scenario. This article walks you through a structured approach to dissecting a case study, from understanding the problem domain to proposing a complete software solution. By practising with a sample retail inventory system, you will build confidence in identifying requirements, modelling data, designing interfaces, choosing a development methodology, and planning testing and maintenance.
案例研究分析是 CCEA Year 12 计算机科学课程的核心，要求你将理论知识应用于实际场景。本文将带你按照结构化的方法剖析案例研究，从理解问题领域到提出完整的软件解决方案。通过一个零售库存系统的样本练习，你将自信地学会识别需求、建模数据、设计界面、选择开发方法，以及规划测试与维护。
1. Understanding the Case Study Scenario | 理解案例研究场景
Every case study begins with a narrative describing a real-world problem. Read the scenario multiple times, highlighting key entities, processes, constraints, and user expectations. In our example, a small retail chain wants to replace its paper-based stock tracking with a digital system that records sales, updates inventory in real time, and generates low-stock alerts for managers. You must grasp the business context before leaping into technical details.
每一个案例研究都以描述现实问题的叙述开始。反复阅读场景，突出关键实体、流程、约束和用户期望。在我们的示例中，一家小型零售连锁店希望用数字系统取代纸质库存跟踪，该系统记录销售、实时更新库存并为经理生成低库存警报。在深入技术细节之前，必须掌握业务背景。
2. Identifying Stakeholders and Their Needs | 识别利益相关者及其需求
Stakeholders are anyone affected by the system. For the retail inventory project, we identify the shop manager (needs daily sales summaries, low-stock warnings), sales assistants (require fast product lookup and checkout), stockroom staff (need to log new deliveries and returns), and the owner (wants profit reports). Each stakeholder’s viewpoint shapes the functional requirements, so interview notes or use-case descriptions help capture them systematically.
利益相关者是受系统影响的任何人。针对零售库存项目，我们确定了店铺经理（需要每日销售摘要、低库存警告）、销售助理（需要快速产品查找和结账）、仓库员工（需要记录新到货和退货）以及店主（希望看到利润报告）。每个利益相关者的视角都塑造了功能需求，因此访谈记录或用例描述有助于系统地捕捉它们。
3. Functional and Non-Functional Requirements | 功能性和非功能性需求
Functional requirements state what the system must do – log sales, update inventory levels by subtracting sold quantities, generate restock alerts when stock falls below a threshold, and produce weekly sales reports. Non-functional requirements cover how the system performs: it should respond to a barcode scan within 1 second, support up to 10 concurrent users, be accessible on a standard office PC, and enforce role-based login security. Clearly distinguishing these two categories ensures nothing is overlooked.
功能性需求说明系统必须做什么——记录销售、通过减去已售数量更新库存水平、当库存低于阈值时生成补货警报，并生成每周销售报告。非功能性需求涵盖系统的性能表现：应在 1 秒内响应条码扫描，支持最多 10 个并发用户，可在标准办公 PC 上访问，并实施基于角色的登录安全。清晰区分这两类可确保不遗漏任何内容。
4. Feasibility Study: Economic, Technical, Legal, Operational | 可行性研究：经济、技术、法律、操作
Before committing resources, evaluate feasibility. Economic feasibility: compare development costs (hardware, software licences, developer time) against savings from reduced paperwork and stock loss. Technical feasibility: confirm that the existing LAN, PCs, and barcode scanners can support the application. Legal feasibility: ensure the system complies with GDPR because it stores employee login data; implement clear data retention policies. Operational feasibility: assess whether staff can adapt to the new workflow and whether training is sufficient. A simple cost-benefit table can summarise the findings.
在投入资源之前，评估可行性。经济可行性：对比开发成本（硬件、软件许可证、开发者时间）与减少文书工作和库存损失带来的节省。技术可行性：确认现有的局域网、PC 和条码扫描器能够支持该应用。法律可行性：因系统存储员工登录数据，须确保符合 GDPR；实施明确的数据保留政策。操作可行性：评估员工是否能适应新工作流程，以及培训是否充分。一个简单的成本效益表可以总结结果。
5. Data Flow Diagrams (DFDs) and System Context | 数据流图与系统上下文
A Data Flow Diagram models how information moves through the system. Start with a context diagram: a single process ‘Inventory Management System’ interacting with external entities – Customer (provides product selection, receives receipt), Supplier (sends delivery details), and Manager (requests reports). Level-1 DFD breaks this into processes like ‘Process Sale’, ‘Update Stock’, and ‘Generate Alert’, showing data stores such as ‘Product File’ and ‘Sales Transaction File’. Use standard symbols: circles for processes, rectangles for external entities, open-ended rectangles for data stores, and arrows for data flows.
数据流图模拟信息如何在系统中流动。从上下文图开始：一个单独的进程「库存管理系统」与外部实体交互——客户（提供产品选择，接收收据）、供应商（发送交货详情）和经理（请求报告）。一级 DFD 将其分解为「处理销售」、「更新库存」和「生成警报」等进程，显示「产品文件」和「销售交易文件」等数据存储。使用标准符号：圆形代表进程，矩形代表外部实体，开口矩形代表数据存储，箭头代表数据流。
6. Entity-Relationship Diagrams (ERDs) for Database Design | 数据库设计的实体关系图
alAmount), SALE_ITEM (SaleID, ProductID, Quantity, UnitPrice), and SUPPLIER (SupplierID, Name, Contact). Relationships: a SALE contains many SALE_ITEMs; each SALE_ITEM references one PRODUCT; a PRODUCT is supplied by one SUPPLIER. Use crow’s foot notation to indicate one-to-many relationships. This diagram directly translates into SQL table definitions: for example, ProductID acts as a foreign key in SALE_ITEM.
ERD 映射数据结构。实体可能包括 PRODUCT（ProductID, Name, Price, StockLevel, ReorderThreshold）、SALE（SaleID, Date, TotalAmount）、SALE_ITEM（SaleID, ProductID, Quantity, UnitPrice）和 SUPPLIER（SupplierID, Name, Contact）。关系：一次 SALE 包含多个 SALE_ITEM；每个 SALE_ITEM 引用一个 PRODUCT；一个 PRODUCT 由一个 SUPPLIER 供应。使用鱼尾纹符号表示一对多关系。该图可直接转换为 SQL 表定义：例如，ProductID 在 SALE_ITEM 中作为外键。
7. User Interface Prototyping | 用户界面原型设计
Create low-fidelity wireframes to visualise the main screens. The checkout screen could display a searchable product list, a barcode input field, a shopping cart pane, and a total with tax calculation. The manager’s dashboard might show a bar chart of daily sales, a list of low-stock products highlighted in red, and a button to export reports. Prototyping clarifies navigation paths and uncovers missing requirements early, such as the need for a product return function. Use simple tools like paper sketches or digital wireframe apps.
创建低保真线框图以可视化主要屏幕。结账屏可展示可搜索的产品列表、条码输入框、购物车窗格以及含税计算的总额。经理仪表板可能显示每日销售柱状图、红色突出显示的低库存产品列表，以及导出报表的按钮。原型制作理清了导航路径，并尽早发现缺失的需求，例如需要产品退货功能。使用纸质草图或数字线框应用等简单工具即可。
8. Software Development Methodology: Agile vs Waterfall | 软件开发方法论：敏捷与瀑布
For a small retail system with evolving requirements, an Agile approach using Scrum might be ideal. The project could be divided into sprints: Sprint 1 – basic product catalogue and sale entry; Sprint 2 – inventory update and low-stock alerts; Sprint 3 – reporting and user management. Daily stand-ups, sprint reviews, and a product backlog allow the client to reprioritise features. In contrast, the Waterfall model would lock requirements upfront, which is riskier if the retailer later decides to add e-commerce integration. Justify your choice based on project size, clarity of requirements, and stakeholder involvement.
对于需求不断演变的小型零售系统，采用 Scrum 的敏捷方法可能最理想。项目可划分为多个冲刺：冲刺 1——基本产品目录和销售录入；冲刺 2——库存更新与低库存警报；冲刺 3——报表和用户管理。每日站会、冲刺评审和产品待办列表允许客户重新排列功能优先级。相比之下，瀑布模型会将需求提前锁定，若零售商后来决定增加电商集成则风险更大。根据项目规模、需求清晰度和利益相关者参与度来证明你的选择。
9. Testing Strategies: Unit, Integration, System, Acceptance | 测试策略：单元、集成、系统、验收
A comprehensive test plan ensures reliability. Unit testing checks individual modules, e.g., the function that reduces StockLevel when Quantity is sold. Integration testing verifies that the Sale module correctly updates the Stock module and writes to the database. System testing evaluates the entire application under simulated real-world loads, such as rapid barcode scans. Acceptance testing involves the shop manager and sales assistants performing typical tasks (checkout, reporting) in a trial environment. Record test cases with input data, expected outcomes, and actual results in a table to track pass/fail status.
全面的测试计划确保可靠性。单元测试检查单个模块，例如当销售数量减少 StockLevel 的函数。集成测试验证 Sale 模块是否正确更新 Stock 模块并写入数据库。系统测试在模拟的真实负载下评估整个应用，如快速条码扫描。验收测试让店铺经理和销售助理在试用环境中执行典型任务（结账、生成报表）。用表格记录测试用例，包括输入数据、预期结果和实际结果，以跟踪通过/未通过状态。
10. Evaluation and Maintenance Planning | 评估与维护计划
After deployment, evaluate the system against its original objectives: has stock loss decreased by 20% as projected? Are sales processed 30% faster? Gather quantitative metrics and user feedback through surveys. Plan for corrective maintenance (fixing bugs discovered late), adaptive maintenance (adjusting to new tax rates or barcode standards), and perfective maintenance (adding features like email alerts). A maintenance log helps track issues and their resolution, ensuring long-term sustainability.
部署后，依据最初目标评估系统：库存损失是否如预期减少了 20%？销售处理速度是否加快了 30%？通过问卷调查收集量化指标和用户反馈。规划纠正性维护（修复后期发现的错误）、适应性维护（适应新税率或条码标准）和完善性维护（增加如电子邮件警报等功能）。维护日志有助于跟踪问题及其解决，确保长期可持续性。
11. Ethical, Legal and Environmental Considerations | 道德、法律和环保考虑
Beyond the technical aspects, you must reflect on wider impacts. Ethically, the system should not monitor employee behaviour beyond what is necessary for stock control; transparency about data usage is essential. Legally, the database containing staff IDs and customer purchase histories must be encrypted and access-controlled per GDPR. Environmentally, moving from paper records to digital reduces paper consumption, but consider energy usage of always-on servers and recycling old hardware. Discussing these points demonstrates holistic thinking expected in top-grade answers.
在技术层面之外，必须思考更广泛的影响。道德上，系统对员工行为的监控不应超出库存控制所必需的范围；关于数据使用的透明度至关重要。法律上，包含员工 ID 和客户购买记录的数据库必须按 GDPR 加密并进行访问控制。环境层面，从纸质记录转向数字化减少了纸张消耗，但需考虑常开服务器的能耗以及旧硬件的回收。讨论这些要点体现了获得高分的答案所期望的整体思维。
12. Applying the Case Study: A Retail Inventory System | 应用案例：零售库存系统
Let us now synthesise everything into a coherent project proposal for the retail inventory system. We have identified the shop owner, manager, assistants, and stockroom staff as stakeholders; defined functional requirements such as sale recording, stock deduction, and alert generation; and set non-functional targets like sub-second response and role-based access. A preliminary ERD shows four main tables, and DFDs clarify how a sale cascades into stock updates and report triggers. We chose Agile development over Waterfall to accommodate changing needs, and designed a test plan covering all stages. The final proposal includes a wireframe showing a dashboard with low-stock indicators and a weekly sales graph, a development timeline of three sprints, and a post-launch evaluation framework. By following this structured method, you can confidently tackle any CCEA case study question.
现在让我们将所有内容综合成一个连贯的零售库存系统项目提案。我们已将店主、经理、助理和仓库员工确定为利益相关者；定义了功能性需求，如销售记录、库存扣减和警报生成；并设定了非功能性目标，如亚秒级响应和基于角色的访问。初步 ERD 显示了四个主表，DFD 阐明了销售如何级联到库存更新和报告触发。我们选择了敏捷开发而非瀑布模型以适应变化的需求，并设计了覆盖所有阶段的测试计划。最终提案包含一个显示低库存指示器和每周销售图表的仪表板线框图、一个三个冲刺的开发时间表，以及一个启动后评估框架。遵循这一结构化方法，你可以自信地应对任何 CCEA 案例研究问题。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图