4. C（Confidence）判定——技术可行性、供应商成熟度、风险登记表

4.1 本章边界

置信度（Confidence）判定是需求分析阶段的第三道关卡，位于价值估算（Value）和实现成本（Cost）之后。本章聚焦于技术可行性、供应商成熟度与风险登记表三个维度，综合评估团队对需求落地的信心程度。输出结果直接决定该需求是进入设计阶段，还是被降级为“待验证”或“暂缓”。

4.2 分层结构

置信度判定分解为三个并行层次，每层聚焦独立评价维度：

1. 技术可行性层——评估目标技术栈的成熟度、团队经验、集成复杂度。
2. 供应商成熟度层——评估硬件供应商/芯片厂商的交付能力、生态支持、长期供货承诺。
3. 风险登记层——识别并量化项目级风险，形成风险登记表（Risk Register）。

三层评估结果经加权或逻辑规则融合，最终输出置信度等级。

4.3 组件职责

4.4 数据流 / 控制流 / 信任链路

数据沿“需求输入 → 三层并行评估 → 置信度融合 → 决策出口”流动。控制流依赖三个评估组之间的异步协同：技术可行性评分和供应商成熟度评分作为风险登记表的上下文输入，但风险登记表可独立更新。信任链路通过评审机制保证——每层输出均需架构师与领域专家联签。

4.5 选型权衡

• 成熟 vs 前沿：成熟供应商评估容易，但可能因适配成本导致延期；前沿技术短期信心不足，但长期竞争力强。建议对关键路径采用“成熟供应商 + 高风险预备方案”，对创新需求设定“技术验证型 Confidence=2”。
• 风险登记粒度：过细的风险登记导致评估成本高（每个风险都需缓解计划）；过粗则可能遗漏关键隐患。推荐按“严重性≥3 且可能性≥3”定位为红级风险，必须出具专项应对。
• 评分合并规则：采用取最小值或加权法。建议：
  C = min(技术可行性分, 供应商成熟度分, 3 - 二进制风险标志（存在红灯风险减1）)。
  此规则可避免单项高分掩蔽另两项的缺陷。

4.6 风险点

1. 技术评估过度乐观：未充分验证底层硬件中断延迟、内存带宽等硬约束，导致后期重新选型。
2. 供应商信息不对称：厂商宣传的生态支持实际未覆盖目标场景，建议从现有用户咨询独立验证。
3. 风险登记静态化：在需求分析阶段仅做一次登记，之后不再更新。需建立定期刷新机制（每两周或里程碑节点）。
4. 置信度与成本耦合不足：高置信度可能伴随高成本风险，需与上一章 Cost 判定联动。

4.7 落地步骤

1. 收集输入材料：需求说明书、系统架构图、预选供应商清单、过往项目经验数据。
2. 技术可行性评估会议：由硬件架构师、驱动工程师、系统集成工程师共同评审关键技术指标（功耗、带宽、实时性）。
3. 供应商成熟度打分：对照标准模板（如交付准时率、应变更频率、FAE 响应时间）逐项评定。
4. 风险识别与登记：使用结构化列表（风险 ID、描述、可能性、影响等级、缓解措施、责任人、状态）。
5. 置信度融合：按规则计算 C 值，若 C≤1 则标记为“需预研/原型验证”，C=2 为“可接受但需关注”，C=3 为“高信心，直接进入设计”。
6. 结果同步：将置信度等级及风险登记表写入需求决策记录，并抄送产品经理和项目管理者。
7. 迭代更新：在后续阶段每次关键决策点（如设计评审、采购签约）前重新评估三层数据，刷新置信度。

4.8 验收标准

• 技术可行性评分明确记录，并附上关键验证点（如 PoC 结果、参考设计链接）。
• 供应商成熟度评分引用至少两份可信资料（如合同、第三方用户报告）。
• 风险登记表包含 ≥3 条风险项，且每条均有缓解措施和责任人。
• 置信度等级以红色/黄色/绿色状态显示在需求看板上。
• 所有阶段输出均通过架构师 + 测试负责人的双签确认。