第二章 需求分析入门：如何读懂产品需求文档（PRD）
说实话，很多硬件工程师一看到PRD就头疼。
几十页的文档，密密麻麻的文字，还有一堆看不懂的业务术语。我刚开始带项目那会儿，也踩过这个坑。有一次，我拿到一份PRD，扫了两眼就开干了。结果做到一半，产品经理跑过来说：「这个功能不是这样的啊！」——嗯，从那以后，我再也不敢跳过需求分析了。
2.1 什么是PRD？它到底长什么样？
PRD，全称Product Requirements Document，产品需求文档。说白了，就是产品经理把脑子里的想法，变成一份白纸黑字的说明书。
一份标准的PRD，通常包含这几块内容：
- 项目背景：为什么要做这个产品？解决什么问题？
- 用户场景：谁在用？怎么用？在什么环境下用？
- 功能列表：产品要具备哪些功能？优先级怎么排？
- 性能指标：响应时间、功耗、精度……这些硬指标是多少？
- 约束条件：成本上限、尺寸限制、认证要求等等。
你可能会问：「这些不都是产品经理的事吗？跟我硬件工程师有什么关系？」
关系大了去了。你想想看，如果PRD里写了一句「设备需支持远程升级」，那你作为硬件工程师，就得考虑要不要加Wi-Fi模块、要不要预留OTA接口、Flash容量够不够……这些全是硬件层面的决策。
核心观点：PRD不是给产品经理一个人看的。它是整个团队的「宪法」。硬件、软件、结构、测试，所有人都得按这个来。
2.2 如何高效读懂PRD？我的三步法
我个人习惯，拿到一份PRD后，不会从头读到尾。那样太慢了，而且容易迷失在细节里。我一般分三步走：
第一步：先看「背景」和「目标」
这两部分通常在文档最前面。花10分钟看完，你就能回答三个问题：
- 这个产品是给谁用的？
- 它要解决什么痛点？
- 成功的标准是什么？
我在项目中遇到过一种情况：产品经理写「提升用户体验」，但没写具体指标。后来我追问才知道，原来是要把开机时间从10秒降到3秒以内。你看，这个信息对硬件选型影响多大？
第二步：圈出「硬件相关」的功能点
PRD里很多内容是软件和业务层面的。你不需要全看懂，但要把跟硬件相关的部分圈出来。比如：
- 需要哪些传感器？
- 通信方式是什么？蓝牙？Wi-Fi？4G？
- 供电方式？电池还是市电？续航要求？
- 有没有特殊环境要求？防水？防尘？高温？
小技巧：我习惯用不同颜色的荧光笔标记。红色代表「必须满足」，黄色代表「待确认」，绿色代表「已明确」。这样回头跟产品经理对需求时，一目了然。
第三步：找出「模糊地带」和「矛盾点」
PRD写得再详细，也一定有模糊的地方。比如「响应要快」——多快算快？「功耗要低」——多低算低？这些模糊地带，就是你需要跟产品经理确认的地方。
我曾经遇到过一个经典矛盾：PRD里既要求「电池续航30天」，又要求「屏幕常亮显示」。这两个需求放在一起，基本不可能实现。后来我们开了三次会，才达成妥协——屏幕改成「抬腕亮屏」模式。
2.3 需求分解：把「大需求」拆成「小任务」
读懂PRD只是第一步。接下来，你要把那些笼统的需求，拆成一个个可执行的任务。这个过程，我称之为「需求分解」。
举个例子：PRD里写「设备需支持OTA升级」。
这个需求听起来很简单，对吧？但拆开来看，它包含：
- 硬件层面：需要Wi-Fi或蓝牙模块，Flash容量至少2MB，MCU要支持在线编程。
- 软件层面：需要Bootloader程序，升级协议，断点续传机制。
- 结构层面：天线位置、散热设计、外壳是否需要开孔。
- 测试层面：升级成功率测试、异常断电测试、版本回退测试。
你看，一个「OTA升级」，拆出来至少十几个子任务。每个子任务都要有人负责，都要有明确的交付标准。
我的经验：需求分解做得越细，后期返工的概率就越低。我一般会用一个Excel表格，把每个子任务列出来，标注负责人、预计工时、依赖关系。这个表格，就是后续项目管理的「作战地图」。
2.4 功能定义：把「要做什么」变成「怎么做」
需求分解之后，下一步是功能定义。这一步，是把「产品要做什么」翻译成「硬件要怎么做」。
举个例子：PRD里说「设备需支持指纹识别」。
功能定义阶段，你要回答这些问题：
- 用光学指纹还是电容指纹？
- 识别速度要求多少？<1秒？<0.5秒？
- 误识率（FAR）和拒真率（FRR）的指标是多少？
- 指纹模组的接口是什么？SPI？I2C？UART？
- 是否需要活体检测功能？
这些问题的答案，最终会写进你的硬件设计方案里。我习惯用一张表格来整理功能定义：
| PRD需求 | 硬件功能定义 | 关键参数 | 备注 |
|---|---|---|---|
| 指纹识别 | 电容式指纹模组 | 识别速度<0.5s，FAR<0.001% | 需支持活体检测 |
| 远程升级 | Wi-Fi模块+OTA Bootloader | Flash≥4MB，支持断点续传 | 需考虑升级失败回退 |
| 低功耗待机 | MCU深度睡眠模式 | 待机电流<10μA | 需RTC唤醒 |
注意：功能定义阶段，一定要跟软件工程师、结构工程师对齐。我曾经吃过一次亏：我选了一颗性能很强的指纹芯片，结果软件那边说驱动库不兼容，最后只能换方案，白白浪费了两周时间。
2.5 输出需求规格说明书（SRS）
需求分解和功能定义都做完之后，最后一步，就是输出一份正式的文档——需求规格说明书（Software/System Requirements Specification，SRS）。
SRS和PRD有什么区别？
- PRD是产品经理写的，面向整个团队，讲的是「要做什么」。
- SRS是硬件工程师写的，面向研发团队，讲的是「具体怎么做」。
一份合格的SRS，至少包含以下内容：
- 硬件架构概述：系统框图、模块划分、接口定义。
- 详细功能规格：每个功能模块的具体参数、性能指标。
- 电气特性：供电电压、电流消耗、IO电平、时序要求。
- 环境要求：工作温度范围、湿度、防护等级。
- 认证要求：CE、FCC、UL等认证标准。
- 接口定义：所有对外接口的引脚定义、通信协议。
我的习惯：SRS写完之后，我会组织一次「需求评审会」。叫上产品经理、软件工程师、测试工程师，大家一起过一遍。别怕被挑毛病，评审会上发现的问题，总比流片回来再改要便宜得多。
2.6 本章小结
需求分析这件事，听起来很「软」，但它直接决定了硬件设计的成败。我见过太多项目，就是因为需求没搞清楚就开干，结果做到一半发现方向错了，只能推倒重来。
记住三个关键词：读懂PRD、拆解需求、定义功能。这三步走扎实了，后面的原理图设计、PCB Layout、调试测试，才会顺风顺水。
下一章，我们会聊聊「系统架构设计」——怎么把需求变成一张实实在在的硬件框图。到时候见。