📚 Case Study Practical Exercises | 案例分析实战演练
In Year 13 CCEA Computer Science, case studies are a vital part of understanding how information systems are developed in real-world contexts. This article provides a step-by-step practical exercise based on a fictional company, TechMart, to help you master the skills needed for your exam. You will work through stakeholder analysis, feasibility, design, implementation and evaluation, mirroring the approach expected in your coursework and written exam.
在 Year 13 CCEA 计算机科学中，案例分析是理解信息系统在真实环境中如何开发的关键部分。本文以一个虚构公司 TechMart 为例，提供逐步实战演练，帮助你掌握考试所需技能。你将逐一完成利益相关者分析、可行性研究、设计、实施与评估，模拟课程作业和笔试所要求的分析方法。
1. Case Study Overview | 案例概述
TechMart is a small electronics retailer operating from a single high-street store. It currently uses a legacy stock control system written in FoxPro, which runs on a local server. The owner wants to expand into e-commerce to reach a wider customer base and boost sales.
TechMart 是一家小型电子产品零售商，目前仅有一家临街店面。它使用一套基于 FoxPro 编写的遗留库存控制系统，运行在本地服务器上。店主希望拓展电子商务，以接触更广泛的客户群体并提高销售额。
The proposed online system must include a product catalogue, shopping cart, secure payment processing, order tracking and customer accounts. It also needs to integrate with the existing stock database to prevent overselling. The budget is limited and the system must be operational within six months.
拟建的在线系统必须包含产品目录、购物车、安全支付处理、订单跟踪和客户账户。它还需要与现有库存数据库集成，以防止超卖。预算有限，系统必须在六个月内投入运行。
Key constraints include the need for 24/7 availability, compliance with PCI DSS for card payments, and a user-friendly interface suitable for non-technical customers. The owner also requires a content management facility to update product details without relying on developers.
主要约束包括需要全天候运行、符合 PCI DSS 卡支付标准，以及适合非技术客户的友好用户界面。店主还要求提供内容管理功能，以便自行更新产品详情而无需依赖开发人员。
2. Stakeholder Analysis | 利益相关者分析
Identifying stakeholders is the first step in understanding system requirements. For TechMart, the internal stakeholders are the owner, the store manager, two sales assistants and an external IT support contractor. External stakeholders include customers, payment gateway providers, delivery partners and suppliers.
识别利益相关者是理解系统需求的第一步。对于 TechMart，内部利益相关者包括店主、门店经理、两名销售助理和一名外部 IT 支持承包商。外部利益相关者包括客户、支付网关提供商、配送合作伙伴和供应商。
The owner is the primary sponsor who defines the business objectives: increase revenue by 30% in the first year and build brand visibility. The store manager needs reliable stock synchronization between the physical store and the online channel to avoid discrepancies. Sales assistants will use the system to process online returns in-store.
店主是主要发起人，他定义了业务目标：第一年营收增长 30% 并建立品牌知名度。门店经理需要实体店与在线渠道之间可靠的库存同步，以避免差异。销售助理将使用该系统在店内处理线上退货。
Customers expect a smooth browsing experience, accurate stock information, fast checkout and clear return policies. Payment gateway providers demand adherence to security protocols. Third-party delivery services require accurate order data and address formatting. All these perspectives must be captured during analysis.
客户期望流畅的浏览体验、准确的库存信息、快速的结账流程和清晰的退货政策。支付网关提供商要求遵守安全协议。第三方配送服务需要准确的订单数据和地址格式。所有这些视角都必须在分析阶段加以捕获。
3. Feasibility Study | 可行性研究
Before committing resources, a thorough feasibility study is essential. The following table summarises the TELOS framework (Technical, Economic, Legal, Operational, Schedule) applied to the TechMart project.
在投入资源之前，全面的可行性研究必不可少。下表总结了应用于 TechMart 项目的 TELOS 框架（技术、经济、法律、操作、进度）。
| Factor | Assessment |
|---|---|
| Technical | The existing FoxPro database can be migrated to MySQL. Web hosting with PHP and SSL is readily available. The skills required for integration exist in the market. |
| Economic | Initial development costs are estimated at £8,000–£12,000. The expected increase in sales should yield a return on investment within 14 months. |
| Legal | The system must comply with GDPR for customer data, PCI DSS for payment card data, and the Consumer Rights Act. A clear privacy policy is required. |
| Operational | Staff are willing to be trained. The new system will require changes to existing workflows, such as handling online returns. A backup plan for system downtime is needed. |
| Schedule | Six months is challenging but achievable if an agile methodology is used. The critical path includes data migration and payment integration testing. |
技术：现有 FoxPro 数据库可迁至 MySQL。配备 PHP 和 SSL 的虚拟主机服务易于获得。市场具备所需集成技能。
经济：初期开发成本估计为 8000 至 12000 英镑。预期销售额增长可在 14 个月内收回投资。
法律：系统必须遵守 GDPR（客户数据）、PCI DSS（支付卡数据）和《消费者权益法》。需要明确的隐私政策。
操作：员工愿意接受培训。新系统将改变现有工作流程，如处理线上退货。须制定系统停机备用计划。
进度：六个月颇具挑战，但采用敏捷方法可达成。关键路径包括数据迁移和支付集成测试。
4. Requirements Elicitation | 需求获取
To capture detailed requirements, we would use interviews with the owner and store manager, observation of current sales processes, and a questionnaire sent to a sample of potential online customers. A joint application development (JAD) workshop could help resolve conflicting expectations early.
为获取详细需求，我们将与店主和门店经理进行访谈，观察当前销售流程，并向潜在在线客户样本发送问卷。联合应用开发（JAD）研讨会可帮助及早解决相互冲突的期望。
Functional requirements include: searchable product catalogue with filters; shopping cart that persists for at least 30 minutes; integration with PayPal and Stripe; automated order confirmation emails; real-time stock deduction; and a returns portal. Non-functional requirements emphasise a page load time under 3 seconds, mobile responsiveness, and 99.5% uptime.
功能需求包括：带筛选器的可搜索产品目录；至少持续 30 分钟的购物车；与 PayPal 和 Stripe 集成；自动发送订单确认邮件；实时库存扣减；以及退货入口。非功能性需求强调页面加载时间低于 3 秒、移动端响应式设计和 99.5% 的正常运行时间。
We should also document data requirements: each product must have a SKU, name, description, price, stock quantity and image. Customer records will store name, email, hashed password, shipping address and order history. All sensitive data must be encrypted at rest and in transit.
我们还应记录数据需求：每个产品必须有 SKU、名称、描述、价格、库存数量和图片。客户记录将存储姓名、电子邮件、散列密码、配送地址和订单历史。所有敏感数据必须在静止时和传输中加密。
5. System Design | 系统设计
Using a structured approach, we can model the system with a data flow diagram (DFD). At Level 0, the external entities are Customer, Payment Gateway, Delivery Service and Admin. The main process ‘TechMart Online System’ connects them. Data stores include D1 Customer File, D2 Product Inventory and D3 Order File.
采用结构化方法，我们可以用数据流图（DFD）对系统建模。在第 0 层，外部实体为客户、支付网关、配送服务和管理员。主过程「TechMart 在线系统」将它们连接起来。数据存储包括 D1 客户文件、D2 产品库存和 D3 订单文件。
The Level 1 DFD would decompose the main process into: 1.0 Browse & Search, 2.0 Manage Cart, 3.0 Checkout & Payment, 4.0 Process Order, 5.0 Update Stock, and 6.0 Admin Content Management. Each can be further refined. The system architecture will follow a three-tier model: presentation (HTML/CSS/JS), logic (PHP), and data (MySQL).
第 1 层 DFD 将主过程分解为：1.0 浏览与搜索，2.0 管理购物车，3.0 结账与支付，4.0 处理订单，5.0 更新库存，以及 6.0 管理内容。每个过程可进一步细化。系统架构遵循三层模型：表示层（HTML/CSS/JS）、逻辑层（PHP）和数据层（MySQL）。
An alternative object-oriented design could use classes such as Customer, Product, Order, ShoppingCart and Payment. The MVC pattern would separate concerns: Model for database interaction, View for HTML templates, Controller for business logic. Given the tight deadline, a proven framework like Laravel could accelerate development.
另一种面向对象设计可使用 Customer、Product、Order、ShoppingCart 和 Payment 等类。MVC 模式可分离关注点：Model 负责数据库交互，View 生成 HTML 模板，Controller 处理业务逻辑。鉴于时间紧迫，可选用诸如 Laravel 的成熟框架加快开发。
6. Database Design | 数据库设计
The entity relationship diagram (ERD) identifies the following entities: Customer, Product, Category, Order, OrderItem and Payment. A Customer can place many Orders (1:M). An Order contains many OrderItems, each linked to one Product. A Product belongs to one Category.
实体关系图（ERD）确定了以下实体：Customer、Product、Category、Order、OrderItem 和 Payment。一个客户可下多个订单（1:M）。一个订单包含多个 OrderItem，每一项关联一个产品。一个产品属于一个类别。
Below is the proposed table structure. Primary keys are underlined; foreign keys are indicated with (FK).
以下是建议的表结构。主键以下划线标出；外键标注 (FK)。
| Table | Attributes |
|---|---|
| Customer | customerID, firstName, lastName, email, passwordHash, address, phone, registeredDate |
| Category | categoryID, categoryName, description |
| Product | productID, SKU, name, description, price, stockQuantity, imageURL, categoryID (FK) |
| Order | orderID, customerID (FK), orderDate, status, totalAmount |
| OrderItem | orderItemID, orderID (FK), productID (FK), quantity, unitPrice |
| Payment | paymentID, orderID (FK), paymentDate, amount, method, transactionRef |
Normalisation would be checked to 3NF: each table has a single purpose, all attributes depend on the primary key, and there are no transitive dependencies. For instance, categoryName is stored in the Category table, not repeated in Product.
将进行第三范式规范化检查：每个表有单一用途，所有属性均依赖于主键，且不存在传递依赖。例如，categoryName 存储在 Category 表中，而不是在 Product 表中重复。
7. User Interface Prototyping | 用户界面原型设计
A low-fidelity prototype using pen and paper would sketch the homepage layout: logo top-left, search bar centre, hamburger menu for categories on mobile. The product listing page shows thumbnail images, name, price and an ‘Add to Cart’ button. The checkout flow should follow a clear linear progression: cart → shipping details → payment → confirmation.
先用纸笔绘制低保真原型：首页布局为左上角 logo、中间搜索栏、移动端用汉堡菜单显示类别。产品列表页展示缩略图、名称、价格和「加入购物车」按钮。结账流程应遵循清晰的线性顺序：购物车 → 配送信息 → 支付 → 确认。
High-fidelity wireframes can be built using tools like Figma. Usability heuristics (Nielsen’s) should be applied: visibility of system status (e.g., loading spinners), match between system and real world (e.g., a cart icon for the basket), user control (option to edit cart before paying), and error prevention (input validation on the payment form).
高保真线框图可用 Figma 等工具构建。应遵循可用性启发式原则（尼尔森启发式）：系统状态可见性（如加载动画）、系统与现实世界的匹配（如用购物车图标表示篮子）、用户控制（付款前可编辑购物车）和错误预防（支付表单的输入验证）。
Accessibility must be built in from the start: sufficient colour contrast, alt text for images, keyboard navigability and ARIA labels for screen readers. Compliance with WCAG 2.1 AA level reduces legal risk and expands the customer base.
从一开始就须融入无障碍设计：足够的颜色对比度、图片的替代文本、键盘可操作性以及屏幕阅读器的 ARIA 标签。符合 WCAG 2.1 AA 级别可降低法律风险并扩大客户群。
8. Implementation Planning | 实施规划
The development team will adopt an agile Scrum methodology with two-week sprints. Sprint 1: set up hosting, migrate legacy product data to MySQL, create basic product catalogue. Sprint 2: user registration and login. Sprint 3: shopping cart and checkout. Sprint 4: payment integration and sandbox testing. Sprint 5: order management and stock sync. Sprint 6: content management, security hardening and user acceptance testing.
开发团队将采用敏捷 Scrum 方法，每两周为一个冲刺。冲刺 1：设置主机托管，将遗留产品数据迁移至 MySQL，创建基本产品目录。冲刺 2：用户注册与登录。冲刺 3：购物车与结账。冲刺 4：支付集成与沙盒测试。冲刺 5：订单管理与库存同步。冲刺 6：内容管理、安全加固和用户验收测试。
Changeover strategy: a phased rollout is preferable to a direct cutover, as it reduces risk. The online store could launch with a limited product range initially, while the physical store continues to operate normally. Once stock synchronisation proves reliable, the full catalogue can go live. A parallel run with the legacy stock system will be maintained for the first month.
转换策略：分阶段推出优于直接切换，因为它能降低风险。在线商店可先以有限产品范围上线，同时实体店正常运营。一旦库存同步被证明可靠，即可全面上线。首月将与遗留库存系统并行运行。
A contingency plan must address data migration failure, payment gateway outage, and security breaches. Daily database backups and a rollback script should be prepared. Staff training sessions should be held before go-live.
应急计划必须应对数据迁移失败、支付网关故障和安全漏洞。应准备好每日数据库备份和回滚脚本。上线前应安排员工培训。
9. Testing Strategies | 测试策略
Testing is organised into four levels. Unit testing will validate individual functions, such as the password hashing algorithm and the stock deduction module, using a PHPUnit framework. Integration testing will check the interaction between the shopping cart and stock database, ensuring that adding an item to the cart does not lock the entire table.
测试分为四个层级。单元测试将验证各项独立功能，如密码散列算法和库存扣减模块，使用 PHPUnit 等框架。集成测试将检查购物车与库存数据库之间的交互，确保将商品添加到购物车时不会锁定整个表。
System testing will verify end-to-end scenarios: a guest user browses, registers, adds items, pays and receives a confirmation email. It will also test boundary values, e.g., ordering a quantity of 0 or a quantity exceeding stock. Performance testing will simulate 200 concurrent users to confirm response times stay under 3 seconds.
系统测试将验证端到端场景：访客浏览、注册、添加商品、支付并收到确认邮件。它还将测试边界值，例如订购数量为 0 或超过库存。性能测试将模拟 200 个并发用户，以确认响应时间保持在 3 秒以下。
User acceptance testing (UAT) will involve the owner, manager and a small group of real customers. They will be given realistic tasks and asked to report any issues. A test log will record each defect, its severity, and the developer responsible for fixing it.
用户验收测试（UAT）将邀请店主、经理和一小群真实客户参与。他们将完成真实任务并报告任何问题。将使用测试日志记录每个缺陷、其严重程度和负责修复的开发人员。
10. Security Measures | 安全措施
Security is paramount for an e-commerce system. All traffic will be encrypted using TLS 1.3. Passwords are stored using bcrypt with a per-user salt. Input fields will be sanitised to prevent SQL injection and XSS attacks: prepared statements with parameterised queries will be used for all database interactions.
安全对电子商务系统至关重要。所有流量将使用 TLS 1.3 加密。密码使用 bcrypt 和每用户独有的盐进行散列存储。输入字段将被净化以防 SQL 注入和 XSS 攻击：所有数据库交互将使用带参数化查询的预处理语句。
Authentication will include a lockout policy after five failed login attempts. Administrative interfaces will be restricted to whitelisted IP addresses and enforce two-factor authentication. A web application firewall (WAF) will monitor incoming traffic for malicious patterns. Regular penetration testing is scheduled every quarter.
身份验证将包含五次登录失败后的锁定策略。管理界面将限制为白名单 IP 地址并强制实施双因素认证。Web 应用防火墙（WAF）将监控传入流量中的恶意模式。计划每季度进行定期渗透测试。
Compliance with GDPR requires a lawful basis for data processing (consent for marketing emails, contract for order fulfilment). Customers must be able to request data deletion and opt out of tracking. A cookie consent banner will be implemented.
遵守 GDPR 需要为数据处理提供合法依据（营销邮件需获取同意，订单履行需履行合同）。客户必须能够请求删除数据并选择退出跟踪。将实现 cookie 同意横幅。
11. Evaluation and Maintenance | 评估与维护
Post-launch evaluation will measure the project against the original objectives. Quantitative metrics include: uptime percentage, average page load time, conversion rate (visitors to purchasers), and number of support tickets raised. Qualitative feedback will be gathered via a customer satisfaction survey.
上线后评估将对照原始目标衡量项目成效。定量指标包括：正常运行时间百分比、平均页面加载时间、转化率（访客到购买者）和提交的支持工单数。定性反馈将通过客户满意度调查收集。
Three types of maintenance are anticipated. Corrective maintenance will fix bugs discovered after launch. Adaptive maintenance may be needed if payment providers change their APIs or tax regulations are updated. Perfective maintenance will add features like product reviews or loyalty points based on user demand.
预计有三种类型的维护。纠正性维护将修复上线后发现的错误。若支付提供商更改其 API 或税务法规更新，可能需要进行适应性维护。完善性维护将根据用户需求添加功能，如产品评价或积分奖励。
The total cost of ownership should be reviewed annually, including hosting, SSL certificates, domain renewal and developer retainer fees. A mechanism for collecting user feedback and feature requests will help prioritise future work.
应每年审查总拥有成本，包括主机托管、SSL 证书、域名续费和开发人员聘用费。建立收集用户反馈和功能请求的机制将有助于确定未来工作的优先级。
12. Exam Tips for CCEA Case Studies | CCEA 案例研究的考试技巧
When tackling a case study question in the CCEA exam, read the scenario carefully and highlight all the constraints, stakeholders and existing systems mentioned. Structure your answer using the headings you have practised: feasibility, requirements, design, implementation and evaluation.
在 CCEA 考试中作答案例分析题时，请仔细阅读情境描叙，并标出所有提及的约束条件、利益相关者和现有系统。使用你已练习过的标题来组织答案：可行性、需求、设计、实施和评估。
Use technical vocabulary precisely. Instead of writing ‘secure the site’, write ‘implement bcrypt password hashing, TLS encryption and prepared statements to prevent SQL injection’. Justify every design choice with a reason linked to the case study constraints, such as ‘a phased rollout was chosen to minimise disruption to existing store operations’.
准确使用技术词汇。不要写「确保网站安全」，而应写「实施 bcrypt 密码散列、TLS 加密和预处理语句以防止 SQL 注入」。为每项设计选择提供与案例约束相关的理由，例如「选择分阶段推出是为了最大限度减少对现有门店运营的干扰」。
For higher marks, show the ability to consider trade-offs. For example, ‘while a native mobile app could offer a better user experience, the budget constraint means a responsive website is a more feasible choice in the short term’. Include simple diagrams in your answer if time permits, such as an ERD or a DFD fragment.
为获取更高分数，需展现权衡利弊的能力。例如，「虽然原生移动应用可提供更好的用户体验，但预算约束意味着响应式网站在短期内更为可行」。若时间允许，可在答案中绘制简单图表，如 ERD 或 DFD 片段。
Finally, always relate your technical solutions back to the needs of the business: ‘By implementing real-time stock sync, the system prevents customers ordering out-of-stock items, reducing complaints and improving trust in the brand.’
最后，务必将技术解决方案与业务需求联系起来：「通过实施实时库存同步，系统可防止客户订购缺货商品，从而减少投诉并提升品牌信任度。」
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课程辅导，国外大学本科硕士研究生博士课程论文辅导