★ FEATURED ARTICLE 简介这份文档资料面向硬件产品经理、设计研发及测试人员系统梳理硬件产品需求文档的编写思路与方向帮助团队在项目初期建立统一认知避免因需求细节堆叠而造成的理解偏差。内容围绕项目简介、使用场景、产品原则、硬件组成及关系、功能性需求、性能需求、接口需求、存储需求、安全需求、机械电子设计需求、环境要求、设计约束条件等十余个维度展开并延伸至可生产性、可测试性、外购元器件、内外部技术合作与嵌入式固件要求配有功能框架图与硬件框架图辅助说明。资源包内含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”。参数要带测试条件否则没有意义。我常用的电气规格表模板参数符号最小值典型值最大值单位测试条件供电电压VCC4.55.05.5V适配器输入待机电流Istb—3050μA25℃无负载工作电流Iop—120200mAWiFi连续传输电池容量Cbat—2000—mAh标称值充电时间Tchg—2.53.0h0到80%选型约束也要写进去。比如“MCU必须支持至少2路UART、1路SPI、1路I2CFlash不小于256KB封装不大于QFN48”。这些约束不是让你指定具体型号而是给硬件工程师划一个可选范围。如果你已经有倾向性选型可以写“推荐XX系列但需评估交期和成本”。提示电气参数一定要标注测试条件。没有测试条件的“待机电流50μA”和“待机电流50μA25℃、3.7V输入、无外设使能”是两回事后者才能写进测试报告。3.3 机械规格和环境可靠性的写法机械规格的核心是“接口边界”。外形尺寸、安装孔位、接口位置和朝向、按键和指示灯位置这些必须给到结构工程师。我一般会附一张标注了关键尺寸的2D图文档里用表格列出关键尺寸和公差。项目标称值公差备注整机长度120mm±0.5mm—整机宽度65mm±0.5mm—整机厚度18mm±0.3mm含脚垫安装孔间距100mm±0.2mmM3螺纹接口高度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 B30MHz到1GHz准峰值限值40dBμV/m10m”。同时要在PRD里预留认证整改时间通常至少2周。4.4 现象BOM成本超标采购说“你选的这颗料是独家的”原因PRD里只写了功能参数没有写供应链约束。硬件工程师选了性能最好但交期52周、单一供应商的物料。解决在电气规格里增加“供应链约束”字段写明“关键器件需有至少两家可选供应商”“交期不超过12周”“不接受NRND状态物料”。这些约束要在选型评审时逐条核对。4.5 现象PRD改了七八版研发不知道以哪版为准原因没有版本管理和变更记录。需求通过微信群、邮件、口头传达文档本身没有更新。解决PRD首页放版本记录表每次变更记录版本号、日期、变更内容、变更原因、影响评估。文档命名带版本号和日期比如“XX产品硬件PRD_V1.3_20250115”。评审通过后冻结基线后续变更走变更申请流程。版本日期变更内容变更原因影响评估V1.02025-01-05初版——V1.12025-01-08待机电流从50μA改为30μA客户要求需重新选型LDOV1.22025-01-12增加IP54防护要求市场反馈结构增加密封圈V1.32025-01-15删除NFC功能成本超标减少一颗NFC芯片5. 进阶用需求追溯矩阵把PRD变成可验证的工程文件5.1 需求追溯矩阵的建立方法PRD写完不是终点。真正让硬件PRD发挥作用的是建立需求追溯矩阵Requirements Traceability Matrix。简单说就是每一条需求都能追溯到它的来源也能追溯到它的验证方法。我一般用一张Excel表来维护列包括需求编号、需求描述、来源、优先级、验证方法、验证阶段、责任人、状态。需求编号需求描述来源优先级验证方法验证阶段责任人状态REQ-001待机电流≤50μA客户M电流表实测DVT硬件已关闭REQ-0021米跌落无功能失效内部M跌落测试DVT结构进行中REQ-003通过SRRC认证法规M送检认证认证未开始REQ-004BOM成本≤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没标”导致的翻车我见过不止一次。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
