3、需求管理：从产品需求到技术规格，如何编写清晰的嵌入式软件需求文档

说实话，我见过太多嵌入式项目死在需求阶段。

产品经理说「我要一个智能温控器」，开发团队闷头干了两周，结果发现连传感器选型都没定。这种事，我职业生涯里至少碰到过五六回。后来我总结了一句话：需求文档写不清楚，后面全是坑。

3.1 为什么嵌入式需求文档特别难写？

嵌入式软件和纯软件不一样。你想想看，纯软件跑在通用操作系统上，输入输出都是屏幕和键盘。嵌入式呢？要跟硬件打交道，要管中断、管时序、管功耗、管内存。

我个人的习惯是，把嵌入式需求分成三层：

• 业务需求：产品要解决什么问题？比如「实现一个智能门锁」
• 系统需求：软硬件怎么分工？比如「指纹识别由硬件模块完成，MCU负责通信和逻辑」
• 软件需求：代码具体要做什么？比如「当指纹匹配成功时，在200ms内输出高电平驱动电机」

很多团队只写了第一层，然后直接跳到写代码。嗯，这就是灾难的开始。

3.2 需求文档的核心结构

我在团队里推行过一套模板，用了三年，效果还不错。分享给你：

章节	内容	示例
1. 范围	文档覆盖哪些功能、不覆盖哪些	本需求涵盖温控器的PID控制逻辑，不涉及云端通信
2. 术语表	关键缩写和定义	ADC：模数转换器；PWM：脉宽调制
3. 功能需求	每个功能的具体行为	当温度超过阈值时，风扇以80%占空比启动
4. 非功能需求	性能、功耗、实时性等	中断响应时间不超过50μs
5. 接口定义	硬件引脚、通信协议、API	UART1：115200bps，8N1
6. 约束条件	硬件限制、成本、法规	RAM使用不超过32KB

这个结构的好处是，每个角色都能找到自己关心的部分。硬件工程师看接口定义，测试工程师看功能需求，项目经理看范围。

3.3 如何把模糊的产品需求变成清晰的技术规格？

这是最考验功力的地方。产品经理说「响应要快」，你不能直接写「响应要快」。快是多少？100ms？10ms？1ms？

我一般用「五问法」来拆解：

1. 问场景：这个功能在什么情况下触发？
2. 问边界：最坏情况是什么？
3. 问时序：从触发到完成，允许多久？
4. 问资源：能用多少CPU、内存、功耗？
5. 问异常：出错时怎么办？

举个例子。产品需求是「设备检测到震动时报警」。

你看，这样写出来，开发人员就知道代码该怎么写了。测试人员也知道怎么测了。

3.4 需求文档的避坑指南

我记得有一次，一个项目因为需求文档里没写「看门狗超时时间」，结果测试时发现系统每隔3秒就复位一次。查了两天才发现，是看门狗配置和任务执行时间不匹配。如果当初在需求里写清楚「看门狗超时设为5秒，且喂狗任务优先级最高」，这问题根本不会出现。

3.5 需求文档的评审与版本管理

文档写完了，不是就完事了。我建议做两件事：

• 交叉评审：让硬件工程师审软件需求，让测试工程师审功能需求。不同视角能发现很多盲区。
• 版本号管理：每次修改都要更新版本号，并在文档开头写明变更记录。我见过最惨的案例，是开发人员拿着旧版需求写了三个月，最后发现需求早就改了。

3.6 一个完整的示例片段

最后，给你看一段我实际项目中用过的需求描述。这是关于一个电池供电的温湿度采集器：

REQ-101：温湿度采集
  描述：系统每10秒通过SHT30传感器采集一次温湿度数据。
  精度：温度±0.3°C，湿度±2%RH。
  接口：I2C，地址0x44，速率100kHz。
  异常处理：
    - 若连续3次读取失败，标记传感器故障，上报错误码0xA1。
    - 故障恢复后，自动恢复正常采集。
  功耗约束：单次采集（含传感器上电、读取、下电）总电流不超过2mA，持续时间不超过50ms。

你看，这个需求写出来，硬件工程师知道要配什么传感器，软件工程师知道怎么写驱动，测试工程师知道怎么设计用例。每个人拿到文档，都能直接干活。

说白了，需求管理就是把模糊变成清晰，把抽象变成具体。这件事做得好，后面开发、测试、维护都能省下大量时间。做不好，那就是「需求一时爽，开发火葬场」。

嗯，今天就聊到这儿。下一章我们讲讲如何用看板和每日站会，让团队协作真正跑起来。