软件需求分析中的用例迭代与工具应用
在软件需求分析过程中，Facade迭代和Filled迭代是两个重要的阶段，它们各自有着明确的目标、步骤和相应的工具，下面将详细介绍这两个迭代阶段的相关内容。
1. Facade迭代
Facade迭代为后续的用例开发提供了一个高层次的系统视图，并为各项任务创建了占位符。在这个阶段，需要运用多种工具来确保迭代的顺利进行。
1.1 用例图
在Facade迭代中，要为每个Facade用例创建用例图。可以根据自己的喜好决定是否在一个图中放置多个用例。此时，只能显示发起者为简笔人物形象以及带有名称的用例气泡。虽然这看似简单，但提前开始做能为后续迭代的细节提供基础。
1.2 层次结构问题
需求的层次结构应该被摒弃。功能分解存在诸多问题，会使需求规范变得复杂。尽管如此，人们还是倾向于将用例放入整齐的层次结构中，这与功能分解类似，甚至有些方法还会对层次进行颜色编码，增加了混乱。
根据Dr. Suh的最小良好系统公理，系统的需求必须相互独立。如果一个需求是另一个需求的子集，它们就不独立，这会在需求变更时引发问题，也会影响利益相关者的理解，还需要团队之间进行大量的沟通和额外的管理层次。
不过，在项目中有时需要对用例进行分组。可以采用以下两种方式避免层次结构带来的问题：
-使用UML包进行项目组织分组：例如，将用例分配给业务分析团队、与不同产品版本相关的用例、处于不同完成度（Facade、Filled、Focused）或成熟度（可演示、稳定）的用例等。UML包是用例的简单容器，当包内的用例被修改、移动、合并或删
