（计算机应用技术专业论文）用例驱动方法在软件需求获取方面的研究及应用.pdf

婴型查兰! 堂堡主堂堡堡奎 ! z z 璺z 5 1 用例驱动方法在软件需求获取方面的研究及应用 专业：计算机应用技术 研究生：向劲松 导师：李志蜀 用例驱动方法是当前国际流行的软件开发过程之一，软件开发所有阶 段的活动都是以用例为核心。u n i f i e dp r o c e s s 和统一建模语言都是基于用例 驱动的软件工程流程。在现实中，我们经常会看到有头无尾的工程，用户 不满意的工程，难以投入使用的工程，或者严重超支和拖延进度的工程。 同时，我们还看到测试用例在实际处理过程中没有起多大作用，编写出的 测试用例并不是用户最初想要的。软件项目存在的问题仍然非常严重，而 这种现象往往是需求问题造成的。软件需求获取是软件系统开发过程中最 为困难也是最为重要的部分，只有真正满足用户需求的软件产品才能为用 户所接受，而需求往往又是最能省钱的地方。 本文在对软件需求进行层次划分的基础上，以行政学院房产管理系统 为背景，探讨了一个以用户为中心，使用用例驱动分析技术依据用户目标 获取不同层次的软件需求的过程。首先根据业务需求的远景通过用例获取 用户需求，接着通过求精这些用例获取相应的功能需求，最后再通过对获 得的用户需求和功能需求的分析验证来反馈修正业务需求。实践证明，这 种循环迭代式的需求获取方法可以有效地获取正确、合理的软件需求，以 开发出令用户满意的软件产品来。用例驱动、迭代增量的软件体系结构构 建方法，对于软件体系结构的构建具有很好的指导作用，它符合人们的认 识和思维方式。以用例为核心组织需求一一所有需求，最终的需求文档可 以简单到只有一个用例文档。用例分析方法尽管有其自身的缺点，但目前 四川大学工学硕士学位论文 仍然是非常好的解决方案。实践证明，这种方法相对于传统的体系结构构 建方法，具有更高的效率。 关键词：用例驱动；需求获取；用户需求；功能需求；参与者：e r 图 四川大学工学硕士学位论文 r e s e a r c ha n da p p l i c a t i o no fu s e - c a s ed r i v e na n a l y s l s m e t h o do ns o f t w a r er e q u i r e m e n t se l i c i t a t i o n m a j o r ：s p e c i a l t yo f c o m p u t e r a p p l i c a t i o n g r a d u a t es t u d e n t ：x i a n gj i n s o n g a d v i s o r ：l iz _ h i s h u u s ec a s ed r i v e n a p p r o a c hi sap o p u l a rk i n do f s o f t w a r ed e v e l o p i n g p r o c e s s e si nt h ew o r l da tp r e s e n t ，a n du s ec a s e sa r et h ec o r eo f a l la c t i v i t i e si n e a c hp h a s e u n i f i e dp r o c e s sa n dt h eu n i f i e dm o d e l i n gl a n g u a g e ( u m l ) a l ea l i s o i t w a r ee n g i n e e r i n gp r o c e s s e sw h i c hb a s e do nu s e s - c a s ed r i v e na p p r o a c h w e c a ns e ef r e q u e n t l yi nt r u e l i f et h ep r o j e c tw h i c hs t a r t ss o m e t h i n gb u tn o tf i n i s h i t ，c o n s u n l c rn o ts a t i s f a c t o r y , d i f f i c u l t yt op u t si n t ou s e ，o rs e r i o u s l ye x c e e d s e x p e n d i t u r e sa n dd e l a y st h ep r o g r e s s a tt h es a m et i m e w ea l s o 蛳t h e t e s t - c a s ed o e sn o tp r o c e s s e st h em a j o rf u n c t i o ni nt h ea c t u a lt e s t i n g , t h e t e s t c a s ei sn o tt h eo n ew h i c hc o n s u m e rw a n t sa tf i r s t t h ee x i s t e n tp r o b l e m s i ns o f t w a r ep r o j e c tw c r es t i l le x t r e m e l ys e r i o u s ，b u tt h i sk i n do f p h e n o m e n o n o f t e na r o s eb yt h er e q u i r e m e n t sp r o b l e m s g a i n i n gs o f t w a r er e q u i r e m e n t si st h e m o s ti sd i f f i c u l ta n di m p o r t a n tp a r ti nt h ep r o c e s so f s o f t w a r es y s t e m d e v e l o p m e n t ，o n l yt h es o f t w a r ep r o d u c tw h i c hm e e t st h ec o n s u m e r sn e e d i n d e e dt ob ca b l et oa c c e p tb yt h ec o n s u m e r a n dt h er e q u i r e m e n t so f t e na l s oi s ap l a c ew h i c hm o s tc a ne c o n o m i z e t h i sp a p e r , w h i c ht a k et h eh o u s ep r o p e r t ym i so f a d m i n i s t r a t i o nc o l l e g ea st h e b a c k g r o u n d e x p l a i n sau s e rc e n t e r e dp r o c e s so f s o f t w a r er e q u i r e m e n t s e l i e i t a t i o no nt h eb a s i so f r e q u i r e m e n th i e r a r c h y , i nw h i c hu s ec a s ed r i v e n a n a l y s i si su s e dt oe l i c i ts o f t w a r er e q u i r e m e n t sa td i f f e r e n tr e q u i r e m e n tl e v e l a c c o r d i n gt ou s e r sg o a l s t h r o u g ho b t a i n i n gt h eu s e r sn e e d sw i t ht h el l s ec a s e 四川i 大学工学硕士学位论文 a c c o r d i n gt ot h ed i s t a n tv i e wo f t h eb u s i n e s sr e q u i r e m e n t sa tf i r s t ，t h e no b t a i n t h ec o r r e s p o n d i n gf u n c t i o nr e q u i r e m e n t st h r o u g hu s ec a s er e f i n e m e n t f i n a l l y t h r o u g ht h eu s e r sr e q u i r e m e n t sa n df u n c t i o nr e q u i r e m e n t s v a l i d a t i o na n d a n a l y s i s ，w h i c ho b t a i n e db e f o r e ，f e e d b a c k sa n dr e v i s e st h eb u s i n e s s r e q u i r e m e n t s p r a c t i c eh a sp r o v e dt h a tt h ec i r c u l a t o r ya n di t e r a t i v em e t h o do f s o f t w a r er e q u i r e m e n t se l i c i t a t i o nc a no b t a i nc o r r e c t ，r e a s o n a b l es o f t w a r e r e q u i r e m e n t se f f e c t i v e l y ，i no r d e r t od e v e l o pt h es o f t w a r ep r o d u c tm a k i n gu s e r s s a t i s f i e d u r g e ，t h ec o n s t r u c tm e t h o do f s o f t w a r es y s t e ms t r u c t u r ew h i c hm a k e u s eo fi t e r a t i v ei n c r e m e n ta n du s ee a s e ，h a v ev e r yg o o dg u i d a n c ef u n c t i o n st o t h ec o n s t r u c t i o no f t h es y s t e ms t r u c t u r eo f t h es o f t w a r e ，i ta c c o r d sw i t h p e o p l e s u n d e r s t a n d i n ga n dm o d eo f t h i n k i n g t oo r g a n i z er e q u i r e m e n t sb a s e do n u s e - c a s e a l lr e q u i r e m e n t s ，t h ef i n a lr e q u i r e m e n t sd o c u m e n t sm a ya ss i m p l ya s o n l yo n eu s e c a s ed o c u m e n t s a l t h o u g hu s ec a s ed r i v e na n a l y s i sh a si t so w n s h o r t c o m i n g s ，i ti ss t i l lav e r yg o o ds o l u t i o na tp r e s e m p r a c t i c eh a sp r o v e d ， t h i sk i n do f m e t h o di sm o r ee f f i c i e n c yt h a nt h et r a d i t i o n a lm e t h o dt h a tb a s e do n s y s t e m a t i s mf a m ec o n s t r u c t k e y w o r d s ： u s e c a s ed r i v e n ；r e q u i r e m e n t se l i c i t a t i o n ；u s e rr e q u i r e m e n t s ；f u n c t i o n a l r e q u i r e m e n t s ；a c t o r ；e rd i a g r a m 四川大学工学硕- 上学位论文 1 引言 对大多数软件和系统开发团队来说，与过去自由的日子相比，2 0 世 纪9 0 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标 准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建 模和重建的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定 和应用了许多有效的软件开发流程。在这十年内，全球经济对软件的依赖 程度加深，它推动着开发流程的发展，同时提高了系统质量。 虽然与“软件危机”一起诞生的软件工程方法和建模理论已经发展了 几十年，取得了长足的发展与进步。但现实的情况是，软件项目存在的问 题仍然非常严重，我们经常会看到有头无尾的工程，用户不满意的工程， 难以投入使用的工程，或者严重超支和拖延进度的工程。而这种现象往往 是需求问题造成的。虽然人们提出了解决需求获取问题的很多方法和技 术，但仍然难以从根本上解决需求问题。 软件需求获取( s o t h v a r er e q u i r e m e n te l i c i t a t i o n ) 是软件系统开发过 程中最为困难也是最为重要的部分，只有真正满足用户需求的软件产品才 能为用户所接受，不能满足这一点的产品不管采用了多么先进的技术对用 户来说也是毫无用处的。需求往往是最能省钱的地方。根据l e m n g w e l l 在1 9 9 7 年的研究，软件项目中4 0 6 0 的问题根源都是在需求的获取 和分析阶段埋下的，而这些问题放到产品发布后再改正，比在需求阶段就 改正，需要多付出6 8 - - 2 0 0 倍的成本。传统的结构化软件开发方法在需求 阶段侧重的是业务数据或者是业务流程却没有把二者结合起来考虑，开 发出来的产品结构复杂难以维护、可重用性差。面向对象技术把数据及其 处理过程集成到类中克服了结构化方法的缺点，但是忽视了用户的需求。 以前说软件开发技术，往往忽视了用户才是软件产品的最终使用者，大多 数公司主要注意的是实现阶段的技术。需求阶段草草了事的居多，他们大 多以功能为中心而忽视了用户的参与，通常会导致最终产品与客户问的期 望差异。但是随着软件业的发展，现在很多公司也已经注意到了需求技术 t r ) l l 大学工学硕士学位论文 的重要性。 同时，我们经常昕到软件测试者抱怨：测试用例在实际处理过程中没 有起多大作用，测试人员在实际测试时根本没有按测试用例执行，测试用 例的编写非常困难，编写出来的测试用例不能真正体现用户的需要。我们 分析认为，对测试用例重要性的认识不够，测试流程不完善，针对测试用 例的管理流程更不完善是其中的原因，但根本原因在于需求获取阶段。 测试人员在需求阶段应该参与软件需求调研，以测试角度分析需求的 可测性，可构思将来对其测试的方法、原则等：更重要的是，对不可测或 难以测试性问题要及时与客户或项目经理协调解决。全面了解系统需求， 从客户角度考虑软件测试需要达到的验证状态，即哪些功能点需要重点测 试、哪些无需测试，以便将来制定测试计划。测试人员有必要编写一份软 件功能点测试描述书，它是软件的详细测试分析文档，其主旨是将系统 分析人员的开发分析文档加工成以测试为目标的功能点分析文档，重要的 是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何 种数据测试、期望测试结果等等，这些信息都是描述性的，无须具体数据： 它的作用是据此编写测试用例，以及钡4 试执行时的参考依据，基于它直接 来源于需求，覆盖当然最全，也最能满足客户要求，产生的系统也是高质 量的有效系统。 基于用例驱动分析技术( u s e c a s ed r i v e na n a l y s i s ) 的软件需求获取 ( s o f t w a r er e q u i r e m e n te l i c i t a t i o n ) 是以体系结构为中心，采用迭代、增 量方式的需求开发方法。通过对系统用户按角色( r o l e ) 进行划分，明确 各类角色的目标( g o a l ) ，用户可以清楚地了解系统可以帮助他们完成什 么任务以及是否满足了他们的真正需求。而图形化的表达方法和场景技术 的运用，方便了分析人员与用户进行需求获取和验证，从而有效地消除了 期望差异。 2 什么是用例 用例是由i v a r a c o b s o n ( 1 9 9 2 ) 及其在瑞典爱立信的研究小组引入 四川大学工学硕士学位论文 信息技术界的。他的专著( o b j e c t o r i e n t e ds o f t w a r ee n g i n e e r i n g ”1 在计算界引起轰动，从那以后用例开始流行起来。j a c o b s e n 把用例看作 是叫做“0 b j e c t o r y ”的整个系统开发生命周期方法论的一部分，把这种 方法论看作是产品，并开办了o b j e c t o r y 公司。在j a c o b s o n 之前，m e i l ir p a g e j o n e s 、r e b e c c aw i r f s b r o c k 以及其他人曾经提出把故事和场景用 作需求的各种想法。我们能够对这些行业巨人的思想做补充的是，用例的 实际使用，以解决需求获取问题。我们试图对用例进行改进，但不做根本 性的改变，而是围绕用例产生其他制品，以帮助创建更完备的需求工具套 件。 用例( u s ec a s e ) 是一种描述系统需求的方法，使用用例的方法来描 述系统需求的过程就是用例建模。用例方法后来被综合到u m l 规范之中， 成为一种标准化的需求表述体系。用例的使用在r u p 中被推祟备至，整 个r u p 流程都被称作是“用例驱动( u s e c a s ed r i v e n ) ”的，各种类型的 开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要 输入工件，用例模型奠定了整个系统软件开发的基础。 用例的定义有很多种版本，我们选择r u p 的版本：au s e - c a s ei n s t a n c e i sas e q u e n c eo fa c t i o n sas y s t e mp e r f o r m st h a ty i e l d sa no b s e r v a b l er e s i l l to f v a l u et oap a r t i c u l a ra c t o r 。au s ec a s ed e f i n e sas e to f u s e - c a s ei n s t a n c e s 。f 1 9 】 ( “用例实倒是系统执行的动作序列，这些动作将生成特定a c t o r 可见的价 值结果。一个用例定义一组用例实例”) 理解这个定义，可以很好地帮助 我们解决在应用用例技术的过程中可能会碰到的各种问题。 用例表示某个外部实体和系统之间最终提供业务价值的一系列交互。 通过描述系统及其环境之间的交互，看起来就是输入什么，输出什么。听 起来很简单，但是在实践中却很难。系统专业人员很难创建使用户都能理 解的用例。系统开发人员习惯于把系统作为白盒，而不是黑盒来处理，习 惯于关注“怎样”。而用户只看到黑盒，即“什么”。r o b e r tp i r s i g 在( ( z e n a n dt h ea r to f m o t o r c y c l em a i n t e n a n c e ) ) 一书中使用了历史术语描述摩托车 四川大学工学硕士学位论文 的不同视图( 如图1 所示) ：浪漫视图和类视图。类视图通过子系统观察 摩托车：传动系统、制动、转向、安全性等。浪漫视图从摩托车能够为骑 手做什么的角度观察摩托车：加速、减速、颠簸、避免事故等。每种视图 观察的都是同样一辆摩托车，但是通过完全不同的视角观察。 圈i 两个人以不同的方式观察摩托车 用户把计算机系统看作黑盒子。“黑盒”这个词暗指从应用的角度只 关心输入的是什么，输出的是什么，对于黑盒来说，内部怎样处理并不重 要。在“输入”和“输出”背景环境下叙述所有内容的需求文档才更贴切 用户的需要。用户和计算机系统之间的交互是需求获取中真正重要的内 容。例如，用户想要在考勤表中输入数字，让系统打印出工资支票，对用 户来说，这个考勤表怎样先经过许多道具体工序才能生成支票并不重要， 因为那是设计。用户只关心系统能否产生支票并且支票是正确的。需求获 取活动中的用例通过浪漫视图看待系统。用例只关心系统能够为用户做什 么。这使得用例能够极为有效地向用户传递信息，因为用例撇开所有经典 视点。直接切入最基础的需求。 用例的重要功能是通过画用例图来鉴别和划分系统功能。它把系统分 成参与者( a c t o r ) 和用例( u s ec a s e ) 。参与者( a c t o r ) 表示系统用户能扮演 四川大学t 学硕士学位论文 的角色( r o l e ) 。这些用户可能是人，可能是其他的计算机或者是其他软件 系统，惟一的标准是他们必须要被划分在用例的系统部分以外。他们必须 能刺激系统部分并接收返回内容。用例描述了当角色给系统特定的刺激时 系统的活动。这些活动用文本描述。主要描述了触发用例的刺激的本质。 用例文本通常也描述每一个活动在进行特殊活动时可能的错误和系统应 采取的补救措施。 用例具有四个目标： 1 ) 向参与者提供价值的交互 用例是展示系统与位于该系统之外的实体之间交互的手段。外部实 体，也就是参与者，包括用户、其他计算机系统或外部事件，例如满足特 定要求的日期或时间。每种交互都应该为外部实体提供某种价值。如果交 互没有提供价值，那么交互就应该直接把价值提供给没有参与交互的某个 外部实体。 2 ) 与具体实现无关的语言 用例是黑盒表示，不包含任何与具体实现有关的语言。作为用例的定 义者，要避免使用与具体实现有关的语言，假设这个用例怎样通过程序设 计或用户界面实现。在抵制使用与具体实现有关语言的同时，应该采用用 户的词汇编写用例。所有的数据项和交互都应该使用用户用来描述其工作 的语言中的词汇和短语。 3 ) 适合用户的细节层次 随着需求获取的进行，用例会从通用逐渐发展到具体。信息技术人员 倾向于迅速转向细节。至少要在进入细节之前。首先从通用层次上开始。 4 ) 适合用户的用例量 i v a rj a c o b s o i l 在o o p s l a ( 面向对象程序设计系统、语言与应用) 会 议上说，非常大的系统拥有的用例数不应超过7 0 到8 0 个。d e b b i e a r d 说， 每个合理的大型系统看起来拥有2 8 个用例! 其实如果仔细判断，把用例 数控制在很低的水平上不仅是可能的，而且是极为明智的。只为最主要的 四川大学工学硕上学位论文 功能创建这样少的用例，分析人员和用户要被迫抽象系统的活动，直到这 些活动真正表达了系统必须完成的工作。剔除细枝末节和假设之后，两个 看起来独立的处理过程开始合并，并得到更好的结果。 这里指的是用例数，而不是场景数。场景是用例使用具体数据经历具 体路径的个体实例。根据测试工作的详细程度，或在用户和需求分析人员 之间存在严重的隔阂，可能会有大量的场景。 用例是一种需求技术。用例是基于用户目标的需求组织技术：用例把 “系统应能够接受用户录入取款金额”。“系统应能够从帐户中扣除取款 金额”等需求组织到一个场景中，而整个场景的描述采用的是用户的角度。 交互结束后，用户达到了一个目标。 用例是有层次的需求组织技术：通过用例这种需求技术，需求就可以 按照“目标一路径一步骤一约束”四个层次组织起来，如图2 所示。这样， 需求就按照不同的精度和稳定性分出了层次。“取款”这个需求精度很低， 但很稳定；“用户输入密码”精度高了，稳定性下降了，而绑定到这条需 求的“密码由8 位数字组成”稳定性就更低。分层的意义在于可以对需求 分而治之，某层需求的变更不会影响到上一层。 用例( 取款) 低精度，稳定 路径( 基本路径) 步骤( 用户输入密码) 补充约束( 密码由8 位数字组成) 高精度，不稳定 图2 需求的组织层次 6 四川 学工学硕士学位论空 3 需求及其分类 3 1 需求及其工作流程 有效的需求是产生满足用户需要的系统的关键。可以毫不夸张地说， 需求本身就是用户需要。诈多项目由于需求不好，从而导致进展不利或失 败。需求是推动其他系统开发工作的手段，因此到系统部署时，需求方面 任何小的疏漏都会放大为严重缺陷。弥补这些缺陷会极为耗时，并且成本 很高，因为有很多的工作已经被引导到错误的方向上。由于需求非常抽象 并且与计算机程序有很大的差别，因此对于以具体计算机程序设计为主业 的程序员来说，恰当地处理需求相当困难。 曾经在网上看到一幅漫画( 如图3 所示) ，这幅漫画虽然不乏夸张，但 却是能够激起我们的深思： 圈3 软件需求曾经让我僵j 如此狼狈 四川大学工学硕士学位论文 b e n j a m i nl k o v i t z 曾说：“需求是利用计算机程序设计，计算机能够 在问题领域中发挥出的作用。没有需求，就没有办法确认程序设计，也就 是说，没有办法将程序与客户需要逻辑她联系起来。”r a t i o n a l 把需求定 义为“( 正在构建的) 系统必须符合的条件或具备的功能”( r u p 的需求 工作流程如图4 所示) 。著名的需求工程设计师m e r l i nd o r f r n a n 和r i c h a r d h 。t h a y e r 提出了一个包容且更为精练的定义，它特指软件方面，但不仅 仅限于软件；“用户解决某一问题或达到某一目标所需的软件功能。系统 或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足 或具备的软件功能。” 圈4r a t i o n a lu n i f i e dp r o c e s s 的需求工作流程。o i 四川大学工学硕士学位论文 需求就是计算机应用系统必须为其用户做的事情，是系统必须提供的 具体功能、特性、质量或原则，以体现出系统的存在价值。需求部分地决 定软件开发项目的范围。增加些需求，项目开发范围就会扩大；撤销一 部分需求，范围就会缩小。需求还要决定系统应该如何回应用户的交互。 用户以一定的方式输入时，系统应该做特定的事。 由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定 了项目的成功或失败，因此找出需求是什么，将他们记下来，进行组织， 并在发生变化时对他们进行追踪，这些活动都是有意义的。换句话说，需 求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使 客户与项目团队对不断变更的系统需求达成并保持一致的过程。 需求常常看起来很抽象、难以理解，特别是对软件开发人员。需求和 设计在软件人员头脑中很容易被搅在一起，直到两者再也不能分开。但是， 将需求与设计分离是至关重要的。 3 2 需求的层次 在软件系统开发过程中，不同角色的人员对需求有着不同的理解。客 户所理解的需求就是使用软件系统所要达到的经济效益和工作效率方面 的目标，这是一个高层次的、抽象的概念。系统分析员所考虑的则是由客 户的高层次的需求导出的软件系统在范围、功能以及系统架构方面的需 求。而对予具体的开发人员来说，软件需求则变成了由系统分析员指定的 软件模块的详细设计要求，如输入输出的数据格式、处理过程以及模块 的接口要求等。 为了保证各类人员在软件需求问题上达成共识，避免期望差异，就必 须对软件需求按不同的角色进行划分。软件需求一书中有对需求层次 的详细定义： 业务需求( b u s i n e s sr e q u i r e m e n t s ) 反映了组织机构或客户对系统、 产品高层次的目标要求。他们在项目视图与范围文档中予以说明。 用户需求( u s e rr e q u i r e m e n t s ) 描述了系统的直接使用者使用产品 所必须要完成的任务，这在使用用例( u s ec a s e ) 文档或方案脚本 ( s c e n a r i o ) 说明中予以说明。 9 i r q 川大学工学硕士学位论文 功能需求( f u n c t i o n a lr e q u i r e m e n t s ) 、非功能需求( n o n f u n c t i o n a l r e q u i r e m e n t s ) ：功能需求定义了开发人员必须实现的软件功能，使得用 户能完成他们的任务，从而满足业务需求；它是用户对系统要做什么的要 求，功能需求是功能和特性，是通常要在描述系统时考虑的需求。所谓特 性( f e a t u r e ) 是指逻辑上相关的功能需求的集合，给用户提供处理能力并满 足业务需求。非功能需求描述了系统展现给用户的行为和执行的操作等， 包括要遵从的业务规则、人机接口、安全性和可靠性等要求；它描述对用 户很重要的系统隐藏部分，尽管他们可能没有意识到这些部分的重要性。 业务需求决定了用户需求，而每个用户需求又对系统提出了一个或多 个功能需求。有时，不同的用户需求会对系统提出相同的功能需求。他们 间的关系如图5 所示。需求分层有助于跟踪需求的来源，控制系统范围， 并且有效避免期望差异。 图5 需求种类及层次 0 四川大学工学砸上学位论文 3 3 需求的冲突及常见的需求问题 有的时候，虽然已经将用户分类并选出了用户代表。但是需求的来源 众多，往往会发生需求之间自相矛盾的事情。需求从四面八方收集来后， 人们难以解决冲突，澄清模糊之处以及协调不一致的地方。某些人还要对 不可避免要发生的范围问题单独做出决定。在项目的早期阶段，你必须决 定谁是需求问题的决策者。如果不清楚谁有权并且有责任来做出决策，或 者授权的个人不愿意或不能做出决策，那么决策者的角色将自然而然地落 在开发者身上。这是一个非常糟糕的选择，因为开发者通常没有足够多的 信息和观点来做出业务上的决策。 在软件项目中，谁将对需求做出决策的问题并没有统一的正确答案。 分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用用户 代表这一手段，也必须解决来自不同用户类的相冲突的需求。通常，应尽 可能由处于公司底层的人做出决策，因为他们与问题密切相关，并能得到 关于这些问题的广泛信息。 如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户 的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产 品的业务目标的关系如何，将有助于你决定哪个用户类所占份额最大。 当开发者想象中的产品与客户需求冲突时，通常应该由客户做出决 策。同时，不要陷到“客户总是对的”的陷阱中去，对他们百依百顺。现 实中，客户并不总是对的。客户总是持有自己的观点，开发者必须理解并 尊重这一观点。 需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需 求管理”则是对所有相关活动的规划和控制，它准确地强调了追踪变更以 保持涉众与项目团队之间共识的重要性。需求管理的流程面临着很多难 题，当它真正在实际项目中实施时，困难就暴露出来了。c o m p u t e ri n d u s t r y d a i l y 曾报导了s e q u e n t c o m p u t e r s y s t e m s 公司的项研究( 如图6 所示) ， 该公司对美国和英国5 0 0 名i t 经理作调查后发现，百分之七十六的受访 者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败 的原因就是“变更用户需求”。 四川大学工学硕仁学位论文 图6 常见的需求问题 事实上还有更多与需求有关的问题： 1 ) 需求并不总是显而易见的，而且它可能来自各个方面。 2 ) 需求并不总是容易用文字明白无误地表达。 3 ) 存在不同种类的需求，其详细程度各不相同。 4 ) 如果不加以控制，需求的数量将难以管理。 5 ) 需求相互之间以及与流程的其他可交付工件之间以多种方式相关 联。 6 ) 需求有惟一的特征或特征值。例如，他们既非同等重要，处理的 难度也不同。 7 ) 需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组 人员来管理。 8 ) 需求发生变更。 9 ) 需求可能对时间敏感。 为什么要管理需求? 避免失败就是个很充分的理由。提高项目的成 功率和需求管理所带来的其他好处同样也是理由。s t a n d i s hg r o u p 的 c h a o s 报告进一步证实了与成功项目关系最大的因素是良好的需求管 理。 3 4 现代需求实践 四川大学工学硕士学位论文 许多开发团队经常抱怨“我们的客户连需求都说不清楚”、“我们的客 户对计算机了解太少了。”多年以来，大家都习惯从自己的角度来定义、 分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业。针对这 些现象，许多先贤们开始了实践，并且总结出了一系列优秀的现代需求实 践： 1 ) u s e c a s e ：用例分析技术 鼎鼎大名的r u p 是这样总结自己的：用例驱动，以体系结构为中心， 迭代、增量的开发过程。u s ec a s e 也伴随着r u p 、u m l 一起名扬天下。 用例用来描绘一个系统外在可见的需求情况，是代表系统中各个项目 相关人员( 风险承担人，s t a k e h o l d e r ) 之间就系统的行为所达成的契约。 2 ) u s e rs t o r y ：用户故事 用户故事悬k e n tb e c k 在极限编程( x p ) 方法论中推荐的最佳实践之 一。它由客户参与编写，说明他们需要系统为他们做什么，一般用客户的 术语写就，三句话左右。 用户故事( u s e rs t o r y ) 的目的和用例( u s ec a s e ) 类似但不完全相同。 用户故事用来建立为产品发布计划做出时间估算的依据。用户故事还可以 用来代替大量的需求文档，更加简洁、有表达力、可测试；用户故事是由 客户或客户代表角色如领域专家来撰写系统的执行工作。用户故事类似于 场景情节脚本的撰写。 用户故事不仅限于描述用户界面，用户故事使用客户的术语而非技术 术语，用户故事聚集于使用者的需要，应当尽量避免描述技术上的细节、 数据库配置和算法实现。通过用户故事，应当聚焦于使用者的需求和利益， 而非界面描述。 3 ) f e a t u r e ：特征或具有客户价值的功能( c l i e n t - v a l u e df u n c t i o n s ) 这是特征驱动开发( f d d ) 方法论的核心实践之一。一个特征是一个 小的、具有客户价值的功能，表示如下： 整体模型一 构造一个特征袭一 报据特征制定计划) 根据特征进行设计一 根据特征进行构造 i 一反复选代- - - i 动作( ) 、结果( ) 和对象( ) 之间通过适当 四川大学工学硕士学位论文 的方式联系起来。特征的特点是，它是短小的，可以在两个星期内实现。 由于小，特征的粒度是可以统一的。统一粒度的特征可以用来描述项目进 度。特征又是具有统一编写规范、格式的，并且还是具有客户价值的。所 以，特征反映了项目真实的进度，客户也可以看到他们期望的进度。 从上面的定义来看，这三种现代软件工程需求实践无一例外地遵从两 个原则：一是站在用户的角度看待系统、定义系统；二是使用用户看得懂 的语言表达。但用户故事和特征都有不同程度的缺陷： 1 ) 用户故事略显粗糙，掌握起来需要经验，没有详细的规则用于按 部就班，一开始采用容易迷失方向：而用例相对来说更加形式化，易于上 手： 2 ) 特征看上去很有吸引力，但毕竟相关的理论还未完整，引入团队 实践有些困难。 鉴于以上两点考虑，我们推荐使用“用例驱动分析技术”。 4 用例驱动分析技术 4 1 简介 多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方 式，从而获取需求( m c g r a wa n dh a r b i s o n1 9 9 7 ) 。i v a rj a c o b s o n ( 1 9 9 2 ) 把这种看法系统地阐述成用例( u s ec a s e ) 的方法进行需求获取和建模。 虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方 法的项目中。因为用户并不关心你是怎样开发你的软件。而最重要的是， 用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显 得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他 们做什么这一传统方法。 用例驱动分析技术是i v a rj a c o b s o n 先生于1 9 6 7 年在爱立信公司开发 a x e 交换机时开始研究，并于1 9 8 6 年总结、发布的一项源于实践的需求分 析技术。i v a r 先生在加盟r a t i o n a l 之后，与g r a d yb o o c h 、j i mr a m b a u g h 共 同创建了一种可视化地说明、建造软件系统的工业标准语言统一建模 语言( u m l ) 、完善了r u p ，用例驱动分析技术也因此被人广泛了解和关注。 四川大学工学硕士学位论文 用例驱动分析技术为软件需求规格化提供了一个基本的元索，而且该 元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环 节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。 用例是一些外部参与者和计算机系统之间交互的文本描述。用例图是 参与者和用例之间、一个用例和另一个用例之间的图形表示。所产生的用 例和用例图文档应该使用户能够很容易理解。用例应该以“用户语言”编 写，避免掺杂“对象语言”和实现细节。每个用例内部是一个有效驱动系 统开发过程其余部分的精巧的需求包。 不少人是在学习u m l 的时候接触到u s ec a s e ，所以很多人都误解其 为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述 j 是用例驱动分析技术的核心。下面是一个简单的例子( 如图7 所示) ： 单填充 图7 通过产品目录订购产品 用例名称：填充订单 描述t 客户通过“通过产品目录订购产品”用例完成订单，系统标识 产品和客户帐户，并准备投递和出具发票命令。 参与者； “通过产品目录订购产品”用例 订单填充用于电话和w e b 网络销售的现有系统 触发条件：客户通过产品目录订购产品 四川丈学工学硕士学位论文 前提：无 基本事件过程： 1 ) 通过引用“通过产品目录订购产品”用例提供的数据标识要购买 的产品。 2 ) 检查库存是否有所订购的产品。 3 ) 通过引用标识，查询客户记录。 4 ) 根据订单减少库存量。 5 ) 调用“提交订单”用例。( 该用例会核销客户的信用卡，并邮寄所 订购的产品。) 后果；订单被标为已挂起或已填充。 用例不仅驱动需求获取，而且还驱动整个软件开发周期。有些方法论， 包括非常流行的r a t i o n a l 统一过程( r u p ) ，都是用例驱动的。用例具有 表达计算机系统本质的简洁性，同时又可以在需求可跟踪性问题的解决过 程中驱动整个方法论。 在使用用例分析技术时，很多人都觉得如何确定用例的粒度是一个难 点，而且感觉到用例没有什么规则遵从，甚至有无所适从的感觉。c o e k b u m 先生提出学习用例分析技术应分为三个阶段： 1 ) 练习基本功，遵循规则，照章办事； 2 ) 突破传统方法因地制宜地灵活应用； 3 ) 超脱任何限制和规则，随心所欲地使用。 但是用例驱动分析技术让第一阶段的初学者感到无法很快地掌握。 c o c k b u m 先生在其所著的编写有效用例一书中对i v a rj a c o b s o n 的用 例驱动分析技术做了一些补充： 1 ) 用例是契约。是系统与涉众之间达成的契约。也就是将用例朝着 形式化的方向发展。 2 ) 将用例分为三级： 概要级：包括多个用户目标( 显示用户目标运行的语境，显 示相关目标的生命周期、为低层用例提供一个目录表) ； 用户目标级： 1 6 四川人学工学磷士学位论文 子功能级。 c o c k b u r n 先生的思路与理念对于初学用例分析技术的人来说非常有 价值。使得用例驱动分析技术更具操作性，但这同时也或多或少地局限了 使用者的思维。因此，第三阶段就是超脱任何限制和规则，按需灵活使用。 4 2 参与者( a c t o r ) a c t o r 不是指入，而是代表某一种特定功能的角色，角色是抽象的职 责定义，它定义的是所执行的一组活动和所拥有的一组工件，因此同一个 人可能对应很多个a c t o r 。a c t o r 是虚拟的概念，甚至可以是外部系统和设 备。理论上我们可以把一个软件系统的所有u s ec a s e 画出来，但实际运 用时只需把重要的、交互过程复杂的那些画出来。 角色通常由一个人或作为团队相互协作的多个人来实现。项目团队成 员通常要履行许多不同的角色职能；就象一个人可以担任许多职务，一个 人也可以担任许多不同的角色。角色并不代表个人，而是说明个人在业务 中应该如何表现以及他们应该承担的责任。虽然大多数角色都由组织内部 人员来实现，但开发组织之外的人员也担当了种重要的角色：所开发的 项目或产品的涉众。在现实世界中可能是某个岗位或职位，等等。这种划 分是客观存在的。比如一个财务系统的用户可能就有出纳、会计或财务主 管等。他们会使用系统做不同的事，自然就会有不同的u s e c a s e 。所以不 分青红皂白，只用个a c t o r 是不行的。如果a c t o r 与现实世界相符。那 用户非但不会摘糊涂，反而会对u s ec a s ed i a g r a m 理解得更清楚。 参与者是与系统交互的外部实体，它是直接