问题历史：
复杂的需求通常以高层次的抽象形式表达，或者包含多个隐藏的条件和例外。如果不对这些需求进行分解和澄清，可能会导致客户、开发人员和测试人员之间出现误解。
问题：
模糊或不足够分解的需求导致团队“自行推测”细节。结果是业务价值未能实现或扭曲，修正将变得更加复杂和昂贵。
解决方案：
系统分析师通过拆分技术（用例图、活动图、基于INVEST的用户故事、事件风暴、分解树）对需求进行详细分析。重要的是制定场景（基本/替代/例外流程），建立决策表和转换矩阵，最后通过与客户共同验证每个“节点”的边缘案例进行验证。分解后，分析师将所有部分集合起来，分析集成点并确保一致性。
关键特性：
仅仅一个用户故事的文本描述是否足够？
不，单纯的用户故事不够：需要序列图、边缘案例的示例、用户界面的模型和复杂业务逻辑的决策表。
分解是否自动保证需求之间没有矛盾？
不，分解必须伴随冲突需求的整合、定期审查会议和依赖关系分析。
可以将分解完全交给开发人员或测试人员吗？
不，分析师负责完整的细化。如果将其交给其他角色，就会出现多种解释和不一致。
负面案例：
业务客户写道：“系统应为每个客户单独计算折扣。”结果开发出了严格的折扣方案。测试时发现隐藏参数超过十个，这在形式化阶段没有被识别。
优点：
缺点：
正面案例：
分析师通过事件风暴工作坊，找出了所有计算的参数和条件。建立了决策表和序列图，与业务方面确认了边缘案例的示例。需求变得清晰且可验证，错误在开发开始前被发现。
优点：
缺点：