2. 需求分析阶段：RICE中的R（Reach）在硬件需求中的定义、覆盖边界、用户场景提取
2.1 Reach 的硬件语义定义
在RICE框架中，Reach（触达范围）特指硬件系统必须覆盖的功能场景集合与物理/逻辑边界。它回答两个核心问题：
- 硬件“为谁做”：全量用户、特定环境、特殊负载下的可用场景。
- 硬件“做到什么程度”：最小功能集、性能下限、兼容接口范围。
不同于软件层面的用户触达，硬件Reach必须面向物理约束（功耗、温度、接口协议、机械尺寸）与系统交互场景（上电时序、异常复位、外设握手）。
| 维度 | 软件Reach | 硬件Reach |
|---|---|---|
| 作用对象 | 用户操作、API调用 | 信号、电源、时钟、总线、传感器 |
| 边界形式 | 页面、业务流程 | 引脚、协议版本、温度范围、电压纹波 |
| 覆盖证据 | 日志、埋点 | 时序波形、仿真用例、测试向量表 |
关键认知：硬件Reach 的遗漏会导致芯片不可用（功能缺失）或死锁（电性问题），无法像软件那样通过热补丁修复。因此 Reach 定义必须包含最坏工况场景。
2.2 覆盖边界与分层
硬件Reach 的覆盖可分为三层，每层对应不同的职责与交付物：
- 系统边界层：定义整机/板级与外部世界的交互边界（接口类型、电源范围、通信协议、机械尺寸）。
- 子系统边界层：分解为各功能模块（如DDR、以太网、显示、音频）的内部功能范围与互连协议。
- 组件边界层：芯片/模块内部的寄存器、状态机、时钟域、电源域的具体覆盖。
2.3 组件职责：谁负责定义与维护 Reach
| 角色 | Reach 职责 |
|---|---|
| 系统架构师 | 确定系统级边界（连接器、供电、散热、环境适应性） |
| 硬件需求分析师 | 从用户场景提取出“必须覆盖”的功能与性能条目 |
| 硬件设计工程师 | 将需求条目映射为具体电路指标与仿真/测试用例 |
| 测试/验证工程师 | 编写覆盖矩阵，确保所有硬边界被遍历 |
| 项目经理 | 裁剪 Reach 范围以平衡成本与交付周期 |
2.4 数据流 / 控制流 / 信任链路
硬件Reach 的信息流路径：
- 数据流：用户场景 → 场景特征列表 → 硬件功能需求 → 详细规格文档 → 测试用例列表。
- 控制流：架构评审 → 需求优先级排序 → 硬件实现启动 → 覆盖验证 → 回归确认。
- 信任链路：每个场景条目必须可追溯到唯一的硬件功能点；每条硬件需求必须被至少一个测试用例覆盖。信任链路的断裂意味着 Reach 丧失完整性。
2.5 选型权衡：Reach 粒度的代价
| 策略 | 优点 | 风险 |
|---|---|---|
| 粗粒度 Reach | 开发周期短，初期弹性大 | 容易遗漏极端场景，后期改版成本极高 |
| 细粒度 Reach | 降低流片失败概率，覆盖率可量化 | 需求膨胀，验证资源超支 |
| 基于风险的裁剪 | 平衡覆盖与工期 | 需要成熟的场景风险评级模型 |
建议：在硬件项目早期（如芯片预研阶段）采用粗粒度 Reach，至少覆盖“典型+边界+错误”三大类场景；在 RTL 实现阶段逐步细化为可测试的微场景。
2.6 风险点
- 场景遗漏：未考虑极端温度、电源毛刺、电磁干扰、多板互联时序。
- 边界模糊：硬件需求未明确“非正常”状态（如启动失败、时钟丢失、通信超时）。
- 信任链路断裂：需求文档与测试用例之间缺乏双向追溯表，导致覆盖盲区。
- 过度覆盖：无节制的 Reach 定义导致硬件规格臃肿，增加 PCB 层数、BOM 成本、功耗预算。
2.7 落地步骤：从用户场景到硬件 Reach 规格
- 收集原始场景：从产品 PRD、市场调研、竞品分析、历史故障库中获取用户操作与系统交互的典型情景。
- 场景结构化：按“环境+操作+预期结果”三要素描述，排除软件专属流程。
- 硬件化转换：将每个场景映射为硬件信号条件（电平、时序、负载）和功能响应。
- 边界扩展：为每个硬件功能添加最小/最大/标称三组数值，并标注异常状态。
- 优先级排序：按业务价值、技术风险、实现成本分为 P0（必须达） / P1（强烈建议） / P2（可选）。
- 生成 Reach 矩阵：形成二维表，横轴为硬件功能点，纵轴为场景条目，标记覆盖状态。
2.8 验收标准
- 所有 P0 场景对应的硬件功能点均已通过仿真验证。
- 每项硬件需求拥有唯一的场景标识号，并可反向追溯至 PRD 原始条目。
- 硬件 Reach 矩阵中不存在未覆盖的 P0/P1 场景。
- 通过架构评审，确认 Reach 边界在物理实现上可行（功耗、面积、信号完整性均在预算内）。
2.9 Reach 覆盖边界与提取流程（内联 SVG）
下图概括了 Reach 从用户场景到硬件需求规格的提取与边界分层过程：
2.10 案例提示：某物联网网关硬件 Reach 定义
场景：网关在 −20℃ 环境温度下启动，连接8个从设备，供电电压跌落至标称值的 90%。
硬件 Reach 定义：
- 电源模块：3.3V 输出在 −20℃ 且 Vin=4.5V 时纹波 ≤ 30mVpp。
- MCU：RTC 在 −20℃ 下仍能保持时钟精度 ±20ppm。
- 总线：RS‑485 在 1.2km 长线、−20℃ 下接收灵敏度 ≥ 200mV。
覆盖验证：高低温箱 + 可编程电源 + 负载板，执行 50 次上电循环。
硬件 Reach 定义：
- 电源模块：3.3V 输出在 −20℃ 且 Vin=4.5V 时纹波 ≤ 30mVpp。
- MCU：RTC 在 −20℃ 下仍能保持时钟精度 ±20ppm。
- 总线：RS‑485 在 1.2km 长线、−20℃ 下接收灵敏度 ≥ 200mV。
覆盖验证：高低温箱 + 可编程电源 + 负载板，执行 50 次上电循环。
2.11 验收标准（本章结论）
- Reach 矩阵已通过架构团队评审，所有 P0 场景覆盖。
- 每个硬件需求条目拥有唯一追溯 ID，关联原始场景描述。
- 边界扩展覆盖 Min / Typ / Max 三组数值，且包含异常状态（如时钟丢失、电压过冲）。
- 信任链路图中不存在孤立节点（无来源场景的需求或无目标的测试用例）。