3、需求文档规范：需求文档模板（BRD/PRD）、需求优先级划分（MoSCoW方法）、需求可追溯性矩阵
说实话，做了十几年嵌入式项目，我见过太多「做着做着就偏了」的项目。原因在哪？十有八九是需求没理清楚。你想想看，一个需求文档写得像散文，开发靠猜，测试靠蒙，最后产品出来跟客户要的完全是两码事。嗯，今天我们就来聊聊怎么把需求文档这件事做扎实。
3.1 需求文档模板：BRD 与 PRD
先说说两个最常见的文档：BRD 和 PRD。很多人分不清，其实很简单。
BRD（商业需求文档），说白了就是回答「为什么要做这个产品」。它的读者是老板、投资人、市场部门。我习惯在 BRD 里只写三件事：市场机会、商业价值、投入产出比。别扯技术细节，老板不关心你用 STM32 还是 ESP32。
PRD（产品需求文档），这才是我们嵌入式工程师的主战场。它回答的是「产品具体要做什么」。我见过最烂的 PRD 就是抄了一堆竞品功能列表，完全没考虑硬件约束。
我个人习惯的 PRD 模板长这样：
# PRD：智能温控器 V2.0
## 1. 版本历史
| 版本 | 日期 | 修改人 | 变更说明 |
|------|------|--------|----------|
| V1.0 | 2024-01-10 | 张三 | 初稿 |
| V1.1 | 2024-01-15 | 李四 | 增加低功耗模式需求 |
## 2. 功能需求
- F001：温度采集精度 ±0.5°C
- F002：支持 Wi-Fi 远程控制
- F003：本地 OLED 显示
## 3. 非功能需求
- N001：待机功耗 < 50μA
- N002：响应时间 < 200ms
- N003：工作温度 -20°C ~ 85°C
## 4. 硬件约束
- MCU：STM32L4 系列
- Flash：256KB
- RAM：64KB
3.2 需求优先级划分：MoSCoW 方法
需求永远做不完，资源永远不够用。怎么办？分优先级。
MoSCoW 方法是我最常用的工具。它把需求分成四类：
| 分类 | 含义 | 嵌入式场景举例 |
|---|---|---|
| Must have | 必须有，没有产品无法交付 | 系统启动、基本传感器采集 |
| Should have | 应该有，但可以找替代方案 | OTA 升级（可用串口升级替代） |
| Could have | 可以有，锦上添花 | 语音播报、炫酷动画 |
| Won't have | 这次不做，以后再说 | AI 预测算法、云端大数据分析 |
为什么会这么分？因为嵌入式项目有个特点：硬件定型后，改不了。你想想看，如果 PCB 打样回来了，发现 Flash 不够，那可不是改几行代码能解决的。
我曾经犯过一个错：在一个智能门锁项目里，把「人脸识别」标成了 Should have。结果硬件选型时选了低性能 MCU，后来发现跑不动算法，只能外挂协处理器，成本直接翻倍。从那以后，我定优先级时一定会拉上硬件工程师一起过一遍。
核心原则：Must have 的需求，必须在硬件选型阶段就确认可行性。Should have 和 Could have 的需求，可以留到软件迭代中逐步实现。
3.3 需求可追溯性矩阵
这个名词听起来很唬人，其实就是一个表格。它的作用是：从需求到代码，从代码到测试，每一步都能追回来。
我见过最惨的案例：一个医疗设备项目，客户投诉说某个功能没实现。结果一查，需求文档里写了，但开发漏了，测试也没测到。最后赔了钱还丢了客户。嗯，这就是没有可追溯性矩阵的后果。
一个标准的 RTM（需求可追溯性矩阵）长这样：
| 需求 ID | 需求描述 | 优先级 | 设计文档 | 代码模块 | 测试用例 | 状态 |
|---|---|---|---|---|---|---|
| F001 | 温度采集精度 ±0.5°C | M | DS_ADC_001 | temp_driver.c | TC_TEMP_001~005 | 已通过 |
| F002 | Wi-Fi 远程控制 | M | DS_WIFI_001 | wifi_manager.c | TC_WIFI_001~010 | 开发中 |
| F003 | 本地 OLED 显示 | S | DS_OLED_001 | oled_display.c | TC_OLED_001~003 | 未开始 |
怎么用这个矩阵？很简单：
- 开发阶段：每实现一个需求，就在「代码模块」列里填上对应的文件路径
- 测试阶段：测试人员根据 RTM 编写测试用例，确保每个需求都有对应的测试
- 验收阶段：客户问「这个功能做了吗？」直接查 RTM，一目了然
说白了，RTM 就是项目的「账本」。每一笔需求，从提出到交付，都有据可查。你想想看，如果每个项目都有这么一张表，还会出现「需求漏了没人知道」的情况吗？
我的习惯：RTM 用 Excel 或者在线表格做，方便多人协作。但一定要有版本控制，别让两个人同时改同一个单元格。我一般会在表格里加一列「修改人」和「修改时间」，谁改了什么，一目了然。
最后说一句：需求文档不是写给别人看的，是写给自己和团队用的。写得清楚，项目就顺；写得模糊，后面全是坑。嗯，今天就聊到这，下一章我们讲讲系统设计文档怎么写。