2、需求文档规范：需求文档的结构、功能需求与非功能需求、需求优先级划分

好，咱们接着聊需求文档。说实话，我见过太多项目栽在需求不清晰上。有的团队上来就写代码，写到一半发现需求理解错了，那叫一个痛苦。我个人习惯是，不管项目多急，先把需求文档立住。今天咱们就掰开揉碎了讲讲，一份靠谱的需求文档到底该怎么写。

2.1 需求文档的结构：骨架要硬

一份好的需求文档，结构得像人的骨架一样清晰。你想想看，如果骨架歪了，后面再怎么填肉也长不正。我一般会把文档分成这么几块：

• 项目背景与目标：为什么要做这个？解决什么问题？
• 范围定义：做哪些，不做哪些。这个特别重要，能避免后期扯皮。
• 功能需求：系统要“做什么”。
• 非功能需求：系统要“做得怎么样”。
• 接口定义：跟外部怎么交互。
• 约束条件：硬件资源、成本、时间等限制。

我在项目中遇到过，有人把功能需求和非功能需求混在一起写，结果评审的时候大家吵成一团。后来我强制要求分开，效率高多了。

2.2 功能需求与非功能需求：一个都不能少

很多新手容易忽略非功能需求。说白了，功能需求是“能不能用”，非功能需求是“好不好用”。

功能需求

功能需求描述的是系统对外表现的行为。比如：

• 系统上电后，LED 指示灯应在 2 秒内点亮。
• 用户按下按键后，蜂鸣器响 500ms。
• 系统每 100ms 采集一次传感器数据。

写功能需求时，我建议用“主语 + 动作 + 条件 + 结果”的句式。举个例子：

// 不好的写法
系统应该能处理按键输入。

// 好的写法
当用户按下按键 S1 并保持超过 50ms 时，系统应进入配置模式，同时 LED1 以 1Hz 频率闪烁。

你看，后者明确多了。测试人员拿到这个需求，直接就能写测试用例。

非功能需求

非功能需求往往决定了一个产品的成败。我记得有一次做工业控制器，功能都跑通了，结果现场温度一高，系统就死机。这就是非功能需求没写清楚。

常见的非功能需求包括：

2.3 需求优先级划分：别什么都想做

做嵌入式系统，资源永远是有限的。CPU 算力有限，内存有限，开发时间也有限。所以需求必须分优先级。我个人习惯用 MoSCoW 方法：

• M - Must have：必须有，没有产品就废了。比如“系统能正常启动”。
• S - Should have：应该有，但可以延迟。比如“支持 OTA 升级”。
• C - Could have：可以有，锦上添花。比如“支持多国语言菜单”。
• W - Won't have：这次不做，以后再说。比如“支持蓝牙 5.0”。

你想想看，如果所有需求都是 Must have，那跟没有优先级有什么区别？我见过一个项目，产品经理把所有需求都标成 P0，结果开发团队累死累活，最后还是延期了。

这里有个实用的做法：

1. 先列出所有需求。
2. 跟产品、测试、硬件一起评审，每人给每个需求打分（1-5分）。
3. 算平均分，分数最高的就是 Must have。
4. 如果 Must have 太多，砍！砍到团队能在规定时间内完成。

2.4 避坑指南：我踩过的那些坑

嗯，这里我要多说几句。写需求文档这么多年，我踩过的坑真不少。

• 坑一：需求太模糊。比如“系统要稳定”。什么叫稳定？是 7x24 小时不重启，还是掉电后数据不丢失？一定要写清楚。
• 坑二：需求变更不记录。我曾经有个项目，客户口头说改个参数，我顺手就改了。结果后来测试发现对不上，查了半天才发现是需求变了。从那以后，任何变更都必须走文档流程。
• 坑三：忽略边界条件。比如“按键按下时执行操作”，那如果按键按了 10 秒不松手呢？系统应该怎么处理？这些边界条件一定要写进需求里。

最后说一句，需求文档不是写完了就完事了。它要跟着项目走，不断更新、评审、确认。只有这样，后面的设计、开发、测试才有据可依。

好，这一章就到这里。下一章咱们聊聊需求追踪矩阵，那是个好东西，能把需求和测试用例串起来，谁用谁知道。