企业官网建设流程全解析

简介：一份以好食上餐厅管理系统为完整案例的用例文档，面向软件工程学习者、系统分析师及项目前期需求梳理人员。文档从前言入手，依次覆盖编写目的、系统背景与内容概述，随后给出用例列表、用例图和用例描述三大核心模块，逻辑层次清晰，能够直接作为撰写同类需求文档的结构模板。在用例描述部分，资源对顾客资料管理、店内顾客订餐、电话订餐、网上订餐、账单结算、顾客反馈信息管理、连锁店管理等用例逐一展开，其中店内顾客订餐用例完整写出了名称、描述、前置条件、触发条件、基本流程、扩展流程及特殊要求，有助于读者理解用例各要素的含义和填法。文档末尾还附有总结与参考资料，服务教学演示、课程设计或企业项目文档编写等场景。资源包内含1个docx文件，文件大小约2.9MB，排版规整，目录可直接导航。该资源已被615人浏览学习，适合需要快速掌握用例文档规范写法的开发与需求人员参考。

1. 好食上餐厅管理系统用例文档：一份能直接照抄的需求范本

接手过软件工程课设、毕设或者刚进公司被丢进需求评审会的朋友，应该都有过这种感觉：拿到一份几十页的用例文档，不知道哪些字段是必须写的，也不知道自己系统的用例该拆多细。好食上餐厅管理系统这份用例文档，是 2010 年的课程设计产物，但它的框架放在今天依然能打——覆盖了店内点餐、电话订餐、网上订餐、顾客资料管理、账单结算、反馈管理和连锁店管理七大模块，用例编号、参与者、前置条件、正常流程、异常流程、特殊需求一应俱全。它能解决的不只是「交一份课设作业」，而是让你看到用例文档该怎么组织才能让评审老师挑不出毛病、让开发照着就能建表。适合正在写需求分析文档的学生、刚入行的产品助理，以及想规范团队需求流程的开发者。这篇笔记我会把它拆开，讲清楚每一节该写什么、哪些地方藏着坑，以及如何用这套用例反推数据库设计和测试用例。

2. 把用例文档拆成骨架：编号、参与者和流程字段的行业惯例

2.1 用例列表的编号逻辑：第一层是子系统，第二层是业务动作

这份文档的用例列表很有代表性，编号分两层：1.x对应店内业务，2.x对应电话订餐，3.x对应网上订餐，4.x对应客户资料管理，5.x对应账单处理，6.0和7.0单独管理反馈和连锁店。这种编号方式在软件工程课设里是主流做法，它的优点是看到编号就能定位到子系统，不用翻正文。

实际工作中我一般会再往后推一步：把编号和模块表对应起来。比如1.1店内顾客订单录入，对应的就是订单模块下的「收银台下单」功能；4.1分析账单维护顾客资料数据库，对应的就是客户模块下的「消费行为分析」任务。这样设计的好处是，后期做需求追踪矩阵时，每个用例编号都能直接映射到设计文档里的类和方法，评审时老师问到「这个编号怎么来的、对应哪个功能」，你能直接答上来，而不是支支吾吾。

这份文档有个小瑕疵：内容概述里写「文档包括 5 个用例」，但用例列表实际列了 18 项。文档里说的是 5 个大的用例类别，列表里是细分后的具体用例。这种「大类 + 子项」的写法没问题，但概述段应该写清楚「5 类用例、共 18 个具体场景」，否则评审容易抓这个漏洞。

2.2 参与者识别的三类角色：主参与者、辅助参与者、系统外部设备

文档里参与者写得很清楚：营业员、服务员、接线员、送货员、系统管理员、顾客。这是用例分析里最关键的一步——找对参与者，用例才不会跑偏。我拆这份文档时发现，它其实暗合了用例分析的经典套路：主参与者是发起用例的人，辅助参与者是被系统调用的人，外部设备是地图系统、网上银行这类系统边界之外的东西。

具体到这份文档，2.3获取最优外送路线里，送货员是主参与者，地图系统是外部设备；3.3获取网上顾客的订单里，顾客是主参与者，网上银行是外部设备。如果你在自己的系统里写用例，我建议把参与者单独抽一页写清楚，包括每个参与者的职责边界。这份文档没单独列参与者表，只能从每个用例里反推，读起来有点累，你可以做得更好。

2.3 用例描述的标准字段：前置条件、正常流程、异常流程缺一不可

这份文档的用例描述用了统一的模板：目标、产生原因、大概过程、输出结果、优先级、触发条件、前置条件、后置条件、正常流程、异常流程、相关用例、假设。这套字段就是用例描述的行业标配，尤其是前置条件、正常流程、异常流程这三项，评审老师基本必看。

我拿1.1店内顾客订单录入说，文档写「前置条件：有多余的营业员有时间来处理该订单」，这句话其实是废话——不够前置。前置条件应该是系统状态，而不是人员状态。正确写法是「账单信息数据库在线且可写」这类可验证的条件。另一个问题在异常流程：1.1的异常流程写「营业员发现订单信息不完备，让服务员重新向顾客咨询完善订单信息」，这个处理方式是对的，但它没有写「系统是否保留已输入的部分数据」。实际开发时，这种半截数据怎么处理，必须在异常流程里写清楚，否则程序员只能自己拍脑袋。

2.4 个性化菜单和高频词的场景化落地

拆完这份文档，我意识到「个性化」这个词出现了十几次：个性化菜单、个性化服务、个性化优惠。这就是这个餐厅系统的核心卖点，也是用例文档真正有价值的地方——它不是罗列功能，而是把「回头客」「优惠」「定制菜单」这些业务目标落到了具体的用例流程里。比如2.2提供个性化菜单供参考，写明了从接线员输入订餐信息到反馈个性化菜单必须控制在 1 秒内，这就是一个明确的性能需求，开发时就知道这个地方不能做重型计算，得走缓存或预计算。

3. 从用例到落地：菜单设计、订单流转和顾客资料三大模块的实战拆解

3.1 店内、电话、网上三通道订餐的流程差异与合并策略

这份文档最有意思的地方在于，它把同一个「订餐」场景拆成了三条用例线：店内、电话、网上。这三条线的主流程几乎一样——收集顾客信息、录入菜单、确认订单，但参与者、前置条件、异常流程差别很大。

店内订餐的主参与者是营业员，核心痛点是手工纸面订单录入效率低；电话订餐的主参与者是接线员，核心痛点是顾客信息要边聊边录、还要同步提供个性化菜单，文档里写了特殊需求「反馈时间控制在 1 秒内」；网上订餐的主参与者是顾客自己，核心痛点是网络异常导致的中断处理。

这三条线如果是我来做系统设计，会这样处理：店内和电话订餐共用一个订单录入接口，区别仅在于订单来源字段（order_source取store或phone）；网上订餐单独走一个面向顾客的接口，因为它的入参格式、校验逻辑和支付流程完全不同。用例文档里它们分开写没问题，但数据库设计阶段要提前想到「订单主表 + 来源字段」这种合并策略，否则后面会做出三张订单表，只能在 service 层做适配，维护成本直接翻倍。

3.2 顾客资料管理里的「待确定问题」：文档留口的正确姿势

4.1分析账单维护顾客资料数据库、4.2顾客分类提供优惠、4.3制定个性化菜单，这三条用例有一个共性：都写了「待确定问题」。比如4.1写「如何根据账单信息数据库提取出顾客资料还有待进一步确定」，4.3写「对于个性化菜单的具体内容还有待进一步确定」。

在课设文档里出现「待确定问题」是加分项，因为这说明你意识到了方案的不确定性，比假装一切确定要诚实。但这里有个边界——待确定问题不能太多。这份文档的4.x模块几乎每条都待确定，这会让评审产生「你是不是没做完」的怀疑。我的建议是：预留 1～2 个待确定问题，并且每个都给出候选方案，比如「计划采用会员等级 + 最近三个月消费频次来分类顾客，具体阈值待与客户确认」。这样既诚实，又显得你已经有思路。

3.3 账单处理的验证反向路径：余额核对和异常账目处理

1.4顾客账单录入并验证这个用例写得很细：营业员输入账单部分信息，系统反馈完整账单信息，营业员核实纸面账单与系统反馈一致，再保存。这个「输入-反查-核对-存储」的路径就是账单处理的核心逻辑。

系统设计时，1.4的验证逻辑可以落成这样：订单表和账单表分离，订单表存储顾客点的菜，账单表存储顾客最终要付的钱。1.4做的事情就是比对这两张表的金额是否一致，不一致走异常流程。如果你带着这个思路去读后面的5.1账单汇总结算，就会发现1.4是单张账单的校验，5.1是 N 张账单的汇总校验，两者一个是明细级、一个是汇总级，不能相互替代。很多新手会把这两个功能合并，导致明细账和汇总账对不上，这就是翻车点。

3.4 反馈信息管理的时间线和责任链

1.3顾客反馈信息收集是服务员在线下做的，1.5顾客反馈信息录入是营业员在系统里做的，6.1打印反馈信息报表是管理员做的。这条线是清晰的责任链：线下收集 → 系统录入 → 报表输出。

这里有一个可以优化的点：1.3和1.5之间隔了一个「纸质反馈表」的物理环节。实际项目里，与其让服务员收纸质表再让营业员录入，不如让服务员直接拿平板让顾客当场录入，省掉一次人工转录。但如果你做的是课设，保留纸质环节反而能多展示一个「反馈表设计」的产出物。系统的复杂度和文档的丰富度有时成正比，这个度需要你自己把握。

4. 按图索骥：把用例描述转换成字段清单、接口路径和测试场景

4.1 从每个用例提取数据字段，直接生成数据库表雏形

用例文档写得够细，数据库设计就能照抄。我拆1.1店内顾客订单录入和1.4顾客账单录入并验证的时候，顺手把字段清单拉出来了。下面这张表就是我从用例描述里提取出来的订单核心字段：

这套字段提取方法其实很机械：正常流程每出现一个「录入」「保存」动作，就至少有一个新字段；后置条件里的「被保存到账单信息数据库」，就是对主表的一次 INSERT 操作。顺着用例描述走一遍，核心表结构基本就有了雏形。唯一要注意的是item_list这种 JSON 字段，适合数据量小的中小系统；如果将来要按菜品维度做销售统计，我建议拆成 order_item 子表，一个订单多条记录，查询统计会快得多。

4.2 用例流程到接口路径的映射：一个正常流程对应一个接口分支

用例的正常流程可以视为接口的「happy path」，异常流程则是「error path」。拿2.1顾客订餐信息收集并录入来说，正常流程是「接线员接听 → 咨询信息 → 录入系统」，对应接口就是 POST/api/phone-order，入参是顾客资料和菜品列表，返回订单 ID 和个性化菜单。

拉一个接口清单长这样：

POST /api/orders/store # 1.1 店内顾客订单录入 POST /api/orders/phone # 2.1 电话订餐信息录入 POST /api/orders/web # 3.1 网上订餐信息录入 GET /api/menu/personalized # 2.2 / 3.2 个性化菜单查询 POST /api/bills/validate # 1.4 账单录入并验证 GET /api/bills/summary # 5.1 账单汇总结算 POST /api/feedbacks # 1.5 顾客反馈信息录入 GET /api/feedbacks/report # 6.1 打印反馈信息报表 POST /api/branches # 7.1 新增连锁店

逻辑说明：每个接口对应一个用例的触发条件和正常流程，接口粒度尽量和用例粒度一致，方便做需求追踪。参数说明：/api/orders/phone的入参包含customer_id、item_list、delivery_address，其中delivery_address是电话订餐独有字段，店内和网上订餐不需要。这一步做完后，后端开发的接口文档基本就有底了。

4.3 用例到测试用例的翻译：正常流程 + 异常流程 = 测试场景矩阵

用例文档能直接用，在写测试用例时体现得最明显。每个正常流程是一组正向测试用例，每个异常流程是一组反向测试用例。用1.4顾客账单录入并验证来演示：

# test_bill_validate.py def test_bill_validate_normal(): """正常流程：输入部分账单信息，系统反馈完整账单，核对一致后保存""" bill = {"order_id": "20241101001", "paid_amount": 128.50} resp = client.post("/api/bills/validate", json=bill) assert resp.status_code == 200 assert resp.json["status"] == "verified" assert resp.json["bill_amount"] == 128.50 def test_bill_validate_amount_mismatch(): """异常流程 3a：纸面账单与系统账单金额不符""" bill = {"order_id": "20241101001", "paid_amount": 99.00} resp = client.post("/api/bills/validate", json=bill) assert resp.status_code == 400 assert resp.json["error_code"] == "AMOUNT_MISMATCH"

逻辑说明：第一个用例对应正常流程第 3 步「营业员核实纸面账单与系统反馈账单信息一致」，第二个用例对应异常流程第 3a 步「餐费或纸面账单与系统账单不符」时的系统响应。参数说明：AMOUNT_MISMATCH这个错误码需要后端提前定义，测试用例写起来才有依据。实际上，写测试用例的过程经常会反推需求——比如1.4里没写金额不一致时营业员能不能强制提交，我一般是禁止强制提交，走「作废重录」的逻辑，这也是这套用例文档留出的设计空间。

5. 用例文档避坑指南：从编号到流程的五条高频翻车记录

5.1 概述说 5 个用例，列表列出 18 个：数字对不上

现象：文档 2.2 内容概述写「文档包括 5 个用例」，但 3 节的用例列表实际列了 18 个，评审一眼就看出矛盾。

原因：作者把「5 个用例类别」和「18 个具体用例场景」混为一谈了。内容概述里说的是大类，列表里展示的是细项，中间没有过渡说明。

解决：概述段改成「本文档包含 5 个用例类别（店内订餐、电话订餐、网上订餐、顾客资料管理、账单处理等），细化后共 18 个具体用例」；或者列表只列 5 个顶级编号，细分场景放到用例描述节里展开。无论选哪种，数字要全文一致，我一般在文档初稿完成后专门抽 10 分钟全局搜索数字。

5.2 相关用例循环引用：1.1 关联 1.2，1.2 又关联 1.1

现象：1.1店内顾客订单录入的相关用例写了1.2、1.3，1.2查看顾客资料给予个性化服务的相关用例又写了1.1、1.3，1.3又引用回1.1、1.5，形成环形依赖。

原因：用例之间确实存在业务上的顺序关系——先录订单才能查看顾客资料，结账后才能收反馈——但「相关用例」这个字段的本意是让读者找到与本用例有扩展或包含关系的其他用例，不是业务时间线。所有用例都两两相关，就等于没有相关用例。

解决：写相关用例时只保留「语义相关」的，典型的是包含关系（include）和扩展关系（extend）。2.1电话订餐录入包含2.2个性化菜单查询，这样写才有价值。普通的时间先后不该写进相关用例。我在课设评审时见过最夸张的文档，7 个用例的相关关系画出来是一张全连通图，评委只是摇了摇头，别学它。

5.3 前置条件写成人员状态：无法验证也无法测试

现象：1.1前置条件写「有多余的营业员有时间来处理该订单」，1.3前置条件写「顾客愿意填写反馈信息」——这些都是人话，但系统没法判断。

原因：作者没有区分「业务前置条件」和「系统前置条件」。人员有空、顾客愿意，属于业务层面的现实情况，不是系统能感知的状态。

解决：前置条件只写系统可以验证的内容，比如「账单信息数据库在线」「网上订餐平台运行正常」「顾客已登录且会话有效」。人员状态可以通过用例假设来写——文档末尾的「假设营业员懂得对系统操作」就是处理这个问题的正确方式。如果你在前置条件里写「顾客已通过网银完成支付」，那测试用例就能直接 validate 支付状态字段，而不是 mock 一个「顾客愿意」的布尔值。

5.4 特殊需求只有性能指标，没有具体数值上下文

现象：2.2写「反馈个性化菜单的时间必须控制在 1 秒之内」，3.2写「必须控制在 1.5 秒之内」，但没说这个 1 秒是从哪个动作开始计时的。

原因：特殊需求描述过于简洁，从「接线员输入信息」到「菜单显示」的起点不明确，不同人理解可能差异很大。

解决：把计时窗口写清楚——「从接线员提交完整顾客信息的最后一个字段起，到个性化菜单在接线员界面完整渲染止，耗时不得超过 1000ms」。如果有性能测试报告，直接把压测条件也写上，比如「100 并发用户下，95% 请求在 800ms 内返回」。评审看到这种写法，第一反应是「这人真的有工程经验」，而不是「这数值是不是拍脑袋定的」。

5.5 异常流程写的方案不可执行：一句「重新开始」无法落地

现象：多个用例的异常流程都写「重新从步骤 1 开始执行」，但没说系统里已有的数据怎么处理。网页端顾客取消了订餐，那购物车里已选的菜要不要清空、半填的信息要不要暂存？文档没有答案。

原因：异常流程描述停留在业务层面，没有落到数据和状态层面。课设文档常见，但这个问题会导致开发时怎么实现都对不上需求。

解决：异常流程要写「状态回退规则」。我一般建议这样写：「若顾客在支付确认前取消，当前订餐会话状态置为 CANCELLED，已填写字段保留 30 分钟，供顾客下次进入时恢复；若超出保留期则清空会话」。这条实话实说，是我在真实项目里被问过无数次的细节——用例里不写，开发就会用 0 和 1 的幂等方案解决，用户体验怎么样全看运气。

6. 用例文档的三种进阶验收：需求追踪矩阵、CRUD 检查和异常流程补全

文档写到这份上，基本的结构和套路你已经掌握了，但如果想让这份用例文档更像「需求规格说明书」而不只是「课设作业」，我建议做三个进阶动作，每个都不难，却能显著拉高文档的完成度。

第一个动作是建需求追踪矩阵。把每个用例编号和设计文档里的类、数据库表列一份对照表。做完了放在文档附录里，评审问起「某一条需求对应哪张表哪个字段」，你可以直接翻到附录回答。以这份餐厅系统为例，1.1对应Orders表和OrdersController.create()，4.1对应CustomerProfile表的update_grade方法，7.1对应Branches表的insert操作。表格可以是四列：用例 ID、用例名称、设计模块、数据库表。这份矩阵一旦建好，后续开发时不至于漏掉需求。

第二个动作是执行 CRUD 检查——遍历一遍你的用例，看有没有只写了 Create 和 Read、漏了 Update 和 Delete 的场景。这份餐厅文档就是一个典型的偏科案例：连锁店管理写了新增、关闭、查看、打印报表，覆盖了 C/R/U/D 的前三个；顾客反馈信息管理只写了收集和录入，没有修改、删除和查询单条反馈详情的用例；顾客资料管理里顾客自己更新手机号、修改收货地址的场景完全没有留位置。我建议把漏掉的场景补齐，每块业务模块至少保证有一套完整的增删改查用例，这才是闭环。

第三个动作是给核心用例补一条「状态流转描述」。1.1到1.4的订单，状态变化可以画成一条线：草稿 → 已确认 → 已结算 → 已归档。每个状态由哪个用例触发、谁能触发、状态之间允不允许回退，在用例描述里补一小段就行。写到这里你也许发现了，我反复在强调同一件事——用例文档写得好不好，不是看格式多标准、字段多齐全，而是看它能不能让开发人员不加脑补就能实现。这份餐厅用例文档，格式上是合格的模板，细节上有不少可以商榷的地方，但正因如此，它才值得拆开来看。

我希望你拿到这份文档后，不只把它当作一份课设参考，而是试着做我刚才说的三个动作：建一次追踪矩阵、补一轮 CRUD、写一组状态流转。做完之后你再看任何一份需求文档，眼光都会不一样。从那以后，我每次拿到用例文档，都会强制自己先做一遍这三个动作再开工——光这一点，就帮我避开了好几次需求理解偏差的返工。希望帮到你。

本文还有配套的精品资源，点击获取