（计算机应用技术专业论文）基于i的面向目标的需求分析方法的研究.pdf

基于f 的面向目标的需求分析方法的研究 摘要 本文主要介绍了一种面向目标的需求分析方法。当前，人们在需求工程中 越来越多地采用面向目标的方法。目标被用于需求工程过程中的各种推理活动 中。在一些r e 框架中，它们是关键的，在其它框架中它们也起着重要的作用。 它们驱动着对需求的评估。它们对需求说明提供了一个完整的评价标准；如果 需求说明满足了所有已陈述的目标，那么，需求说明就是完整的。此外，目标 一般比获取它们的需求说明更加稳定。 在本文中。我们首先介绍一些需求工程中常用的方法，并回顾了它们的不 足，特别提出了面向目标的需求分析方法。目前，存在着两个互补的体系在需 求模型中集成目标和目标改进：一个形式化的体系和一个定性的体系。 f * 体系是一种根据战略依赖关系及其原理，来理解和重新设计业务处理过 程的面向目标建模方法【y u 9 4 】。f * 体系是一种定性的体系。我们认为，f * 体系在 对需求说明的评估能力上存在着不足。针对发现的问题，我们将f * 体系的定性 的需求分析方法改进为一种定量的需求分析方法。 最后，我们使用改进后的f * ( d i s t r i b u t e di n t e n t i o n ) 体系来完成在需求模型中 集成目标和软目标的过程。 关键词：需求工程，面向目标，a g e n t ，非功能需求，j t 体系，g r l ( 面向目标的 需求语言) r e s e a r c ho ng o a l o r i e n t e dr e q u i r e m e n ta n a l y s i sm e t h o d o l o g y b a s e do nf o a b s t r a e t i n t h i sd i s s e r t a t i o n ，w ei n t r o d u c eag o a l o r i e n t e dr e q u i r e m e n ta n a l y s i s m e t h o d o l o g y n o w ，m o r ea n dm o r ep e o p l ep r e f e r t oa d o p tag o a l o r i e n t e d r e q u i r e m e n ta n a l y s i sm e t h o d o l o g yi nr e q u i r e m e n te n g i n e e r i n g d u r i n gt h ep r o g r e s s o fr e ，t h eg o a li su s e di nm a n ya c t i v i t yo fr e a s o n i n g i ns o m er ef r a m e w o r k ，t h e g o a li sv e r yc r i t i c a l ，a n di no t h e rf r a m e w o r k ，t h e ya l s op l a yi m p o r t a n tr o l e t h e y d r i v et h ee l a b o r a t i o no fr e q u i r e m e n t st os u p p o r tt h e m t h e yp r o v i d eac o m p l e t e n e s s c r i t e r i o nf o rt h er e q u i r e m e n t ss p e c i f i c a t i o n ；t h es p e c i f i c a t i o ni sc o m p l e t ei fa l l s t a t e dg o a l sa r em e tb yt h es p e c i f i c a t i o n g o a l sa r eg e n e r a l l ym o r es t a b l et h a nt h e r e q u i r e m e n t st oa c h i e v et h e m f i r s t ，w ei n t r o d u c es o m ea p p r o a c hi nr e ，a n dr e v i e w ss o m ea t t e m p t st o a d d r e s st h o s ei n a d e q u a c i e s ，w i t hs p e c i a le m p h a s i so nag o a l o r i e n t e da p p r o a c h t w o c o m p l e m e n t a r yf r a m e w o r k sh a v eb e e np r o p o s e df o ri n t e g r a t i n gg o a l sa n dg o a l r e f i n e m e n ti nr e q u i r e m e n t sm o d e l s ：af o r m a lf r a m e w o r ka n daq u a l i t a t i v eo n e t h ei + f r a m e w o r kp r o p o s e sa n a g e n t o r i e n t e da p p r o a c h t o r e q u i r e m e n t s e n g i n e e r i n gc e n t e r i n go nt h ei n t e n t i o n a lc h a r a c t e r i s t i c so ft h ea g e n t i 。f r a m e w o r k i saq u a l i t a t i v ef r a m e w o r k w et h i n kt h a ti f r a m e w o r ki si n a d e q u a t et oe v a l u a t e r e q u i r e m e n ts p e c i f i c a t i o n i no r d e rt o d e a lw i t ht h eq u e s t i o n ，w er e f o r mt h e q u a l i t a t i v er e q u i r e m e n ta n a l y s i sm e t h o d o l o g ya s aq u a n t i t a t i v e r e q u i r e m e n t a n a l y s i sm e t h o d o l o g y f i n a l l y ，i no r d e rt of u l f i l lt h ep r o c e s so fi n t e g r a t i n gg o a la n ds o f t g o a l ，w eu s e r e f o r m e di f r a m e w o r kt os u p p o r tt h ep r o c e s s k e yw o r d s ：r e q u i r e m e n t se n g i n e e r i n g ，o b j e c t - o r i e n t e d ，g o a l o r i e n t e d ，a g e n t ，g o a l ， n o n f u n c t i o n r e q u i r e m e n t ，i f r a m e w o r k ，g r l ( g o a l o r i e n t e d r e q u i r e m e n tl a n g u a g e ) 合肥工业大学 本论文经答辩委员会全体委员审查，确认符合合肥工业大学硕士 学位论文质量要求。 答辩委员会签名：( 工作单位、职称) 摭澎研艄掀 颓：岬多 珊级 j 钠己乙蔓士丫蝮 喜；、 露却 导，咳刊 佥7 欠刹叮 ；， 酬豇款 图表清单 图1 - 1 需求工程的基本过程和步骤2 图1 2 软件需求各组成部分之间的关系4 图1 3d f d 的基本图形符号7 图i 4 问题的分解7 图2 1t r o p o s 与其它软件开发方法的比较1 4 图4 1i n t e n t i o n a lr ef r a m e w o r k 2 7 图4 2f 方法的工作流程一2 8 图4 3 改进后的f - 方法的工作流程2 9 图4 4 非意愿元素2 9 图4 5 目标元素3 0 图4 6 任务元素3 0 图4 7 资源元素3 1 图4 8 软目标元素3 1 图4 9 促进关系3 1 图4 1 0 相关关系3 2 图4 1 1 方式一目的关系3 2 图4 1 2 任务分解关系3 3 图4 1 3 依赖关系3 3 图4 1 4 满意矩阵3 4 图4 1 5 意愿元素之间的冲突3 5 图4 1 6 意愿元素之间的冲突3 5 图5 - 1 电力公司的初始目标图4 0 图5 2 电力公司的战略推理模型4 1 图5 3 软件系统的战略依赖模型4 2 图5 4 软件系统的战略推理模型4 3 图5 5 新系统的战略依赖模型4 4 图5 - 6r o l e 、p o s i t i o n 和a g e n t 层次图4 5 图5 7 系统最终的依赖模型4 6 范例3 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。据我所 知，除了文中特别加以标志和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果， 也不包含为获得金蟹王些盍堂 或其他教育机构的学位或证书而使用过的材料。与我一同工作 的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示谢意。 学位论文作者签字：帮i a 移签字日期：一埤f 月目 学位论文版权使用授权书 本学位论文作者完全了解盒蟹王些盔堂有关保留、使用学位论文的规定，有权保留并向 国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅或借阅。本人授权盒胆王些盘 主l 可以将学位论文的全部或部分论文内容编入有关数据库进行检索，可以采用影印、缩印或扫 描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者签名 霄，啦 导师签名：多j 岔一i ， v 签字日期：工一，年f 月3 0 日签字日期：p 矿年f 月3 0 日 学位论文作者毕业后去向 工作单位： 通讯地址： 电话 邮编 致谢 本人在三年的硕士研究生课程学习和撰写学位论文的过程中，自始至终得 到了我的导师袁兆山教授的悉心指导，无论从课程学习、论文选题，还是到收 集资料、论文成稿，都倾注了袁兆山老师的心血，由衷感谢袁兆山老师在学业 指导及各方面所给予我的关心以及从言传身教中学到的为人品质和道德情操， 老师广博的学识、严谨的治学作风、诲人不倦的教育情怀和对事业的忠诚，必 将使我终身受益，并激励我勇往直前。 同时，真诚感谢计算机与信息学院的全体老师，他f 门的教诲为本文的研究 提供了理论基础，并创造了许多必要条件和学习机会：感谢李心科老师与邵堑 老师，在我课程学习和论文撰写期间，给予我的大力支持。 感谢所有的同学给予的帮助。 作者：管飚 2 0 0 5 年4 月1 6 目 第一章需求工程概述 1 1 需求工程的过程和定义 1 1 1 需求工程的起源 需求工程( r e q u i r e m e n t se n g i n e e r i n g ，r e ) 是随着计算机科学的发展而发展 起来的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写， 需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为 其第一阶段。随着软件系统规模的扩大和“软件危机”带来的软件工程的发展， 需求分析与定义在整个软件开发与维护过程中越来越重要，人们普遍认识到， 进行需求分析和定义可以避免系统开发时的盲目性。随着软件工程的研究和应 用的逐渐深入，人们同时认识到需求分析活动不再仅限于软件开发的最初阶段， 它贯穿于系统开发的整个生命周期。 8 0 年代中期，形成了软件工程的子领域一需求工程。进入9 0 年代以来， 需求工程成为研究的热点之一。从1 9 9 3 年起每两年举办次需求工程国际研讨 会( i s r e ) ，自1 9 9 4 年起每两年举办一次需求工程国际会议( i c r e ) ，在1 9 9 6 年 s p r i n g e r v e r l a g 发行了一个新的刊物一 r e q u i r e m e n t se n g i n e e r i n g ) ) 。一些关于 需求工程的工作小组也相继成立，如欧洲的r e n o i r ( r e q u i r e m e n t se n g i n e e r i n g n e t w o r ko fi n t e r n a t i o n a lc o o p e r a t i n gr e s e a r c hg r o u p s ) ，并开始开展工作。 需求工程的目标是深入描述软件的功能和性能，确定软件设计的限制和软 件同其它系统元素的接口细节，定义软件的其他有效性需求。需求分析的任务 就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做 什么”的问题。需求活动以“工程化”的方法被提出、分析和组织，它鼓励用 户以一种积极的方式参与需求分析活动中，并在整个软件生命周期中强调用户 参与和领域专家的指导作用，促使目标系统最大地满足用户需求。 1 ，1 2 需求工程的定义 需求工程是系统工程和软件工程的交叉学科。之所以把需求作为“工程” 来研究，其目的是强调它是一个系统的、协同的和反复的过程，是一个由客户、 用户、系统设计、开发、实现和测试人员等众多风险承担人参与的复杂活动， 涉及社会、人们的认知、表达方式以及企业文化等众多领域的问题。目前“需 求工程”还没有标准的定义，一般认为需求工程是指应用已证实有效的原理、 技术和方法，描述目标系统的外部特征和相关约束，从而确定客户需求，帮助 分析人员理解目标系统的一门学科。 需求研究是当前软件工程中的关键问题，从美国于1 9 9 5 年开始的一项调查 结果就足以看出这一点。在这项调查中，他们对全国范围内的8 0 0 0 个软件项目 进行跟踪调查，结果表明，有1 3 的项目没能完成，而在完成的2 3 的项目中， 又有1 2 的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程 相关的原因占了4 5 ，而其中缺乏最终用户的参与以及不完整的需求又是两大 主要原因，各占1 3 和1 2 。 1 i 3 需求工程的过程 需求工程是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两 个方面。从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用 领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难 度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功 能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说， 需求工程需要方方面面人员的参与( 如：领域专家、领域用户、系统投资人、 系统分析员、需求分析员等等) ，各方面人员有不同的着眼点和不同的知识背景， 沟通上的困难给需求工程的实施增加了人为的难度。 需求工程通过合适的工具和符号系统地描述待开发系统及其行为特征和相 关约束，形成需求文档，在验证的基础上冻结需求，并对用户不断变化的需求 演进给予支持。它是一个不断演进的过程。8 0 年代，h e r b k r a s n e r 认为需求工 程过程分为五个阶段：需求的定义和分析、需求决策、形成需求规格说明、需 求实现与验证、需求演进管理。近年来，m a t t h i a s j a r k e 和k l a u s p o h l 又提出了 需求工程过程可以分为三个阶段：获取、表示和验证。综合流行的关于需求工 程的定义，我们认为，需求工程包括获取需求和管理需求两个其本过程，并进 一步细分为八个步骤，如图1 一l 所示。 需要强调的是，需求工程是软件工程不可分割的重要组成部分，它贯穿于 整个软件工程的各个阶段，不可能把两者完全分割开来，之所以专门提出“需 求工程”的概念，完全是为了在过程中更专注于需求的获取、管理。 h 丙习 问 题 获 取 获取需求fl 管理需求 需 求 分 析 编 写 规 格 说 明 需 求 验 证 变 更 控 制 版 盘 控 制 而 求 跟 踪 图1 1需求工程的基本过程和步骤 需 求 状 态 跟 踪 1 1 4 需求的定义 需求就是以一种清晰、简明、一致且无二义性的方式对一个待开发的系统 中各个方面有意义的陈述的集合。需求必须包含足够多的信息，足以使设计师 和工程师来产生一个使客户满意的产品。 i e e e 软件工程标准词汇表( 1 9 9 7 年) 中定义需求为： 1 ) 用户解决问题或达到目标所需的条件或权能( c a p a b i l i t y ) 。 2 ) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具 有的条件或权能。 3 ) 一种反映上面1 ) 或2 ) 所描述的条件或权能的文档说明。 需求的层次： 软件需求包括三个不同的层次一业务需求、用户需求和功能需求一也包括 非功能需求。业务需求( b u s i n e s sr e q u i r e m e n t ) 反映了组织机构或客户对系统、 产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求 ( u s e rr e q u i r e m e n t ) 文档描述了用户使用产品必须要完成的任务，这在使用实例 ( u s ec a s e ) 文档或方案脚本( s c e n a r i o ) 说明中予以说明。功能需求 ( f u n c t i o n a lr e q u i r e m e n t ) 定义了开发人员必须实现的软件功能，使得用户能完成 他们的任务，从而满足了业务需求。所谓特性f f e a t u r e ) 是指逻辑上相关的功能 需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间 的关系如图l 。2 所示。 作为补充，软件需求规格说明还应包括非功能需求。它包括产品必须遵从 的标准、规范和合约；外部界面的具体细节；性能要求：设计或实现的约束条 件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质 量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描 述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或 测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。 f r e d e r i c k b r o o k s 在他1 9 8 7 年的经典的文章“n os i l v e r b u l l e t ： e s s e n c ea n d a c c i d e n t so fs o f t w a r ee n g i n e e r i n g ”中充分说明了需求过程在软件 项目中扮演的重要角色：“开发软件系统最为困难的部分就是准确说明开发什 么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、 面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来 极大损害的部分，并且以后再对它进行修改也极为困难。” 可以说需求工程的核心就是获得关于目标系统稳定、准确的描述，因此需 求工程的最终产品是一组系统需求文档，其中最主要的文档是项目管理文档和 需求规格说明，如图1 2 所示。这些文档是对需求”固化”的结果，是对系统的 功能性需求和非功能性需求的陈述。系统需求文档是后继系统设计、实现和测 试的依据，它必须完整、一致、没有二义性，而且在系统开发、运行和维护的 过程中，还必须能够对其进行修改、跟踪、验证和使用。为了达到这个目标， 目前趋向于引入形式化方法进行一致性检查、类型检查、有效性验证、行为预 测以及设计求精验证。 图1 2 软件需求各组成部分之间的关系 1 2 需求工程面临的问题 需求问题是软件工程中的最古老的问题。一个早期的对软件工程项目的经 验的研究揭示出了不充分的、不一致的、不完全的或含糊的需求对产生的软件 的质量有决定性的影响。后期对需求错误的改正具有惊人的费用。人们逐渐产 生一致，工程的高质量需求是困难的。 软件需求应该被仔细地和准确地工程化。然后用系统的方法来引出需求， 用连贯的结构来组织它们，并检查它们是否高质量地( 完全、一致和充分) 满足 真正的需求。 当前需求工程的方法仍然是有限的，因为： 夺需求工程过程的广泛的范围和固有的复杂性， 审经常错误地理解基本的想法真正是什么( 例如，需求，一致性，完整性) ， 夺对用于需求工程的大多数的推理技术缺少抽象， 夺对推理软件是什么及其环境缺少支持， 夺自然倾向于创造新的符号和随后的检查技术而不是结构上的方法， 夺关于形式( 对于可分析性) 和简单( 对于可用性) 的冲突的事务。 需求工程过程所面临的三种复杂的问题。 夺w h y 问题：为什么在当前或可预见的条件下需要这个系统。这样，新 系统的目标可以被确认，分析和求精，这些目标通常可以通过当前形势 的问题分析，交互场景的考察等等来获得。除了功能目标( 例如，要求 的满足，事务的状态信息) ，还有许多非功能目标( 例如安全性，性能 实用性等) ，这些目标的确认和求精通常需要特定的领域知识。 夺w h a t 问题：操作各种己识别出的不同目标的需求需要被准确地定义， 并相互关联。同时，需要明确操作过程中做出的假设并且文档化。除了 功能需求之外，还有与服务质量有关的非功能需求。 夺w h o 问题：需求要作为约定的义务被分配给系统中的代理。这些代理 包括要开发的软件，传感器执行机构，已存在的软件等。软件和它的 环境之间的边界产生于职责的分配：不同的职责分配定义了不同的系统 方案。 这样，我们可以看到，需求工程并没有像软件说明中表明的那样限制在 w h a t 问题上。 鉴于一些频繁产生的混淆，澄清需求是什么也是十分必要的。 首先必须分清楚需求和领域属性。自然规律，组织策略，规则，项目的定 义或在环境中的操作不是需求。例如，对应用于火车控制系统中的操作 o p e n d o o r s ，其前提条件( 门必须是关上的) 是一个领域属性，不是一个需求：另 一方面，为了获得安全运输的目标，关于同一个操作( o p c n d o o r s ) 的前提条件( 火 车到站1 是一个需求。 其次，必须明确地区分需求和软件说明。用s t a k e h o l d e r s 可理解的词汇来 系统地陈述需求；它们分别获取由软件控制和监视的环境中的目标之间的必要 关系。根据由软件操纵的目标，用程序员可理解的词汇来系统地陈述软件说明， 它们在输入和输出软件目标间获取必要的关系。在软件和需要输入和输出软件 目标状态以准确地反映相应的它们描述的受监视和控制的目标的环境之间的边 界上，准确性目标是非功能目标。在我们的火车系统的例子中，需要有一个准 确性目标来陈述门是开着的，相应的d o o r s t a t e 有一个值“o p e n ”。 第三，必须明确地区分需求和假设。尽管它们都是祈愿属性，需求由软件 来执行，而假设由环境中的代理来执行。例如，当门是开着时，软件可以执行 火车到站，但是不能执行乘客上车。 如果r 表示一系列需求，a s 表示一系列假设，d 表示一系列领域属性，s 表示一系列软件说明，a c 表示一系列准确性目标，g 表示一系列考虑中的目标， 下面的满足关系： s ，a c ，d 户r w i t hs ，a c ，dl ；，- f a l s e r ，a s ，dl = g w i t hr ，a s ，df = f a l s e 在软件的生命周期中，需求工程过程是一个复杂的步骤，其原因如下： 专需求工程的范围是广泛的。它涉及到两个系统一系统现在是什么和它 将是什么。它不仅包括要被开发的软件，而且包括软件被操作的环境。 后者可以包括复杂的组织策略或需要考虑的自然现象。范围也包括整 个的事务和描述，从高层目标到低层约束，从初始的模糊到最终的准 确，有时是形式化的。 夺r e 过程由复合的交错的子过程组成，例如领域分析，s t a k e h o l d e r 分析， 目标和场景的引出，对选择方案的研究，风险分析，讨论，选择的文 档，说明，证实和验证，和变更管理。 夺通常有许多不同的参与者，他们不必共享同一个目标和背景一客户、 领域专家、管理者、分析员、开发者，等等。 夺大量的和不同的事务不可避免地产生冲突，这需要适当地检测和解决。 在这个火车控制系统的例子中，安全运输的目标要求火车不能太接近， 这与为更多乘客服务的目标相冲突。在电子付费系统中，匿名和应负 责任目标是冲突目标，保密性通过密码与可用性冲突。需求工程师存 在于冲突是规律的环境中，而不是例外；冲突管理是需求工程过程的 驱动力量。 夺除了冲突和不一致外，有许多需求说明可能包含的其它类型的错误和 缺陷：它们有些是重要的，例如不完全，不适当或模糊；其它的，例 如干扰，o v e r s p e c 诳c a t i o n s ，f o r w a r d e f e r e n c e s ，或w i s h f u lt h i n k i n g 一 般是不严重的，但是阻碍了可理解性和产生了新的问题。需求说明中 的错误是为数众多的，持久的，昂贵的和危险的。 1 3 需求分析方法学 需求分析的方法大致分为以下几类：面向过程、面向数据、面向控制、面 向对象和面向目标等。 面向过程的分析方法主要研究系统输入输出的转化方式，对数据本身及控 制方面并不很重视。传统的结构分析方法s a ( s t r u c t u r ea n a l y s i s ) 、s a d t ( s t r u c t u r e a n a l y s i sa n dd e s i g nt e c h n i q u e ) 和可执行可操作模型p a i s l e y 、d e s c a r t e s 以及形 式方法v d m ( v i e n n ad e s i g nm e t h o d ) 、z 等都属于这一类。 面向数据的方法强调以数据结构的方式描述和分析系统状态，j s d 和关系实 体( e r ) 模型都属此类。 面向控制的方法强调同步、死锁、互斥、并发以及进程激活和挂起，数据 流图就是典型的面向控制的方法，s a d t 是以面向控制的方法为辅的。 面向对象的方法把分析建立在系统对象以及对象间交互的基础上，通过对 象的属性、分类结构和集合结构定义和沟通需求。从对象模型、动态模型和功 能模型三个方面对问题进行描述。面向对象的方法正在成为需求分析中的一个 热点，并展现出良好的应用前景。y o u r d a n 和c o a d 的o o a 方法、b o o c h 的方法、 j a c o b s o n 的o o s e 、r u m b a u g h 的o m t 方法等，都是这一方法的典型流派。 1 3 1 面向过程的需求分析方法 传统的面向过程的需求分析方法即结构化分析方法( s a ) ，s a 方法是一种 自顶向下逐步求精的功能分解方法。分析人员先做出顶层数据流图( d f d 图) ， 在此基础上反复细化，得到更详细的新的一层数据流图，直到得到的数据流图 中的加工均为基本加工为止。 数据流图可以用来抽象地表示系统或软件。它从信息传递和加工的角度， 以图形化的方式刻画数据流从输入到输出的移动变换过程，同时可以按自顶向 下逐步求精的功能分解方法表示内容不断增加的数据流和功能细节。因此，数 据流图既提供功能建模的机制，也提供了信息流建模的机制，从而可以建立起 系统或软件的功能模型。数据流图的基本图形符号如图l - 3 所示。 o 加工。辅入数据在此变换产生 输出数据苴中注明撩作的名字。 厂 数据输入的张点( s o u 虻e ) 和输出奇勺 点( s i n 埘 其中注明源点和汇点白勺昭字。 且 数据流被加工的数据与流向，箭头边鲐出 数据流名字，用名词或名词性短语命名 数据存储文件用名词或名词性短语命名 图1 3d f d 的基本图形符号 图1 - 4 问题的分解 为了揭示系统内部数据传递和处理变换的细节，可对其功能和信息都作进 一步分解。这种分解可以是在同一层次上的，称为横向分解；也可以是多层次 的纵向分解。如图1 4 所示。对系统的功能层次结构化分析可以采用自顶向下 的结构化分析方法。从系统的顶层开始，首先分析系统的主要业务处理，划分 成若干个主要的功能模块，然后对这些模块再分别进行扩展，逐步加细，划分 成更小的功能模块。越向下划分，反映的业务处理就越具体。值得注意的是， 在进行功能分析的时候，应把重点放在处理的逻辑过程上，而不要去研究采用 什么样的技术手段或方法。 传统的s a 方法以过程为中心进行功能组合。其优点在于容易掌握，缺点 是对用户的要求较高，对现实系统的业务管理、数据是否齐全要求也比较严格， 而且，从s a 方法到结构化设计( s d ) ，中间要经过从流程图到数据流图、再到 系统设计的h i p o 图和结构控制图的不断转移，环节多，差异大，转换质量难 以保证。因此，软件的扩充和复用能力都较差。 1 3 2 面向对象的需求分析方法 面向对象( o o ) 技术起源于六十年代的面向对象语言s i m u l a ，进行八十年代 后，面向对象程序设计( o o p ) 的概念目渐成熟，并开始走向实用；八十年代中 期，o o p 的基本概念被引入到设计阶段，面向对象设计( o o d ) 方法逐步形成； 八十年代后期，o o p 和o o d 的基本概念又被引入到分析阶段，从而开始形成 面向对象分析方法( o o a ) 。事实上，与结构化分析方法、形式化方法及软件复 用技术类似，o o 方法首先从编码阶段产生，进而发展到软件生命期的前期阶 段，最终走向成熟。当前，o o 方法正处于研究探索时期，尚不成熟和完备， 也没有关于o o 方法的统一认识标准。 目前已经衍生许多种o o a 方法。每种方法都有其进行产品或系统分析的过 程，有一组可描述过程演进的图形标识，咀及能使得软件工程师以一致的方式 建立模型的符号体系。现在广泛使用的o o a 方法有以下几种： b o o t h 方法b o o c h 方法包含“微开发过程”和“宏开发过程”，微开发过 程定义了一组任务，并在宏开发过程的各个步骤中反复使用它们，以维持演进 途径。b o o c h 的o o a 宏开发过程的任务包括标识类和对象、标识类和对象和语 义、定义类与对象间的关系，以及进行一系列求精操作从而实现分析模型。 r u m b a u g h 方法r u m b a u g h 和他的同事提出的对象模型化技术( o m t ， o b j e c tm o d e l i n gt e c h n i q u e ) 用于进行分析、系统设计和对象级设计。分析活动 建立3 个模型：对象模型( 描述对象、类、层次和关系) ，动态模型( 描述对象和 系统的行为) ，功能模型( 类似于高层的数据流图，描述穿越系统的信息流) 。 c o a d 和y o u r d o n 方法c o a d 和y o u r d o n 方法常常被认为是最容易学习的 o o a 方法。建模符号相当简单，而且开发分析模型的导引直接明了。其o o a 过程概述如下： a ) 使用“要找什么”准则标识对象。 b ) 定义对象之间的一般化一特殊化结构。 c ) 定义对象之间的整体一部分结构。 d ) 标识主题( 系统构件的表示) 。 e ) 定义属性及对象之间的实例连接。 f ) 定义服务及对象之间的消息连接。 j a c o b s o n 方法 也称为o o s e ( 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 ，面向 对象软件工程) 。j a c o b s o n 方法与其它方法的不同之处在于它特别强调使用实例 ( u s ec a s e ) 一用以描述用户与系统之间交互的场景。j a c o b s o n 方法概述如下? a ) 标识系统的用户和它们的整体责任。 b 1 通过定义参与者及其职责、使用实例、对象和关系的初步视图，建立需 求模型。 c ) 通过标识界面对象、建立界面对象的结构视图，表示对象行为、分离出 每个对象的子系统和模型，建立分析模型。 w i r f s b r o c k 方法w i r f s b r o c k 方法不明确区分分析和设计任务。从评估 客户规格说明到设计完成，是一个连续的过程。与w i r f s b r o c k 分析有关的任 务概述如下： a ) 评估客户规格说明。 b ) 使用语法分析，从规格说明中提取出候选类。 c ) 将类分组以表示超类。 d ) 定义每个类的职责。 e ) 将职责赋予每个类。 n 标识类之间的关系。 g ) 基于取责定义类之间的协作。 h ) 建立类的层次表示。 i ) 构造系统的协作图。 统一的o o a 方法u m l统一的建模语言( u m l ，u n i f o r mm o d e l i n g l a n g u a g e ) 已经在企业中广泛使用，它把b o o c h ，r u m b a u g h 和j a c o b s o n 等各自 独立的o o a 和o o d 方法中最优秀的特色组合成统一的方法。u m l 允许软件 工程师使用由一组语法的语义实用规则支配的符号来表示分析模型。 在u m l 中用5 种不同的视图来表示一个系统，这些视图从不同的侧面描述 系统。每个视图由一组图形来定义。这些视图概述如下： a ) 用户模型视图：这个视图从用户( 在u m l 中叫参与者) 角度来表示系统。 它使用实例( u s ec a s e ) 来建立模型，并用它描述来自终端用户方面的可用 的场景。 b ) 结构模型视图：从系统内部来看数据和功能性，即对静态结构( 类、对 象和关系) 模型化。 o ) 行为模型视图：这种视图表示了系统动态和行为。它还描述了在用户模 型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。 d ) 实现模型视图：将系统的结构和行为表达成易于转换为实现的方式。 e ) 环境模型视图：表示系统实现环境的结构和行为。 通常，u m l 分析建模的注意力放在系统的用户模型和结构模型视图，而 u m l 设计建模定位于行为模型、实现模型和环境模型。 面向对象的软件分析能克服s a 方法的缺点。以对象模拟现实实体，因而 能使用户和分析员之间很好地沟通，更容易理解需求。由于对象的封装等特点， 变化容易隔离并能较快实现。从0 0 a 阶段到o o d 阶段，使用同一的对象概念， 开发过程中阶段的改变，不需要方法的转换，最重要的是面向对象技术中的继 承机制能更好地适应重用，提高了软件质量的可靠性和效率。 但是，多数o o a 方法未能有效地描述系统的外部行为和特性，未能提供建 立完整的需求规约的手段，从而未能全面实现需求分析的目标。这也是当前 o o a 方法的不足之处，在选择o o a 方法时应当充分认识到这一点。 1 4 本章小结 本章首先回顾了需求工程的起源，需求工程的定义和需求工程的过程，详 细分析了软件需求的三个不同层次，给出了软件需求各组成部分之间的关系。 我们认为，需求工程不仅仅要解决做什么( w h a t ) 的问题，还要解决w h y 问题 和w h o 闯题。随后，我们讨论了当前存在主要的需求分析的方法，重点分析了 面向过程和面向对象的需求分析方法的优缺点。本章将为后续章节讨论的面向 目标的需求建模问题提供基础。 第二章面向目标的需求分析方法 当前，由于i n t e r n e t 技术的迅速发展，对传统的软件技术提出了新的挑战。 传统的软件系统往往替代了人们的某些重复繁琐的工作，由于组织环境的变化， 人们发现，原有的软件系统不能适应环境的变化。因此，人们认为，需求工程 不仅要对软件系统，而且还要对软件系统所处的组织环境进行分析建模。 前面我们回顾了一些需求分析方法的不足，这里特别介绍了面向目标的需 求分析方法。概括地说，一个目标相当于系统通过软件和环境中代理的协作来 获得的目的。目标在需求工程过程中起着重要的作用。它们驱动着对需求的改 进。它们对需求说明提供一个完整的标准；如果需求说明满足了所有已陈述的 目标，那么需求况明是完整的。目标一般比获得它们的需求是更加稳定的。它 们是需求存在的基础；由于存在一些基本的对需求提供基础的目标，需求就存 在。简而言之，需求“执行”目标就像程序执行设计说明。 2 1 为什么要引入面向目标的需求分析方法 今天，目标的观念在需求工程中被越来越多地使用。在不同的需求工程活 动中引入目标具有不同的原因，获得了不同的目的。在一些需求工程体系中， 它们起着核心的作用；在另一些需求工程体系中，它们仅仅起着辅助的作用。 虽然不同的体系的创始人说明了目标在他们各自的体系中的意义和作用，但是 还没有真正尝试去理解和澄清目标在需求工程的不同领域中的作用。 2 1 1 目标的定义 目标就是由系统将要获得的目的，它是对意向的一种说明性的描述。这里 的系统指的是软件以及软件远行的环境。目标有多种类型。按层次划分可以分 为高层目标和低层目标：高层目标是指具有战略性，粗粒度的和组织范围上的 目标，例如，对于火车控制系统来说，可以有这样一个高层目标：“为更多的乘 客服务”；低层目标是指技术上的、细粒度的和设计上的目标，对于火车控制系 统来说，可以有这样一个低层目标：“每秒发送三次加速指令”。按照涉及的类 型可以分为功能目标和非功能目标，功能目标是所期望的服务，例如“计算火 车加速度”，非功能目标是指服务的质量：保密性，安全性，准确性，可执行性， 费用，可使用性等，例如“维持最坏情况下的停车距离”，也可以指开发的质量： 适应性，互操作性，可重用性等。 分配给软件中的单个代理的目标就是需求，例如“在火车速度不为零时， 车门必须是关着的。”分配给环境中的单个代理的目标就是期望，它不能由软件 来实施，例如“在火车站，当门是开着时，乘客上车”。代理负责目标的完成， 也就是说：“要限制代理的行为 f e a t h e r 8 7 】”，“目标必须是可以实现的 【l e t i e r 0 1 】 。 2 1 2 目标在需求工程中的作用 需求工程的范围在本质上是广泛的，跨学科的和开放式的。它涉及从来自 于真实世界的非形式化的观察到形式化的说明语言的转换。由于某些原因，与 计算机科学的其它研究领域相比，需求工程领域似乎有些混乱【z a v e 9 7 。许多 研究人员发现，在他们的研究领域引入目标的概念是根有帮助的。下面，我们 列举一些目标在需求工程不同的领域的作用。 1 ) 需求获取目标被认为在需求的获取和评估中有重要的作用。例如， k a o s 方法使用目标作为在需求获取中的核心的概念。a n t o n 也将目标 作为开发需求说明的主要的指导概念。目标的识别本质上导致了不断地 询问“w h y ”、“h o w ”和“h o we l s e ”问题。一个s t a k e h o l d e r 的需求经 常在评估目标的过程中被揭示出来。s t a k e h o l d e r s 也更加了解可能的选 择方案以满足它们的目标，并且不太可能过早地指定技术上的解决方 案。 2 ) 连接需求到组织或事务环境在过去，需求仅仅关注于系统应该做什 么。随后，人们认为需要理解和表现即成的系统和环境之间的相互作用。 近年来，人们认为，软件系统对事务和组织问题提供解决方案，所以。 要根据基于目标的关系来表示软件系统和它们的环境之间关系。由于现 在日益变化的事务和组织环境，系统被越来越多地用于改变事务过程， 而不是使长期建立的实践自动化。建模技术需要支持推理分析的“w h y ” 和“h o we l s e ”类型。p o h le ta l 强调面要模型化组织环境，这就包括作 为一个重要元素的目标。 3 ) 澄清需求从客户和s t a k e h o l d e r s 获得的初始的需求通常是不清晰的。 目标提供了一个澄清需求的方式。根据目标的分解和改进来分析需求可 以看成是选取出需求陈述的许多层次，每一个层次涉及下一个层次的要 求。这种澄清需求的方式特别适合于非功能需求的情况( 例如灵活性， 稳定性，可重用性和可维护性) 。面向目标的方法允许以一种渐增的过 程来改进和澄清需求。c h u n g 的n f r 体系是一种处理非功能需求的面 向目标和面向过程的体