需求用例分析之二:级别设置

在《编写有效用例》(阿莱斯特-科伯恩著,下面用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了例如以下级别:海平面、云朵、风筝、蛤等等。

科伯恩建议用例级别分为多个个目标层次:概要、用户目标、子功能,书写需求用例时,仅仅能选择其一,以下对其详细说明:

  • 概要:包含多个用户目标,它有“显示相关目标的生命周期顺序”和“为低层用例提供一个文件夹表”的功能,概要用例通常须要运行几个小时、几天、几个星期、几个月、甚至几年。
  • 用户目标:它是主运行者努力使工作得以完毕的目标,或是用户使用系统的目标,通常情况下指系统为用户提供的界面操作。
  • 子功能:指那些在实现用户目标时可能会被用到的目标,通常是指系统内部运行,而用户看不到界面的用例。

在雅各布森用例分析方法(UML统一建模语言、RUP瑞理统一过程之父Ivar Jacobson伊瓦·雅各布森在OOSE、RUP和UML中阐述的用例分析方法)中,充分利用了UML中包来组织子系统、模块和用例。雅各布森用例方法与UML、RUP三者之间有着天然的紧密联系,除了能够用RUP的格式文本描写叙述用例外,还推荐适当地选择利用UML用例图、活动图、包图和状态图等等图示从各个角度来描写叙述和组织用例,可谓手段充足、武器齐备。

级别与静态展现

两者事实上没有本质差别,雅各布森用例分析方法更加注重在RUP和UML下协同发挥作用。从如今工具的情况来看,用包来包括用例是UML的标准做法,毕竟以用例来包括用例显得有些怪异,眼下没有看到有工具支持用例包括用例。从静态而言,包攻克了多级别用例的问题。

级别与动态变化

可是这里其实另一个时间动态的问题:即是海平面级用例一般而言是早于云朵风筝级用例出现的,而蛤级用例是最后出现的。在RUP中强调迭代演进来处理包和用例分解重组等等,其实最后将淹没以前出现的海平面级用例,这对于追溯用户最初的需求而言是不利的。当然RUP配套有业务用例分析,业务用例将收集用户起初的业务须要,但这显得过于累赘。但实际採用中,非常少见到严格依照RUP先分析业务用例,再分析用例,往往的直接分析用例。

改良的级别设置方法

所以在雅各布森用例分析方法中採用原始需求列表来替代业务用例分析,是既能追溯最初的需求,又能节约大量业务用例分析的工作量,这样就能从时间动态和结构静态双方面融合了两种方法的优势。

相应在科伯恩用例分析方法,相当于将首批海平面级用例(用户直接表达的目标)专冊收集兴许跟踪,而利用包来替代云朵和风筝,后来的海平面(经分析后的海平面)级用例仍然是实质性的用例。

改良的级别处理方式能融合两大流派在这方面的各自考虑,综合发挥优势,规避劣势。

參考资料

  1. RUP
  2. 编写有效用例
  3. 统一用例分析 作者:张恂
      http://www.uml.org.cn/oobject/200606013.htm

需求用例分析之二:级别设置

时间: 2024-10-14 10:06:47

需求用例分析之二:级别设置的相关文章

苍狼敏捷需求用例分析方法简介并讲义下载

作者:张克强    作者微博:张克强-敏捷307 用例分析方法已经有不短的历史,发展出了多种用例分析方法.笔者花费了大量时间,对用例分析的各个方面进行实践和分析,得到如下系列文章: 需求用例分析之一:异常流 需求用例分析之二:级别设置需求用例分析之三:补充规约 需求用例分析之四:业务规则 需求用例分析之五:业务用例之Rational系 需求用例分析之六:业务用例之科伯恩系 需求用例分析之七:业务用例之小结 需求用例分析之八:用例颗粒度 在这些分析的基础上与及笔者的实践,总结整理得到"苍狼敏捷需求

需求用例分析之九:序列图

作者:张克强    作者微博:张克强-敏捷307 序列图,也称时序图.顺序图,英文名Sequence Diagram.在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图.而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少. 在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合.它是在得到用例之后初步识别了类之后发挥巨大作用的.序列图是交互图(interaction diagr

需求用例分析之级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,以下用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了如下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,只能选择其一,下面对其具体说明: 概要:包括多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个目录表"的功能,概要用例通常需要执行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主执行者努力使工作

需求用例分析之业务规则

作者:张克强 作者微博:张克强-敏捷307 在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有"业务规则"的属性,在科伯恩方法中有个相近的属性是约束条件.但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢? 从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书.在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物.受到传统需求规格说明书的深远影响,不少人觉得这样的业务规则是值得写的用例

需求用例分析之异常流

问题的引出 备选流,又称备选事件流,英文是Alternative Flow.在RUP和UML中,备选流的解释如下:备选事件流包括与正常行为相关的可选或异常特征的行为,同时也包括正常行为的各种变形.您可以将备选事件流看作是基本事件流的"绕行道",有些备选事件流将返回到基本事件流,而有些将结束此用例的执行. 分析RUP对于备选流的定义,可以看到备选流可以分成两类: 1,不同做法但仍然达成用例目标: 2,异常情况,无法达成用例目标. 在实际用例分析中,由于备选流可能存在两种情况,导致备选流存

需求用例分析之补充规约

补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求.这些需求包括: § 法律法规方面的需求和应用标准. § 要建立的系统质量属性,包括可用性需求.可靠性需求.性能需求和可支持性需求. § 其他需求,诸如操作系统和操作环境.兼容性需求以及设计约束. 补充规约是对用例模型的重要补充.补充规约和用例模型应该一起获取对系统的一整套需求. 通过以上文字可以知道,补充规约是全局性的要求,与上述c文中的"全局规则"极为接近.而中文中"补充规约"的说法让不少人以

需求用例分析之备选流

#用例分析#之备选流 alternative flow-这是用例方法中最混淆之处,不管中文还是英文.都出现很多不同的理解和不同的做法.问题在于备选流字面意思模糊,能够是可选的不同做法,也能够说异常.也能够是导致失败的情况.可叹的是,其原定义是清楚的:无法达成用例目标的情况.但它起了个不恰当的名字 或许是由于这个混乱,导致出现了"主成功场景"替代基本流,"扩展场景"来替代备选流的做法. 这与用例的优雅的初衷事实上是不相符的.用例之优雅在于对场景的抽象.而不是直接铺陈场

需求用例分析之六:业务用例之科伯恩系

作者:张克强    作者微博:张克强-敏捷307 来自于科伯恩<编写有效用例>对业务用例的说明 在<使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处>中分析科伯恩编写有效用比例如以下: Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了同样的用例说明模版. 业务用例与系统用例说明使用这个模版的差别是设计范围,而不是模版. Cockburn 想通过目标层次对用例进行分类.如表格1所看到的. 图1: Alistair 

LoadRunner性能测试样例分析

LR性能测试结果样例分析 测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1- 1所示.性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向.我们回顾一下本次性能测试的目的,正如 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服