3. 需求工程基础
硬件产品开发中，需求工程是连接市场机会与产品实现的桥梁。许多硬件项目延期、成本超支甚至失败，根源往往不在技术攻关，而在需求定义模糊、需求变更失控或需求验证缺失。本章围绕需求类型、需求来源、需求属性以及需求管理工具四个核心模块展开，帮助产品经理、项目经理和硬件工程师建立一套可落地的需求工程方法论。
上图展示了需求工程的核心框架：需求来源是输入，需求类型是分类维度，需求属性是管理抓手，而需求管理工具则是支撑整个流程的载体。硬件产品开发中，需求工程的目标不是“写一份完美的文档”，而是建立一套从市场声音到产品规格、再到测试验证的可追溯闭环。下面逐一展开。
3.1 需求类型：五类核心需求与硬件产品映射
3.1.1 核心原理
硬件产品的需求类型通常划分为五类：用户需求、业务需求、功能需求、性能需求和法规需求。这五类需求在硬件开发中扮演不同角色，且相互之间存在层级关系。
- 用户需求（User Requirements）：描述用户“想要什么”和“期望什么”，通常用自然语言表达，不涉及技术实现。例如：“用户希望智能门锁在0.5秒内完成指纹识别并开锁”。
- 业务需求（Business Requirements）：从公司战略和商业目标出发，回答“为什么要做这个产品”。例如：“该产品目标市场为欧洲中高端住宅，预计年销量10万台，毛利率不低于45%”。
- 功能需求（Functional Requirements）：定义系统“必须做什么”，是用户需求的技术化转译。例如：“指纹模块应支持至少100枚指纹存储，支持假指纹拒绝率≥99%”。
- 性能需求（Performance Requirements）：量化功能实现的水平，包括速度、精度、容量、功耗、可靠性等。例如：“待机功耗≤50μA，指纹识别成功率≥98%，工作温度范围-20℃~+60℃”。
- 法规需求（Regulatory Requirements）：强制性的法律、标准、认证要求，不可妥协。例如：“产品需通过CE认证、RoHS 2.0、REACH、RED指令，以及欧盟通用数据保护条例（GDPR）对生物识别数据的合规要求”。
3.1.2 判断方法：需求类型识别矩阵
在实际项目中，一条原始需求往往混合了多种类型。建议使用以下判断矩阵进行归类：
| 原始描述示例 | 主要类型 | 次要类型 | 处理策略 |
|---|---|---|---|
| “开锁要快，不能等太久” | 用户需求 | 性能需求 | 转化为量化指标：≤0.5s |
| “支持手机APP远程开锁” | 功能需求 | 用户需求 | 拆分为APP、通信模块、云端等子需求 |
| “电池续航至少一年” | 性能需求 | 业务需求 | 需结合功耗预算和电池容量计算 |
| “通过CE认证” | 法规需求 | 业务需求 | 强制项，列入项目关键路径 |
| “成本控制在200元以内” | 业务需求 | 性能需求 | 作为设计约束，影响器件选型 |
3.2 需求来源：六条通道与优先级排序
3.2.1 核心原理
硬件产品的需求来源比纯软件产品更广泛，因为硬件涉及供应链、制造、认证、售后等更多环节。主要来源包括：
- 用户/客户调研：通过访谈、问卷、可用性测试、用户反馈收集。硬件产品尤其要关注“使用场景”和“环境约束”。
- 市场与竞品分析：分析竞品功能、拆解竞品硬件方案、研究市场趋势报告。
- 法规/标准/认证机构：包括目标市场的强制认证、行业标准、环保指令等。
- 内部干系人：研发（硬件、软件、结构）、生产制造、质量、采购、售后等部门的意见。
- 售后/运维反馈：来自RMA（退货授权）、维修记录、客服工单、现场故障数据。
- 高层战略/产品规划：公司技术路线图、产品平台战略、成本目标等。
3.2.2 操作流程：需求收集与过滤
建议采用“漏斗式”需求收集流程：
Step 1: 广泛收集（Brainstorming / 访谈 / 问卷 / 竞品拆解）
Step 2: 分类归档（按上述五类需求类型打标签）
Step 3: 冲突识别（不同来源的需求可能存在矛盾，如成本 vs 性能）
Step 4: 优先级排序（结合业务目标，使用MoSCoW或Kano模型）
Step 5: 需求评审（跨部门评审会，确认需求可行性）
Step 6: 基线化（批准后纳入需求基线，变更走正式流程）3.2.3 案例拆解：智能门锁的需求来源冲突
某智能门锁项目在需求收集阶段出现以下冲突：
- 市场部提出：“必须支持人脸识别，否则没有卖点。”
- 硬件工程师反馈：“人脸识别模块成本增加80元，且功耗增加，电池续航会从12个月降到6个月。”
- 法规工程师提醒：“人脸数据属于生物识别信息，在欧洲销售需满足GDPR，需要额外的安全芯片和数据处理流程。”
- 生产部门提出：“人脸识别模组需要额外的校准工序，产线节拍会从30秒/台增加到45秒/台。”
分析过程：项目组通过需求优先级矩阵评估，将“人脸识别”标记为“Should Have”（应有），但将“电池续航≥10个月”标记为“Must Have”（必须有）。最终决策：采用低功耗人脸识别方案（如3D结构光降级为2D+红外），增加电池容量（从5000mAh提升到6500mAh），并调整产线增加自动校准工位。虽然成本增加了约120元，但通过砍掉“指静脉识别”这一“Could Have”（可有）需求来平衡总成本。
复盘经验：需求冲突不可怕，可怕的是没有机制来暴露和解决冲突。建议每周召开一次需求评审会，让市场、硬件、软件、结构、生产、法规等角色共同参与，用数据说话，而不是靠职位高低决定。
3.3 需求属性：可验证性与优先级
3.3.1 可验证性（Verifiability）
一条合格的需求必须是可验证的，即存在一种客观、经济、可重复的方法来确认需求是否被满足。硬件需求的可验证性尤其重要，因为硬件修改成本高、周期长。
判断标准：
- 可测量：需求中应包含量化指标。例如“工作温度范围-20℃~+60℃”可验证，而“适应各种恶劣环境”不可验证。
- 可测试：存在对应的测试方法或工具。例如“ESD接触放电±8kV”可通过静电放电测试仪验证。
- 可判定：测试结果有明确的通过/失败标准。例如“指纹误识率≤0.001%”有明确阈值。
3.3.2 优先级（Priority）
硬件产品开发中，优先级排序直接影响资源分配和项目排期。推荐使用MoSCoW法：
| 优先级 | 含义 | 硬件场景示例 | 处理策略 |
|---|---|---|---|
| Must Have（必须有） | 没有它产品无法发布 | 安全功能（过流保护）、法规认证、基本开锁功能 | 列入项目关键路径，资源优先保障 |
| Should Have（应该有） | 重要但可临时降级 | 远程OTA升级、语音提示、低电量提醒 | 尽量实现，但允许延期到下一版本 |
| Could Have（可有） | 有更好，没有也不影响 | 氛围灯、个性化主题、NFC卡片开锁 | 有余力时实现，否则砍掉 |
| Won't Have（这次不做） | 明确排除 | 人脸识别（因成本/功耗不达标） | 记录在案，避免后续反复讨论 |
3.3.3 实战场景：需求属性评审清单
在需求评审会上，建议逐条需求过以下清单：
- 该需求是否有唯一编号（如 REQ-HW-001）？
- 是否包含量化指标？指标是否有测试方法支撑？
- 优先级是 Must/Should/Could/Won't 中的哪一级？
- 该需求是否可追溯到来源（哪个客户、哪个法规条款、哪个竞品分析）？
- 该需求是否与其他需求存在冲突？冲突是否已解决？
- 该需求是否已分配责任人（硬件/软件/结构/测试）？
3.4 需求管理工具：从Excel到专业平台
3.4.1 工具选型对比
| 工具类型 | 代表产品 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| 轻量协作 | Jira + Confluence | 中小团队、敏捷开发 | 上手快、灵活、与开发任务联动 | 需求追溯链弱，不适合复杂合规项目 |
| 专业需求管理 | Jama Connect / Polarion / DOORS | 大型项目、汽车/医疗/军工等高合规行业 | 强大的追溯矩阵、基线管理、变更流程 | 学习成本高、license费用贵 |
| 硬件专用 | Valispace / Helix RM | 硬件参数驱动开发 | 支持参数化需求、自动传播变更影响 | 生态相对封闭，与主流PLM集成需定制 |
| 表格工具 | Excel / Google Sheets | 原型验证、早期探索 | 零成本、灵活 | 无法有效管理变更、追溯、权限 |
3.4.2 操作流程：需求管理工具落地步骤
1. 需求导入：将收集到的原始需求录入工具，分配唯一ID
2. 属性填充：为每条需求填写类型、优先级、来源、状态、责任人
3. 建立追溯：连接需求→设计规格→测试用例→验证结果
4. 基线管理：在里程碑节点（如EVT/DVT/PVT）冻结需求基线
5. 变更控制：任何需求变更需提交ECR（工程变更请求），经CCB（变更控制委员会）审批
6. 状态跟踪：实时查看每条需求的实现状态（草稿/已批准/已实现/已验证/已关闭）3.4.3 案例拆解：从Excel到Jama Connect的迁移
某工业传感器公司，团队约40人，原先使用Excel管理需求，问题频发：
- 需求版本混乱，不同工程师手上的Excel内容不一致
- 需求变更后，无法快速评估影响范围（哪些设计文档、测试用例需要同步更新）
- 客户审计时，无法提供清晰的需求追溯链
迁移过程：
- 第一阶段（1个月）：将现有Excel需求清洗、去重、补全属性，导入Jama Connect。
- 第二阶段（2个月）：建立需求→设计规格→测试用例的追溯矩阵，要求新项目必须使用Jama管理需求。
- 第三阶段（持续）：配置变更控制流程，所有需求变更必须通过Jama提交ECR，由CCB审批。
结果对比：
- 需求遗漏率从15%降至3%
- 需求变更平均处理时间从5天缩短至2天
- 客户审计准备时间从2周缩短至2天
代价与风险：Jama Connect的license费用约每年20万元，且需要配置专人维护。初期工程师抵触情绪较大，通过培训和多轮沟通逐步解决。
3.5 常见误区与应对策略
| 误区 | 典型表现 | 后果 | 应对策略 |
|---|---|---|---|
| 需求文档“一次性” | 写完需求文档后束之高阁，开发过程中不更新 | 需求与实现脱节，测试无依据 | 将需求文档纳入版本管理，每周评审更新 |
| 过度追求“完美需求” | 花大量时间试图把所有细节定义清楚 | 项目启动延迟，错过市场窗口 | 采用“渐进细化”策略，先定义核心需求，后续迭代补充 |
| 忽略非功能需求 | 只关注功能，不关注功耗、EMC、可靠性、可制造性 | 后期测试阶段问题集中爆发 | 在需求评审中设置“非功能需求检查项” |
| 需求变更不设门槛 | 任何干系人都能随意提出变更，且不评估影响 | 项目范围蔓延，进度失控 | 建立CCB（变更控制委员会），所有变更走正式流程 |
| 需求与测试脱节 | 测试用例不是从需求推导出来的 | 测试覆盖不足，缺陷漏测 | 建立需求-测试追溯矩阵，确保每条需求至少有一个测试用例 |
需求工程是硬件产品开发的地基。地基不牢，后续的设计、开发、测试、量产都会付出惨痛代价。建议团队在项目启动时，花10%-15%的项目时间投入需求工程活动，这将在项目后期节省数倍的时间和成本。