第二章：需求分析实战——如何与甲方/工艺工程师沟通、需求文档（PRD）撰写要点、功能清单与优先级划分

好，咱们直接进入正题。

很多刚入行的HMI工程师，拿到项目第一件事就是打开软件开始画界面。我见过太多这样的案例——画了三天，甲方一看，全推翻了。为什么？因为需求没对齐。

说白了，需求分析才是整个HMI项目里最值钱的环节。你画图可能只花20%的时间，但需求分析要占掉40%的精力。剩下的40%？改需求。

2.1 如何与甲方/工艺工程师有效沟通

先说说沟通对象。甲方和工艺工程师，其实是两类完全不同的人。

甲方通常是老板或项目经理，他们关心的是：

• 这个界面看起来专不专业？
• 操作员能不能快速上手？
• 能不能减少误操作？
• 成本控制在多少？

工艺工程师呢？他们关心的是：

• 这个参数能不能实时显示？
• 报警阈值设多少？
• 历史数据能不能导出？
• 操作权限怎么分配？

你看，关注点完全不同。所以沟通策略也要分开。

跟工艺工程师沟通，我建议你带上纸和笔。去现场走一圈，看他们怎么操作。我在项目中遇到过一位工艺工程师，他说「这个按钮要放在左上角」，我问为什么？他说「因为操作员右手拿工具，左手点屏幕」。你看，这种细节，你不去现场根本不知道。

2.2 需求文档（PRD）撰写要点

PRD不是写作文，是写说明书。我见过最离谱的PRD，写了30页，全是「界面要美观」「操作要流畅」这种废话。没用。

好的PRD，要能回答三个问题：

1. 谁用？——操作员、管理员、维护人员？
2. 干什么？——监控、控制、报警、记录？
3. 怎么干？——触摸、键盘、鼠标？

我一般把PRD分成这几个模块：

写PRD的时候，有个小技巧：用「用户故事」代替「功能列表」。比如：

• ❌ 功能：显示温度报警
• ✅ 用户故事：作为操作员，我希望当温度超过80度时，屏幕闪烁红色并发出声音，这样我能第一时间发现异常。

你想想看，哪个更容易让开发人员理解？

2.3 功能清单与优先级划分

功能清单不是把所有想到的功能都列上去。那样做，项目永远做不完。

我常用的方法是MoSCoW法则：

• M - Must have（必须有）：没有这个功能，系统没法用。比如：实时数据显示、报警提示。
• S - Should have（应该有）：重要但不紧急。比如：历史趋势图、报表导出。
• C - Could have（可以有）：锦上添花。比如：多语言切换、皮肤主题。
• W - Won't have（这次不做）：明确排除。比如：远程APP控制（留给二期）。

举个例子，一个典型的HMI功能清单：

还有一个坑：功能清单要写「不做什么」。我习惯在文档最后加一页「本次不包含的功能」，让甲方签字确认。为什么？因为项目做到一半，甲方突然说「加个报表功能吧」，你拿出这张纸，他就不吭声了。

2.4 需求确认与变更管理

需求分析做完，一定要做一件事：需求确认会。把甲方、工艺工程师、开发人员叫到一起，对着PRD和界面草图，一条一条过。

我一般会准备一个需求确认表：

确认之后，再有人提需求变更，就按流程走：

1. 提交《需求变更申请单》
2. 评估影响（工期+成本）
3. 甲方签字确认
4. 更新PRD和功能清单

好了，需求分析这块就讲这么多。下一章咱们聊聊原型设计——怎么用Axure或Figma快速做出可交互的HMI原型，让甲方在开发前就能「摸到」最终效果。