3、需求分析：用户需求调研、功能需求分析、性能指标定义、需求文档编写
说实话，很多自控项目做砸了，根源不在技术，而在需求没搞清楚。
我见过太多团队，上来就画电路图、写PLC程序，结果做到一半用户说“我要的不是这个”。嗯，那场面，真是欲哭无泪。所以这一章，咱们好好聊聊需求分析到底该怎么做。
3.1 用户需求调研：别猜，去问
用户需求调研，说白了就是搞清楚用户到底想要什么。但这里有个坑——用户往往说不清楚自己要什么。
我曾经参与过一个污水处理项目，用户说“我要自动化控制”。结果一细问，他想要的只是远程开关阀门，连PID调节都不需要。你想想看，如果按我的惯性思维去设计，那得多出多少无用功？
调研的核心方法：
- 现场走访：必须去实地看，看设备布局、看操作流程、看现有问题
- 用户访谈：找操作工、找班长、找设备科经理，不同角色需求不同
- 问卷调研：适合收集大量基础数据，但别指望靠问卷拿到深度需求
- 原型演示：画个简单的界面草图，让用户“看到”未来的系统
我个人习惯，每次调研都带个小本子。用户随口说的一句话，可能就是一个关键需求。比如有次用户说“那个按钮按下去有时候没反应”，后来发现是电气干扰问题，这要是没记下来，后面调试得哭死。
3.2 功能需求分析：把“想要”变成“要做”
调研完了，手里一堆用户的原话。接下来要做的，就是把这些“人话”翻译成“技术语言”。
举个例子：用户说“我希望系统能自动报警”。这句话太模糊了。你得问清楚：
- 什么条件下报警？温度超限？压力异常？还是设备故障？
- 报警方式是什么？声光报警？短信通知？还是上位机弹窗？
- 报警级别怎么分？一级报警要停机，二级报警只提示？
我建议用功能分解法，把一个大需求拆成若干个小功能。比如“自动控制”可以拆成：
- 数据采集功能
- 逻辑控制功能
- PID调节功能
- 联锁保护功能
- 手动/自动切换功能
小技巧：每个功能需求都要写清楚“输入-处理-输出”。比如：
- 输入：液位传感器信号（4-20mA）
- 处理：当液位 > 80% 时，开启排水泵
- 输出：DO信号控制接触器
3.3 性能指标定义：没有标准，就没有验收
功能需求说清楚了，但还不够。你得告诉用户，这个系统到底能做到多好。这就是性能指标。
我记得有个项目，用户说“系统响应要快”。结果验收时他说“快”是0.5秒，我理解的是2秒。你看，这就是没定义清楚指标的下场。
常见的自控系统性能指标包括：
| 指标类别 | 具体指标 | 典型值 |
|---|---|---|
| 实时性 | 扫描周期、响应时间 | PLC扫描周期 ≤ 50ms |
| 可靠性 | MTBF、可用率 | MTBF ≥ 8760小时 |
| 精度 | 测量精度、控制精度 | 温度控制 ±0.5℃ |
| 容量 | I/O点数、标签数量 | 预留20%余量 |
| 可用性 | 系统开机率、故障恢复时间 | 开机率 ≥ 99.9% |
注意：性能指标一定要可量化、可验证。别写“系统稳定”，要写“系统连续运行72小时无故障”。否则验收时就是扯皮。
3.4 需求文档编写：把共识固定下来
需求文档，就是所有需求的最终载体。它不光是给用户看的，也是给开发、测试、验收用的。
我写需求文档有个习惯：先写目录，再填内容。目录结构一般是：
- 项目概述：背景、目标、范围
- 用户需求：原始需求描述（用户原话）
- 功能需求：每个功能的详细说明
- 性能指标：量化指标表
- 接口需求：与外部系统的交互
- 约束条件：预算、工期、法规等
- 验收标准：怎么才算通过
文档写完后，一定要让用户签字确认。我曾经吃过这个亏——口头说好的需求，到验收时用户不认账。白纸黑字，对双方都是保护。
需求文档的黄金法则：
- 每个需求都要有唯一编号（如 REQ-001）
- 每个需求都要有优先级（P1必须做，P2尽量做，P3可选）
- 每个需求都要有验收标准（怎么证明做完了）
3.5 需求分析的核心逻辑
说了这么多，其实需求分析就三步：
- 收集：从用户那里拿到原始需求
- 转化：把原始需求变成技术需求
- 固化：用文档把需求固定下来
下面这张图，是我自己总结的需求分析流程，你可以参考一下：
嗯，需求分析这块，说白了就是“把话说清楚”。用户说不清楚，你帮他说清楚；用户说不量化，你帮他量化。最后落到文档上，大家签字画押，后面干活才踏实。
我的经验：需求分析阶段多花20%的时间，项目整体工期能缩短30%。别急着动手干活，先把需求搞透。我曾经有个项目，需求分析做了两周，结果实施只用了三周，一次验收通过。隔壁团队需求分析做了一周，实施做了两个月，还在改。
公众号:蓝海资料掘金营，微信deep3321