📚 Case Study in Action: Mastering System Analysis for AS CCEA Computer Science | 案例分析实战演练：掌握 AS CCEA 计算机系统分析
Case study questions are a crucial part of the AS CCEA Computer Science assessment. They require you to step into the role of a systems analyst, applying your knowledge of the software development lifecycle to a real‑world scenario. In this article we will work through a complete case study for a small independent bookstore, demonstrating step by step how to break down the problem, capture requirements, design a solution, and plan for testing and evaluation. Follow this walkthrough to build confidence for your exam.
案例分析题是 AS CCEA 计算机科学考核的关键部分。它要求你扮演系统分析员的角色，将软件开发生命周期的知识应用于真实场景。本文将完整演练一家小型独立书店的案例，逐步展示如何分解问题、捕获需求、设计解决方案以及制定测试与评估计划。跟随这次演练，为你的考试树立信心。
1. Understanding the Case Study | 理解案例背景
Imagine a small bookstore called ‘Chapter One’. Currently the owner uses a handwritten ledger to track stock and sales. This is time‑consuming and error‑prone. The business wants a computerised system that can keep an accurate inventory, process customer purchases, and produce daily sales summaries. The owner also needs a low‑stock alert to reorder popular titles before they run out.
设想一家名为 ‘Chapter One’ 的小书店。目前店主用手写账本记录库存和销售，既费时又容易出错。该企业需要一个计算机化系统，能够准确管理库存、处理顾客购买并生成每日销售汇总。店主还需要缺货提醒功能，以便在畅销书售罄前及时补货。
As an analyst your first task is to identify the stakeholders and describe the current system’s limitations. The primary stakeholder is the owner, who will use the system daily. The secondary stakeholders are the customers, who expect a smooth checkout experience. The existing manual system suffers from data inconsistency, slow retrieval, and an inability to generate timely reports.
作为分析员，你的首要任务是识别利益相关方并描述当前系统的局限。主要利益相关者是每日使用该系统的店主。次要利益相关者是顾客，他们期望顺畅的结账体验。现有手工系统存在数据不一致、检索缓慢以及无法及时生成报告的问题。
2. Identifying Functional Requirements | 识别功能需求
Functional requirements define what the system must do. For the Chapter One bookstore we can list several core features derived from the owner’s needs.
功能需求定义了系统必须做什么。根据 Chapter One 书店的需要，我们可以列出以下核心功能。
The system must allow the user to add a new book to the inventory with details such as ISBN, title, author, price, and initial stock quantity. It must also support updating and deleting existing book records.
系统必须允许用户向库存中添加新书，相关细节包括 ISBN、书名、作者、价格和初始库存数量，同时必须支持更新和删除现有的书籍记录。
A key requirement is processing a sale. When a customer buys one or more books, the system should deduct the sold quantity from the stock, calculate the total cost, and store the transaction. Search functionality is essential: the owner should be able to find a book by entering an ISBN, a partial title, or an author name.
一个关键需求是处理销售。当顾客购买一本或多本图书时，系统应扣除相应的库存数量，计算总价并存储交易记录。搜索功能必不可少：店主应能通过输入 ISBN、部分书名或作者姓名来查找图书。
The system should generate a low‑stock alert whenever the quantity of any book falls below a predefined threshold, for example 5 copies. Finally, a daily sales report must be produced, summarising the number of sales, total revenue, and best‑selling titles.
当任意图书的数量低于预定阈值（例如 5 本）时，系统应生成缺货提醒。最后，必须生成每日销售报告，汇总销售笔数、总收入和最畅销的书目。
3. Non‑Functional Requirements | 非功能需求
Non‑functional requirements describe how the system should behave. They are just as important as functional requirements in a case study answer.
非功能需求描述系统应如何表现，在案例分析答案中它们与功能需求同样重要。
The system must respond to any search query within 2 seconds, ensuring the owner does not wait during busy periods. It should be usable by a person with basic IT skills, meaning the interface must be intuitive and avoid technical jargon. All data must be protected: sales figures and stock costs should only be accessible after a password‑based login. The software must run on the shop’s existing Windows PC with at least 4 GB of RAM and 100 MB of free disk space.
系统必须在 2 秒内响应任何搜索查询，确保店主在繁忙时段无需等待。系统应可供具备基本 IT 技能的人使用，这意味着界面必须直观并避免技术术语。所有数据必须受到保护：销售数据和库存成本只有在基于密码登录后才可访问。软件必须能在商店现有的 Windows PC 上运行，该电脑至少拥有 4 GB 内存和 100 MB 可用磁盘空间。
4. Data Modelling with Entity‑Relationship Diagrams | 实体关系图数据建模
To design a database we start by identifying the main entities and the relationships between them. In this case study three entities stand out: BOOK, SALE, and SALELINE. A SALE consists of one or more SALELINE records, and each SALELINE refers to exactly one BOOK.
要设计数据库，我们从识别主要实体及其关系入手。本案例中有三个明显的实体：BOOK（图书）、SALE（销售）和 SALELINE（销售明细）。一次 SALE 包含一条或多条 SALELINE 记录，每条 SALELINE 恰好对应一本 BOOK。
The BOOK entity stores attributes such as ISBN (primary key), Title, Author, Price, and QuantityInStock. SALE includes SaleID (primary key), SaleDate, and TotalAmount. SALELINE acts as a link table with composite primary key (SaleID, ISBN) and additional attributes QuantitySold and UnitPrice. The relationships are one‑to‑many from BOOK to SALELINE and from SALE to SALELINE.
BOOK 实体存储属性如 ISBN（主键）、书名、作者、价格和库存数量。SALE 包含 SaleID（主键）、销售日期和总金额。SALELINE 作为链接表，拥有复合主键（SaleID, ISBN）以及附加属性销售数量和单价。关系分别为 BOOK 到 SALELINE 的一对多，以及 SALE 到 SALELINE 的一对多。
5. Database Design & Normalisation | 数据库设计与规范化
We now translate the ER model into a set of normalised tables. The following table definitions comply with Third Normal Form (3NF), eliminating redundancy.
现在我们将 ER 模型转换为一组规范化表。以下表定义符合第三范式 (3NF)，消除了冗余。
| Table Name | Attributes (Primary Key underlined) | Description |
|---|---|---|
| Book | ISBN, Title, Author, Price, QuantityInStock | Stores book details and current stock level. |
| Sale | SaleID, SaleDate, TotalAmount | Records each transaction header. |
| SaleLine | SaleID, ISBN, QuantitySold, UnitPrice | Records each line item in a sale. |
Notice that the Book price is stored only once in the Book table. The SaleLine table captures the UnitPrice at the time of sale, which allows prices to change without affecting historical transactions. The TotalAmount in the Sale table is a calculated field derived from the sum of (QuantitySold × UnitPrice) for all associated SaleLine rows; it is stored to speed up daily reporting.
请注意，图书价格仅在 Book 表中存储一次。SaleLine 表捕获销售时的单价，这使得价格可以变更而不影响历史交易。Sale 表中的总金额是根据所有相关 SaleLine 行汇总（销售数量 × 单价）计算得出的字段；存储此字段可以加速每日报告。
6. Algorithm Design with Pseudocode | 伪代码算法设计
Examiners may ask you to write pseudocode for a key process. Below is the algorithm for processing a sale, updating stock, and creating the required records.
考官可能要求你为关键过程编写伪代码。以下是处理一次销售、更新库存并创建相应记录的算法。
PROCEDURE ProcessSale(CustomerBuysList)
LET NewSaleID ← GenerateNextSaleID()
LET Total ← 0
FOR EACH Item IN CustomerBuysList DO
SEARCH Book WHERE ISBN = Item.ISBN
IF Book NOT FOUND OR Book.QuantityInStock < Item.Qty THEN
DISPLAY “Sale cannot complete for ” + Item.ISBN
RETURN
ENDIF
LET LineCost ← Book.Price × Item.Qty
INSERT INTO SaleLine VALUES(NewSaleID, Item.ISBN, Item.Qty, Book.Price)
UPDATE Book SET QuantityInStock ← QuantityInStock – Item.Qty
Total ← Total + LineCost
END FOR
INSERT INTO Sale VALUES(NewSaleID, TODAYSDATE, Total)
DISPLAY “Sale completed. Total: ” + Total
END PROCEDURE
The pseudocode begins by generating a unique SaleID and initialising a total accumulator. For each item in the customer’s basket it validates book existence and stock sufficiency, creating a SaleLine record, decrementing stock, and updating the running total. After the loop a Sale header is inserted. This ensures data integrity and prevents partial sales.
伪代码首先生成唯一的 SaleID 并初始化总金额累加器。对于顾客购物篮中的每一项，它验证图书是否存在且库存充足，创建 SaleLine 记录，扣减库存并更新累加总和。循环结束后插入 Sale 表头。这确保了数据完整性并防止部分销售发生。
7. User Interface Mockup | 用户界面原型
A simple, text‑based menu is often sufficient for AS‑level case studies. The following main menu structure shows how the functional requirements map to menu options.
对于 AS 阶段的案例分析，一个简单的文本菜单通常就足够了。以下主菜单结构展示了功能需求如何映射到菜单选项。
MAIN MENU
1. Add a new book
2. Update book details
3. Delete a book
4. Search for a book
5. Process a sale
6. Generate daily sales report
7. Low‑stock alert
8. Exit
主菜单
1. 添加新书
2. 更新图书详情
3. 删除图书
4. 搜索图书
5. 处理销售
6. 生成每日销售报告
7. 缺货提醒
8. 退出
Each option presents a dedicated screen. For instance, the ‘Search for a book’ screen asks the user to choose a search criterion (ISBN, title, or author) and displays matching records in a table. The ‘Process a sale’ screen accepts a list of ISBNs and quantities, then calls the ProcessSale procedure. Consistency in screen layout reduces the user’s learning curve.
每个选项提供一个专用界面。例如，“搜索图书”界面要求用户选择搜索依据（ISBN、书名或作者），并以表格形式显示匹配记录。“处理销售”界面接受 ISBN 和数量列表，然后调用 ProcessSale 过程。一致的屏幕布局降低了用户的学习成本。
8. Testing Strategy | 测试策略
A thorough testing plan should cover normal, boundary, and erroneous data. Below is a sample test table for the search by ISBN function.
完善的测试计划应覆盖正常数据、边界数据和错误数据。以下为按 ISBN 搜索功能的测试表样例。
| Test ID | Input | Expected Outcome | Type |
|---|---|---|---|
| T1 | ISBN “978-3-16-148410-0” | Book details displayed | Normal |
| T2 | ISBN of a book with 0 stock | Details shown, stock zero | Boundary |
| T3 | ISBN not in database | Message “Book not found” | Error |
| T4 | Empty string | Message “Please enter ISBN” | Error |
For the sale process, boundary testing includes buying the last copy of a book and buying one more than the available stock. Erroneous testing covers negative quantities and non‑numeric inputs. Each test should be traceable to a specific functional requirement.
对于销售流程，边界测试包括购买最后一本书以及购买数量超过可用库存。错误测试涵盖负数量和非数字输入。每个测试都应可追溯到具体的功能需求。
9. Evaluation & Maintenance | 评估与维护
After implementation the system must be evaluated against the original requirements. Does it reduce the time to search for a book? Can it generate a correct daily report? The owner should be involved in acceptance testing, providing feedback on usability and accuracy.
实施后，必须根据原始需求评估系统。它是否缩短了搜索图书的时间？能否生成正确的每日报告？店主应参与验收测试，并就可用性和准确性提供反馈。
No system is static. Maintenance tasks include correcting bugs discovered after deployment (corrective maintenance), adapting the software when the shop introduces new product categories like magazines (adaptive maintenance), and improving the low‑stock algorithm to suggest optimal reorder points based on sales velocity (perfective maintenance).
没有系统是静止不变的。维护任务包括修正部署后发现的错误（改正性维护）、当商店引入杂志等新品类时对软件进行适应性修改（适应性维护），以及改进缺货算法，根据销售速度建议最佳补货点（完善性维护）。
10. Common Exam Pitfalls | 常见考试陷阱
Many students lose marks by listing only functional requirements and forgetting non‑functional constraints such as response time and security. Always read the scenario carefully for implied constraints – for example, a bookshop owner who is ‘not very technical’ signals a need for a simple interface.
许多学生因只列出功能需求而忘记响应时间和安全性等非功能约束而失分。务必仔细阅读场景中隐含的约束——例如，一位“不太懂技术”的书店老板就暗示需要简单的界面。
Another common mistake is designing a database without considering data integrity. Failing to specify a composite primary key for SaleLine could allow duplicate entries. Also, remember that calculated values like TotalAmount should not generally be stored unless there is a clear performance reason; in this case we stored it for faster reporting, but you must justify the decision.
另一个常见错误是设计数据库时未考虑数据完整性。没有为 SaleLine 指定复合主键可能导致重复条目。此外，请记住，除非有明确的性能理由，像 TotalAmount 这样的计算值通常不应存储；在此案例中我们为加速报告而存储，但你必须说明理由。
When writing pseudocode, avoid vague instructions. Use clear assignment arrows, proper indentation, and explicit error checking. Label loops, conditions, and procedure names clearly. An incomplete sale transaction that leaves the database in an inconsistent state is a severe design flaw that examiners watch for.
编写伪代码时，避免含糊的指令。使用清晰的赋值箭头、正确缩进和明确的错误检查。清楚地标注循环、条件和过程名。导致数据库处于不一致状态的不完整销售交易是考官会重点关注的严重设计缺陷。
11. Putting It All Together – Exam Technique | 综合实战——考试技巧
In the exam, you might be presented with a similar scenario and asked to produce selected design artifacts. Start by underlining key verbs in the question: ‘state’, ‘describe’, ‘design’, ‘evaluate’. Structure your answer with clear headings, mirroring the sections in this walkthrough. This makes your response easier for the examiner to mark and demonstrates a methodical approach.
在考试中，你可能会遇到类似的场景，并被要求输出特定的设计产物。首先划出题目中的关键词：“陈述”、“描述”、“设计”、“评估”。使用清晰的标题组织答案，与本文演练的章节相对应。这能让阅卷人更容易评分，并展示出有条理的方法。
Always provide a justification for design decisions. For example, when you choose a particular data type for the Price field, explain why a float or currency type is appropriate rather than an integer. Linking your decisions back to the case study shows deep understanding and lifts your answer to the highest mark band.
始终为设计决策提供理由。例如，当你为 Price 字段选择特定数据类型时，解释为什么浮点型或货币型比整型更合适。将决策与案例背景联系起来，能展示深入理解，并将你的答案提升到最高分数段。
12. Final Thoughts | 结语
Case study questions are not simply about recalling facts; they require you to synthesise knowledge across the whole AS specification. By practising with a structured approach – understanding the scenario, specifying requirements, modelling data, designing algorithms, and planning tests – you will develop the analytical muscles needed to tackle any scenario the exam board sets.
案例分析题不仅仅考察记忆事实，它们要求你综合运用整个 AS 规范中的知识。通过结构化方式的练习——理解场景、明确需求、数据建模、算法设计及测试计划——你将培养出应对考试局设定的任何场景所需的分析能力。
Use this walkthrough as a template, but remember that every case study has unique details. Adapt the techniques shown here to fit the specific business, users, and constraints described in your question. With focused practice, you can turn the case study from a daunting task into a confident, high‑scoring part of your exam.
将本演练作为模板使用，但请记住每个案例都有独特细节。灵活运用这里展示的技巧，以适应题目中描述的特定业务、用户和约束。通过专注练习，你可以将案例分析从令人生畏的任务转变为考试中充满自信的高分板块。
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课程辅导，国外大学本科硕士研究生博士课程论文辅导