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