第二章 需求分析与规格制定：如何读懂需求文档、技术规格书的撰写要点、可行性评估
说实话，很多刚入行的硬件工程师，拿到需求文档的第一反应就是——直接翻到电气参数表。我以前也这样，结果吃过不少亏。
有一次，客户给了一份需求文档，里面写着“支持USB 2.0高速传输”。我心想这简单，随便找个MCU带USB外设就行。结果做到一半才发现，客户要的是OTG模式，还得支持BC1.2充电协议。嗯，那款MCU根本不支持。最后只能换平台，项目延期了两周。
所以，读懂需求文档，真不是扫一眼参数表就完事了。
2.1 需求文档里到底藏着什么？
一份正经的需求文档，通常包含这几块内容：
- 项目背景：为什么要做这个产品？目标市场是谁？
- 功能需求：产品能干什么？比如“支持蓝牙5.0”、“待机功耗低于10μA”。
- 性能指标：具体到数字。比如“ADC采样率≥1Msps”、“工作温度-40℃~85℃”。
- 接口定义：用什么通信协议？UART、I2C、SPI还是CAN？
- 机械结构：板卡尺寸、安装孔位、接插件型号。
- 认证要求：要不要过FCC、CE、UL？
- 成本目标：BOM成本控制在多少以内？
我个人习惯，拿到文档后先通读一遍，然后用荧光笔把所有带数字的句子标出来。为什么？因为数字最容易出问题。
核心原则：需求文档里每一个数字，都必须有明确的测试条件或参考标准。没有条件的数字，就是坑。
举个例子，“工作电流≤50mA”。你得问清楚：这是平均电流还是峰值电流？是在什么负载条件下测的？供电电压是多少？我曾经遇到过一个需求，写着“待机电流5μA”，结果客户说的是常温下的典型值，而高温下实际飙到了20μA。这差距，你想想看，电池续航直接少了一半。
2.2 技术规格书怎么写才不背锅？
技术规格书，说白了就是硬件工程师的“施工图纸”。写得好，后面调试顺风顺水；写得烂，那就是给自己挖坑。
我总结了一套“三要三不要”原则：
| 要做的 | 不要做的 |
|---|---|
| 要写明测试条件 | 不要只写典型值 |
| 要给出容差范围 | 不要写“约等于” |
| 要注明参考标准 | 不要用模糊描述 |
举个例子，写电源纹波指标：
❌ 错误写法：
输出纹波：≤50mV
✅ 正确写法：
输出纹波：≤50mVpp（20MHz带宽限制，负载1A，输入12V±5%）
你看，多了几个条件，后面测试时就不会扯皮了。我在项目中遇到过好几次，测试工程师说纹波超标，结果发现是探头没设带宽限制。有了明确的测试条件，谁的问题一目了然。
2.3 可行性评估——别让项目死在你手里
可行性评估，是硬件工程师最核心的能力之一。说白了，就是判断这个需求能不能做、怎么做、要花多少钱。
我一般从四个维度来评估：
- 技术可行性：现有方案能不能满足性能指标？有没有成熟芯片可用？
- 成本可行性：BOM成本、开模费、认证费加起来，能不能控制在预算内？
- 时间可行性：从原理图到量产，时间够不够？芯片交期能不能赶上？
- 风险可行性：有没有技术难点？有没有专利壁垒？
我的小技巧：做可行性评估时，先画一张系统框图。把每个功能模块拆开，标出关键芯片型号和接口关系。这样一眼就能看出哪里可能出问题。
下面这张图，是我做可行性评估时常用的框架：
2.4 避坑指南——我踩过的那些雷
做需求分析和规格制定这么多年，我踩过的坑真不少。挑几个典型的说说：
我曾经犯过的错：
- 忽略温度范围：有一次做户外设备，规格书只写了“工业级”，没写具体温度。结果夏天户外实测，机箱内部温度到了75℃，芯片直接罢工。从那以后，我所有项目都会明确标注“-40℃~85℃”或“-20℃~60℃”。
- 低估功耗预算：客户说“电池供电，续航一周”。我按平均电流算了算，觉得没问题。结果没考虑Wi-Fi发射时的峰值电流，电池电压直接被拉低，系统频繁复位。后来我学乖了，功耗评估一定要算峰值功耗和平均功耗两个值。
- 接口电平不匹配：主控是3.3V，外设是5V，中间没加电平转换。第一次上电，主控GPIO就烧了。嗯，这个教训花了2000块钱换芯片才记住。
2.5 实战建议——从需求到规格的转化
最后，分享一个我自己的实战流程：
- 需求澄清会：拿到需求文档后，约客户或产品经理开个会。把每个模糊的点都问清楚，形成需求澄清纪要。
- 写初步规格书：根据澄清后的需求，写一份技术规格书初稿。重点是把所有性能指标都量化，并注明测试条件。
- 内部评审：拉上硬件、软件、测试、结构工程师一起评审。每个人从自己角度挑毛病。我一般会问三个问题：这个指标能不能测？这个方案有没有备选？这个成本能不能降？
- 可行性评估报告：把技术、成本、时间、风险四个维度都评估一遍，给出明确的结论。
- 规格书定稿：所有评审意见都闭环后，规格书才能定稿。定稿后就不能随便改了，改一次就要走变更流程。
我的习惯：规格书定稿后，我会在首页加一个版本变更记录表。每次修改都写清楚：谁改的、改了哪里、为什么改、评审人是谁。这样做的好处是，万一出了问题，能快速定位到责任人。
好了，关于需求分析和规格制定，就聊这么多。记住一句话：需求文档里没有废话，每一个字都可能影响你的设计。多花点时间在前期分析上，后面调试就能少掉几根头发。
公众号:蓝海资料掘金营，微信deep3321