第二章 需求分析与管理：从模糊到精确的必修课
说实话，我见过太多项目栽在需求这个环节上。客户说“我要一个能跑的智能锁”，结果开发团队闷头干了三个月，做出来的东西客户根本不认。为什么会这样？因为“能跑”这个词，每个人理解都不一样。
这一章，我们就聊聊怎么把客户嘴里那些模棱两可的话，变成工程师能看懂、能执行的技术规格。这是整个项目的地基，地基歪了，后面再漂亮的代码也白搭。
2.1 从客户模糊需求中提取技术规格
客户通常不会说“我需要一个响应时间小于50ms的传感器接口”。他们更可能说“这个设备要反应快一点”。嗯，反应快一点——这怎么量化？
我自己的做法是三步走：倾听→追问→翻译。
2.1.1 倾听：别急着给方案
很多工程师有个毛病，客户刚说两句就开始想技术方案。我建议你先忍住。让客户把话说完，哪怕他说的全是业务场景，跟技术八竿子打不着。
比如客户说：“我们仓库的叉车经常撞到货架，想要个报警器。”你一听，哦，超声波测距嘛。但等等，客户真正想要的是“减少碰撞事故”，报警只是手段，不是目的。
2.1.2 追问：用5W1H挖出真需求
我习惯用5W1H来追问。拿上面那个例子：
- Who：谁用这个报警器？叉车司机？仓库管理员？
- What：报警器要提示什么？距离太近？速度太快？
- When：什么时候报警？倒车时？行驶中？
- Where：装在叉车上？还是货架上？
- Why：为什么不用现有的方案？成本问题？精度不够？
- How：怎么报警？声音？灯光？震动？
这一轮问下来，你会发现客户自己都没想到的细节。我曾经遇到一个客户，追问之后才发现，他们真正需要的是“在倒车时检测后方1.5米内的障碍物，并发出分级报警”——这才是能写进技术规格的东西。
2.1.3 翻译：把业务语言转成技术语言
这一步最考验功力。你需要把客户的业务需求，翻译成可测量、可验证的技术指标。
| 客户原话 | 翻译后的技术规格 |
|---|---|
| “反应要快” | 传感器采样周期 ≤ 20ms，从检测到报警输出延迟 ≤ 50ms |
| “要能防水” | 防护等级 ≥ IP65，通过30分钟喷淋测试 |
| “电池要耐用” | 待机电流 ≤ 10μA，连续工作续航 ≥ 72小时 |
| “操作要简单” | 用户交互步骤 ≤ 3步，按键反馈时间 ≤ 100ms |
我的经验：翻译的时候，尽量用数字说话。凡是能用“多少毫秒”、“多少微安”、“多少次”来描述的，就不要用“快”、“省电”、“耐用”这种模糊词。数字是工程师之间最没有歧义的语言。
2.2 需求文档的撰写：PRD与TRS
需求文档分两类：产品需求文档（PRD）和技术需求规格书（TRS）。很多人把这两者混为一谈，其实它们服务的对象不同。
2.2.1 PRD：写给产品经理和客户看的
PRD的核心是“做什么”。它描述的是产品的功能、行为、用户体验，不涉及具体的技术实现。比如：
- 用户按下按钮后，设备应在1秒内发出确认音
- 设备在低电量时，应通过LED闪烁提示用户
- 设备应支持通过手机App进行固件升级
写PRD的时候，我习惯用用户故事的格式：“作为一个[角色]，我希望[功能]，以便[价值]”。这样写出来的需求，客户看得懂，开发团队也知道为什么要做这个功能。
2.2.2 TRS：写给工程师看的
TRS的核心是“怎么做”。它把PRD里的每一条功能需求，拆解成具体的技术实现方案和验收标准。比如PRD里说“设备应支持固件升级”，TRS里就要写：
- 升级方式：通过BLE 5.0传输固件包，每次传输数据包大小256字节
- 升级协议：自定义OTA协议，包含CRC32校验和重传机制
- 升级失败处理：升级过程中断电，设备应能回滚到上一个可用版本
- 性能指标：完整升级时间不超过5分钟，升级成功率 ≥ 99.5%
注意：TRS里不要出现“可能”、“大概”、“尽量”这类词。每一条技术规格都必须是可测试的。如果你写不出测试方法，说明这条规格还不够具体。
2.3 需求追踪矩阵（RTM）的建立
RTM是什么？说白了，就是一张对照表。它把客户需求、PRD条目、TRS条目、测试用例、代码模块全部串起来。有了它，你就能回答三个问题：
- 每个客户需求，有没有对应的技术实现？
- 每个技术实现，有没有对应的测试用例？
- 测试覆盖了所有需求吗？有没有遗漏？
2.3.1 RTM的结构
我常用的RTM表格长这样：
| 需求ID | 客户需求描述 | PRD条目 | TRS条目 | 测试用例ID | 测试结果 | 状态 |
|---|---|---|---|---|---|---|
| REQ-001 | 设备反应要快 | PRD-1.1 | TRS-1.1.1 | TC-001 | 通过 | 已实现 |
| REQ-002 | 要能防水 | PRD-1.2 | TRS-1.2.1 | TC-002 | 待测试 | 已实现 |
| REQ-003 | 电池要耐用 | PRD-1.3 | TRS-1.3.1 | TC-003 | 未通过 | 修改中 |
你看，每一行都是一个完整的追溯链。从客户说“电池要耐用”，到测试发现“待机电流超标”，整个过程一目了然。
2.3.2 建立RTM的时机
我建议在需求评审通过后立即建立RTM。不要等到开发快结束了才想起来做这件事。那时候再补RTM，你会发现很多需求已经走样了，或者根本没人记得当初为什么要做某个功能。
核心原则：RTM不是事后记录，而是过程管理工具。它应该随着项目进展持续更新。每次需求变更，都要同步更新RTM，确保追溯链不断裂。
2.4 需求分析流程总览
下面这张图，是我自己总结的需求分析流程。它把从客户沟通到RTM建立的整个链条串起来了。
这个流程看起来是线性的，但实际上，需求分析是一个反复迭代的过程。你可能在写TRS的时候，发现某个需求没法量化，又得回头去跟客户沟通。这很正常，别怕返工。前期多花点时间把需求理清楚，后期能省下十倍的时间。
2.5 避坑指南
最后，分享几个我踩过的坑：
- 别替客户做决定：我曾经觉得某个功能“肯定不需要”，就直接跳过了。结果客户验收时发现没有，差点翻脸。记住，需求分析不是猜谜，是沟通。
- 别忽略非功能需求：很多项目只关注功能，忽略了功耗、可靠性、可维护性这些非功能需求。等产品量产了才发现电池撑不过一天，那时候改就晚了。
- 别让RTM变成摆设：我见过有人把RTM建好后就扔在一边，直到项目结束才拿出来填。那还不如不建。RTM要跟着项目走，每次需求变更、每次测试完成，都要更新它。
一个小技巧：在项目启动会上，把RTM投影出来，让所有团队成员都看到。这样每个人都知道自己的工作在整条追溯链中的位置。责任清晰了，推诿就少了。
需求分析这件事，说难不难，说简单也不简单。关键就两个字：较真。对每一个模糊的词较真，对每一个不确定的指标较真，对每一条追溯链较真。做到位了，项目就成功了一半。