第二章 需求分析阶段：用户需求调研方法、功能需求与非功能需求定义、需求文档撰写规范
2.1 用户需求调研：别让产品经理背锅
做门禁系统这么多年，我见过太多「上线即翻车」的项目。原因很简单——需求没搞清楚就开干。
我个人习惯，在调研阶段先问三个问题：
- 谁在用？ 保安、行政、还是访客？
- 怎么用？ 刷卡、刷脸、还是手机开门？
- 什么时候用？ 高峰期多少人同时进出？
你想想看，如果连这些都没摸清，后面做出来的设备大概率要返工。我在项目中遇到过最典型的案例：某园区要求「快速通行」，结果我们按常规做了0.5秒识别，实际现场高峰期需要0.2秒以内。最后只能换硬件方案，成本直接翻倍。
核心方法：
- 现场观察法： 蹲点看人流，记录高峰时段、异常行为。我一般带个秒表，实测开门时间。
- 用户访谈： 别只问领导，一定要问保安和保洁。他们才是天天用设备的人。
- 问卷调研： 适合大规模收集意见，但问题要具体。别问「您觉得好不好」，要问「您希望开门速度在几秒内」。
- 原型演示： 拿个Demo板或UI原型给用户看。嗯，这一步能避免80%的误解。
我的小技巧： 调研时带个录音笔，回来反复听。很多细节当时没注意，回放时才发现用户说了关键需求。
2.2 功能需求定义：把「想要」变成「要做」
用户说「我要一个安全的门禁」，这话等于没说。功能需求必须拆解到可执行的程度。
举个例子，用户说「要支持远程开门」。我们得追问：
- 远程是手机APP还是网页？
- 有没有延时要求？比如按下按钮后1秒内必须开门？
- 断网了怎么办？本地还能不能开？
我曾经吃过这个亏。客户说「要远程开门」，我们做了APP控制。结果现场网络差，每次开门要等5秒。客户暴怒。后来才知道，他们需要的其实是「保安室一键开门」，根本不需要走互联网。
功能需求定义时，我习惯用用户故事来描述：
作为 [角色]，我希望 [功能]，以便 [价值]。
示例：
作为 保安，我希望 在监控室一键开启所有门禁，以便 在紧急情况下快速疏散人员。
作为 访客，我希望 通过扫码自助登记，以便 不用排队等保安核实。
每个功能需求都要有明确的验收标准。比如：
| 功能 | 验收标准 |
|---|---|
| 刷卡开门 | 刷卡后0.3秒内门锁动作，成功率≥99.9% |
| 人脸识别 | 光照50-500lux下识别率≥98%，戴口罩也能识别 |
| 远程开门 | APP点击后2秒内门锁动作，支持离线缓存指令 |
注意： 功能需求一定要区分「必须做」和「最好有」。我见过太多团队在「访客自动邀请」这种锦上添花的功能上浪费了两个月，结果核心的「刷卡开门」都没做好。
2.3 非功能需求定义：看不见的才是要命的
功能需求决定设备能不能用，非功能需求决定设备好不好用。说白了，用户不会夸你「这个门禁真稳定」，但一旦出问题，他会骂你一辈子。
非功能需求我一般分这几类：
- 性能： 开门速度、并发处理能力、识别准确率。我记得有个项目要求「高峰期每分钟通过60人」，我们实测只能过40人，最后加了双通道才搞定。
- 可靠性： MTBF（平均无故障时间）、故障恢复时间。门禁设备一般要求MTBF≥50000小时，也就是5年多不能坏。
- 安全性： 防撬、防拆、防复制。我见过有人用IC卡复制器，几分钟就复制了一张卡。所以现在我们都用CPU卡或加密卡。
- 环境适应性： 温度、湿度、防水防尘。室外门禁至少IP65，北方还要考虑-30℃低温启动。
- 可维护性： 固件能否远程升级？故障能否自诊断？我曾经为了升级一个固件，跑了20个工地，累到崩溃。后来所有设备都加了OTA功能。
避坑指南： 我曾经在非功能需求上栽过大跟头。一个项目验收时，客户说「你们设备在夏天高温时经常死机」。我们一查，机箱内部温度到了70℃，而芯片最高只支持60℃。最后只能加风扇、改散热。如果需求阶段就明确「工作温度-20℃~+60℃」，这事根本不会发生。
2.4 需求文档撰写规范：写清楚，别让人猜
需求文档是团队的「宪法」。写得好，开发、测试、生产都省心。写不好，后面全是扯皮。
我个人的文档模板长这样：
# 门禁设备需求规格说明书
## 1. 项目背景
（一句话说清楚为什么要做这个设备）
## 2. 用户角色
- 保安：日常管理、远程开门
- 员工：刷卡/刷脸通行
- 管理员：权限配置、日志查看
## 3. 功能需求
### 3.1 刷卡开门
- 描述：用户刷卡后，设备验证卡号并开门
- 输入：Mifare卡或CPU卡
- 输出：门锁动作、蜂鸣器提示
- 验收标准：0.3秒内开门，成功率≥99.9%
### 3.2 人脸识别开门
- 描述：摄像头抓拍人脸，比对成功后开门
- 输入：人脸图像（支持戴口罩）
- 输出：门锁动作、屏幕显示结果
- 验收标准：识别率≥98%，光照范围50-500lux
## 4. 非功能需求
- 性能：高峰期每分钟通过40人
- 可靠性：MTBF≥50000小时
- 环境：-20℃~+60℃，IP65
- 安全：防拆报警、数据加密
## 5. 约束条件
- 成本：BOM成本不超过800元
- 认证：必须通过CCC认证
- 接口：提供SDK供第三方集成
撰写要点：
- 用词精确： 别用「大概」「可能」「尽量」，要用「必须」「至少」「在XX条件下」。
- 可验证： 每个需求都要能测试。比如「响应速度快」就不合格，要写成「响应时间≤0.5秒」。
- 版本控制： 需求文档一定要有版本号。我见过因为版本混乱，开发按V1.0做，测试按V2.0测，最后全乱套。
- 评审签字： 需求文档必须经过客户、产品、开发、测试四方评审签字。别嫌麻烦，这是保护自己的最好方式。
血的教训： 我曾经有个项目，需求文档里写了「支持手机开门」，但没写清楚是蓝牙还是WiFi还是4G。结果开发做了蓝牙方案，客户想要的是4G远程开门。最后重做，损失了30万。从那以后，我要求所有需求必须附带技术实现方案简述，哪怕只是几句话。
2.5 需求变更管理：唯一不变的就是变化
做门禁这么多年，我还没见过哪个项目需求完全不变。关键是变更要有流程。
我的做法是：
- 变更申请： 必须书面提出，说明变更原因和预期效果。
- 影响评估： 变更对进度、成本、质量有什么影响？我一般用Excel拉个表，逐项评估。
- 决策： 项目经理和客户共同决定是否接受变更。
- 更新文档： 变更后立即更新需求文档，并通知所有相关人员。
你想想看，如果变更不走流程，开发按新需求做，测试按旧需求测，最后上线时发现对不上，那场面得多尴尬？
好了，需求分析阶段就讲到这里。下一章我们聊聊设计阶段，怎么把需求变成实实在在的硬件方案。