第4章 设备接入需求采集方法：利益相关方识别、用户访谈提纲、现场调研清单
4.1 需求采集的三大核心环节
设备接入MQTT的需求不能仅凭猜测或技术假设来定义。本章聚焦于从真实业务环境中获取原始需求的三类方法：利益相关方识别确保“问对人”，用户访谈提纲保证“问对事”，现场调研清单落实“看到真实现状”。三者构成一个闭环，避免需求遗漏或偏离。
业务警示：某智能仪表项目因未识别出产线维护工程师为关键利益相关方，导致MQTT心跳间隔设置过短，被工厂安全网关频繁阻断。重新采集需求后修改参数，该项目延期4周。
4.2 利益相关方识别矩阵
为MQTT设备接入项目识别利益相关方时，应涵盖至少以下四类角色。遗漏任何一方都可能导致验收时发现严重需求缺口。
| 利益相关方 | 典型角色 | 关注的核心需求 | 访谈优先级 |
|---|---|---|---|
| 业务决策者 | 产品总监、项目负责人 | 设备在线率、数据完整性、总拥有成本 | 高（项目立项前） |
| 设备运维者 | 现场工程师、设备管理员 | 心跳异常警告、远程重启、批量配置 | 高（贯穿始终） |
| 技术实施者 | 嵌入式开发、平台后端开发 | MQTT版本稳定性、QoS等级、证书管理 | 中（方案设计阶段） |
| 安全合规者 | 信息安全工程师、法务 | 数据传输加密、设备认证、日志审计 | 中（需求验证阶段） |
实践技巧：使用“影响力—利益”矩阵对相关方进行排序。高影响力且高利益的相关方应安排1对1深度访谈；低影响力但高利益的相关方可通过问卷收集需求。所有访谈记录需录入需求追溯库，确保每条需求可追溯到具体相关方。
4.3 用户访谈提纲设计
访谈提纲应围绕现状、痛点、期望、约束四个维度展开。以下是为智能设备接入MQTT场景定制的访谈问题结构，每个问题都指向一个具体需求点。
4.3.1 现状与痛点的信息采集
- 角色确认：您日常工作中有哪些设备需要上云？目前使用什么协议？（评估MQTT替代或升级的必要性）
- 故障场景：最近一次设备掉线持续了多久？现场如何发现和处理？（定义心跳机制与异常响应需求）
- 数据需求：您需要设备上报哪些关键参数？采样的频率要求是什么？（明确数据模型与发布频率）
4.3.2 期望与约束的精准挖掘
- 技术约束：现有网络环境是否允许固定端口？是否需要代理或桥接？（确定MQTT连接与防火墙策略）
- 未来扩展：未来半年可能增加多少设备？是否需要动态发现或批量注册？（影响设备管理模块设计）
- 安全底线：设备证书是否支持离线颁发？密钥轮换周期由谁管理？（明确认证与加密方案）
常见偏差：访谈者容易直接询问“您需要MQTT的QoS等级是多少？”，正确的做法是先了解“您认为数据丢失的容忍度是多少？”再将业务容忍度映射为技术参数。跳过映射步骤将导致技术与业务脱节。
4.4 现场调研清单
现场调研是为了验证访谈中获取的信息，并发现被访谈者忽略的环境细节。以下清单覆盖了MQTT设备接入的四个关键领域：网络环境、设备接口、部署约束、物理安全。
| 调研领域 | 检查项 | 记录要点 |
|---|---|---|
| 网络环境 | 企业出口防火墙规则、NAT策略、WIFI/有线频段干扰 | 记录MQTT默认端口(1883/8883)是否被封锁，是否需改为8080/443过代理 |
| 设备接口 | 物理串口/网口型号、CPU算力、内存容量、固件版本 | 确认是否支持TLS 1.2以上、硬件随机数生成器是否存在 |
| 部署约束 | 安装位置、供电稳定性、散热条件、预留升级空间 | 评估是否需要本地断线缓存与回补机制 |
| 物理安全 | 设备机柜锁、网线/电源线保护、USB禁用措施 | 判断是否需要独立的硬件安全模块(HSM)或物理防篡改设计 |
4.5 从调研到需求的定义映射
采集到的原始信息必须经过结构化转换。以下是一个典型的映射模板，将调研结果直接转化为需求条目。
| 调研发现（原话） | 业务需求描述 | 技术需求映射 | 优先级 |
|---|---|---|---|
| “上次设备掉线2小时后才发现” | 设备异常需在5分钟内被感知 | MQTT心跳间隔≤120s，心跳超时3次触发告警 | P0 |
| “产线改造时网关IP经常变化” | 设备可自动发现并重新连接MQTT Broker | 支持SVR记录与IP绑定，且启用最后遗嘱消息 | P1 |
| “安全部门要求所有通讯加密” | 从设备到Broker全程TLS加密传输 | 强制使用TLS 1.2+，证书由PKI自动分发 | P0 |
交付物模板提示：本章完成后，应产出《利益相关方登记册》、《结构化访谈记录表》、《现场调研检查表》以及《需求—技术映射表》四份模板。这些模板将作为第5章“需求拆解”的输入工件，务必确保每一条调研发现都有对应的需求编号。