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

《基于用例驱动分析的软件需求获取方法.pdf》由会员分享，可在线阅读，更多相关《基于用例驱动分析的软件需求获取方法.pdf（5页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、2 0 0 2年第 6期 计算机与现代化 J I S U A N J I Y U A N D A J H U A 总第 8 2期 文章编号：1 0 0 6 2 4 7 5(2 0 0 2)0 6 0 0 3 6 0 5 基于用例驱动分析 的软件需求获取方法 谢 卫宇，王恒 山(上海理工 大学管理 学院，上 海2 0 0 0 9 3)摘 要：用例驱动方 法是 当前 国际流行的软件 开发过程之 一，软 件 开发所 有阶段 的活 动都 是 以用例 为核 心。本 文在 对软 件需求进行 层次划 分的基础上，探讨 了一个 以用户为 中心，使 用用例 驱动分析技 术依据 用户 目标 获取 不 同层 次 的

2、软 件 需 求的过程：关键词：用例；执行 者；场景；业务需求；用户需求；功 能需求 中图分类号：I 1)3 l 1 5 文献标识码：A The Us e Ca s e Dr i v e n Ana l y s i s M e t h o d o f S o f t wa r e Re q u i r e me n t s El i c i t at i o n XI E i y u W ANG He n g s h a h (I n s t i t u t e o f M a n a g e me n t，U t r i v e r s i b y o f s h a n g h a i f

3、o r S c i e n c e a n d T e c h n o l o g y，s h ang h a i 2 0 0 0 9 3，C h i n a)Abs t r a c t：Us e Ca s e Driv e n App r o a c h i s a p o p u l a r k i n d o f s o f t wa r e d e v e l o p p i ng p r oc e s s i n t h e wo r l d a t p r e s e n t an d Use(s e s a r e t h e e o r e o f a l l a c t i,

4、i t i e s i n e a c h p h a s e T h i s p a p e r e x p l ain s a u s e r-c e n t e r e d p r o c e s s o f s o f twa r e r e q u i r e me n t s e l i e i t a t i o n o n t h e b a s i s o f r e q u i r e me n t hi e r a r c h y，i n wh i c h Use Ca s e Driv e n An a l y s i s i s u s e d t o e l i c

5、 i ts o f twa r e r e q ui r e me n t s a t di ff e r e n t r e q ui r e me n t l e v e l a c c o r d i n g t o user s g o a l s Ke y wo r d s：us e c&se；a c t o r；s c e n a r i o；b us i n e s s r e qu i r e me n t s；u s e r r e qu i r e me n t s；f u n c t i o n,d r e q ui r e me n t s I J 引 吾 软件需求 获

6、取(S o f t w a r e R e q u i r e m e n t E l i e i t a t i o n)是 软件系统开发过程 中最为困难也是最为重要的部分，只有真正满足用户需求 的软件产品才能为用户接受，不能满足这一点 的产品不管 采用 了多么先进 的技术 对用 户 来说 也 是 毫 无 用 处 的=根 据 L e f fi n,e l l 在 1 9 9 7年的研 究，软件项 目中 4 0 6 0 的问题都是 在需求的获取和分析阶段埋下 的祸 根。传统 的结构 化软件开发方法在需求 阶段侧 重的是业务数据或者 是业务流程，却没有 把二者结合起来 考虑，开发 出来 的产品结

7、构复杂难 以维护、可重用性差。面向对象技 术把数据及其处理过程集成到类 中，克服了结构化方 法 的缺点，但是忽视 了用户的需求?用户才是软件产 品的最终使用者，以上需求分析方法都是 以功能为中 心而忽视 了用户的参与，通常会导致最终产品与客户 间的期望差异。基于用例驱动分析技 术(U s e C a s e D r i v e n A n a l v s i s)的软件需求获取(S o ft w a r e R e q u i r e m e n t E l i e i t a t i o n)是 以任务和用户为中心的、迭代的增量式 的需求开发方 法。通过对系统用户按角色(R o l e)进行

8、划分，明确各 类角色的 目标(G o a 1)，用户可以清楚地 了解 系统可 以 帮助他们完成什么任务 以及是否满足 了他们 的真正 需求。而图形化的表达方法和场景技术的运用，方便 了分析人员与用户进行需求获取 和验证，从而有效地 消除了期望差异。1 软件需 求及 其分 类 在软件系统开发过程 中，不同角色的人员对需求 有着不同的理解。客户所理解 的需求就是使用软件 系统所要达到的经济效益和工作效率方面的目标，这 是一个高层次的、抽象的概念。系统分析员所考虑的 则是 由客户的高层次 的需求导出的软件系统在范围、功能以及系统架构方面 的需求。而对 于具体 的开发 人员来说，软件需求则变成 了由系

9、统分析员指定的软 件模块的详细设计要求，如输入 输 出的数据格式、处 收稿 日期：2 0 0 1 1 2 1 4 作者简介：谢卫宇(1 9 7 4 一)，男，江苏江都人，上海理工大学管理学院硕士研究生，研究方向：MI S、软件工程、数据库技术。维普资讯 http:/ 2 0 0 2年 第 6期 谢卫 宇等：基 于用例驱动 分析 的软件 需求获取 方法 3 7 理过程以及模块 的接 口要求等。为了保证各类人员在软件需求上达成共识，避免 期望差异，必须对软件需求按不 同的角色进行划分。软件需求可划分成三个不 同的层次：业务需 求(B u s i n e s s R e q u i r e m e

10、n t s)反 映了组织 机 构或客户对系统、产 品高层次 的目标要求。用户需求(U s e r R 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)、非功能需 求(N o n f u n c t i o n al R e q u i r e m e n t s)：功能需求定 义 了开发人 员必须实现 的软件功 能，使得用 户能完 成他们 的任 务，从而满足业务需求。非功能需求描述 了系统展现 给用户的行为和执行的操作等，包括要遵从 的业务规

11、则、人机接口、安全性 和可靠性等要求。业务需求决定了用 户需求，而每个用户需求又对 系统提 出了一个或多个功能需求。有时，不 同的用户 需求会对系统提 出相同的功能需求。它们 间的关 系 见图 1。需求分层有助于跟踪需 求 的来源，控制 系统 范围，避免期望差异。业务需求 项目视图与范围文 用户需求甩例模型 功能需求 功能需求用例模型 软件需求规格说明 约 图 1 需求种 类及层 次 2 用例驱动 分析技 术 2 1 相 关概 念 执行者(A c t o r)是直接 与系统相互 作用 的系统、子系统或类 的外部实体 的抽 象概念。每 个执行者定 义了一个角色集合，当系统 的用户与系统相互作用时

12、 会采用它们。一个物理对象如果满 足多个执行者 的 角色，那它就可扮演多个执行者。用例(U s e C a s e)是执行者与系统之间一系列可能 的交互行 为序列的集合，以实现用户的使用系统所要 达到的特定 目标。用例描述执 行者使用 系统所要实 现的行为，但是它不涉及具体 的实现细节，强调 的是 能做什么，而不是怎么去做。2 2 用 例 驱动 分 析 用例驱动分 析的基本概念是执行 者和用 例。通 过识别并独立分析每一个执行者不同用例，可以了解 系统的每一类用户的要求和愿望，而不会沉溺于实现 细节，而用户 的要求和愿望正是 系统最重要 的部分。所有用例的集合描述 了系统的功能，客户可 以预先

13、确 定项 目的范围，从而避免了最终产品与客户间的期望 差异。此外，由于采用 了自然的描述语 言和图形化的 表达方式，使得客户和最终用户能够积极地参与需求 的获取活动，系统分 析人员能够识别潜在 的用户，他 们的实际需求，以及他们的典型行为，、用例驱动 的分 析方法不 同于传统的分析方法，它是个面向对象而不 是面向实现 的过程，因此 它不 同于 传统 的功能 分解 法。3 软 件需求 的获取 3 1 业 务 需求 的 获取 业务需求反映 了组织机构或客户对系统、产 品高 层次的 目标要 求，一般在项 目视 图与范 围文档 中说 明。因为业务需求 是高度抽象 的并且 其定义简单明 确，用例驱动技术

14、不可直接用于业务需求 的获取。但 采用用例驱动技术进行迭代、增量式地获取用户需求 和功能需求 时，对 原先 的业务需求具 有反 馈修 正作 用，可 以帮助明确和限定系统 的范 围，消除不明确的、二 义性 的概念，使客户和系统分析人员之间在系统的 范围、开发计划 以及资源 占用等方面达成共识。3 2 用户需求 的获取 组织 的业务需求确定之后，必然在如何改进组织 的业务流程、提高工作效率和促进各部门协作等方面 提 出了要求。用户为 了实现业务需求所提出的要求，必须要借助于待开发的软件系统协助他们完成工作，这就是用户对软件 系统的用户需求。软件 系统最终 是给用户使用，用户使用软件系统的 目的是为

15、了实现 业务上的 目标，因此，软件 系统成功与 否不仅是看它 采用怎样的先进技术，更重要的是取决于用户是否满 意。这使得用户需求 的获取这一阶段在 整个软件 生 命周期 中显得极为重要，这一阶段产生的错误的用户 需求将使软件开发过程 的后续 阶段出现重大的偏差，为了纠正这些偏差而耗费 的资源将 是在需 求开发阶 段所 消耗资源的几 十倍甚 至更 多。为了获取正确 的 用户需求，需 要用户 的积极参 与，但是用户具有 丰富 维普资讯 http:/ 3 8 计算机与现代化 2 0 0 2 年 第 6 期 的领域知识却缺少软件开发方面的知识，而分析人 员 正好 与之相反，这使得用户与分析员之间的沟通

16、产生 了困难。用例驱动技术抓住执行者、执 行者的 目标、用例 三个要 素，借 助 于场 景(S c e n a r i o)分 析、顺 序 图(S e q u e n c e D i a g r a n)和协 作 图(C o l l a b o r a t i o n D i a g r a m)等技 术克服 了以上 的困难，最 大可能地 消除了期 望差异，最终的用例模型(U s e C a s e Mo d e 1)就是 客户 与开发人 员之 间达成一致的系统开发合 同(C o n t r a c t)。3 2 1 执行者的确定 在用户需求获取 阶段，为 了获取用户需求首先要 明确 系统 的

17、用户。这里的用户是指要 与待 开发的系 统相互作用 的外部 实体，不是 专指组 织 的人员。首 先，通过提问以下一些问题来获得初始的用户列表：(1)谁直接使用系统?(2)谁负责系统的维护工作?(3)系统 使用 的外部硬件(4)要与本系统交换信息的其他系统。得到用户列表后，需要根据各用户使用系统 的动 机和 目的不同对他们进行分类，每一分类代表一种逻 辑 角色，而属同一种角色 的用户的集合就是用例 的执 行者：一般 的做法是，对几个 人的用户组(一般 23 人)查看 已识别 的执行者是 否已经 包括 了他们 的需 要，如已经包括 了他们 的需要，则他们 所属 的执 行者 类型就确定 了。在识别执

18、行者的过程 中，提问以下的 问题 是 很有 用 的：(1)谁将提供、使用、删除信息?(2)谁将使用这个功能?(3)谁对某一特定需求感兴趣?(4)淮负责系统某一方面的维护工作?(5)系统的外部资源是什么?(6)哪些外部系统需要与系统 的这一部分交互?确定了执行者也就基本上确定了系统 的边界，这 有助于理解系统 的 目标 和范围。只有直接 与系统 交 互的用户才可 以被看作是执行者，如果赋予执行者多 余的角色，必然会 超 出系统 的当前 范围。此 外，执行 者的确定不是一次性的工作，而是与用例的识别协 同 进行的，通过多次的迭代最终确定。3 2 2 用户需求用例的获取 因为系统 是为它的用户而开发

19、的，所以应该 以用 户的需求为基础。在得到 了初步 的执行者后，系统 的 用户转化成 了扮演各种逻辑 角色的系统外部 的执行 者，用户需求也转变成 了执行者所要执行的用例。所 以，用户需求的获取就变成了执行者用例的获取。获取用例的最好办法 是考虑每个执行者需要 系 统为他做些 什么，即执 行者 的 目标 对 于每 个执行 者，考虑以下 问题来识别用例：(1)执行者需要 系统执行 的主要任务是什么?(2)执行者需要在系统中创建、存储、修改、删除 和读取数据吗?(3)执行者需要 告知 系统 突然发生 的外部变动 吗?(4)系统 的所有 特性是否可 被 已经识别 的用例 实现?(5)执行者是否要执行

20、 系统的启动和关 闭?这些问题 的答案 代表 了候选用例 的事件 流。并 不是所有的事件流都能构成独立的用例，有的事件流 是同一用例事件流的变体。一般来说，用户总是趋 向 于首先确定业务领域(B u s i n e s s D o m a i n)中的最重要用 例(E s s e n t i a l U s e C a s e)，因此，最先经过用户确定的用 例往往具有最高 的优先级。不要期望一次得 到所有 的用例，而是 应 先根 据 系统 的 主要 执 行 者(P r i m a r y A c t o r)的需求，识别他们 的重要用例，再与用户代表和 领域专家进行验证和评审，确定 了这些重要

21、用例后，也就确立了系统的核心功能，初步 的用例获取工作即 告完成。接下来的用例获取工作应 围绕 系统 的次要 执行者(S e c o n d a r y A c t o r)的需求来进 行。经过 多次的 迭代，当下面的一些情景 出现时，用例 的获取工 作可 以认为 已初步完成。(1)用户不能想 出更多的用例。(2)用户提 出的新 的用例可 以通过 已获取 的用 例相关 的功能需求来实现。(3)用户新提出的需求涉及到具体的实现 细节，可 由有 限的简单操作完成，其相应 的用例粒度太小。(4)用户提出的需求 涉及到系统将来的特性，超 出了当前的系统范围。在 这个层次 的用例 反映 的是用户需求，即

22、用 户(体现为执行者)通过系统要完成的 目标。因此，这些 用例是抽象的、大粒度的，不涉及系统 的实现细节，每 个用例应有一段简洁 的叙述性 的文字来 描述用例的 目标和基本的交互序列。3 2 3用户需求的用例模型 当用例 获取基本 完成后，应对所有 用例进 行验 证，详察 所有用 例 以确 保满 足所有 的用 户需求。然 后，从所有 的用例 中识别 出表达抽 象行 为 的抽 象用 例，在基用例与这些抽象用例 之间运用用例 的包含、扩展和泛化关系建立联 系。同时，在具有公共特性 的 执行者之 间建立执行 者的泛化关系。最 终得到的是 维普资讯 http:/ 2 0 0 2年 第 6期 谢卫 宇等

23、：基于用例驱 动分析 的软 件需 求获取 方法 3 9 一个结构化的用 例模型。这 个模型是个高层 的反 映 用户需求 的抽象的模型，它从 系统外部用户的角度描 绘了系统的功能、范围，但不 涉及系统的具体实现细 节，它是功能需求 获取 工作流 的输 入，系统 的功能需 求都是从这个模型导出。3 3 功 能 需求 的 获取 3 3 1 相 关 概念 事件(E v e n t)是 执行 者 与 系统 的一 次交 互 的发 生。事 件流(F l o w o f E v e n t s)描述 了执行者执行用例过 程 中发 生的各种 交互的序列。通常有两种类型事件 流：一 个执 行 者顺 利达 成 目标

24、 的基本 事 件流(B a s i c F l o w o f E v e n t s)，另一种是反映可选或异常情况行为的 候选事件流(A h e r n a t i v e F l o w o f E v e n t s)。每 个用例 只 有一个基本事件流，但可有多个候选事件流。场景(SCe n a r i o)是 在 某 一前 提 条 件(P r e C o n d i t i o n s)下为达 到执行者 的 目标而发 生的交互 的序列，并且产生与执行者 目标相关 的特定结 果。这些交互 从触发动作开始，一直持续到执行者的 目标实现或被 放弃。系统负责实现交互 中的相关职责。用例是 场景

25、 的集 合，场景是用 例 的一 个具体实 例，它们的关系类似于类和对象的关系。场景和事件 流基本上是一回事，场景作为用例的实例总有一个相 应的事件流，两者间的细微区别是场景多了一个前提 条件。与基本事件 流对 应的是用例 的主要场景(P r i m a x T S c e n a r i o)，与候选事件流对应的是用例的次要场 景(S e c o n d a r y Sce n a r i o)。3 3 2 用例求精(U s e C a s e R e fi n e me n t)用户需求阶段 获取 的用例描述 了系统外部 的执 行者要实现的 目标，反映 的是用 户需求，但 并没有 涉 及系统

26、应提供 的相关 的具体 功能细节。用 户需求 决 定 了系统的功能需求，为 了获取这 些功能需求，必须 要对用户需求阶段 获取 的大粒度 的抽象用例进行求 精，通过细化用例 的事件流，得到用例 的所有 场景的 集合，而这些场景 中各个 步骤就是功能需求 的来源。具体步骤如下：(1)从用户需求阶段获取的所有用例 中选择一个 具有最高优先级用例。(2)场景分析。根据执行者的 目标确定顺利完成 目标的基本的最简单的交互序列，即先确定用例的主 要场景。然后，根据 主要场景 中每个基本步骤考虑其 异常情况和其他可选项 确定次要场 景。当得到用例 的所有场景后，转入第(3)步。(3)用例分解(U s e

27、C ase D e c o m p o s i t i o n)。用 例是 场景的集合，场景 中的每一步都可看成是一个小 的子 用例，这是个递归关系(图 2)。这些子用例是场景所 属外部用例 的下级 用例(S u b o r d i n a t e U s e C ase)，其 执 行者称为系统的内部 执行者，包括系统、子 系统 和对 象三类实体。这些 内部执行 者是下级用例 中与外部 用例执行者交互的实体对象。图 2 用例 与场景(4)用例判定。根据场景 中下级用例的粒度做 出 判定：对于像更新 数据库这类 的简单操 作，因其粒度 太小，将它继续看成用例 只能造 成用例数量 的膨胀，毫无 益

28、 处，故 应 该 把 它 当作 系 统 实 现 的 简单 行 为(P r i m i t i v e A c t i o n)，这个简 单行 为就是 系统要 实现 的 一个功能需求；对于较大粒度 的下级用例，因其本 身 代表了一个复杂的子交互 序列(S u b Seq u e n c e o f I n t e r a c t i o n s)，其执行者有 明确 的 目标，应将其 当作新 的待 求精用例，重复(2)(4)步获取其功能需求。(5)对剩余的用例，重复(2)(4)步。当再没有用例可 以求精时，最终得到的所有用例 中的简单行 为的集合就是系统的功能需求。3 4 非功能需求的获取 非功能

29、需求反映系统 的质量属性 的特性 和业务 规则、法规制 度等 各种 约束。具体 的有 以下一些 方 面：(1)易操作性；(2)可靠性；(3)可维护性；(4)业 务 规则；(5)各种法规、制度等。非功能需求不能由用例分析得到。相反，其 中一 些非功能需求会对用例的实现具有制约作用。因此，必须在这些用例和非功能需求之间建立联系，或把非 功能需求写入用例文档，或在两者间建立需求跟踪机 制。其他 的非功能需求须独立地获取。3 5 用例 文档的编制 对 于系统 中 的每 个用例，都必 须编写相 应的文 档，其模板如下：维普资讯 http:/ 计算机与现代化 2 0 0 2年 第 6 期 用例规范：用例名

30、 1 用例名 1 1 简要描述：简要描述用例的执行者和 目标 j 2 事 件流 2 1 基本流 2 2 候 选流 2 2 1 2 2 1 1 为 了提 高候选流 的清晰性，候选 流可被进 一步分 解成 逻 辑性的子块 2 2 2 ：复杂的用例可有多个候选流，保持各个候选流的相互独 立可提高事件流的清晰性。3 特殊 需求：这里的特殊需求典型的是一个特定于用例的非功能需 求：这个非功能需 求不容 易 以 自然 的方式在用 例 的事件 流 中 描 述=3 1 4 前 提条件 用例启动前 系统必 须满 足 的状 态 4 1 5 事后结果：完成条件是用例结束后系统所处的可能状态的列表。6 扩展点：用例的

31、扩展点 6 1 事件流中扩展点位置的定义 4 结束语 需求的获取是软件开发中一个非常重要 的阶段。0 0707 0707 0(上接 第 2 8页)b u f 3 4；m e m c p y(b u f+4，h o s t l P v 6，1 6)C C：4+】6：由于人认识复杂问题能力 的限制，不可能一下子就全 面透彻地 了解 复杂 的问题，而需一 个渐 进反 复的过 程。此外，由于软件系统的客户和开发人员背景和知 识结构 的不同，构成 了双方沟通 的障碍，导致难 以获 得正确 的需求。本文在对软件需求 进行层次划分 的 基础上，探讨 了用例驱动分析技术获取不同层次软件 需求的方法。首先根据业

32、务需求 的远景通过用例获 取用户需求，接着通过求精这些用例获取相应的功能 需求，最后再通过对获得的用户需求和功能需求的分 析验证来反馈修正业务需求，这种循环迭代式的需求 获取方法可 以有效地 获取 正确、合理 的软件需求，以 开发出令用户满意的软件产品来。参考文献：1 G r a d y B o o c h，J a m e s R am b u g h，I v a r J a c o b s o n n le U n i fi e d Mo d e l i n g L a n g u a g e U s e r G u i d e M A d d i s o n We s l e y L o

33、n g n l a ll，I n c，1 9 9 9 2 G r a d y B o o c h，J ame s R a m b a u g h，I v a r J a c o b son r n le U ni fi e d Mode l i n g I m g u a g e R e f e r e n c e Ma n u a l M A d dison We s l e y Lo n g ma n，I n c，1 9 9 9 3 G r a d y B o o c h，J ame s R a m b a u g h，I v a r J a c o b son r n le U ni f

34、i e d S o f t w a r e D e v e l o p m e n t P r o c e s s M j A d di son We s l e y L o n g m an，I nc，1 9 9 9 4 K a r l E We i g e r s Sof t w a r e R e q u i r e me n t s Mj M i c r o sof t C o r p o r a t i o n，2 0 0 0 5 M ark P r i e s t l e y P r a c t i c al O b j e c t o r i e n t e d D e s i

35、g n w i t h U M L l M 3 h e Mc G r a w H i l l C o m p a n i e s，I n c ，2 0 0 0 6 C o c k b u r n A S t r u c t u r i n g U s e C a s e wit h G o als l J j J o u r n al o f O b j e c t o ri e n t e d P r o g r a m m i n g，1 9 9 7(5)：3 54 0，and 1 9 9 7 (6)：5 66 2*(u n s i gne d s h o r t*)(b u r+C C)

36、：h o s t p o r t；*目标 主机 端 口*，C C：C C+2：s e n d(S，b u f，e e，O)；向代理服务器发送 目标 主机的连接请求后，等待 响应 r e(1v(S，b u f，s i z e o f(b u f)，O)；i f(b u f O =5&b u f 1 =：O)*与 目标主机 连接成功*e l s e *与 目标主机连 接失败*与 目标主机连接成功之后，客户程序便可通过这 个 s o c k e t 间接地 与 目标主机通讯 了。目标 主机是不 知道客户机到底是 直接连 接的还是经过代理服务器 连接 的。参考文献：1 R F C 1 9 2 8，S o c k s P r o t o c o l V e r s i o n 5 S 2 R F C 1 9 2 9，U s e mame P a s s w o r d A u t h e n t i c a t i o n f o r S o c k s V 5 S 维普资讯 http:/