用例建模的五个子过程

1、倾听;

2、捕获;

3、细化;

4、调整;

5、检查;

五个字过程相互独立,有各自的输入和输出,以输入的变化为活动触发因素。

倾听:既是和客户交流,搞清楚他们要什么。

捕获:“谁”通过使用系统的“什么功能”达成“什么目的”?不断回答这个问题,确定用例和角色,宁可重复覆盖,也不要覆盖不全。

细化:对各个用例进行细化,考虑各个业务场景,归纳成事件流,用活动图描述出来。

调整:也许某些用例全部或部分重复了,也许某个用例过于复杂,也许某个用例包含了多条事件流且这些事件流没有相交,也许某些事件流都包含了同一个子段,这些都需要调整,随着用例的调整,角色也随之相应调整。

检查:通过以上4个子过程输出的用例模型如果不满足一下4点则需要打回重构:

1、是否覆盖了所有需求?

2、某些地方的描述是不是有二义性?

3、某些地方与其他地方的描述是不是相矛盾?

4、是不是易于理解?

时间: 2024-10-11 04:11:51

用例建模的五个子过程的相关文章

用例建模指南

用例建模指南 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模.用例方法最早是由Iva Jackboson博士提出的,后来被综合到UML规范之中,成为一种标准化的需求表述体系.用例的使用在RUP中被推崇备至,整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的,各种类型的开发活动包括项目管理.分析设计.测试.实现等都是以系统用例为主要输入工件,用例模型奠定了整个系统软件开发的基础. 1. 什么是用例? 在介始用例方法之

采用[ICONIX] 方法实践分析和设计之二 [用例建模](转)

在上一篇文章中我们了解并进行了域建模,换言之我们有了一个好的开始,起码开发人员对自己要开发的软件已有了初步的认识,且也得到了进行交流时可以使用的术语表. 本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模,同样在文章的最后还会有在这个阶段最容易犯的10个错误,以给大家提醒或在分析过程中进行参照.     本文在ICONIX方法中所处的位置如下图(红圈标记的地方)     在开始进行用例建模之前,我们需要对这一过程有一些粗线条的认识,如果您以前做过或学习过这方面的知识,可以把下面的

第三项任务——用例建模

SRS文档——用例建模 一.spec概念 Specification, 又叫spec, 有两种: a) functional spec, 软件功能说明书, 主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子). b) technical spec, 软件技术说明书, 又叫 design doc, 设计文档, 主要用来说明软件内部的设计 (把软件当作一个透明的箱子). 二.用例建模 用例建模(Use Case Modeling)是使用用例的方法来描述系统的功能需求的过程,用例模

用例建模和分析

描述用例建模的优点 定义参与者和用例,并能够从上下文图以及其他资源中确定参考图和用例 描述四类参与者 描述用例模型图种可能出现的关系 描述准备用例模型图的准备 描述如何构造用例模型图 描述用例的各节内容 定义用例分级的目的.优先权矩阵,以及用例依赖关系图 关键术语 以用户为中心的开发:一个系统开发过程,该过程基于对关联人员的需求,以及对开发该系统原因的充分理解之上 用例建模:使用业务时间.发起业务事件的人,以及系统如何相应这些事件来建模系统功能的过程 用例图:描述系统与外部其他系统以及用户之间交

项目管理中的五个过程组和九大知识领域

五个过程组指的是:    启动.规划.执行.监控.收尾 九大知识领域指的是: 整体.范围.进度.成本.质量.人力资源.沟通.风险.采购 在5个过程组.9个知识领域内,分布着各个子过程组,PMBOK2004中有44个,到新版本的PMBOK2008调整为42个过程,我用下图来进行描述. 知识领域 启动 规划 执行 监视与控制 收尾 项目整体管理 制定项目章程 制定项目管理计划 指导项目执行 监视与控制项目工作 项目收尾 项目或阶段收尾(新) 制定初步范围说明书 整体变更控制 范围管理 范围规划 收集

再学UML-UML用例建模解析(三)

2. 编写用例文档 绘制用例图只是完成了用例建模最基本也是最简单的一步,用例建模的核心在于编写用例文档,用例文档又称为用例规约或用例描述.顾名思义,用例文档是用于描述用例的文档,每一个用例对应于一个用例文档,在用例文档中需要用文字的方式描述用例的执行过程,即执行者与系统的交互过程. 用例文档需要通俗易懂,不仅项目的开发人员能够理解,系统的用户以及客户也能够看懂用例文档.一个完整的用例文档包括用例编号.用例名.执行者.前置条件.后置条件.涉众利益.基本路径.扩展路径.字段列表.业务规则.非功能需求

工程实践用例建模Use Case Modeling

用例建模就是通过对软件需求的调研,从具体的功能性需求中抽象出用例模型的工作过程.参与者和用例由对功能性需求的分析来确定,用例图是参与者和用例的可视化表示.用例图中的四种关系: 1.关联:建立参与者与用例通信的渠道,当然关联可以是双向的,可以是单向的.箭头的方向表示消息的传递方向. 2.依赖:一个用例受到另一个用例的影响. 3.包含:基USE CASE图本用例的行为包含了另一个用例的行为 4.扩展:扩展用例是基本用例的一个扩展 5.泛化:存在于Actor和Use case之间,例如数学老师是老师的

Linux文件系统的用例建模

1 用例 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模. 1.1 参与者和用例 从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,也就是被开发出来的系统将是如何被使用的,这就是用例方法的基本思想.用例模型主要由以下模型元素构成: 参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境. 用例(Use Case)用例用于表示系统所提供的服务,它定

Uml学习-用例建模简介

用例建模简介  用例建模是UML建模的一部分,它也是UML里最基础的部分.用例建模的最主要功能就是用来表达系统的功能性需求或行为.用例图重点描述用户需求. 它描述需求.用户和主要组件之间的关系. 它不会详细描述用户需求:在可链接到每个用例的其他关系图或文档中可详细描述这些需求.用例图是UML的九个图中较为重要和常用的一种图.常常用于软件开发的需求分析阶段,也能用于软件的系统测试阶段.简单的来说,用例图是描述系统的外部视图,为了搞清某个项目的大概需求,我们往往要问两个问题, 1.  这个系统有什么