基于用例驱动分析的软件需求获取方法.docx

基于用例驱动分析的软件需求获取方法谢卫宇 ,王恒山(上海理工大学管理学院 ,上海 200093)摘要 : 用例驱动方法是当前国际流行的软件开发过程之一 ,软件开发所有阶段的活动都是以用例为核心 。本文在对软件需求进行层次划分的基础上 ,探讨了一个以用户为中心 ,使用用例驱动分析技术依据用户目标获取不同层次的软件需 求的过程 。关键词 : 用例 ; 执行者 ; 场景 ; 业务需求 ; 用户需求 ; 功能需求中图分类号 : TP31115文献标识码 : AThe Use Ca se Driven Analysis Method of Soft ware Requirements ElicitationXIE Wei2yu ,WANG Heng2shan( Institute of Management ,Universiby of shanghai for Science and Technology ,shanghai 200093 ,China)Abstract :Use Case Driven Approach is a popular kind of software developping processes in the world at present , and Use Cases are thecore of all activities in each phase . This paper explains a user2centered process of software requirements elicitation on the basis of require2ment hierarchy , in which Use Case Driven Analysis is used to elicit software requirements at different requirement level according to users goals.Key words :use case ;actor ; scenario ; business requirements ; user requirements ;functional requirementssis) 的软件需求获取 ( Software Requirement Elicitation)是以任务和用户为中心的 、迭代的增量式的需求开发 方法 。通过对系统用户按角色 ( Role) 进行划分 ,明确 各类角色的目标 ( Goal) ,用户可以清楚地了解系统可 以帮助他们完成什么任务以及是否满足了他们的真 正需求 。而图形化的表达方法和场景技术的运用 ,方 便了分析人员与用户进行需求获取和验证 ,从而有效 地消除了期望差异 。引言0软件需求获取 ( Software Requirement Elicitation) 是软件系统开发过程中最为困难也是最为重要的部分 ,只有真正满足用户需求的软件产品才能为用户接受 ,不能满足这一点的产品不管采用了多么先进的技术 对用 户 来 说 也 是 毫 无 用 处 的 。根 据 Leffingwell 在1997 年的研究 ,软件项目中 40 %60 %的问题都是在需求的获取和分析阶段埋下的祸根 。传统的结构 化软件开发方法在需求阶段侧重的是业务数据或者是业务流程 ,却没有把二者结合起来考虑 ,开发出来 的产品结构复杂难以维护 、可重用性差 。面向对象技术把数据及其处理过程集成到类中 ,克服了结构化方法的缺点 ,但是忽视了用户的需求 。用户才是软件产 品的最终使用者 ,以上需求分析方法都是以功能为中心而忽视了用户的参与 ,通常会导致最终产品与客户 间的期望差异 。基于用例驱动分析技术 (Use Case Driven Analy2软件需求及其分类在软件系统开发过程中 ,不同角色的人员对需求 有着不同的理解 。客户所理解的需求就是使用软件 系统所要达到的经济效益和工作效率方面的目标 ,这 是一个高层次的 、抽象的概念 。系统分析员所考虑的1则是由客户的高层次的需求导出的软件系统在范围 、功能以及系统架构方面的需求 。而对于具体的开发人员来说 ,软件需求则变成了由系统分析员指定的软 件模块的详细设计要求 ,如输入/ 输出的数据格式 、处收稿日期 :2001212214作者简介 :谢卫宇 (19742) ,男 ,江苏江都人 ,上海理工大学管理学院硕士研究生 ,研究方向 :MIS、软件工程 、数据库技术 。为了保证各类人员在软件需求上达成共识 ,避免期望差异 ,必须对软件需求按不同的角色进行划分 。 软件需求可划分成三个不同的层次 :现的行为 ,但是它不涉及具体的实现细节 ,强调的是能做什么 ,而不是怎么去做 。2 . 2用例驱动分析用例驱动分析的基本概念是执行者和用例 。通 过识别并独立分析每一个执行者不同用例 ,可以了解 系统的每一类用户的要求和愿望 ,而不会沉溺于实现业务需求 (Business Requirements)反映了组织机构或客户对系统 、产品高层次的目标要求 。用户需求 (User Requirements) 描述了系统的直接 使用者使用产品所必须要完成的任务 。功能需求 ( Functional Requirements) 、非功能需求(Nonfunctional Requirements) : 功能需求定义了开发人 员必须实现的软件功能 , 使得用户能完成他们的任 务 ,从而满足业务需求 。非功能需求描述了系统展现 给用户的行为和执行的操作等 ,包括要遵从的业务规 则 、人机接口 、安全性和可靠性等要求 。业务需求决定了用户需求 ,而每个用户需求又对 系统提出了一个或多个功能需求 。有时 ,不同的用户 需求会对系统提出相同的功能需求 。它们间的关系 见图 1 。需求分层有助于跟踪需求的来源 ,控制系统 范围 ,避免期望差异 。细节 ,而用户的要求和愿望正是系统最重要的部分 。所有用例的集合描述了系统的功能 ,客户可以预先确定项目的范围 ,从而避免了最终产品与客户间的期望 差异 。此外 ,由于采用了自然的描述语言和图形化的 表达方式 ,使得客户和最终用户能够积极地参与需求 的获取活动 ,系统分析人员能够识别潜在的用户 ,他 们的实际需求 ,以及他们的典型行为 。用例驱动的分 析方法不同于传统的分析方法 ,它是个面向对象而不 是面向实现的过程 , 因此它不同于传统的功能分解 法 。3 软件需求的获取3 . 1业务需求的获取业务需求反映了组织机构或客户对系统 、产品高 层次的目标要求 , 一般在项目视图与范围文档中说 明 。因为业务需求是高度抽象的并且其定义简单明 确 ,用例驱动技术不可直接用于业务需求的获取 。但采用用例驱动技术进行迭代 、增量式地获取用户需求 和功能需求时 , 对原先的业务需求具有反馈修正作用 ,可以帮助明确和限定系统的范围 ,消除不明确的 、二义性的概念 ,使客户和系统分析人员之间在系统的范围 、开发计划以及资源占用等方面达成共识 。3 . 2 用户需求的获取组织的业务需求确定之后 ,必然在如何改进组织 的业务流程 、提高工作效率和促进各部门协作等方面 提出了要求 。用户为了实现业务需求所提出的要求 , 必须要借助于待开发的软件系统协助他们完成工作 , 这就是用户对软件系统的用户需求 。软件系统最终是给用户使用 ,用户使用软件系统的目的是为了实现 业务上的目标 ,因此 ,软件系统成功与否不仅是看它 采用怎样的先进技术 ,更重要的是取决于用户是否满 意 。这使得用户需求的获取这一阶段在整个软件生 命周期中显得极为重要 ,这一阶段产生的错误的用户需求将使软件开发过程的后续阶段出现重大的偏差 , 为了纠正这些偏差而耗费的资源将是在需求开发阶 段所消耗资源的几十倍甚至更多 。为了获取正确的 用户需求 ,需要用户的积极参与 ,但是用户具有丰富图 1 需求种类及层次2 用例驱动分析技术2 . 1相关概念执行者 (Actor) 是直接与系统相互作用的系统 、 子系统或类的外部实体的抽象概念 。每个执行者定 义了一个角色集合 ,当系统的用户与系统相互作用时会采用它们 。一个物理对象如果满足多个执行者的角色 ,那它就可扮演多个执行者 。用例 (Use Case) 是执行者与系统之间一系列可能 的交互行为序列的集合 ,以实现用户的使用系统所要正好与之相反 ,这使得用户与分析员之间的沟通产生了困难 。用例驱动技术抓住执行者 、执行者的目标 、用例 三个要 素 , 借 助 于 场 景 ( Scenario ) 分 析 、顺 序 图 ( Se2quence Diagram) 和协作图 ( Collaboration Diagram) 等技术克服了以上的困难 ,最大可能地消除了期望差异 , 最终的用例模型 (Use Case Model) 就是客户与开发人 员之间达成一致的系统开发合同 ( Contract) 。3 . 2 . 1 执行者的确定在用户需求获取阶段 ,为了获取用户需求首先要 明确系统的用户 。这里的用户是指要与待开发的系 统相互作用的外部实体 , 不是专指组织的人员 。首 先 ,通过提问以下一些问题来获得初始的用户列表 :统为他做些什么 , 即执行者的目标 。对于每个执行者 ,考虑以下问题来识别用例 :(1) 执行者需要系统执行的主要任务是什么 ?(2) 执行者需要在系统中创建 、存储 、修改 、删除 和读取数据吗 ?(3) 执行者需要告知系统突然发生的外部变动 吗 ?(4) 系统的所有特性是否可被已经识别的用例 实现 ?(5) 执行者是否要执行系统的启动和关闭 ?这些问题的答案代表了候选用例的事件流 。并 不是所有的事件流都能构成独立的用例 ,有的事件流 是同一用例事件流的变体 。一般来说 ,用户总是趋向于首先确定业务领域 (Business Domain) 中的最重要用 例 ( Essential Use Case) ,因此 ,最先经过用户确定的用 例往往具有最高的优先级 。不要期望一次得到所有 的用例 , 而 是 应 先 根 据 系 统 的 主 要 执 行 者 ( Primary Actor) 的需求 ,识别他们的重要用例 ,再与用户代表和领域专家进行验证和评审 ,确定了这些重要用例后 , 也就确立了系统的核心功能 ,初步的用例获取工作即 告完成 。接下来的用例获取工作应围绕系统的次要 执行者 ( Secondary Actor) 的需求来进行 。经过多次的 迭代 ,当下面的一些情景出现时 ,用例的获取工作可以认为已初步完成 。(1) 用户不能想出更多的用例 。(2) 用户提出的新的用例可以通过已获取的用 例相关的功能需求来实现 。(3) 用户新提出的需求涉及到具体的实现细节 ,可由有限的简单操作完成 ,其相应的用例粒度太小 。(4) 用户提出的需求涉及到系统将来的特性 ,超 出了当前的系统范围 。在这个层次的用例反映的是用户需求 , 即用户(体现为执行者) 通过系统要完成的目标 。因此 ,这些 用例是抽象的 、大粒度的 ,不涉及系统的实现细节 ,每 个用例应有一段简洁的叙述性的文字来描述用例的 目标和基本的交互序列 。3 . 2 . 3 用户需求的用例模型当用例获取基本完成后 , 应对所有用例进行验 证 ,详察所有用例以确保满足所有的用户需求 。然后 ,从所有的用例中识别出表达抽象行为的抽象用(1)(2) (3)(4)谁直接使用系统 ?谁负责系统的维护工作 ?系统使用的外部硬件 。 要与本系统交换信息的其他系统 。得到用户列表后 ,需要根据各用户使用系统的动机和目的不同对他们进行分类 ,每一分类代表一种逻 辑角色 ,而属同一种角色的用户的集合就是用例的执 行者 。一般的做法是 ,对几个人的用户组 ( 一般 23 人) 查看已识别的执行者是否已经包括了他们的需 要 ,如已经包括了他们的需要 ,则他们所属的执行者类型就确定了 。在识别执行者的过程中 ,提问以下的 问题是很有用的 :(1)(2) (3) (4) (5) (6)谁将提供 、使用 、删除信息 ?谁将使用这个功能 ? 谁对某一特定需求感兴趣 ? 谁负责系统某一方面的维护工作 ? 系统的外部资源是什么 ? 哪些外部系统需要与系统的这一部分交互 ?确定了执行者也就基本上确定了系统的边界 ,这有助于理解系统的目标和范围 。只有直接与系统交 互的用户才可以被看作是执行者 ,如果赋予执行者多余的角色 ,必然会超出系统的当前范围 。此外 ,执行 者的确定不是一次性的工作 ,而是与用例的识别协同 进行的 ,通过多次的迭代最终确定 。3 . 2 . 2 用户需求用例的获取因为系统是为它的用户而开发的 ,所以应该以用 户的需求为基础 。在得到了初步的执行者后 ,系统的用户转化成了扮演各种逻辑角色的系统外部的执行者 ,用户需求也转变成了执行者所要执行的用例 。所 以 ,用户需求的获取就变成了执行者用例的获取 。例 ,在基用例与这些抽象用例之间运用用例的包含 、扩展和泛化关系建立联系 。同时 ,在具有公共特性的执行者之间建立执行者的泛化关系 。最终得到的是用例 ,这是个递归关系 (图 2) 。这些子用例是场景所属外部用例的下级用例 ( Subordinate Use Case) , 其执 行者称为系统的内部执行者 ,包括系统 、子系统和对象三类实体 。这些内部执行者是下级用例中与外部 用例执行者交互的实体对象 。用户需求的抽象的模型 ,它从系统外部用户的角度描绘了系统的功能 、范围 ,但不涉及系统的具体实现细 节 ,它是功能需求获取工作流的输入 ,系统的功能需求都是从这个模型导出 。3 . 3 功能需求的获取3 . 3 . 1 相关概念事件 ( Event ) 是 执 行 者 与 系 统 的 一 次 交 互 的 发 生 。事件流 ( Flow of Events) 描述了执行者执行用例过 程中发生的各种交互的序列 。通常有两种类型事件 流 :一 个 执 行 者 顺 利 达 成 目 标 的 基 本 事 件 流 (Basic Flow of Events) ,另一种是反映可选或异常情况行为的 候选事件流 (Alternative Flow of Events) 。每个用例只有一个基本事件流 ,但可有多个候选事件流 。场景 ( Scenario ) 是 在 某 一 前 提 条 件 ( Pre2Condi2 tions) 下为达到执行者的目标而发生的交互的序列 , 并且产生与执行者目标相关的特定结果 。这些交互 从触发动作开始 ,一直持续到执行者的目标实现或被放弃 。系统负责实现交互中的相关职责 。 用例是场景的集合 , 场景是用例的一个具体实例 ,它们的关系类似于类和对象的关系 。场景和事件 流基本上是一回事 ,场景作为用例的实例总有一个相 应的事件流 ,两者间的细微区别是场景多了一个前提条件 。与基本事件流对应的是用例的主要场景 ( Pri2 mary Scenario) ,与候选事件流对应的是用例的次要场 景 ( Secondary Scenario) 。3 . 3 . 2 用例求精( Use Ca se Ref inement)用户需求阶段获取的用例描述了系统外部的执 行者要实现的目标 ,反映的是用户需求 ,但并没有涉及系统应提供的相关的具体功能细节 。用户需求决 定了系统的功能需求 ,为了获取这些功能需求 ,必须 要对用户需求阶段获取的大粒度的抽象用例进行求 精 ,通过细化用例的事件流 ,得到用例的所有场景的 集合 ,而这些场景中各个步骤就是功能需求的来源 。具体步骤如下 :(1) 从用户需求阶段获取的所有用例中选择一个 具有最高优先级用例 。(2) 场景分析 。根据执行者的目标确定顺利完成 目标的基本的最简单的交互序列 ,即先确定用例的主要场景 。然后 ,根据主要场景中每个基本步骤考虑其 异常情况和其他可选项确定次要场景 。当得到用例 的所有场景后 ,转入第 (3) 步 。(3) 用例分解 ( Use Case Decomposition) 。用 例 是图 2 用例与场景(4) 用例判定 。根据场景中下级用例的粒度做出判定 :对于像更新数据库这类的简单操作 ,因其粒度 太小 ,将它继续看成用例只能造成用例数量的膨胀 ,毫无 益 处 , 故 应 该 把 它 当 作 系 统 实 现 的 简 单 行 为( Primitive Action) , 这个简单行为就是系统要实现的 一个功能需求 ;对于较大粒度的下级用例 ,因其本身 代表了一个复杂的子交互序列 ( Sub2Sequence of Inter2actions) ,其执行者有明确的目标 ,应将其当作新的待 求精用例 ,重复 (2) (4) 步获取其功能需求 。(5) 对剩余的用例 ,重复 (2) (4) 步 。 当再没有用例可以求精时 ,最终得到的所有用例中的简单行为的集合就是系统的功能需求 。3 . 4 非功能需求的获取非功能需求反映系统的质量属性的特性和业务 规则 、法规制度等各种约束 。具体的有以下一些方 面 : (1) 易操作性 ; ( 2) 可靠性 ; ( 3) 可维护性 ; ( 4) 业务 规则 ; (5) 各种法规 、制度等 。非功能需求不能由用例分析得到 。相反 ,其中一 些非功能需求会对用例的实现具有制约作用 。因此 , 必须在这些用例和非功能需求之间建立联系 ,或把非 功能需求写入用例文档 ,或在两者间建立需求跟踪机 制 。其他的非功能需求须独立地获取 。3 . 5 用例文档的编制对于系统中的每个用例 , 都必须编写相应的文 档 ,其模板如下 :版本 : 用例规范 : 日期 : 1. 用例名面透彻地了解复杂的问题 , 而需一个渐进反复的过程 。此外 ,由于软件系统的客户和开发人员背景和知 识结构的不同 ,构成了双方沟通的障碍 ,导致难以获得正确的需求 。本文在对软件需求进行层次划分的 基础上 ,探讨了用例驱动分析技术获取不同层次软件 需求的方法 。首先根据业务需求的远景通过用例获 取用户需求 ,接着通过求精这些用例获取相应的功能 需求 ,最后再通过对获得的用户需求和功能需求的分析验证来反馈修正业务需求 ,这种循环迭代式的需求 获取方法可以有效地获取正确 、合理的软件需求 ,以 开发出令用户满意的软件产品来 。1. 1 简要描述 简要描述用例的执行者和目标 。2. 事件流2. 1 基本流2. 2 候选流2. 2. 1 2. 2. 1. 1 为了提高候选流的清晰性 ,候选流可被进一步分解成逻 辑性的子块 2. 2. 2 复杂的用例可有多个候选流 ,保持各个候选流的相互独 立可提高事件流的清晰性 。3. 特殊需求 这里的特殊需求典型的是一个特定于用例的非功能需 求 。这个非功能需求不容易以自然的方式在用例的事件流中 描述 。3. 1 4. 前提条件 用例启动前系统必须满足的状态 4. 1 5. 事后结果 完成条件是用例结束后系统所处的可能状态的列表 。6. 扩展点 用例的扩展点 6. 1 事件流中扩展点位置的定义 参考文献 :1Grady Booch ,J ames Rambaugh , Ivar J acobson. The UnifiedModeling Language User Guide M . Addison Wesley Long 2man , Inc . ,1999.Grady Booch ,J ames Rambaugh , Ivar J acobson. The Unified Modeling Language Reference Manual M . Addison Wesley Longman , Inc . ,1999.Grady Booch ,J ames Rambaugh