简介：这份文档资料面向硬件产品经理、设计研发及测试人员，系统梳理硬件产品需求文档的编写思路与方向，帮助团队在项目初期建立统一认知，避免因需求细节堆叠而造成的理解偏差。内容围绕项目简介、使用场景、产品原则、硬件组成及关系、功能性需求、性能需求、接口需求、存储需求、安全需求、机械电子设计需求、环境要求、设计约束条件等十余个维度展开，并延伸至可生产性、可测试性、外购元器件、内外部技术合作与嵌入式固件要求，配有功能框架图与硬件框架图辅助说明。资源包内含1个docx文档，约440KB，结构完整、条理清晰，适合作为需求文档撰写的参考模板与自查清单。目前已有173人学习，可帮助读者快速掌握需求文档的模块划分与撰写要点，提升跨团队协作效率。
1. 硬件产品需求文档的编写思路与方向：为什么你的PRD总被研发怼回来
画过板子、跟过模具、催过打样的硬件产品经理，大概率都经历过这个场景：一份自认为写得很全的硬件需求文档丢进群里，结构工程师回一句“这个尺寸跟上次说的不一样”，电子工程师问“工作温度到底按哪个标准”，采购说“这颗料交期52周你知不知道”。问题不在技术能力，而在需求文档没有把“谁在什么条件下要做什么”锁死。硬件产品需求文档（很多团队直接叫硬件PRD）和软件PRD最大的区别是：软件改一行代码就能发版，硬件改一个丝印可能报废一整批PCBA。所以硬件PRD的核心不是“描述功能”，而是“冻结约束”——把电气参数、机械边界、环境条件、认证要求、成本区间、生命周期这些硬约束在开模开板之前定下来。这篇文章面向的是正在从0到1定义一款硬件产品的人：消费电子、工业设备、物联网终端都适用。我会按“先想清楚要写什么→再动手写→最后怎么验证和迭代”的顺序，把每个环节的模板、参数表、评审检查点拆开讲，让你看完能直接套用到自己手上的项目里。
2. 先搞清楚硬件PRD到底要锁住哪些东西
2.1 硬件PRD和软件PRD的本质差异
软件PRD可以容忍模糊，因为迭代成本低。硬件不行。一颗MCU选型错了，从打样到量产导入至少6到8周；一个结构倒扣设计错了，模具修模费用起步五位数。所以硬件PRD的第一原则是：所有下游环节依赖的输入，必须在文档里有唯一确定的答案。
具体来说，硬件PRD要锁住的东西分五层：
- 功能层：产品要做什么，用户交互流程是什么，有哪些工作模式。
- 电气层：供电方式、功耗预算、接口协议、信号电平、EMC要求。
- 机械层：外形尺寸、重量、安装方式、接口位置、散热路径。
- 环境层：工作温度、存储温度、防护等级、跌落和振动标准。
- 商务层：目标BOM成本、目标零售价、认证清单、量产时间节点。
这五层里，功能层最像软件PRD，但后面四层才是硬件PRD真正的“骨头”。很多从互联网转过来的产品经理写硬件PRD时，功能描述写了二十页，电气参数只有一句“支持USB供电”，结果就是硬件工程师反复来问，项目周期被拉长。
2.2 需求来源的四个渠道和优先级判定
硬件产品的需求不是拍脑袋来的。常见来源有四类：
| 来源 | 典型输入 | 优先级 | 注意事项 |
|---|---|---|---|
| 市场/客户 | 招标参数、客户痛点反馈 | 高 | 要区分“想要”和“必须” |
| 竞品拆解 | 拆机报告、BOM成本反推 | 中 | 不能直接抄，要理解设计意图 |
| 内部战略 | 平台化规划、供应链议价 | 中 | 容易和市场需求冲突 |
| 法规/认证 | 强制标准、行业准入 | 最高 | 不满足直接出局 |
优先级判定的实操方法是：把每条需求标注为“必须满足（M）”“应该满足（S）”“可以满足（C）”。M类需求如果做不到，项目直接停；S类需求做不到，需要产品负责人签字确认；C类需求排期时看资源。这个MoSCoW方法在硬件项目里特别管用，因为硬件资源（模具费、认证费、打样次数）都是真金白银，不能什么都想要。
2.3 一份可执行的硬件PRD最小结构
我一般会把硬件PRD分成八个模块，按这个顺序写：
- 产品概述（一句话定义、目标用户、核心场景）
- 功能需求（工作模式、交互逻辑、状态机）
- 电气规格（供电、功耗、接口、关键器件选型约束）
- 机械规格（尺寸、重量、材质、安装）
- 环境与可靠性（温度、湿度、防护、寿命）
- 认证与合规（必须过的认证清单）
- 成本与进度（BOM目标、关键里程碑）
- 附录（术语表、参考文档、变更记录）
这个结构不是死的，但顺序有讲究：先功能后电气再机械，因为电气选型影响功耗和尺寸，机械又受电气布局约束。写反了，后面全是返工。
3. 动手写：从功能描述到电气参数表的落地方法
3.1 功能需求怎么写才不被研发追问
功能需求最常见的翻车是“只写正常流程，不写异常和边界”。比如“设备支持WiFi配网”，研发会问：配网超时多久？配网失败怎么提示？配网过程中断电怎么恢复？同时配网多个设备怎么处理？
我的做法是用状态机的方式写功能。每个功能模块画一个状态转移表，列出状态、触发条件、动作、异常处理。用文字表格就行，不需要画图。
以“按键开关机”为例：
| 当前状态 | 触发事件 | 动作 | 异常处理 |
|---|---|---|---|
| 关机 | 长按3s | 开机，LED常亮 | 电量低于3%时红灯闪3次后关机 |
| 开机 | 长按3s | 关机，保存状态 | 系统忙时延迟500ms执行 |
| 开机 | 短按 | 切换模式 | 无 |
| 任意 | 长按10s | 强制重启 | 不保存状态 |
这种写法研发一看就懂，测试也能直接拿来做用例。关键是“异常处理”那一列，逼着你在写文档阶段就想清楚边界。
3.2 电气规格的参数表和选型约束
电气规格是硬件PRD里最“硬”的部分。不要写“低功耗”，要写“待机电流小于50μA，工作电流峰值不超过200mA，平均电流小于15mA”。参数要带测试条件，否则没有意义。
我常用的电气规格表模板：
| 参数 | 符号 | 最小值 | 典型值 | 最大值 | 单位 | 测试条件 |
|---|---|---|---|---|---|---|
| 供电电压 | VCC | 4.5 | 5.0 | 5.5 | V | 适配器输入 |
| 待机电流 | Istb | — | 30 | 50 | μA | 25℃，无负载 |
| 工作电流 | Iop | — | 120 | 200 | mA | WiFi连续传输 |
| 电池容量 | Cbat | — | 2000 | — | mAh | 标称值 |
| 充电时间 | Tchg | — | 2.5 | 3.0 | h | 0到80% |
选型约束也要写进去。比如“MCU必须支持至少2路UART、1路SPI、1路I2C，Flash不小于256KB，封装不大于QFN48”。这些约束不是让你指定具体型号，而是给硬件工程师划一个可选范围。如果你已经有倾向性选型，可以写“推荐XX系列，但需评估交期和成本”。
提示：电气参数一定要标注测试条件。没有测试条件的“待机电流50μA”和“待机电流50μA@25℃、3.7V输入、无外设使能”是两回事，后者才能写进测试报告。
3.3 机械规格和环境可靠性的写法
机械规格的核心是“接口边界”。外形尺寸、安装孔位、接口位置和朝向、按键和指示灯位置，这些必须给到结构工程师。我一般会附一张标注了关键尺寸的2D图，文档里用表格列出关键尺寸和公差。
| 项目 | 标称值 | 公差 | 备注 |
|---|---|---|---|
| 整机长度 | 120mm | ±0.5mm | — |
| 整机宽度 | 65mm | ±0.5mm | — |
| 整机厚度 | 18mm | ±0.3mm | 含脚垫 |
| 安装孔间距 | 100mm | ±0.2mm | M3螺纹 |
| 接口高度 | 8mm | ±0.3mm | 距底面 |
环境可靠性部分，消费电子和工业设备差别很大。消费电子通常写工作温度0到40℃、存储温度-20到60℃、跌落1米六面。工业设备可能要写-40到85℃、IP67、振动5到500Hz。这些参数直接决定器件选型和结构设计，不能含糊。
3.4 认证清单和成本进度的绑定
认证清单要在PRD里列全，因为认证周期和费用直接影响项目排期。国内销售至少要考虑CCC（如果在内目录）、SRRC（无线产品）、RoHS。出口的话CE、FCC、UL、PSE看目标市场。
成本部分，我建议写“目标BOM成本”和“关键器件成本上限”。比如“整机BOM目标成本不超过80元，其中MCU不超过12元，WiFi模组不超过15元”。这样采购和硬件工程师在选型时就有明确的取舍依据。
进度部分用里程碑表：
| 里程碑 | 交付物 | 目标日期 | 负责人 |
|---|---|---|---|
| PRD评审通过 | 签字版PRD | 第1周 | 产品经理 |
| 原理图评审 | 原理图+PCB布局 | 第4周 | 硬件工程师 |
| EVT打样 | 5台样机 | 第8周 | 项目经理 |
| DVT测试 | 测试报告 | 第14周 | 测试工程师 |
| 认证送检 | 认证申请 | 第16周 | 认证工程师 |
| PVT试产 | 100台 | 第20周 | 生产 |
这张表让所有人知道什么时候该交什么，比口头催进度管用得多。
4. 避坑：硬件PRD评审中最容易翻车的五个地方
4.1 现象：研发说“这个需求做不了”，产品说“别人家怎么做的”
原因：需求写的是“实现XX功能”，但没有写约束条件。比如“支持无线充电”，但没写功率、距离、线圈尺寸限制。研发按最难的方案评估，自然说做不了。
解决：每条功能需求后面加“约束条件”字段。无线充电的例子应该写成“支持Qi标准5W无线充电，线圈直径不大于30mm，充电距离3到8mm，效率不低于70%”。约束给清楚了，研发才能判断能不能做、怎么做。
4.2 现象：结构图和电气布局打架，开模后才发现装不进去
原因：机械规格和电气规格分开写，没有做交叉检查。结构工程师按外形尺寸设计外壳，硬件工程师按PCB尺寸布局，最后发现电池放不下。
解决：在PRD里增加“空间预算表”，把内部空间按区域划分，标注每个区域的可用尺寸和归属模块。比如“电池仓：60×40×10mm”“主板区：50×35×1.6mm”“天线净空区：15×8×3mm”。这个表在原理图评审前就要冻结。
4.3 现象：认证测试不过，整改导致项目延期一个月
原因：PRD里写了“需要通过CE认证”，但没有写具体的测试标准和限值。研发按经验设计，结果辐射骚扰余量不足。
解决：认证要求要写到标准号和限值。比如“辐射骚扰满足EN 55032 Class B，30MHz到1GHz准峰值限值40dBμV/m@10m”。同时要在PRD里预留认证整改时间，通常至少2周。
4.4 现象：BOM成本超标，采购说“你选的这颗料是独家的”
原因：PRD里只写了功能参数，没有写供应链约束。硬件工程师选了性能最好但交期52周、单一供应商的物料。
解决：在电气规格里增加“供应链约束”字段，写明“关键器件需有至少两家可选供应商”“交期不超过12周”“不接受NRND状态物料”。这些约束要在选型评审时逐条核对。
4.5 现象：PRD改了七八版，研发不知道以哪版为准
原因：没有版本管理和变更记录。需求通过微信群、邮件、口头传达，文档本身没有更新。
解决：PRD首页放版本记录表，每次变更记录版本号、日期、变更内容、变更原因、影响评估。文档命名带版本号和日期，比如“XX产品硬件PRD_V1.3_20250115”。评审通过后冻结基线，后续变更走变更申请流程。
| 版本 | 日期 | 变更内容 | 变更原因 | 影响评估 |
|---|---|---|---|---|
| V1.0 | 2025-01-05 | 初版 | — | — |
| V1.1 | 2025-01-08 | 待机电流从50μA改为30μA | 客户要求 | 需重新选型LDO |
| V1.2 | 2025-01-12 | 增加IP54防护要求 | 市场反馈 | 结构增加密封圈 |
| V1.3 | 2025-01-15 | 删除NFC功能 | 成本超标 | 减少一颗NFC芯片 |
5. 进阶：用需求追溯矩阵把PRD变成可验证的工程文件
5.1 需求追溯矩阵的建立方法
PRD写完不是终点。真正让硬件PRD发挥作用的，是建立需求追溯矩阵（Requirements Traceability Matrix）。简单说，就是每一条需求都能追溯到它的来源，也能追溯到它的验证方法。
我一般用一张Excel表来维护，列包括：需求编号、需求描述、来源、优先级、验证方法、验证阶段、责任人、状态。
| 需求编号 | 需求描述 | 来源 | 优先级 | 验证方法 | 验证阶段 | 责任人 | 状态 |
|---|---|---|---|---|---|---|---|
| REQ-001 | 待机电流≤50μA | 客户 | M | 电流表实测 | DVT | 硬件 | 已关闭 |
| REQ-002 | 1米跌落无功能失效 | 内部 | M | 跌落测试 | DVT | 结构 | 进行中 |
| REQ-003 | 通过SRRC认证 | 法规 | M | 送检 | 认证 | 认证 | 未开始 |
| REQ-004 | BOM成本≤80元 | 内部 | S | 采购核算 | EVT | 采购 | 进行中 |
这张表的好处是：评审时逐条过，谁负责、怎么验、什么时候验，一目了然。项目后期如果出现争议，翻这张表就能定位问题。
5.2 用验证结果反哺PRD迭代
硬件项目通常分EVT、DVT、PVT三个阶段。每个阶段结束后，把验证结果更新到追溯矩阵里。如果某条需求验证不通过，要么改设计，要么改需求。改需求的话，PRD要同步更新版本。
我自己的习惯是：DVT结束后做一次PRD全量评审，把验证过程中发现的边界条件、测试方法、参数修正全部补进去。这份更新后的PRD就是PVT和量产阶段的基线文件。很多团队PVT阶段还在改需求，就是因为DVT结束后没有做这个动作。
5.3 一个具体技巧：把PRD拆成“冻结层”和“灵活层”
硬件项目最怕的是所有需求都冻结，导致市场变化时无法响应；也怕什么都不冻结，导致研发无所适从。我的做法是把PRD分成两层：
- 冻结层：电气参数、机械接口、认证要求、安全规范。这些在EVT前必须冻结，变更需要走正式变更流程。
- 灵活层：外观颜色、UI交互细节、包装配件、非关键功能。这些可以在DVT前调整，由产品经理直接确认。
在PRD里用标签标注每条需求属于哪一层。比如“REQ-001（冻结）”“REQ-015（灵活）”。这样研发知道哪些能商量，哪些不能碰。
注意：冻结层的变更不是不能做，而是要走变更评审。我见过一个项目因为客户临时要求改USB接口位置，没有走变更流程，直接口头通知结构改模，结果模具修了三次，项目延期六周。血泪经验就是：冻结层的任何改动，必须拉上硬件、结构、采购、项目经理一起评审。
5.4 我踩过的坑和现在的习惯
早期写硬件PRD，我总想一次写完美，结果文档写了两个月，研发等不及先开工了，PRD变成“追认文件”。后来我改成“最小可用PRD”策略：第一版只写冻结层和核心功能，两周内评审冻结，然后随着设计深入逐步补充灵活层和细节。这样研发能尽早启动，PRD也能持续迭代。
另一个习惯是：每次PRD评审，我会让测试工程师也参加。测试工程师会从“怎么测”的角度提问，往往能发现产品经理和研发都忽略的边界条件。比如“待机电流50μA”这条，测试会问“用什么设备测、测试时间多长、环境温度多少”，这些问题倒逼PRD把测试条件写清楚。
最后一个习惯：PRD里所有参数都带单位，所有时间都带时区，所有尺寸都带公差。看起来是小事，但硬件项目里因为“mm和cm搞混”“UTC和CST没标”导致的翻车，我见过不止一次。希望帮到你。
本文还有配套的精品资源，点击获取
