用例驱动的需求过程实践

原创 2004年06月11日 22:03:00

      鉴于偶的此文引起大家评论中的内容,在下做出以下声明:

       1)本文是笔者在去年中国系统分析员年会(CSAI 2003,长沙)上的主题报告的讲义整理稿。因此并非十分精细。

       2)对于用例感兴趣的读者,笔者在《程序员》2004年3月刊上有一篇关于用例建模的文章,相信能够满足大家的需求。

一、需求矛盾

  根据CHAO的权威统计,虽然自"软件危机"提出以来,软件工程方法得到了长足的发展与进步,但在去年的软件项目成功率仍然不足30%,绝大多数的软件项目仍然超进度、超成本。而在这些不成功的项目中,由于需求不清晰、需求不完整等方面的因素,占到了60%左右。

  下面的这幅漫画虽然不乏夸张,但却是能够激起我们的深思:

xq1231.gif

  根据笔者多年来从事软件需求捕获、分析工作的实践经验,认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍,双方都以自己的角度、自己的专业术语进行沟通,这使得大家并不能够很好地就软件需求达成共识。

  由于帮助客户更好地利用信息化工具提高工作效率,是我们软件开发团队的责任,因此我们没有权利让用户理解我们所用的语言,而是反过来,我们有义务去理解用户的语言,站在用户的角度看问题。

  而事实上,许多开发团队经常抱怨"我们的客户连需求都说不清楚"、"我们的客户对计算机了解太少了"。多年以来,大家都习惯从自己的角度来定义、分析问题,这也就造成了软件行业成为了一个最缺乏信任的行业,我们需要改一下习惯了。

二、现代需求实践

  针对这些现象,许多先贤们开始了实践,并且总结出了一系列优秀的需求实践:

1)Use case:用例分析技术

  鼎鼎大名的RUP是这样总结自己的:用例驱动,以体系结构为中心,迭代、增量的开发过程。Use case也伴随着RUP、UML一起名扬天下。

  用例用来描绘一个系统外在可见的需求情况,是代表系统中各个项目相关人员(风险承担人,Stakeholder)之间就系统的行为所达成的契约。

2)User Story:用户故事、用户素材

  用户故事是Kent Beck在极限编程(XP)方法论中推荐的最佳实践之一。它由客户参与编写,说明他们需要系统为他们做什么,一般用客户的术语写就,三句话左右。

3)Feature:特征

  这是特征驱动开发(FDD)方法论的核心实践之一。一个特征就是一个小的,具有客户价值的功能,通常表示为<action><result><object>。

  从上面的定义来看,这三种现代软件工程需求实践无一例外地遵从两个原则:一是站在用户的角度看待系统、定义系统;二是用用户看得懂的语言表达。而在笔者的实践中,鉴于以下两点考虑还是先在团队中应用了"用例分析技术":

1)用户故事略显粗糙,掌握起来需要经验,没有详细的规则用于按部就班,一开始采用容易迷失方向;而用例相对来说更加形式化,易于上手;

2)特征看上去很有吸引力,但毕竟相关的理论还未完整,引入团队实践有些困难。

三、用例分析技术简介

  用例分析技术是Rational三友之一Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究,并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后,与三友合作提出了UML、完善了RUP,用例分析技术也因此被人广泛了解和关注。

  用例分析技术为软件需求规格化提供了一个基本的元素,而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。

  许多人是在学习UML的时候接触到Use case,所以许多人都误解其为一种图表,把用例图当作用例分析的全部,其实这是错误的,用例描述才是用例分析技术的核心。下面是一个简单的例子:

xq12312.gif
3.1 参与者,Actor

  参与者,定义了用户在系统交互过程中扮演的角色,其可以是一个人,也可以是另一个相关的系统。

3.2 用例,Use case

  用例实例(场景)是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果,一个用例定义一组用例实例(场景)。

  一个用例应为参与者提供(实现)一个价值。

3.3 事件流

  就像类对应于对象一样,一个用例的实例就是使用场景,用例就是对使用场景进行抽象的总结:

xq12313.gif

  1)前置条件:指在用例启动时,参与者(Actor)与系统应置于什么状态,这个状态应该是系统能够检测到的、可观测的;

  2)后置条件:用例结束时,系统应置于什么状态,这个状态也应该是系统能够检测得到的、可观测的;

  3)基本事件流:基本事件流是对用例中常规、预期路径的描述,也被称为Happy day场景,这时大部分时间所遇到的场景;它将体现系统的核心价值;

  4)扩展事件流:主要是对一些异常情况、选择分支进行描述。

  建议大家在编写事件流时,注意以下几点:

  1)使用简单的语法:主语明确,语义易于理解;

  2)明确写出"谁控制球":也就是在事件流描述中,让读者直观地了解是参与者在控制还是系统在控制;

  3)从俯视的角度来编写:指出参与者的动作,以及系统的响应,也就是第三者的角度;

  4)显示过程向前推移:也就是第一步都有前进的感(例如,用户按下tab键做为一个事件就是不合适的);

  5)显示参与者的意图而非动作(光有动作,让人不容易直接从事件流中理解用例);

  6)包括"合理的活动集"(带数据的请求、系统确认、更改内部、返回结果);

  7)用"确认"而非"检查是否":(如系统确认用户密码正确,而非系统检查用户密码是否正确);

  8)可选择地提及时间限制;

  9)采用"用户让系统A与系统B交互"的习惯用语;

  10)采用"循环执行步骤x到y,直到条件满足"的习惯用语。

四、Alistair Cockburn眼中的用例分析技术

  在使用用例分析技术时,很多人都觉得如何确定用例的粒度是一个难点,而且感觉到用例没有什么规则遵从,甚至有无所适从的感觉。正如Cockburn先生提出的学习用例分析技术的"守、破、离"的三个阶段:

  1)守:练习基本功夫,遵循规则,照章行事;

  2)破:能突破传统,因地制宜地灵活应用; 3)离:超脱任何招式与规则,达到无招胜有招的境界。

  但用例分析技术却让第一阶段的初学者感到无法很快地掌握。而其所著"编写有效用例"则想为用例分析技术补充规则,让大家能够更好地掌握。

  Cockburn先生在Ivar Jacobson的基础上,做了一些补充:

  1)用例是契约,是系统与涉众之间达成的契约。也就是将用例朝着形式化的方向发展;

  2) 将用例分成三级:

  ◆ 概要级:包括多个用户目标(显示用户目标运行的语境,显示相关目标的生命周期、为低层用例提供一个目录表);

  ◆ 用户目标级

  ◆ 子功能级

  不过,对于Cockburn先生的贡献,用例始祖Ivar大师并未做出任何反应。本人在实践中认为,Cockburn先生的思路与理念对于初学用例分析技术的人来说,十分有价值,使得用例分析技术更具操作性,当其同时也有点画地为牢的感觉,也许Cockburn先生也意识到这点,因此第三阶段就是"离",没有规则,按需灵活使用。

五、如何在开发过程中应用用例分析技术

  用例分析技术在需求过程中的地位如下图所示:

xq12314.gif

  对于用例分析技术理解上的两个最大的误区是:

  1)用例分析技术包括了整个需求过程:它只是一个需求分析技术,是在传统的需求捕获技术的基础上使用的,并无法替代这些技术;

  2)用例分析技术是分解技术:其实用例分析技术是一种合成技术,将在需求捕获中收集而来的零散的特性合成为用例:

xq12315.gif

5.1 用例分析前的工作

  在用例分析之前,应该完成以下工作:

  1)确定涉众(Stakeholder)和用户类型(命名、简要描述、涉众代表、特征、能力);

  2)确定涉众代表(命名、简要描述、责任、参与);

  3)在项目中加入涉众代表(访谈、问卷、顾问、评审、角色扮演);

  4)创建共同的构想(问题定义、系统范围、用户目标、非功能需求à前景文档);

  5)采用传统的需求捕获技术捕获需求;

  6)组建用例分析队伍(少量、有问题域知识)。

5.2 用例分析过程中的注意事项

  用例分析的过程如下图所示:

xq12316.gif

  在使用中要注意:

  1)用例源于涉众,请不要自己杜撰出用例;

  2)用例的事件流的编写过程中,应充分加入团队的参与;

  3)虽然用例源于涉众,但不要企图向他们直接问"你还有什么用例?quot;这样的问题。

用例驱动的需求过程实践

 一、需求矛盾  根据CHAO的权威统计,虽然自"软件危机"提出以来,软件工程方法得到了长足的发展与进步,但在去年的软件项目成功率仍然不足30%,绝大多数的软件项目仍然超进度、超成本。而在这些不成功的...
  • fiveday
  • fiveday
  • 2004年12月27日 22:47
  • 491

用例驱动的需求过程实践(转)

一、需求矛盾   根据CHAO的权威统计,虽然自"软件危机"提出以来,软件工程方法得到了长足的发展与进步,但在去年的软件项目成功率仍然不足...
  • currying
  • currying
  • 2016年03月21日 10:11
  • 361

UML从需求到实现----用例

关于用例图的概念相信不用我去说了 .能看到这篇文章的都是知道用例图概念的人. UML 中最重要的是什么图呢 ?毫无疑问应该是用例图 ,用例是后期时序图 和实际开发的重要依据. 说明一...
  • lsh6688
  • lsh6688
  • 2011年03月10日 09:21
  • 6020

《软件需求最佳实践》与《掌握需求过程》对比

最近公司要考察需求技能,抱着总结经验,提升技能的心态,看了两本关于需求的书籍,一本是被公司奉为需求人员教科书的《软件需求最佳实践》徐峰著,一本是《掌握需求过程第三版》James Robertson著。...
  • happymatilian
  • happymatilian
  • 2016年10月27日 16:40
  • 1933

如何写需求用例

今天把项目的第二部分的需求用例提交给了客户,从公司CTO前辈的口中得知客户还是较满意的,这周的任务也算圆满完成了。这几天病得越来越厉害了,看来我得在开发任务下来前好好休息休息了。今天我就先把我对分析和...
  • fen0707
  • fen0707
  • 2013年02月27日 13:35
  • 2192

需求用例分析之八:用例颗粒度

在RUP中,没有对用例的颗粒度给出清晰的指导。2004年Rational 中国区技术销售经理 傅纯一发表一文《用例建模指南》。 2011年,雅各布森为首三人等发布了Use-Case 2.0。其第4条原...
  • zhangmike
  • zhangmike
  • 2014年06月08日 09:13
  • 4622

软件需求用例如何写?

需求是软件设计的一个最最重要的一个部分也是整个软件开发和后期维护的一个重要的基石。试问,开发出来的一款软件,根本不是客户或者是用户所需要的,那么,后果是可想而知的,轻者用户不付款,重者影响到整个公司的...
  • iammerryz
  • iammerryz
  • 2010年04月07日 10:34
  • 6932

需求用例模板

用例编号UC-3用例名称积分累积创建者****最后更新 创建时间二〇〇四年十月二十五日最后更新时间十月二十五日执行者操作员或终端说明执行者收集消费客户的消费信息,并将这些信息发送至处理系统,根据消费客...
  • qiang_gu
  • qiang_gu
  • 2004年11月22日 15:55
  • 1352

软件设计需求分析---用例说明模板1(经典模板)

编者说明:     随着UML的日益普及,用例(Use case)分析技术也在需求实践中广泛被采用。但是也有许多团队在使用该技术时,只画出了用例图,而缺少了用例说明,其实这是一个严重的误区。而本模...
  • ming101593
  • ming101593
  • 2012年05月15日 16:40
  • 1486

产品需求文档PRD的写作(五) – 用例文档(UML用例图、流程图)

在产品和技术领域里都有UML的技能知识,而对于产品人员的UML则更多的是指用例图,也就是我所称呼的用户流程图。在讲PRD文档写作的第二篇文章里,我提到了用户流程图的制作,实际上用户流程图是我在产品规则...
  • wqdwin
  • wqdwin
  • 2016年01月16日 15:38
  • 2772
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:用例驱动的需求过程实践
举报原因:
原因补充:

(最多只允许输入30个字)