第1章 · 需求分析陷阱

需求不明确 · 频繁变更 · 伪需求识别 · 干系人沟通缺失

1.1 需求不明确

需求模糊是技术方案的第一杀手。当用户说“我要一个高性能系统”时，往往隐藏着数十个未定义的边界。不明确的需求导致架构师在真空中做决策，后期返工成本呈指数上升。

                典型症状： 用户故事只有标题、验收标准缺失、非功能需求（性能/安全/可扩展）完全空白。
            

1.2 需求频繁变更

变更本身不是问题，但无序、无影响分析的变更会撕裂架构。每一次变更都应经过“影响域评估 → 方案调整 → 干系人确认”的闭环。

变更类型	常见原因	架构影响
范围蔓延	缺乏变更控制委员会	模块边界腐化
优先级震荡	业务方未达成共识	技术债务累积
非功能后置	性能/安全被当作“以后再说”	重构成本剧增

1.3 伪需求识别

伪需求是“看起来正确，但实际不解决真实问题”的诉求。识别伪需求需要5Why分析法和用户价值映射。以下为常见伪需求模式：

“我也要一个像XX一样的功能” —— 忽略自身业务上下文
“先做出来，以后优化” —— 把架构债当作默认选项
“所有数据都要实时” —— 未区分实时与准实时边界

                避坑工具： 需求价值画布 + 影响地图。每次需求必须回答：解决谁的什么问题？如何衡量成功？
            

1.4 干系人沟通缺失

技术方案失败往往不是因为技术，而是因为关键干系人未参与或沟通频道错位。缺失的干系人包括：运维、安全、法务、数据所有者、最终用户。

                沟通矩阵建议： 每两周一次需求同步会，使用 RACI 模型明确每个需求的负责人、咨询者、告知者。
            

📌 需求分析检查清单

# 需求分析自检 (伪代码)
def check_requirement(req):
    assert req.acceptance_criteria, "验收标准缺失"
    assert req.nfr_performance, "非功能需求未定义"
    assert req.stakeholder_approved, "干系人未确认"
    if req.is_vague():
        apply_5why_analysis(req)
    if req.is_copy_from_other():
        validate_business_context(req)
    return req.ready_for_design