1. 从“酒店+摄像头”到“视觉AI场景”：这份需求分析究竟在分析什么
1.1 项目背景与课程任务的真实目标
看到这个题目，很多人的第一反应是“酒店+视觉AI，不就是刷脸入住、客人来了自动开灯吗？”说实话，最初我调研时也是这么想的，但真正动手写《需求分析说明书》之后才明白，这门课作业要求我们完成的不是“产品概念秀”，而是一份能被后续设计、开发、测试直接引用的工程文档。
这份作业的核心目标有三层：第一，训练我们识别真实业务场景中“谁在什么情况下需要什么东西”；第二，掌握需求建模工具（用例图、类图、状态图、活动图等）的使用时机；第三，学会把模糊的“AI能力”翻译成清晰的、可验证的功能需求和非功能需求。理解了这三层目标，你才不会把说明书写成“功能堆砌表”。
酒店行业的视觉AI需求其实很典型。一间中端连锁酒店，日常运营存在大量重复性、低效率的巡检和响应工作。比如：走廊是否有异常物品遗留、公共区域是否存在跌倒或聚集、客房清洁状态能否自动感知、前台排队长度是否超过阈值。这些场景都适合用摄像头+算法去辅助，但“适合用算法”不等于“可以直接做”，还要考虑成本、隐私、部署周期、与现有系统的集成难度。需求说明书就是要把“适不适合”变成“要不要做、做到什么程度”。
1.2 视觉AI在酒店场景的能力边界与需求来源
我最初犯过一个错误：把视觉AI想得太万能。后来在调研中发现，酒店场景里视觉AI真正成熟、可落地、且有明确业务价值的点其实相对集中。
我整理了一张“能力-需求”对照表，把能做的图像识别能力与酒店业务诉求做映射。注意，这里的“识别能力”不能直接写成需求，必须找到具体的业务触发点和动作响应。比如：
| 视觉AI能力 | 对应的酒店业务诉求 | 可量化的需求描述 |
|---|---|---|
| 人员检测与数量统计 | 公共区域聚集预警、前台排队监测 | 当大堂某区域人数超过设定阈值时，系统应在2秒内推送预警信息 |
| 物体遗留检测 | 走廊、消防通道异物监测 | 检测到包裹、推车等遗留物超过3分钟，自动通知安保人员 |
| 区域占用状态识别 | 客房“请勿打扰”状态辅助核实 | 结合门磁与图像识别，判断客房是否有人占用，辅助保洁排班 |
| 行为识别（跌倒、倒地） | 公共区域安全监控 | 检测到跌倒姿态时，第一时间联动报警和后台人工复核 |
你会发现，每条需求都必须有一个“检测到什么→触发什么动作→多长时间内完成→通知谁”的完整链路。单纯写“系统要具备人员检测能力”是没有意义的，因为检测本身不产生业务价值，产生价值的是检测后的响应。
需求来源方面，我用了三轮调研。第一轮是阅读行业报告和酒店运营管理资料，搞清楚酒店各部门的KPI和痛点；第二轮是访谈了3位不同岗位的从业者（一位店长、一位客房主管、一位前台员工），用半结构化访谈收集原始诉求；第三轮是实地观察一家酒店两个小时的日常运作，记录了走廊巡查、退房清洁、大堂客服等流程。三轮下来，我才敢说需求来源是“有据可查”的。
1.3 我选定的业务场景与需求范围
项目范围如果不能控制，需求说明书就会失控。我们小组一开始列了十多个潜在场景，包括客人表情情绪分析、菜品识别、员工工作服检测等。后来按照“业务价值高、技术可行性强、数据隐私风险低、开发成本可控”四个维度打分，最终保留三个核心场景，并围绕它们开展后续建模：
- 入住客流与排队监测：主要服务前台和大堂经理，用于动态调度人力。
- 公共区域遗留物检测：主要服务安保部和保洁部，用于减少安全隐患。
- 客房占用状态辅助识别：主要服务客房部，用于优化保洁排班和布草配送。
这三个场景不是随意选的，它们刚好覆盖了“人员管理、物品管理、空间管理”三类酒店运营要素，而且都能用摄像机视觉AI实现——不需要额外传感器，也不涉及对客人面部特征的精细识别，隐私争议较小。范围确定后，我在说明书中专门加了一节“范围与假设”，明确说明“本系统不进行人脸身份识别，不存储原始图像超过留存期限，不做情绪分析”，这一步在评审时帮我挡掉了不少“隐私怎么办”的问题。
2. 需求获取阶段：比“问用户想要什么”更有效的几个动作
2.1 利益相关者地图：从店长到保洁员都要覆盖
很多人在做需求分析时习惯只访谈甲方负责人，认为“领导说的就是需求”。但酒店视觉AI项目的用户非常分散：店长关注的是运营数据和管理效率；前台关心的是系统会不会增加操作负担；安保担心的是误报率太高导致狼来了效应；保洁员则会担心“是不是用来监控我们干活的”。如果你不清楚每类利益相关者的立场和顾虑，写出来的需求很可能在评审阶段被某个角色一句话推翻。
我当时画了一张利益相关者地图，按照“对项目的影响程度”和“受项目影响程度”两个维度做了四象限分类。结果表明，除了出资决策的店长外，客房主管和夜班安保是影响最大的两类人——客房主管直接决定保洁排班是否接受系统建议；夜班安保是遗留物检测功能的主要使用者，如果他们觉得系统不可靠，整个功能就会形同虚设。
访谈的时候要注意，不要问“你觉得AI能做什么”，而要问“你每天最烦心的三件事是什么”“遇到客人投诉最多的是哪类问题”。保洁阿姨可能会说“下午退房太集中，根本扫不过来”，这个痛点你听了就能联想到“客房占用状态识别”的排队优化场景。利益相关者分析的意义就在于此，它不是一张给人看的图，而是帮你找到“真实需求藏在谁那里”的寻宝图。
2.2 现场观察法：看不到流程就画不出真需求
访谈只能得到“对方愿意告诉你的事”，但很多业务流程细节，当事人自己都已经到了“有意识盲区”的地步。比如前台主管说“我们高峰期排队大概五六个人”，但实际上高峰期队伍可能排到旋转门附近，且因为开票、问路等原因，每个人耗时差异很大。这些细节，只能靠现场观察去补齐。
我带着笔记本在某酒店大堂站了两个小时，记录了下午4点到6点退房高峰期的完整队列变化。最关键的一个发现是：前台大厅的摄像头视角并不像我们想象中那么理想——吧台遮挡、客人站姿、行李箱堆放，都会影响人员计数的准确性。这个观察直接改变了我的需求设计：在“客流排队监测”的用例规约里增加了“检测区域由人工在管理端绘制，可避开固定遮挡物”的扩展需求。如果没有实地观察，这个需求很可能要等到开发完成、现场测试时才会暴露。
另外，我还在保洁层走廊观察了清洁用品车的停放位置和遗留物巡检路线。传统的安保巡检是“定时定点看一圈”，而视觉AI可以做到“全时段全区域覆盖”。但保洁人员告诉我，物品车停在走廊中间是正常的，因为需要随时取用；如果系统把所有“停着的车”都当遗留物报警，保安会被烦死。于是“遗留物检测”业务规则里必须增加“时间阈值可配置”和“白名单区域设置”两项需求。这就是观察带来的专业度。
2.3 需求冲突的优先级处理
需求冲突是必然的。我们项目里最典型的一个冲突是“识别准确率与响应速度”之争。安保部门希望“遗留物检测”必须在物品出现后1分钟内报警，避免安全隐患；但技术团队评估后认为，要在高人流区域达到低误报率，至少需要观察该物品2-3分钟才能做出稳定判断——1分钟就报警会把很多人短暂停留的包、伞等误判为遗留物。
这个冲突不能靠甲方拍脑袋，要拿出数据来折中。我查阅了同类安防系统的经验值，给出了一个“分区域差异化”的方案：消防通道、楼梯前室等高风险区域设置为1分钟报警加二次人工复核；客房走廊等中风险区域设置为3分钟报警阈值；大堂等混杂区域默认5分钟并支持动态调整。同时增加了一个“置信度反馈机制”——当算法识别为遗留物的置信度低于90%时，系统不直接报警，而是推送一张截图给安保人员快速确认。
处理冲突的最高原则是“回到业务目标”。我们的目标不是“证明AI准确率高”，而是“降低安全事件发生率、同时不增加员工工作负担”。把目标摆正后，很多争论都能迅速收敛。我在需求说明书中单列了“优先级排序规则”，明确按“安全类>效率类>体验类”排序，并按MoSCoW法划分了Must、Should、Could、Won't四个等级。这样评审会上即使有人提出新需求，也能快速归类，而不是毫无原则地往文档里塞。
3. 需求建模：从用例图到类图的层层拆解
3.1 用例图：把“AI识别”变成有业务价值的用例
建模最怕的是“为了画图而画图”。我见过很多同学把“识别客人”“分析图像”这类技术动作当作用例，结果画出来的用例图根本没法指导设计。正确做法是：用例必须是一个“业务用户可以感知到的完整目标”，而不是一个“算法功能”。
以我们的“遗留物检测”场景为例，正确的用例名称应该是“处理走廊遗留物预警”，而不是“运行遗留物检测算法”。参与该用例的Actor包括：安保值班员（主角色）、系统计时器（次触发角色）、可能的保洁员（被通知角色）。用例的主流程是：系统检测到遗留物→生成预警事件→通知安保值班员→安保人员通过平台查看实况截图和位置→前往现场确认→在系统内标记处理结果。整个过程才是业务完整闭环。
顺序上我建议先画“用例图”再细化“用例规约”，因为用例图能帮你确认“系统边界”画在哪里。比如，我们的系统要不要对接酒店的PMS（物业管理系统）？如果要，客房状态识别就多了一个外部接口用例；如果不要，那就需要考虑“人工输入房态”的替代流程。建模阶段想清楚边界，后面的数据字典和接口需求都能少走弯路。
3.2 用例规约：预条件、主流程与异常流的撰写套路
用例图只是骨架，用例规约才是血肉。一份合格的用例规约至少要包含：用例编号、用例名称、参与者、前置条件、后置条件、主成功场景、扩展流程、异常流程、业务规则。很多同学写到这里就开始“编”，导致后置条件和前置条件自相矛盾。我的经验是：写规约前先写下“一句话版本”，比如“当监控区域内出现物品并持续停留超过设定时间后，系统生成预警并通知安保人员确认”，然后围绕这句话拆流程。
以“客流排队监测”为例，我写的主流程是：
- 系统实时获取检测区域内图像帧。
- 算法计算区域内人数及排队长度。
- 人数超过预设阈值时，系统生成“排队拥堵事件”。
- 事件展示在前台管理端和大堂经理移动端。
- 店长或大堂经理确认事件并启动加开窗口流程。
异常流程则要覆盖：摄像头断线、算法服务重启、人数在阈值临界抖动、多人路过导致误计数等。其中最麻烦的是“人数在阈值临界抖动”的需求描述，我最后给出的业务规则是：采用连续3帧平均人数作为判断依据，且事件触发后维持至少5分钟才解除预警，防止频繁报警。这个细节如果不写进用例规约，开发阶段一定会扯皮。
3.3 领域类图与状态图：需求分析的落地骨架
除了用例图，需求说明书里还应有一套“领域模型”，用来表达业务概念及之间的关系。做酒店视觉AI项目时，我设计了几个核心类：Camera（摄像头）、DetectionZone（检测区域）、AlertEvent（预警事件）、SystemUser（系统用户）、AlertRule（预警规则）。这几个类之间的关系很清晰：一个Camera可以关联多个DetectionZone，一个DetectionZone可以关联多个AlertRule，一个Camera产生的图像帧经过算法处理后生成AlertEvent。
画类图时我特别注意了“业务规则应当体现在方法或属性约束中”。例如AlertRule需要有一个属性alertDelaySeconds（报警延迟秒数），不同区域类型使用不同实例；AlertEvent需要有status字段，取值为NEW、CONFIRMED、DISMISSED、EXPIRED。状态图展示的就是AlertEvent从生成到闭环的完整生命历程，这对后续开发设计数据库表结构非常有帮助。
状态图的价值在评审时体现得最明显。评审老师问到“如果一个预警事件一直没人处理会怎么样？”我正因为在状态图中画了“待处理超过30分钟后自动升级为紧急事件，通知店长”这条路径，才没有当场卡壳。需求分析不只是描述“正常情况下怎么做”，更要定义“业务异常时系统怎么兜底”。状态图就是逼你考虑这些分支的工具。
4. 功能性需求与非功能性需求：区分“想做”与“能做”
4.1 功能性需求的粒度划分与编号规则
功能性需求常被写成“系统可以检测遗留物”这种一句话。错误在于：粒度太粗，完全无法估时和测试。功能性需求应该在一个句子内包含“系统在什么条件下、对什么对象、做什么检测、产生什么结果、结果如何呈现”。
我给每个功能需求都加了唯一标识，格式为FR-模块序号-需求序号。例如：
FR-DET-01：系统应能对一个或多个指定检测区域进行连续视频帧分析，识别区域内出现的静态物体，并标记其首次出现时间。FR-DET-02：系统应在静态物体持续存在超过该区域设定的时间阈值后，生成一条遗留物预警事件。FR-QUEUE-01：系统应能统计管理端定义的“排队区域”内的人员数量，并计算排队长度均值。
编号的意义不是为了好看，而是为了追溯。后续设计文档、测试用例都可以引用这个编号，比如“测试用例TC-DET-01 验证FR-DET-02的阈值触发逻辑”。没有编号，需求变更时你根本分不清谁影响谁。
粒度方面，我的经验是“一个需求必须在4小时内能估算工作量”。如果一个需求实现起来需要超过两天，就把它拆分到子功能。比如“支持自定义检测区域”可以拆为“支持通过拖拽绘制多边形区域”“支持将多个区域分组”“支持配置不同业务的识别策略”三个需求。“接收并展示预警事件”可以拆分为“预警事件列表”“预警详情页”“事件确认操作”“事件导出接口”等。拆分后更利于后续排期。
4.2 非功能性需求：准确率、时延、隐私合规一个不能少
非功能性需求是需求说明书里最容易糊弄的部分，也是评审时评委最爱挑刺的部分。很多学生只写一句“系统应保证较好的实时性和准确性”，这句话等于没说。我这次的写法是全部量化，并附上来源和依据。
对于视觉AI系统，最重要的非功能指标有三个：
识别准确率与误报率。我写的目标是：遗留物检测功能在标准场景下，检出率不低于95%，误报率不高于每摄像每日5次；客流统计功能在检测区域人员密度不高于每平米1人时，统计误差不超过±15%。这里的“每摄像每日5次”是可测的：记录算法产生的预警事件总数，人工复核其中误报事件数。评审时承认“算法能力与数据分布有关”，所以还要求“在项目试运行阶段提供为期两周的准确率报告供调参”。
实时性指标。不同业务对时延要求不同：客流排队监测要求从事件发生到前端展示不超过5秒；遗留物检测由于有“持续停留时间”判断，所以从超时那一刻开始算，到生成事件不超过3秒；预警通知推送时间不超过10秒。这里要注意区分“算法推理时延”和“端到端链路时延”，必须在说明书里明确定义从哪个节点到哪个节点。
隐私与合规要求。这是酒店项目躲不开的坎。我明确写了“系统不进行人脸特征提取，不做个体身份识别；视频流仅在本机/局域网内处理，外网传输时必须对图像进行脱敏处理（如人脸区域打码）；原始视频存储时间不超过7天，预警事件截图存储时间不超过30天；系统支持用户对指定区域设置屏蔽”。你不写这些，项目可能连酒店IT部门的初审都过不去。
多提一句，很多人在写“系统兼容性”时只写“支持Windows”，这在现代视觉AI项目里不太够。我们要求的是“服务端支持Linux容器化部署，客户端管理后台支持Chrome、Edge等主流浏览器，移动端支持Android与iOS”并给出了版本号。兼容性需求越具体，后面技术选型越省力。
4.3 需求优先级与版本规划（V3.1的含义）
标题里有个“V3.1”，很多人以为只是版本号随手写的，但在需求分析说明书里，版本号对应的是需求基线与变更记录。我们在这个项目里做了三次迭代规划：V1.0为最小可行性版本，只做“客流排队监测”一个场景，验证算法与设备的集成可行性；V2.0加入“公共区域遗留物检测”；V3.0加入“客房占用状态辅助识别”并完善管理后台和报表能力；V3.1则是在V3.0的基础上增加了“预警规则模板”和“区域绘制功能优化”。
为什么需要这么分？因为视觉AI项目如果把三个场景一次性铺开，数据和算法调优的压力会非常大。每次版本迭代积累的经验，可以反馈给算法团队做针对性优化。需求说明书里应该有一节“版本规划与验收范围”，明确每个里程碑交付哪些功能需求、哪些非功能需求达标。比如V3.1版本我只将“遗留物检测误报率”作为验收重点，而不要求所有指标一次到位。
优先级划分直接影响开发排期。我把Must Have定为：客流监测的阈值预警功能、遗留物人工确认闭环、基础管理后台登录权限管理；Should Have是：房间占用辅助识别、事件导出台账、移动端推送；Could Have是：热力图展示、预测性分析。Won't Have则是：情绪识别、语音交互。评审时有人提“能不能增加客人喜好自动记录”，我直接指着Won't Have清单说“本版本不包含，如需要可在下个版本评估”，这样既没打断评审节奏，又守住了范围。
5. 数据字典与验收标准：让需求说明书不再“纸上谈兵”
5.1 数据字典的编写方法
数据字典是需求说明书里最容易被低估的部分。很多人觉得“这是DBA的事”，但需求阶段的字段级定义恰恰能暴露很多理解偏差。我这次为“预警事件”实体写的数据字典，字段包括：事件编号（全局唯一，格式为EV+年月日+序号）、摄像头编号（关联Camera实体）、所属区域ID、事件类型（遗留物/拥堵/跌倒等）、触发时间、状态（待处理/处理中/已确认/已忽略/过期）、置信度（0-1浮点数）、现场截图路径、处理人及处理备注。每个字段都标注了“是否必填、数据类型、取值范围、字段来源”。
数据字典一开始可能会让文档非常冗长，但它能让需求“无歧义”。比如“处理中”和“已确认”这两个状态到底有何区别？数据字典里必须写清楚：“已确认”表示操作人员认可并开始线下处理；“处理中”表示操作人员点击了“开始处理”按钮，进入挂起状态；“已确认”不一定进入“处理中”。歧义通常就藏在这些邻近概念之间。写完数据字典后，我又反向检查了类图中每个属性的类型，保证两者一致。
数据字典还应该包含“枚举值”定义。例如区域类型枚举：HIGH_RISK（高风险）、MEDIUM_RISK（中风险）、LOW_RISK（低风险）；报警阈值枚举：IMMEDIATE、SHORT、MEDIUM、LONG。这些枚举值在页面上体现为下拉框选项，在算法配置中体现为参数。需求说明书里定义好，后续开发就不需要再问产品“高风险和低风险具体差多少秒”。
5.2 验收标准与测试用例的映射
需求说明书不能只写“系统将实现XX”，还必须给出“怎么证明实现了”。我在文档最后部分做了一个“需求追踪矩阵”，把每个功能需求编号对应到至少一条验收标准。例如：
FR-DET-02对应的验收标准：在测试场景中，将一个静止物体放置在检测区域内，持续超过所设定的时间阈值（如3分钟），系统应在3秒内生成预警事件，并通过管理后台和移动端推送触发通知。FR-QUEUE-01的验收标准：在标准检测区内摆放10个仿真人体道具，系统统计人数误差不超过±2人。
验收标准必须满足“可测试、可观察、可复现”。我建议写验收标准时使用“给定…当…则…”句式。说明书写到这里，才真正变成开发、测试都能用的文件。测试用例可以在后续设计阶段完全复用这些标准，不需要重新发明。
6. 文档撰写与评审：一次通过的小技巧
6.1 需求说明书的目录结构建议
根据这次作业的评审反馈，我总结了一份比较好用的需求说明书目录结构，各位可以直接参考：
- 项目概述（背景、目标、范围与假设）
- 术语与缩略语
- 利益相关者与用户分析
- 系统环境与约束
- 功能性需求（含用例图、用例规约、功能需求表）
- 非功能性需求（性能、安全、可用性、合规）
- 数据需求（数据字典与实体关系）
- 接口需求（内部接口、外部系统接口）
- 版本规划与需求优先级
- 需求追踪矩阵与验收标准
评审老师还特别看重“范围与假设”这一节。假设不写清楚，后面一变更就会变成“你没说啊”。我在假设里写了“系统不直接控制酒店门锁或电梯”“单路摄像头有效检测距离不超过30米”“算法基于可见光摄像头，不包括红外或热成像”等条款。这些看似不起眼的假设，能极大减少后期扯皮。
6.2 评审会上常见的质疑与应对
我们小组模拟评审时被问最多的几个问题，基本可以代表这类项目的典型关切。提前准备好回答思路，现场才不会慌。
第一个问题：“摄像头装在客房走廊里算不算侵犯隐私？”我们的应对是：首先表明本系统不做身份识别，不存储音频，只做区域级的空间状态感知；其次在需求说明书中明确“可设置隐私屏蔽区”，比如客房门口内侧不做分析；最后强调所有数据访问有权限控制和操作日志。从需求层面把合规边界画清楚，对方会放心很多。
第二个问题：“如果网络断了，预警功能怎么办？”这是考系统边界和降级策略。我们写的是：检测区域内的视频分析在边缘设备本地完成，断网不会影响算法推理，但会影响推送和后台联动；因此需要“事件本地缓存”能力，恢复联网后自动补传事件。这个需求一开始我们没有考虑到，是模拟评审时被指出的。你们在写需求时，一定要把“断网、断电、摄像头被遮挡”这类降级场景掰开揉碎写进异常流程。
第三个问题：“精确率和召回率哪个更重要？”这是技术性的坑，但需求人员也逃不掉。我们在遗留物场景写的是“要求召回率不低于98%，精确率不低于90%”。为什么召回率要求更高？因为对安全类场景，漏报比误报更严重——宁可多报几次让安保人员去看一眼，也不能让易燃物遗留很长时间完全没反应。这个取舍逻辑要写进说明书，否则测试阶段数值指标一旦不达标，产品、算法、测试就会互相甩锅。
6.3 我踩过的坑和调整方案
最后分享几个真实踩坑记录，希望能帮大家少走弯路。
第一个坑是“需求描述中混入了技术方案”。第一版我写了“系统采用YOLOv8模型进行目标检测”，评审老师直接否决说：“需求说明书不需要指定算法模型，它属于设计约束，不是需求。”后来我把这句话删除，并将业务需求改为“系统能在可见光摄像头画面中稳定检测出静态物品，且对常见酒店物品（行李箱、背包、清洁车）的检出率不低于95%”。至于用什么模型，那是设计阶段的事。需求分析的人员要守住边界：说清楚“做什么”，不要急着说“怎么做”。
第二个坑是“忽略了管理端角色权限细分”。初版里我用一个“管理员”角色覆盖所有后台操作，但实际业务中，店长有权修改预警规则，而安保组长只能查看和处理事件，前台员工甚至不应该看到其他区域的截图。于是我在权限需求中增加了“基于角色的访问控制（RBAC）”条目，并定义了四类角色：超级管理员、店长、安保人员、客房主管，各自对应不同的功能权限和数据范围。这类需求不做，软件上线第一天就会有人吐槽“怎么什么都能看”。
第三个坑是“预警事件状态没有考虑‘误报标记后回归算法反馈’闭环”。保安看到误报时，如果只是点“忽略”，算法团队就永远不知道哪些是误报、哪些是漏报。于是我在事件状态里增加了一个“标记为误报”的动作，并附带“保存该帧图像用于算法迭代”的附加需求。这样一来，需求文档不仅服务于当前开发，也为后续算法优化留下了数据通路。写需求时多想想“这个数据会不会被另一个模块用到”，往往能发现更多隐藏需求。
踩过这些坑之后回头看，一份好的需求分析说明书，本质上就是把“模糊的业务想象”变成“无歧义的工程依据”。酒店×视觉AI这个题目，技术实现其实不算特别难，难的是把“安保人员要不要看这张截图”“报警延迟3分钟还是1分钟”“出了事谁负责确认”这些业务问题一条条问清楚、写明白。需求文档写到这里，才算真正有了交付价值。
