3. 需求文档编写：SRS、用户故事与验收标准
需求文档这东西，说白了就是项目里的“宪法”。
我见过太多项目，开发到一半才发现大家理解的不一样。硬件工程师以为要跑100M，软件以为50M就行。结果呢？改板子，加成本，延期交付。所以，一份靠谱的需求规格说明书（SRS），是嵌入式项目的第一道防线。
3.1 需求规格说明书（SRS）的核心结构
很多新手觉得SRS就是列功能清单。其实不然。一份好的SRS，要能回答三个问题：系统要做什么？、做到什么程度？、怎么验证？
我个人习惯把SRS分成下面几个模块，你可以直接套用这个模板：
| 章节 | 核心内容 | 嵌入式项目特别关注点 |
|---|---|---|
| 1. 引言 | 项目背景、术语定义、参考文档 | 明确MCU型号、RTOS版本、开发工具链 |
| 2. 总体描述 | 产品视角、用户特征、约束条件 | 功耗限制、成本目标、尺寸要求 |
| 3. 功能需求 | 系统功能、模块划分、交互逻辑 | 传感器采样率、通信协议、中断优先级 |
| 4. 非功能需求 | 性能、可靠性、安全性、可维护性 | 响应时间、看门狗策略、固件升级机制 |
| 5. 接口需求 | 硬件接口、软件接口、人机交互 | GPIO电平、SPI速率、UART波特率 |
| 6. 验收标准 | 测试用例、通过条件、交付物清单 | 环境温度范围、EMC测试等级 |
我的经验： 写SRS时，别怕“啰嗦”。把每个接口的时序图画清楚，把每个异常场景写明白。我曾经因为SRS里没写“掉电时保存最后状态”，导致产品在用户现场频繁丢数据，最后花了三周才定位到问题。
3.2 用户故事：让需求“活”起来
用户故事不是给客户看的，是给开发团队看的。它的格式很简单：
作为 <角色>
我希望 <功能>
以便 <价值>举个例子，一个智能门锁项目：
- 用户故事1： 作为住户，我希望用指纹开锁，以便不用带钥匙。
- 用户故事2： 作为管理员，我希望远程查看开锁记录，以便监控出入情况。
- 用户故事3： 作为安装工程师，我希望通过蓝牙配置Wi-Fi，以便快速完成网络设置。
你想想看，这三个故事一写，开发团队就知道要做什么了。但光有故事还不够，还得有验收条件。
避坑指南： 我曾经遇到一个团队，用户故事写得很漂亮，但验收条件写的是“用户能正常使用”。这等于没写。验收条件必须可量化、可测试。比如：“指纹识别成功率 > 99%”、“开锁响应时间 < 500ms”。
3.3 用例图：把关系画清楚
用例图是UML里最直观的图。它不画流程，只画谁能做什么。对于嵌入式项目，用例图能帮你快速理清系统边界。
下面这张图，展示了一个智能温控器的用例关系：
画用例图时，记住三个原则：
- 参与者：是人还是外部系统？比如“云端服务器”也是一个参与者。
- 用例：是完整的功能单元，不是操作步骤。“输入密码”不是用例，“解锁门”才是。
- 关系：用包含（include）表示公共步骤，用扩展（extend）表示可选步骤。
3.4 验收标准：说清楚“怎样才算做完”
验收标准是需求文档的“最后一公里”。没有验收标准，开发说做完了，测试说没做完，项目经理夹在中间两头受气。
我建议用Given-When-Then格式来写验收标准：
场景：住户通过指纹开锁
Given：门锁处于待机状态，且已录入住户指纹
When：住户将已注册的手指放在指纹传感器上
Then：系统在 500ms 内解锁，并记录开锁时间对于嵌入式项目，验收标准要特别关注边界条件和异常场景：
| 类型 | 验收标准示例 |
|---|---|
| 正常场景 | 指纹识别成功，门锁在 500ms 内打开 |
| 异常场景 | 连续 5 次指纹识别失败，系统锁定 30 秒并发出警报 |
| 边界场景 | 电池电压低于 3.3V 时，系统仍能正常识别指纹 50 次以上 |
| 性能场景 | 系统从待机到完成指纹识别，总功耗不超过 50mJ |
⚠️ 注意： 验收标准一定要在项目启动前和客户、测试、开发三方确认。我见过最惨的案例：开发觉得“响应时间 2 秒”就够，客户要求“1 秒以内”。结果验收时才发现，改代码已经来不及了，只能加钱换芯片。
3.5 需求文档的版本管理
需求文档不是写一次就完事的。项目过程中，需求一定会变。怎么管？
- 版本号规则：V1.0（初稿）、V1.1（小修改）、V2.0（重大变更）。
- 变更记录：每次修改都要写清楚“谁、什么时候、改了哪里、为什么改”。
- 评审机制：重大变更必须走评审流程，不能私下改。
我个人习惯用需求跟踪矩阵（RTM）来管理。把每个需求编号，对应到设计文档、测试用例、代码模块。这样，需求一变，影响范围一目了然。
核心要点： 需求文档的质量，直接决定了项目后期的返工成本。花 1 周把需求写清楚，能省下 1 个月的改 bug 时间。这笔账，你算算看。