2、需求管理：需求捕获与分析、需求文档化规范、需求变更控制流程
做嵌入式项目这么多年，我踩过最大的坑，往往不是技术难题，而是需求没搞清楚就动手了。你想想看，代码写了一半，客户突然说“哦，我忘了说，这个设备要在零下40度工作”——这时候改硬件选型，那叫一个酸爽。所以今天咱们聊聊需求管理，这是整个质量保障体系的基石。
2.1 需求捕获与分析：别让“我以为”害了项目
需求捕获，说白了就是搞清楚客户到底要什么。但这里有个悖论：客户往往不知道自己想要什么。我遇到过一位客户，他说“就要一个智能温控器”，结果深入聊下去，发现他其实想要的是能接入他家那套20年前的锅炉系统。嗯，这完全是两码事。
我个人习惯用“5W1H”法来捕获需求：
- Who：谁在用这个设备？操作员？维护工程师？最终用户？
- What：设备要完成什么功能？核心功能是什么？
- Where：使用环境是怎样的？室内？户外？工业现场？
- When：什么时候用？连续运行？间歇工作？
- Why：为什么要这个功能？背后的真实诉求是什么？
- How：怎么实现？有没有技术约束？
举个例子，我曾经做一个工业数据采集器项目。客户说“要能采集温度”。我多问了一句“为什么要采集温度？”——原来他们是要做设备故障预测，温度只是其中一个参数。最后我们加上了振动、电流等多维采集，产品价值翻了好几倍。你看，多问一句，价值就出来了。
需求分析的核心原则：
- 区分“功能需求”和“非功能需求”。功能需求是“做什么”，非功能需求是“做得怎么样”。比如“每秒采集100次”是功能需求，“在85℃环境下稳定运行”是非功能需求。
- 区分“必须做”和“最好做”。用MoSCoW法则：Must have, Should have, Could have, Won't have。
- 区分“用户说的”和“用户真正要的”。用户说“我要一个红色按钮”，可能他真正要的是“紧急停止时能一眼看到”。
2.2 需求文档化规范：写清楚，才能做明白
需求捕获完了，得写下来。但怎么写？我见过太多团队用Word写个几百页的需求文档，结果没人看，也没人看得懂。我个人建议，嵌入式项目的需求文档要遵循“三化”原则：结构化、可追溯、可验证。
结构化：用统一的模板，每个需求有唯一编号。比如“REQ-SYS-001”表示系统级需求，“REQ-MOD-001”表示模块级需求。这样后期做测试用例时，可以直接追溯到需求。
可追溯：每个需求都要能追溯到来源。是客户说的？是行业标准要求的？还是内部技术决策？我习惯在需求后面加一列“来源”，比如“客户会议纪要2024-01-15”或“IEC 61131-3标准第5.2节”。
可验证：每个需求都要能测试。模糊的需求是质量的天敌。比如“系统响应要快”——这没法测。改成“从按键按下到LED亮起，时间不超过50ms”——这就可验证了。
我的文档模板习惯：
每个需求条目包含：ID、名称、描述、优先级、来源、验收标准、状态。用Excel或专门的ALM工具管理，别用Word——Word没法做版本对比和关联追溯。
这里给一个需求文档的示例片段：
| 需求ID | 需求名称 | 描述 | 优先级 | 来源 | 验收标准 |
|--------------|------------------|----------------------------------------|--------|--------------------|------------------------------|
| REQ-SYS-001 | 系统启动时间 | 系统上电后，5秒内进入主界面 | Must | 客户需求文档 v2.1 | 用示波器测量，从供电到界面显示≤5s |
| REQ-SYS-002 | 数据存储周期 | 每10分钟自动存储一次采集数据到SD卡 | Must | 行业标准IEC 61131 | 检查SD卡文件，时间戳间隔10min±1s |
| REQ-MOD-001 | 温度采集精度 | 温度传感器精度±0.5℃（-20℃~85℃范围） | Should | 技术评审会议纪要 | 用标准温度源校准，偏差≤0.5℃ |
2.3 需求变更控制流程：变是常态，不变是意外
做嵌入式项目，需求不变？那是不可能的。我做过一个车载项目，硬件都打样了，客户说“屏幕要换成触摸的”——嗯，整个UI架构都得重来。所以，需求变更不是问题，问题是没有流程控制变更。
我曾经在一个项目上吃过亏：客户口头说“加个小功能”，开发顺手就做了。结果测试时发现这个“小功能”影响了主任务的实时性，导致整个系统崩溃。从那以后，我坚持所有变更必须走流程。
我的变更控制流程：
- 提出变更：任何干系人都可以提，但必须书面化。口头说的不算，发邮件才算。
- 影响分析：变更对进度、成本、质量、技术方案有什么影响？我习惯用“变更影响矩阵”来评估。
- 评审决策：项目经理、技术负责人、测试负责人一起评审。决定是“接受”、“拒绝”还是“暂缓”。
- 更新文档：如果接受变更，更新需求文档、设计文档、测试用例。版本号要变。
- 通知全员：变更结果通知到所有相关人。别让测试组还在测旧版本。
避坑指南：
我曾经遇到一个团队，变更流程走了，但只更新了需求文档，没更新测试用例。结果测试组按旧用例测，通过了，但新功能根本没测到。上线后出问题，背锅的还是开发。所以，变更一定要闭环——文档、代码、测试用例、部署脚本，一个都不能少。
这里给一个变更影响矩阵的示例：
| 变更内容 | 影响范围 | 进度影响 | 成本影响 | 质量风险 | 决策 |
|------------------|------------------|----------|----------|----------|------|
| 增加触摸屏功能 | UI模块、驱动层 | +2周 | +5000元 | 中 | 暂缓 |
| 修改数据存储格式 | 存储模块、测试用例| +1周 | +2000元 | 低 | 接受 |
| 删除蓝牙功能 | 通信模块 | -0.5周 | -3000元 | 无 | 接受 |
最后说一句，需求管理不是一次性的工作。它贯穿整个项目生命周期。我习惯在每个迭代结束时，和客户做一次需求回顾，看看有没有遗漏或变化。这样做的好处是，避免到最后才发现“哦，原来你要的是这个”。
嗯，需求管理就聊到这里。下一章咱们讲设计阶段的质量保障，到时候聊聊怎么把需求转化成靠谱的架构设计。