通过需求、契约、数据和运营依赖追踪变更影响。首先明确新旧需求的确切差异；“支持更大规模”或“改成实时”过于模糊，无法可靠评估。
沿依赖图追踪
text
[Changed requirement] --> [Affected business flow]
|
[Interface contracts]
/ \
[Consumers] [Data/state]
\ /
[Operations + tests]
以追踪记录和接口目录为起点，再结合已部署配置、实际流量和系统负责人掌握的知识进行验证。文档可能遗漏批处理任务、导出或其他团队负责的消费方。
示例：更快查看库存
假设原约定每小时刷新库存，新需求则要求一分钟内可见。澄清中断期间是否也适用，以及用户需要的是估计值，还是权威的库存预留确认。
检查 ERP 发布变更的能力、下游 API 配额、缓存有效期、新鲜度指标和报表假设。如果源系统只每小时更新一次，仅修改门户刷新间隔无法满足需求。分析可能得出结论：必须改变源系统能力或业务目标。