第二章 需求分析与规格说明：把“想要”变成“要做”
说实话，我见过太多嵌入式项目死在需求阶段。不是技术做不到，而是从一开始就没搞清楚要做什么。你想想看，一个智能门锁，客户说“要安全”，结果验收时才发现他要的是指纹+人脸+静脉识别三重认证——这哪是门锁，这是银行金库。
所以这一章，咱们就聊聊怎么把客户脑子里那些模糊的想法，变成白纸黑字的、可执行的规格说明。我个人习惯把需求分析分成两条线：功能需求和非功能需求。两条线走通了，项目就稳了一半。
2.1 功能需求与非功能需求：一个都不能少
功能需求好理解，就是“系统要做什么”。比如：
- 按下按钮，LED亮起
- 温度超过阈值，风扇启动
- 收到UART指令，返回当前状态
但非功能需求呢？说白了就是“系统要做到什么程度”。我遇到过最典型的坑：客户说“数据要实时传输”，结果验收时发现他理解的“实时”是10ms以内，而我们按100ms做的。嗯，这就是非功能需求没写清楚。
非功能需求常见分类：
| 类别 | 典型指标 | 我的经验 |
|---|---|---|
| 性能 | 响应时间 ≤ 50ms | 别写“快速”，写具体数字 |
| 可靠性 | MTBF ≥ 10000小时 | 要写测试条件，比如温度范围 |
| 功耗 | 待机 ≤ 10μA | 记得区分工作模式和休眠模式 |
| 安全性 | 固件加密，防回读 | 这个容易被忽略，但出事就是大事 |
我的小技巧：写非功能需求时，问自己三个问题——多快？多久？多省？回答完这三个，基本就齐了。
2.2 用例图与用户故事：两种视角，一个目标
用例图是给客户看的，用户故事是给开发团队看的。两者不冲突，反而互补。
用例图，说白了就是画个框，把系统边界画出来，然后标出谁（角色）能做什么（用例）。我习惯用UML工具画，但手绘也行，关键是让客户点头。
举个例子，一个智能温控器：
- 角色：用户、管理员、云端服务器
- 用例：设置温度、查看历史、远程控制、固件升级
用户故事呢？格式很简单：
作为<角色>，我想要<功能>，以便<价值>比如：
作为用户，我想要通过手机APP远程查看室内温度，以便我回家前就能知道要不要开空调。注意：用户故事不是需求文档。它只是沟通的起点。我曾经见过团队拿着用户故事直接开发，结果发现“远程查看温度”背后还有“需要Wi-Fi配网”、“需要绑定设备”、“需要数据加密”……这些细节，用户故事里可没写。
2.3 需求规格说明书（SRS）模板：你的项目宪法
SRS是项目里最重要的文档，没有之一。我习惯用IEEE 830标准做骨架，但会根据嵌入式项目的特点做调整。下面是我常用的模板：
1. 引言
1.1 编写目的
1.2 项目背景
1.3 术语定义
2. 总体描述
2.1 产品功能概述
2.2 用户特征
2.3 约束条件（硬件平台、成本、时间）
3. 功能需求
3.1 模块A
3.1.1 功能描述
3.1.2 输入/输出
3.1.3 异常处理
3.2 模块B
...
4. 非功能需求
4.1 性能指标
4.2 功耗要求
4.3 可靠性要求
4.4 安全要求
5. 接口定义
5.1 硬件接口（引脚定义、电平标准）
5.2 软件接口（API、通信协议）
6. 附录
6.1 用例图
6.2 状态机图
我的习惯：每个功能需求都要有唯一的编号，比如FR-001、FR-002。这样评审时可以直接说“FR-003这条有问题”，而不是“那个温度采集的功能”。你试试看，效率翻倍。
2.4 需求评审流程：别让Bug从源头溜进来
需求评审，说白了就是一群人坐在一起，把SRS从头到尾过一遍。但怎么过才有效？我踩过不少坑，总结下来就三步：
- 预审：提前把文档发下去，每人至少读一遍。我要求大家带着问题来开会，而不是现场读文档。
- 正式评审：逐条过需求。重点看三点——完整性（有没有遗漏）、一致性（前后矛盾吗）、可测试性（能验证吗）。
- 跟踪闭环：评审出的问题要有记录，要有负责人，要有截止日期。别开完会就完了。
我曾经踩过的坑：有一次评审时，硬件工程师说“这个ADC采样率没问题”，软件工程师也说“没问题”。结果联调时发现，ADC采样率太高，CPU根本处理不过来。为什么？因为硬件以为软件会做降采样，软件以为硬件会做硬件滤波。这就是需求里没写清楚接口协议。从那以后，我要求所有接口需求必须写清楚“谁负责什么、数据格式是什么、时序要求是什么”。
嗯，说到这，我想起一个更经典的案例。有个做智能水表的项目，需求里写了“支持远程抄表”。结果验收时发现，客户说的“远程”是指通过NB-IoT，而我们做的是Wi-Fi。你说谁对谁错？需求里没写通信方式，双方都有责任。所以，需求一定要具体到技术实现层面，别留模糊地带。
评审检查清单（我每次必用）：
- 每个功能需求都有对应的非功能需求吗？
- 异常情况有处理吗？（比如断网、掉电、数据溢出）
- 接口定义是否明确到引脚和协议？
- 所有需求都可测试吗？
- 有没有遗漏的边界条件？
最后说一句，需求分析不是一次性的工作。项目进行中，需求变更是常态。但每次变更，都要走评审流程，都要更新SRS。别嫌麻烦，我见过太多项目因为“改个小功能”没更新文档，最后整个系统推倒重来。
下一章，咱们聊聊系统架构设计。到时候我会分享一个我用了十年的架构模板，保证实用。