第3章 需求分析阶段：I（Impact）评估——功能影响度与系统耦合度权衡、影响矩阵
I（Impact）评估是RICE框架中承上启下的关键步骤。在评估需求优先级时，仅靠覆盖度（R）和信心度（C）不足以判断一个需求对现有系统的真实冲击——必须量化功能影响度与系统耦合度，并生成影响矩阵来辅助架构决策。本章围绕该评估建立架构边界、分层视图、组件职责、数据与控制流、选型权衡、风险点、落地步骤及验收标准。
3.1 评估边界与输入输出
- 输入：需求变更说明书、现有系统架构文档（包括模块依赖图）、接口契约、数据字典。
- 输出：每个变更项的影响度评分（1~5）、耦合度评分（1~5）、综合影响矩阵本。
- 边界约束：只评估实现阶段可预见的直接与间接影响，不包含运维期长期影响；不考虑信心度（属于E阶段）。
3.2 分层影响视图
| 层次 | 评估维度 | 典型影响点 |
|---|---|---|
| 业务层 | 功能影响度 | 对业务流程可达性、用户操作路径、合规约束的改变等级 |
| 应用层 | 功能影响度 + 耦合度 | API变更波及的服务数、数据库表字段变化量、事件/消息拓扑改动 |
| 基础设施层 | 耦合度 | 网络策略、存储迁移、容器编排配置、CI/CD流水线适配范围 |
3.3 组件职责
- 架构师：定义影响度与耦合度的量化细则，审核最终矩阵，决定是否启动缓冲/回退机制。
- 需求分析师：初步标记功能影响区域，提交给技术团队。
- 开发领队：进行代码级依赖扫描，输出耦合度评分。
- 测试架构师：补充回归测试范围数据集，辅助评估影响真相。
3.4 数据流与控制流（影响矩阵生成流程）
下图展示了从需求变更到影响矩阵的完整数据与控制流动：
3.5 选型权衡：功能影响度 vs 系统耦合度
无法同时追求高功能影响和低系统耦合——架构师需在以下场景中做判断：
- 高功能影响 + 低耦合（理想态）：直接排入高优先级，但需确认耦合度评估是否遗漏了隐式依赖（如消息顺序、缓存一致性）。
- 高功能影响 + 高耦合：最常见困境。建议采用防腐层(ACL)或绞杀者模式来渐进解耦，同时对该需求分配更高的实施缓冲时间。
- 低功能影响 + 低耦合：可延期或组合交付，但需警惕“看起来简单”的变更可能引发的连锁反应——建议至少进行一次快速迷你冲击分析。
- 低功能影响 + 高耦合：应避免直接实现，优先进行技术债务清理；若必须做，则实施特性开关并限制发布范围。
3.6 风险点与常见偏差
⚠ 常见评估偏差
- 过度乐观耦合评分：仅考虑直接接口调用，忽略异步消息、共享数据库、分布式事务链等隐式耦合。
- 功能影响膨胀：需求分析师将用户预期效用误以为是变更范围，导致影响度虚高。
- 评分粒度不一致：不同模块使用不同评级标准，造成矩阵对比无效。
- 静态依赖图过期：代码库已重构但文档未更新，扫描结果失真。
💡 缓解措施：每季度执行全系统依赖图自动绘制（如使用
depviz 或 clang-uml），并做一次人工交叉评审；评分细则必须在团队内达成共识并记录在架构决策记录（ADR）中。
3.7 落地步骤
- 建立依赖扫描基线：基于最新代码提交生成模块依赖图，识别出所有显式/隐式耦合。
- 定义评分标准模板：功能影响度按“业务不可用用户数”“流程阻断程度”“合规风险等级”打分；耦合度按“波及模块数”“接口变更数”“数据级联修改范围”打分。
- 逐项填写影响矩阵：对每个需求变更记录（
变更ID | 功能影响度 | 系统耦合度）并计算综合风险等级（如乘积法影响度 × 耦合度得到综合分数）。 - 四象限归类：将得分对映到前述象限图，标记每个变更的推荐策略。
- 评审与签核：架构师与测试架构师共同确认矩阵，组织变更控制委员会（CCB）审批。
3.8 验收标准
| 验收项 | 标准 |
|---|---|
| 覆盖率 | 所有计划内需求变更均已填写影响矩阵，无遗漏。 |
| 可追溯性 | 每条评分均能追溯到具体的依赖项或业务影响分析记录。 |
| 一致性 | 同一变更在不同评审节点上的评分差异 ≤ 1 分。 |
| 可操作性 | 矩阵结果可直接输入架构设计会议，为接口隔离或重构提供量化依据。 |
核心小结：I 评估不是一次性动作，而是随架构演化持续校准的循环。影响矩阵是架构师与产品经理沟通的共同语言，其质量直接决定 RICE 后续阶段（C—E）的准确度。下一章将进入 C（Confidence）评估阶段，重点探讨如何结合历史交付数据与测试覆盖度建立信心指数。