第二章 需求分析与规格定义：从客户需求到技术指标
做单片机开发这么多年，我见过太多项目死在需求不清晰上。客户说「我要一个智能温控器」，结果做出来发现他要的是能联网、能学习、还能语音控制的。你说这锅该谁背？
说白了，需求分析就是给项目画个圈。圈里的事我们做，圈外的事不做。这个圈画得好不好，直接决定了后面几个月的开发节奏。
2.1 客户需求 vs 技术指标
客户说的话，和我们工程师理解的东西，中间差着十万八千里。举个例子：
客户说：「这个设备响应要快。」
我们得问：「快是多少？100ms？10ms？还是1ms？」
客户说：「电池要耐用。」
我们得问：「待机多久？工作多久？用多少毫安时的电池？」
我个人习惯，拿到客户需求后先做一件事：把每一条「人话」翻译成「机器话」。
| 客户原话 | 技术指标 |
|---|---|
| 操作要流畅 | 按键响应 ≤ 50ms，界面刷新 ≥ 30fps |
| 数据不能丢 | Flash写入失败重试3次，CRC校验，掉电保护 |
| 要能远程升级 | 支持OTA，Bootloader空间预留32KB，通信协议自定义 |
我在项目中遇到过最坑的一次：客户说「要支持多种传感器」。结果我们做了5种，他最后只用了2种。剩下3种白白浪费了2周的开发时间。从那以后，我要求所有传感器支持列表必须白纸黑字写进合同。
2.2 需求文档怎么写
很多新手觉得需求文档就是流水账。其实不是。一份好的需求文档，应该让任何一个新来的工程师看完就知道：
- 这个产品要干什么
- 不干什么
- 做到什么程度算合格
我常用的模板分三块：
2.2.1 功能需求
这里写「做什么」。比如：
- 支持4路模拟量采集（0-10V，精度0.5%）
- 支持2路PWM输出（频率1kHz-100kHz可调）
- 支持RS485通信（Modbus RTU协议，波特率9600-115200）
注意，每一条都要可验证。什么叫可验证？就是测试工程师能拿仪器测出来。你说「精度高」，那不行。你说「精度±0.5%」，这才行。
2.2.2 非功能需求
这里写「做到什么程度」。比如：
- 工作温度：-20℃ ~ +85℃
- ESD防护：接触放电±6kV，空气放电±8kV
- 平均无故障时间：≥50000小时
嗯，这里要注意。非功能需求往往比功能需求更烧钱。我曾经为了满足一个「-40℃低温启动」的需求，把整个电源方案都换了。所以写的时候一定要和硬件团队确认可行性。
2.2.3 功能边界
这个最容易忽略，也最容易出问题。说白了就是：哪些事我们不干。
举个例子：
- 本设备不负责数据上云（需配合网关使用）
- 本设备不支持热插拔
- 本设备不兼容第三方传感器
你想想看，如果不写清楚边界，客户验收时突然说「为什么不能连阿里云？」你怎么办？
核心原则：需求文档不是写给客户看的，是写给开发团队和测试团队看的。所以不要用「方便」「快速」「智能」这种虚词。每个指标都要能量化、可测试。
2.3 从需求到架构的映射
需求文档写完了，接下来就是把它变成软件架构。这一步很多人跳过去直接写代码，结果后面改得死去活来。
我的做法是：先画一张功能模块图。
比如一个温控器项目：
- 输入模块：温度传感器、按键
- 控制模块：PID算法、状态机
- 输出模块：继电器、显示屏、蜂鸣器
- 通信模块：RS485、WiFi（可选）
- 管理模块：参数存储、日志记录、OTA升级
每个模块对应需求文档里的几条需求。如果发现某个需求没有模块对应，要么是漏了，要么是需求不合理。
小技巧：我习惯用Excel建一个「需求-模块-接口」对照表。每条需求对应哪个模块、模块之间怎么通信、数据格式是什么，一目了然。后期做测试用例也方便。
2.4 避坑指南
做需求分析这么多年，踩过的坑能写一本书。挑几个典型的说说：
坑一：需求镀金
客户说「最好能支持」，工程师一听就来劲了，加了一堆功能。结果项目延期、成本超支。我曾经就干过这种事——客户随口提了一句「要是能蓝牙控制就好了」，我花了两周把蓝牙模块加上去。最后客户说「哦，我就随便说说」。
对策：所有需求必须书面确认。口头说的不算。
坑二：忽略异常场景
需求文档里写的全是正常情况。但嵌入式设备天天面对各种异常：掉电、通信中断、传感器失效、按键抖动...这些不写清楚，测试阶段就是灾难。
对策：写需求时多问自己「如果...怎么办？」。比如：如果传感器断线了，输出保持上次值还是归零？
坑三：需求变更不管理
项目做了一半，客户说「加个功能」。不加吧，得罪客户。加吧，进度全乱。我见过最夸张的，一个项目改了17次需求，最后做出来的东西和最初完全不一样。
对策：建立变更流程。每次变更都要评估影响范围、工作量、风险，然后签字确认。别不好意思，这是保护自己。
2.5 实战案例：一个智能水表的需求分析
拿我去年做的一个项目举例。客户需求很简单：「做一个智能水表，能远程抄表。」
我们团队花了三天做需求分析，最后输出了一份20页的文档。这里挑几个关键点：
| 客户需求 | 技术指标 | 备注 |
|---|---|---|
| 远程抄表 | NB-IoT通信，每天上报一次，数据包含：累计流量、瞬时流量、电池电压、信号强度 | 上报失败需本地存储，下次上报时补传 |
| 电池寿命长 | 2节ER18505锂电池，工作≥6年 | 待机电流≤5μA，上报峰值电流≤200mA |
| 防拆功能 | 磁感应开关检测，拆盖后10秒内上报报警 | 报警信息优先于普通数据上报 |
| 本地显示 | 段码LCD，显示累计流量、瞬时流量、电池电量 | 按键唤醒显示，10秒无操作自动休眠 |
你看，每条需求都变成了可量化的指标。测试工程师拿到这份文档，直接就能写测试用例。开发工程师也知道每个模块要做到什么程度。
最后说一句：需求分析花的时间，会在后面十倍百倍地省回来。别急着写代码，先把需求搞清楚。这是我用无数次加班换来的教训。