需求分析与规格定义：读懂客户需求，撰写硬件规格说明书
说实话，很多硬件工程师觉得画原理图、调板子才是真本事。需求分析？那是项目经理的事。我以前也这么想，直到有一次——客户说“我要一个能跑Linux的板子”，我直接选了颗A7处理器，结果人家要的是工业级-40℃环境，芯片根本扛不住。从那以后，我明白了：需求分析做不好，后面全是白干。
这一章，我们就聊聊怎么把客户那些模糊的“我想要”变成工程师能用的“技术指标”。
2.1 客户需求：从“人话”到“技术话”
客户说“快一点”，你得问清楚：是启动快？还是数据处理快？还是通信延迟低？
客户说“稳定”，你得确认：是全年不掉线？还是故障恢复时间小于30秒？
我习惯把客户需求拆成三层：
- 业务需求：客户想解决什么问题？比如“实现远程设备监控”
- 用户需求：谁用？怎么用？比如“现场工人通过手机APP查看数据”
- 技术需求：具体参数是什么？比如“Wi-Fi通信距离≥100米，电池续航≥8小时”
我的经验：拿到客户需求后，先别急着写文档。约个电话会议，把关键点逐条复述一遍——“您看，我理解的是不是这样？”这一步能避免至少30%的后期返工。
2.2 硬件规格说明书（HSD）怎么写？
HSD不是流水账，它是整个项目的“宪法”。所有后续的设计、测试、验收，都得拿它说话。
一份合格的HSD，至少包含以下章节：
| 章节 | 内容要点 | 常见坑点 |
|---|---|---|
| 1. 概述 | 产品定位、应用场景、主要功能 | 写得太虚，没有具体场景 |
| 2. 电气特性 | 供电电压、功耗、IO电平、时序要求 | 漏掉极端工况（如欠压、浪涌） |
| 3. 机械结构 | 尺寸、接口位置、散热要求、防护等级 | 没考虑安装公差 |
| 4. 环境要求 | 工作温度、湿度、振动、EMC等级 | 照搬芯片手册，没考虑整机环境 |
| 5. 接口定义 | 通信协议、引脚定义、信号流向 | 协议版本没写清楚 |
| 6. 可靠性指标 | MTBF、保修年限、故障检测覆盖率 | 指标定得太高，成本失控 |
| 7. 测试验收标准 | 功能测试、性能测试、环境测试方法 | 测试条件与规格不一致 |
注意：HSD必须由硬件工程师主导撰写，不能丢给市场或项目经理代笔。我曾经见过一份HSD，里面写着“支持高速通信”，结果连是USB 2.0还是3.0都没写——这种文档，签了字就是定时炸弹。
2.3 关键性能指标（KPI）的确定
KPI不是越多越好。定多了，测试成本翻倍；定少了，质量没保障。我一般遵循“核心指标必测，辅助指标抽测”的原则。
举个例子，一个工业数据采集终端，它的KPI可以这样分层：
- 一级KPI（必测）：
- 供电范围：9V~36V DC，纹波≤50mV
- 采样精度：±0.1% FSR（满量程）
- 通信成功率：≥99.9%（丢包率≤0.1%）
- 工作温度：-20℃~+70℃
- 二级KPI（抽测）：
- 启动时间：≤5秒
- 功耗：≤3W（典型值）
- 抗振动：10~500Hz，2g
- 三级KPI（参考）：
- 外观颜色、丝印位置、包装方式
核心原则：每个KPI必须对应一个可重复的测试方法。如果写“通信稳定”，那等于没写。要写成“在-20℃环境下，以115200bps连续发送10000帧数据，误码率≤10⁻⁶”。
2.4 需求分析的核心流程
我习惯用下面这张图来梳理整个需求分析过程。说白了，就是从客户的“一句话”开始，一步步拆解成可执行的规格。
你看，这个流程不是线性的。评审发现问题，就得回到需求拆解那一步重新来过。我见过最惨的项目，HSD都签了字，结果评审时发现客户要的是RS485，我们写成了RS232——改一次，整个接口电路重做。
2.5 避坑指南：我踩过的几个坑
- 坑一：忽略“隐性需求”
客户没说，但你必须想到。比如：产品要不要过CE/FCC？要不要支持远程升级？这些没写进HSD，后面认证时全得补。 - 坑二：KPI定得太理想
我曾经给一个手持设备定了“连续工作24小时”，结果电池体积占了整机一半。客户看了样机直接摇头——太沉了。后来改成“8小时+快充”，才通过。 - 坑三：测试条件与规格脱节
HSD写“工作温度-20℃”，结果测试时只在25℃环境下跑了一遍。等到客户现场冬天一开机，直接死机。后来一查，是某颗电容在低温下容值掉得太厉害。
我的习惯：每次写完HSD，我会自己扮演“杠精”，逐条问自己三个问题：
1. 这条指标有没有测试方法？
2. 测试条件是否覆盖了极端情况？
3. 如果这条指标没达到，后果是什么？
问完这三遍，至少能发现一半的漏洞。
1. 这条指标有没有测试方法？
2. 测试条件是否覆盖了极端情况？
3. 如果这条指标没达到，后果是什么？
问完这三遍，至少能发现一半的漏洞。
2.6 小结
需求分析与规格定义，说白了就是“把话说清楚”。客户说“我要一个好东西”，你得帮他定义什么叫“好”。是性能好？还是成本好？还是可靠性好？
HSD不是写给别人看的，是写给自己和团队看的。它决定了你后面几个月的设计方向，也决定了测试能不能一次通过。
嗯，这一章的内容就到这里。记住：规格定得越细，后面流汗越少。