用例分析包括两个有机的组织部分：用例图是目录，用例描述是封装所有需求的形式。
-
用例图
image.png
- 用例描述与文档
编写用例文档比画用例图更为重要
1、用例是文本形式的情节描述，一般是用于软件的功能性需求，非功能性需求如性能一般可以在用例中加上描述。
2、用例和用例之间主要是包含关系、扩展关系和依赖关系。
3、用例的一些重要内容：参与者、场景。用例就是一组相关的成功的或失败场景集合
4、参与者是某些具有行为的事物，可以是人，计算机系统或组织
5、场景是参与者和系统之间一系列的特定的活动和交互。场景可以从主成功场景和交替场景（也可以叫主路径和扩展路径）
用例编写步骤：
- 选择系统边界
- 确定主要参与者
- 确定每个主要参与者的目标
- 定义满足用户目标的用例，根据其目标对用例命名
真实项目中如何发现用例？
调研需求时先确定涉及多少部门，多少岗位（参与者），然后找到每个岗位的业务代表，问他们类似的问题，你平时都做什么（参与者目标），这件事情是谁交办的？做完了你需要通知或传达给谁吗？做这件事你都需要填写什么表格吗？（用例）
无标题.png
- 用例的来源：
(1)自顶向下
在访谈现场，就流程图讨论出用例图是高效的建模方法。
显然，流程图中的岗位信息（即跨职能流程图中的职责带区、活动图中的泳道）是参与者的候选者，而他们负责的业务活动就是用例的候选者。而评价的要点就在于“是否属于系统范围”。
对于参与者的派生：首先排除不直接使用系统的岗位，然后确定角色
对于用例的派生：对于活动，主要是判断它是否属于系统范畴之内；对于判断，则要分析它是属于某个活动还是一个独立的活动。
(2)自底向上
对于流程不清晰不好梳理的中小型系统，适合采用自底向上合并法，从需求捕获阶段获得的需求列表着手，合并出所需的用例。
①收集原始需求
②确定参与者
根据参与者合分组并用例
