需求分析-04角色与场景分析

用例分析包括两个有机的组织部分：用例图是目录，用例描述是封装所有需求的形式。

• 用例图

  
  image.png

• 用例描述与文档
  编写用例文档比画用例图更为重要
  1、用例是文本形式的情节描述，一般是用于软件的功能性需求，非功能性需求如性能一般可以在用例中加上描述。
  2、用例和用例之间主要是包含关系、扩展关系和依赖关系。
  3、用例的一些重要内容：参与者、场景。用例就是一组相关的成功的或失败场景集合
  4、参与者是某些具有行为的事物，可以是人，计算机系统或组织
  5、场景是参与者和系统之间一系列的特定的活动和交互。场景可以从主成功场景和交替场景（也可以叫主路径和扩展路径）

用例编写步骤：

1. 选择系统边界
2. 确定主要参与者
3. 确定每个主要参与者的目标
4. 定义满足用户目标的用例，根据其目标对用例命名

真实项目中如何发现用例？

调研需求时先确定涉及多少部门，多少岗位（参与者），然后找到每个岗位的业务代表，问他们类似的问题，你平时都做什么（参与者目标），这件事情是谁交办的？做完了你需要通知或传达给谁吗？做这件事你都需要填写什么表格吗？（用例）

无标题.png

• 用例的来源：
  (1)自顶向下
  在访谈现场，就流程图讨论出用例图是高效的建模方法。
  显然，流程图中的岗位信息（即跨职能流程图中的职责带区、活动图中的泳道）是参与者的候选者，而他们负责的业务活动就是用例的候选者。而评价的要点就在于“是否属于系统范围”。
  对于参与者的派生：首先排除不直接使用系统的岗位，然后确定角色
  对于用例的派生：对于活动，主要是判断它是否属于系统范畴之内；对于判断，则要分析它是属于某个活动还是一个独立的活动。
  (2)自底向上
  对于流程不清晰不好梳理的中小型系统，适合采用自底向上合并法，从需求捕获阶段获得的需求列表着手，合并出所需的用例。
  ①收集原始需求
  ②确定参与者
  根据参与者合分组并用例