第三章：需求分析文档——功能需求与非功能需求
好，咱们今天聊聊需求分析文档。说实话，我见过太多项目栽在需求不清上。有一次我接手一个智能家居项目，硬件都打样了，结果发现客户要的是蓝牙Mesh，我们做的是Zigbee……嗯，那感觉，就像菜都下锅了才发现要换食材。
所以，需求分析文档必须写清楚。它分两大类：功能需求和非功能需求。我一个个说。
3.1 功能需求
功能需求，说白了就是“系统要做什么”。比如：
- 用户按下按键，LED亮起
- 传感器每100ms采集一次数据
- 通过UART发送“OK”字符串
我个人习惯用用例图加文字描述来写。光画图不行，文字要写清楚前置条件、后置条件、异常流程。举个例子：
用例：温湿度上报
- 前置条件：传感器初始化成功，WiFi已连接
- 正常流程：每60秒读取一次温湿度 → 打包成JSON → 通过MQTT发布到云端
- 异常流程：读取失败 → 重试3次 → 仍失败则记录错误日志，LED闪烁红色
我在项目中遇到过，有人只写了“上报数据”，结果没定义上报周期和失败处理。后来现场测试，数据丢了一半才发现。所以，异常流程一定要写，这是血的教训。
3.2 非功能需求
非功能需求，就是“系统要跑得多好”。它往往比功能需求更隐蔽，但坑更深。我把它拆成几个维度：
| 维度 | 说明 | 示例 |
|---|---|---|
| 性能 | 响应时间、吞吐量 | 按键响应 < 50ms |
| 可靠性 | MTBF、故障恢复时间 | 系统连续运行7天不重启 |
| 可维护性 | 代码模块化、日志可读 | 支持远程日志级别动态调整 |
| 安全性 | 加密、防篡改 | 固件升级包必须签名验证 |
| 功耗 | 电池续航、休眠电流 | 待机电流 < 10μA |
你想想看，如果只写了功能需求，没写功耗要求，结果产品做出来电池只能用半天——那功能再全也没用。我曾经有个项目，客户说“要低功耗”，但没给具体数字。我们按经验做到50μA，结果客户期望是10μA……最后只能重新改板子，工期拖了一个月。
避坑指南：非功能需求一定要量化。别写“响应要快”，要写“按键响应时间不超过50ms”。别写“要省电”，要写“待机电流小于10μA”。数字越具体，后期扯皮越少。
3.3 需求文档模板
我整理了一个模板，这些年一直在用。你直接拿去改改就能用：
# 嵌入式软件需求文档
## 1. 项目概述
- 产品名称：
- 版本号：
- 编写人/日期：
## 2. 功能需求
### 2.1 用例列表
| 用例编号 | 用例名称 | 优先级 | 关联硬件 |
|----------|----------|--------|----------|
| UC-001 | 按键控制LED | 高 | GPIO |
### 2.2 详细用例描述
（按3.1节的格式写）
## 3. 非功能需求
### 3.1 性能指标
### 3.2 可靠性要求
### 3.3 功耗要求
### 3.4 安全要求
## 4. 接口定义
- 硬件接口：引脚分配、通信协议
- 软件接口：API函数原型、回调函数
## 5. 约束条件
- 开发工具链版本
- 芯片选型限制
- 成本预算这个模板的好处是，每个需求都有唯一编号。后面做测试、做追踪，全靠这个编号。我习惯用“UC-”开头表示用例，“NFR-”开头表示非功能需求。这样一看编号就知道是哪类需求。
3.4 需求追踪矩阵
需求追踪矩阵，英文叫Requirements Traceability Matrix，简称RTM。它就是个表格，把需求、设计、测试、代码全串起来。
为什么要做这个？我讲个真实案例。有一次项目验收，客户问：“你们怎么证明每个需求都实现了？”我们拿出RTM，从需求编号一路查到测试用例编号，再查到代码提交记录。客户一看，服了。要是没这个矩阵，光靠嘴说“我们做了”，谁信呢？
RTM长这样：
| 需求编号 | 需求描述 | 设计文档章节 | 测试用例编号 | 代码模块 | 状态 |
|---|---|---|---|---|---|
| UC-001 | 按键控制LED | 4.2.1 | TC-001 ~ TC-003 | gpio_driver.c | 已实现 |
| NFR-001 | 待机电流 < 10μA | 5.3 | TC-101 | power_mgr.c | 已验证 |
我的小技巧：RTM最好用Excel或在线表格维护。每次需求变更，立刻更新矩阵。别等到项目后期再补，那时候根本补不全。我曾经吃过这个亏，补了三天三夜，眼睛都快瞎了。
另外，RTM里的“状态”列很重要。我一般用这几个状态：
- 已定义：需求刚写出来，还没开始做
- 设计中：正在做方案设计
- 已实现：代码写完了
- 已验证：测试通过了
- 已废弃：需求被砍掉了
这样一看，项目进度一目了然。老板问起来，你直接说“还有3个需求在设计中，2个在验证”，比说“快了快了”强一百倍。
好了，需求分析文档这块就聊到这儿。记住三句话：功能需求写清楚做什么，非功能需求写清楚做多好，RTM把一切串起来。下一章咱们聊系统架构设计，到时候见。