3. 需求工程导论
硬件产品开发与纯软件产品开发有一个本质区别：硬件一旦投板（PCB Layout 冻结、模具开模、光罩流片），修改成本呈指数级上升。一块四层板的改版费用可能数千元，而一颗 ASIC 的流片费用动辄数百万元。因此，硬件开发中需求工程的核心价值，就是在“修改成本还很低”的需求阶段，把“做什么、做到什么程度、如何验证”定义清楚。本章围绕需求的定义、层次划分、关键属性（可验证性、可追溯性）以及需求工程过程展开，帮助学员建立一套从用户声音到硬件可测试规格的完整方法论。
3.1 需求的定义与本质
3.1.1 核心原理：需求是“问题”与“解决方案”之间的桥梁
在硬件产品开发语境下，需求（Requirement）不是简单的“用户想要什么”的愿望清单，而是经过分析、约束、量化后，能够指导设计与验证的工程陈述。IEEE 610.12 将需求定义为：“用户解决问题或达到目标所需的条件或能力；系统或系统组件为满足合同、标准、规范或其他正式文档所必须满足的条件或能力。”
硬件需求与软件需求有一个显著差异：硬件需求必须绑定物理可实现性。例如，“拍照清晰”是一个用户期望，但硬件工程师需要将其转化为“在 100 lux 照度下，MTF50 ≥ 0.6 lp/mm @ 中心视场”这样的光学与传感器联合指标。这中间涉及光学镜头、图像传感器、ISP 处理链路、机械防抖结构等多个子系统的协同约束。
需求在硬件开发中承担三个核心角色：
- 契约角色：需求是研发团队、市场团队、供应链、测试团队之间的“合同”，定义了各方交付的验收标准。
- 决策依据：硬件选型（如 MCU 主频、传感器分辨率、电源拓扑）必须以需求为输入，而非工程师个人偏好。
- 变更管理锚点：当项目发生变更（如成本削减、交期压缩）时，需求是评估变更影响的基准。
3.1.2 判断方法：如何区分“真需求”与“伪需求”
硬件开发中常见的需求陷阱包括：伪需求（用户口头表达但并非真实痛点）、过度需求（超出目标市场价值的技术指标）、模糊需求（无法量化的描述）。判断一个需求是否“合格”，可以使用以下四个过滤器：
- 可观察性：需求是否描述了可观察、可测量的系统行为或属性？例如“系统应快速启动”不可观察，应改为“系统上电到主界面显示时间 ≤ 3 秒”。
- 可测试性：是否存在明确的测试方法或测量手段？例如“低功耗”需要明确是待机功耗、运行功耗还是平均功耗，以及测试条件（供电电压、温度、负载）。
- 可实现性：在当前技术、成本、时间约束下是否可行？例如消费级产品要求“-40°C 到 +85°C 全温区工作”可能大幅增加 BOM 成本。
- 必要性：如果去掉该需求，产品是否仍然满足核心用户价值？若答案是肯定的，该需求可能不是关键路径。
3.2 需求的层次：用户需求 → 系统需求 → 硬件需求
3.2.1 核心原理：三层分解与映射
硬件产品需求通常划分为三个层次，每一层都是对上一层的细化与约束：
| 层次 | 定义 | 典型表达方式 | 责任角色 | 示例（以智能门锁为例） |
|---|---|---|---|---|
| 用户需求 | 用户或市场对产品的期望、痛点、使用场景描述，通常是非技术语言 | 用户故事、场景描述、市场调研报告 | 产品经理、市场人员 | “用户希望门锁在手指有汗时也能快速识别开锁” |
| 系统需求 | 对产品整体（含硬件、软件、机械、结构）的功能、性能、接口、环境约束的工程化描述 | 系统需求规格说明书（SysRS），包含功能需求、性能需求、接口需求、环境需求 | 系统架构师、系统工程师 | “指纹识别模块在手指湿润（相对湿度 80%）条件下，识别成功率 ≥ 98%，识别时间 ≤ 0.5 秒” |
| 硬件需求 | 从系统需求中分配给硬件子系统的需求，包含电路、芯片、接口、电源、时序、环境适应性等具体指标 | 硬件需求规格说明书（HWRS），含原理图设计约束、PCB 设计约束、器件选型约束 | 硬件工程师、硬件架构师 | “指纹传感器 FPC 接口采用 8-pin 0.5mm pitch，SPI 时钟频率 ≥ 4MHz；传感器供电 AVDD = 3.3V ± 5%，纹波 ≤ 30mVpp；ESD 等级 ≥ ±8kV（接触放电）” |
三层需求之间不是简单的“翻译”关系，而是存在双向可追溯性：从用户需求可以追踪到系统需求，从系统需求可以追踪到硬件需求；反向亦然。当硬件实现遇到困难需要调整指标时，必须评估对系统需求和用户需求的影响。
3.2.2 操作流程：从用户声音到硬件规格的分解步骤
以一个便携式医疗监护仪的心率监测功能为例，展示需求分解的完整流程：
- 收集用户需求：通过访谈医生和护士，得到“设备要能准确监测心率，在患者移动时也不能丢失信号”。
- 转化为系统需求：系统工程师定义“心率测量范围 30-250 bpm，精度 ±2 bpm 或 ±2%（取较大值）；在患者肢体运动幅度 ≤ 5cm 时，信号丢失时间 ≤ 2 秒”。
- 分配硬件需求：硬件工程师进一步分解为：
- 模拟前端：ECG 放大器输入噪声 ≤ 10μVpp，带宽 0.05-150Hz，共模抑制比 ≥ 90dB；
- 运动传感器：加速度计量程 ±8g，采样率 ≥ 100Hz，用于运动伪影消除；
- 处理器：MCU 主频 ≥ 64MHz，内置 DSP 指令，ADC 采样率 ≥ 500Hz，12-bit 分辨率；
- 电源：模拟供电 AVDD = 3.0V，纹波 ≤ 5mVpp，数字与模拟地单点连接。
- 验证需求覆盖：检查每个系统需求是否至少有一条硬件需求支撑，每个硬件需求是否能追溯到系统需求。
3.2.3 案例拆解：智能摄像头夜视功能的需求分解
背景与约束：某安防厂商计划开发一款家用智能摄像头，目标成本 BOM ≤ 180 元，夜视距离 ≥ 10 米，支持 1080P 30fps 实时预览。市场反馈用户抱怨“晚上看不清人脸”。
初始现象：早期原型采用 850nm 红外 LED + 普通 CMOS 传感器，实测夜视距离仅 6 米，且画面噪点明显。
关键输入数据：传感器量子效率在 850nm 处仅 18%；红外 LED 辐射功率 800mW；镜头 F 值 1.6；环境照度 0.01 lux。
分析判断过程：
- 系统需求定义为“在 0.01 lux 照度下，可识别 10 米处人脸轮廓（分辨率 ≥ 8 对线/mm）”；
- 硬件需求分解为：传感器最低照度 ≤ 0.001 lux（F1.6 条件下），红外 LED 总辐射功率 ≥ 1.2W，或改用 940nm LED 配合高灵敏度传感器；
- 进一步分析发现：940nm 方案人眼不可见但传感器灵敏度更低，需要选择背照式（BSI）传感器；
- 成本约束下，最终选择 850nm LED + 定制红外增强滤光片 + 背照式传感器，硬件需求更新为“传感器在 850nm 处 QE ≥ 30%，LED 驱动电流 350mA，脉冲调制频率 25kHz 以避免与摄像头帧率干扰”。
实际操作步骤：
- 将系统需求“夜视 10 米识别人脸”拆解为光学、传感器、LED 驱动、图像处理四部分硬件需求；
- 建立需求追踪矩阵，标注每项硬件需求的验证方法（积分球测辐射功率、分辨率测试卡实测）；
- 在 PCB 设计阶段，将 LED 驱动电路与传感器模拟供电分区，避免电源噪声耦合。
结果对比：改进后夜视距离实测 11.5 米，人脸识别率从 62% 提升至 95%。代价是 BOM 增加 22 元，仍在目标范围内。
复盘经验：需求分解时不能只看单一指标，要关注链路耦合——LED 波长、传感器 QE、滤光片透过率三者必须联合优化，单独提升任何一项都无法达到系统目标。
3.3 需求属性：可验证性与可追溯性
3.3.1 核心原理：为什么这两个属性对硬件尤其重要
可验证性（Verifiability）是指需求是否具备明确的、可操作的验证方法。硬件需求的验证通常依赖：测试测量（如示波器测时序、频谱仪测 EMI）、仿真分析（如 SI/PI 仿真、热仿真）、检查确认（如设计评审、DFM 检查）。不可验证的需求是硬件开发中的“定时炸弹”——到了测试阶段才发现无法判定是否满足，导致项目延期。
可追溯性（Traceability）是指需求之间的上下游关联关系是否清晰。硬件开发中，一颗电容的选型变更可能影响电源纹波，进而影响 ADC 采样精度，最终导致系统性能下降。没有追溯矩阵，这种影响链很难被完整识别。
3.3.2 判断方法：如何写出可验证的硬件需求
一个可验证的硬件需求应包含以下要素：
| 要素 | 说明 | 反例 | 正例 |
|---|---|---|---|
| 可测量的参数 | 使用物理量而非形容词 | “电源纹波要小” | “电源纹波 ≤ 30mVpp（20MHz 带宽限制，1μF + 0.1μF 去耦条件下）” |
| 明确的测试条件 | 温度、负载、供电、外围配置 | “USB 通信稳定” | “USB 2.0 高速模式，线缆 3m，主机为 Intel 标准 USB 控制器，连续传输 1GB 数据无丢包” |
| 可判定的通过/失败标准 | 给出数值边界或统计要求 | “ESD 防护要好” | “接触放电 ±8kV，空气放电 ±15kV，测试后功能正常（IEC 61000-4-2）” |
| 验证方法指引 | 指明测试设备或仿真工具 | “时钟精度要高” | “RTC 时钟精度 ±20ppm，使用频率计测量 24 小时累计误差 ≤ 1.7 秒” |
3.3.3 操作流程：建立需求追溯矩阵
推荐使用双向追溯矩阵（Requirements Traceability Matrix, RTM），在硬件项目中至少维护以下关联：
- 用户需求 ↔ 系统需求：确保每个用户痛点都有系统需求覆盖；
- 系统需求 ↔ 硬件需求：确保每个系统指标都分解到硬件子系统的具体参数；
- 硬件需求 ↔ 测试用例：确保每个硬件需求都有对应的验证测试项；
- 硬件需求 ↔ 设计文档：确保原理图、PCB、结构设计都落实了需求约束。
3.4 需求工程过程：五阶段闭环
3.4.1 核心原理：需求工程不是“写文档”，而是“管理不确定性”
需求工程过程包括五个阶段：需求获取、需求分析、需求规格化、需求验证、需求管理。这五个阶段不是一次性顺序执行，而是在整个硬件开发周期中迭代进行。硬件项目尤其需要关注需求变更——因为硬件改版周期长，需求变更的代价随时间急剧上升。
3.4.2 各阶段操作要点
| 阶段 | 核心活动 | 硬件场景下的关键输出 | 常见工具/方法 |
|---|---|---|---|
| 需求获取 | 收集用户声音、市场趋势、法规要求、内部约束 | 用户需求清单、场景描述、竞品分析报告 | 用户访谈、问卷调查、竞品拆解、法规检索 |
| 需求分析 | 分类、去重、冲突消解、优先级排序、可行性评估 | 需求分类表（功能/性能/接口/环境/法规）、优先级列表 | KANO 模型、MoSCoW 法、技术可行性评估（TRL） |
| 需求规格化 | 编写正式的需求文档，确保无歧义、可验证 | 系统需求规格说明书（SysRS）、硬件需求规格说明书（HWRS） | IEEE 29148 模板、需求编号规范、指标量化 |
| 需求验证 | 确认需求正确、完整、一致、可测试 | 需求评审记录、原型验证报告、仿真验证结果 | 同行评审、原型制作、仿真分析（SPICE、SI/PI） |
| 需求管理 | 基线控制、变更管理、状态跟踪、追溯维护 | 需求基线、变更请求记录、RTM 更新记录 | 配置管理工具、变更控制委员会（CCB）、RTM |
3.4.3 案例拆解：需求变更引发的硬件改版教训
背景：某工业网关产品，原设计使用外部看门狗芯片（如 MAX6369）实现系统监控。在需求评审阶段，系统需求为“系统异常时自动复位，复位时间 ≤ 500ms”。硬件需求据此选择了外部看门狗，并完成原理图设计。
变更发生：项目进行到 PCB Layout 阶段，软件团队提出：外部看门狗在固件升级模式下会误触发复位，导致升级失败。因此需求变更为“看门狗功能可配置，升级模式下可禁用”。
影响分析：
- 硬件需求变更：需要增加 GPIO 控制看门狗使能，或改用内部看门狗 + 外部冗余方案；
- 原理图修改：增加 1 个 GPIO 连接、1 个 10kΩ 上拉电阻；
- PCB 修改：需要调整走线，增加一个过孔，板子面积不变；
- 测试用例变更：新增“升级模式下看门狗禁用”测试项。
代价评估：由于变更发生在 Layout 阶段，修改 PCB 需要重新投板，增加 2 周时间和约 5000 元成本。如果需求变更发生在测试阶段，代价将更高（可能需要改结构件）。
复盘经验：硬件需求评审时，必须邀请软件、测试、结构、生产等多角色参与，尤其是跨层需求冲突（如硬件看门狗与软件升级流程的冲突）应在需求分析阶段暴露，而非等到设计阶段。
3.5 常见误区与总结复盘
3.5.1 硬件需求工程中的典型误区
- 误区一：需求文档“一写了之”。需求文档完成后束之高阁，设计与测试各做各的，导致最终产品与需求偏离。正确做法是将需求作为设计评审、测试用例设计、验收测试的输入基准。
- 误区二：只关注功能需求，忽略非功能需求。硬件产品的功耗、EMC、热设计、可靠性、可制造性（DFM）往往决定产品成败。例如，一个功能完备的电路板如果 EMI 超标，可能无法通过认证，导致上市延期。
- 误区三：需求指标“拍脑袋”。没有经过仿真或实测验证的需求指标，可能在开发中后期被证明无法实现。例如，某项目要求 DDR 总线速率 1600MT/s，但 PCB 走线长度和阻抗控制无法满足，最终只能降速。
- 误区四：忽视需求优先级。所有需求都是“Must”，导致资源分配平均，关键路径被次要需求拖累。建议使用 MoSCoW 法（Must/Should/Could/Won't）明确优先级。
3.5.2 总结：硬件需求工程的核心能力
硬件需求工程师（或系统工程师）需要具备三项核心能力：
- 量化思维：将模糊的用户语言转化为可测量的物理参数，并理解参数之间的耦合关系（如功耗与散热的权衡、采样率与数据量的权衡）。
- 系统视角：能够跨越硬件、软件、结构、算法等多个领域，识别需求冲突并推动消解。
- 验证意识：在写需求时就思考“如何测试”，确保每条需求都有对应的验证方法和判定标准。