（计算机软件与理论专业论文）关于建立需求工程过程模型的初步研究.pdf

摘要及关键字 摘要 需求工程是软件工程领域的重要研究内容之。自上世纪6 0 年代软件危机 出现以来，人们都致力于研究解决软件危机的办法。随着研究的逐步深入，人们 意识到使用工程化的方法从事软件开发可以大大提高开发效率，于是软件工程的 概念产生。然而，这并没有从根本上解决软件危机。经调查，仍旧有三分之的 项目中途搁浅，一半以上的项目实际成本是预算的近两倍。研究发现，导致这种 现象的最主要原因大都来自需求分析阶段。 在上世纪8 0 年代，为解决需求问题，需求工程的概念被正式提出，相关研 究也随之进行。经过近二十年的研究，需求工程在方法、技术、工具等各个方面 都逐渐成熟。然而新的问题又出现了，人们发现尽管需求工程的研究成果不少， 但在实践中所起到的作用却远没有达到人们的期望。需求工程理论研究与实践之 间的鸿沟由此产生。 本文试图从过程的角度来分析产生鸿沟的原因。通过对一个实际的需求工程 实施过程的分析和总结，我们发现，需求工程实施的结果和效果如何，从最根本 上取决于我们是否在需求工程实施的最一开始制定一个完整的可行的需求工程 过程。只有在需求工程过程的统一指导下，选择合适的方法和支持的工具，这样 才能保证需求工程实施的质量以及需求工程产品( 如：需求规格说明书) 的质量。 那么，如何在需求工程实施的初期定义一个良好的过程来指导我们的实践 昵? 世上没有包治百病的万能药，同样，没有哪一个过程能够适用所有组织的所 有项目。通过对现有需求工程理论的总结，我们试图建立一个最抽象的需求工程 过程模型。针对不同项目、不同组织的特点对过程模型进行剪裁，从而得到特定 的需求工程过程。 本文中，只建立了一个初步的需求工程过程模型。该模型还需要在不断的实 践中改进和扩充。 关键字：需求工程；需求工程过程；需求工程过程模型 a b s t r a c t r e q u i r e m e n t se n g i n e e r i n g ( r e ) i so n eo ft h ei m p o r t a n tr e s e a r c hs u b j e c t si n s o f t w a r ee n g i n e e r i n g ( s e ) s i n c e1 9 6 0 sw h e nt h es o f t w a r ec r i s e sc a m ef o r t h ，l o t so f p e o p l e c o m m i t t e dt h e m s e l v e st or e s e a r c h i n gh o wt os o l v et h es o f t w a r ec r i s e s a st h e r e s e a r c hw e n td e e p e r , p e o p l er e a l i z e dt h a tt h ee f f i c i e n c yw o u l db ei m p r o v e d b yu s i n g t h em e t h o do f e n g i n e e r i n g t h e r e u p o n t h e c o n c e p t o fs ec a m ei n t o b e i n g n e v e r t h e l e s s ，s ed i dn o ts o l v et h es o f t w a r ec r i s e sr a d i c a l l y a ni n v e s t i g a t i o ns h o w e d t h a to n et h i r do ft h ep r o j e c t sw e r ef a i l e da n dt h er e a lc o s to fm o r et h a nh a l ft h e p r o j e c t sa p p r o x i m a t e l yd o u b l e dt h e i rb u d g e t s t h er e s e a r c h i n gr e s u l ts h o w st h a tt h e m o s ti m p o r t a n tr e a s o nl e a d i n gt ot h e s ep h e n o m e n aa r em o s t l yf r o mt h er e q u i r e m e n t s p h a s e i n1 9 8 0 s ，t os o l v et h er e q u i r e m e n tp r o b l e m s ，t h ec o n c e p to fr ew a sf o r m a l l y b r o u 曲tf o r w a r da n dr e l a t i v er e s e a r c h e sb e g a na f t e rt h a t n o wr eh a sg r o w nu pa t e v e r ya s p e c ts u c ha sm e t h o d ，t e c h n o l o g ya n dt o o l s a f t e r t w e n t yy e a r s r e s e a r c h h o w e v e r , n e wp r o b l e mt h a tl o t so ft h e o r e t i c a lr e s e a r c ha c h i e v e m e n tc o u l dn o tr e s u l t a na n t i c i p a n te f - f c c tc a m ef o r t h t h e r e b yt h eg a pb e t w e e nt h et h e o r e t i c a lr e s e a r c ha n d p r a c t i c ei nr e c a n l ei n t ob e i n g t h i st h e s i st r i e st oa n a l y z et h er e a s o nt h a tr e s u l t si nt h eg a pf r o mt h ep o i n to f v i e w o f p r o c e s s b ya n a l y z i n ga n ds u m m a r i z i n gap r a c t i c a li m p l e m e n t a t i o np r o c e s so f r e w ef i n dt h a tw h e t h e rt h er e s u l ta n dt h ee 赶b c to f i m p l e m e n t a t i o no f r ea r eg o o d o rn o tr a d i c a l l yl i e so nt h a tw h e t h e rw ee s t a b l i s haf u l lf e a s i b l er e p r o c e s sf r o mt h e b e g i n n i n go fi m p l e m e n t a t i o no f r e n oo t h e rt h a nu n d e rt h eu n i t e dg u i d a n c eo fr e p r o c e s s ，c h o o s i n gt h ea p p r o p r i a t em e t h o da n dt h es u p p o r t i n gt o o l s ，t h eq u a l i t yo f i m p l e m e n t a t i o na n dp r o d u c t i o no f r e c a r lb e i m p r o v e d w e l lt h e n ，h o wt od e f i n ean i c e r p r o c e s st og u i d eo i , u p r a c t i c ea tt h eb e g i n n i n go f i m p l e m e n t a t i o no f r e ? t h e r ei sn ou n i v e r s a ls o l u t i o ni nt h ew o r l d 1t h es a m ew a y , t h e r ei sd op r o c e s st h a tc a nb ea p p l i e dt oa l lt h ep r o j e c t so fa l lt h eo r g a n i z a t i o n s b y s u m m a r i z i n gt h et h e o r yo fr ei ne x i s t e n c e ，w et r yt o e s t a b l i s hag e n e r a l i z e dr e i i i 北京工业大学工学硕士学位论文 p r o c e s sm o d e l a c c o r d i n g t ot h ec h a r a c t e r i s t i co fd i f f e r e n tp r o j e c t sa n d o r g a n i z a t i o n s ， t h ep r o c e s sm o d e lc a nb et a i l o r e ds oa st og e tt h es p e c i f i cr e p r o c e s s i nt h i st h e s i s ，a l le l e m e n t a r yr e p r o c e s sm o d e l t h a ta l s on e e dt ob ei m p r o v e da n d e x t e n d e di np r a c t i c ei sj u s te s t a b l i s h e d 【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 ；r e q u i r e m e n t se n g i n e e r i n gp r o c e s s ； r e q u i r e m e n t se n g i n e e r i n g p r o c e s sm o d e l i v 独创性声明 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 签名：邋导师签名：盈至日期：逻堡乡，7 第l 章绪论 第1 章绪论 需求工程( r e q u i r e m e n tse n g i n e e r i n g ，r e ) 作为软件工程的第一个也是非 常重要的一个子领域，正越来越多地受到业界的关注。从“需求工程”的概念最 初被提出至今已近2 0 年，相关的研究成果不在少数，但是理论与实践的脱节仍 旧是困扰该领域研究的一个难题。 1 1 课题研究背景 随着信息时代的飞速发展，各行各业对计算机信息系统的需求量猛增，同时 对信息系统的要求也越来越高：系统越来越复杂；规模也越来越大。并且，随着 企业业务的发展以及业务流程的重组，系统需求变更已成必然。在这样的环境下， 人们对软件产品的质量提出了更高的要求。 然而，软件危机持续了近4 0 年之久，至今仍无法得以很好地解决。经常出 现用户对“已完成”的系统不满意，软件产品b u g 不断，频繁的打补丁，甚至项 目失败搁浅等情况。究其原因，除了与软件本身所具有的复杂性。”的特点有关之 外，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为 关键的原因。 因此，人们逐渐意识到以工程化的原则和方法组织软件开发工作是解决软件 危机的一个重要出路，尽管它可能不是“银弹”。“，但起码可以使从事软件工 作的人们能够在每项工作结束后少些遗憾。 需求分析是软件生命周期的第一个阶段，并贯穿于整个软件生命周期，其重 要性越来越突出。n 2 十世纪8 0 年代中期，逐步形成了软件工程的子领域 需求工程。“。进入9 0 年代后，需求工程成为软件界研究的热点之一。 有关需求工程的研究国外起步较早，也有一些很好的理论以及理论指导下的 方法和工具。国内在这方面的研究才刚刚起步，很多企业或软件开发商还没有认 识到需求工程的重要性。 在需求工程的实践过程中，通常我们会得到一些理论性的指导。但是这些理 论要么是对部分实际问题的简化，缺乏完整性，能起到的指导作用有限；要么是 北京工业大学工学硕士学位论文 理论过于抽象、庞大和复杂，让人感觉无从下手。于是，需求工程研究现状中出 现了一个明显的不足，即理论研究与实际应用的脱节。要获得需求工程的进一步 突破，改善需求工程的开发质量和效率，需要有识之士共同探索更为有效的解决 途径和方法，以缩小理论与实践之间的距离，使研究出来的理论、系统或模型切 实满足实际应用的需要。 本文试图从规范需求工程过程的角度提出一种解决上面问题的思路，以供大 家共同探讨。 1 2 课题依托的项目背景 本课题的发现与研究依托于数字工大综合信息系统项目。下面对该项目的相 关情况做简单介绍。 1 9 9 0 年由美国克莱蒙特大学教授凯尼斯格林( k e n n e t hg r e e n ) 发起并主 持的一项大型科研项目“信息化校园计划”( t h ec a m p u sc o m p u t i n gp r o j e c t ) ， 是数字化校园概念的最早出现。 1 9 9 8 年1 月3 1 日，美国前副总统戈尔( a lg o r e ) 在美国加利福尼亚科学中 心发表了题为“数字地球：二十一世纪认识地球的方式( t h ed i g i t a l e a r t h ： u n d e r s t a n d i n go u rp l a n e ti nt h e2 1 s tc e n t u r y ) ”的演讲，最先提出“数字 地球”概念，全世界普遍接受数字化概念，引出“数字城市”、“数字校园”等各 种概念。随着北京工业大学学校信息化工作的进一步推动，校园网上的信息越来 越多，应用也越来越多，迫切需要对学校的各种资源进行统一管理，对各层次人 员提供信息的集成化服务和面向用户的“个性化”服务：迫切需要统- - 的m p 认 证机制并建立一个统一的电子身份体系；随着网络技术的发展和网上应用的不断 增多，i n t e r n e t 上原有的安全隐患也不断暴露出来，建立一个覆盖全校的网络 安全体系也成为迫切任务。 r 数字工大就是在“数字校园”概念的发展以及学校信息化建设的基础上 提出的，试图用层次化、整体的观点来规划、实旌学校的信息化建设，为北京工 业大学教育信息化确定一个清晰的目标。“数字工大”的建设将对学校所有信息 资源进行统一的、科学的组织与管理，对校园网上的信息进行更好的组织和分类， 第1 章绪论 让用户在网上快速发现自己需求的信息，为师生提供优质的网上信息交流环境， 让管理人员科学地、规范地管理自己的数据，并将这些信息以最有效的方式、更 方便地发布，提供给用户服务。 数字工大主要的建设内容包括以下几个层次： 1 网络基础设施建设：包括工大网络布线拓扑结构的改造及实施、网络设备 的升级、工大i d c ( i n t e r n e td a t ac e n t e r ，互联网数据中心) 的建设； 2 基本网络服务建设：包括电子邮件、网络存储、网络计费、域名服务等； 3 综合信息系统建设：建立一个“北工大综合信息标准数据库”，以教育部 部颁标准为依据，创建一套北工大校园信息建设的数据标准，以规范校内信息交 流，以及与校外合作单位及上级管理单位的信息交换。同时支持建立一套北工大 数字校园决策支持系统，开展校级综合查询应用的开展；建立一套数据交换机制， 实现统一标准下的教务、人员、后勤等校园管理信息的交流机制，实现自动化的 信息交换方式，规范各业务系统之间的数据一致。 4 管理信息系统的建设：目前正在建设或将来需要建设的职能部门的管理信 息系统； 5 校园一卡通建设：包括校内金融结算系统，卡务管理系统，一卡通身份识 别系统； 6 统一身份认证：提供全校师生的统一身份认证； 7 学校门户建设：面向互联网提供全校综合信息服务的统- - 户。 其中本人参与了综合信息系统从需求分析、系统框架设计、技术方案选定以 及数据库设计的过程，目前该项目仍在进行当中，已开始了详细设计和实现。由 于在从事项目前期需求分析阶段的工作时，项目组遇到过很多的问题和困难，我 希望将这些问题进行分析和总结，并提出自己对问题的解决思路，以此作为我研 究生阶段主要的研究课题以及毕业论文的主要内容。 1 3 课题主要研究内容及目标 本课题主要针对目前需求工程领域中比较突出的理论与实践脱节的问题，从 定义需求工程过程的角度，提出解决该问题的一个思路。并初步提出了如何定义 北京工业大学工学硕士学位论文 需求工程过程的方法，即建立最抽象的需求工程过程模型，根据组织和项目的特 点剪裁模型，得到适合某个特定项目的需求工程过程，以便指导需求工程的实施。 因此，本课题的最主要研究目标是建立一个抽象的需求工程过程模型，以次 作为定义特定项目的需求工程过程的基础。 1 4 本文的组织 本文论述的内容是这样安排的。我们首先在第2 章中明确需求以及需求工程 的含义和内容，并简单介绍需求工程的研究现状和存在的问题。紧接着我们在第 3 章巾以数字工大综合信息系统的需求工程实旌过程为例，分析需求工程中经常 出现的问题，并给出解决的建议。第3 章实际的目的是要引出“问题背后的问题”， 即缺乏过程的指导。那么，在第4 章中我们就来讨论需求工程过程的相关内容， 包括：含义、作用、成熟度等概念。在对需求工程过程有了初步认识之后，我们 在第5 章提出一个初步的需求工程过程模型。最后对全文进行个总结，并提出 有待进一步研究的问题。 第2 章需求工程概述 第2 章需求工程概述 需求工程的概念一经提出，相关的研究便如火如荼的展开了。经过近2 0 年 的研究，需求3 - 程的理论逐步完善起来，其中最大的收获莫过于引起了更多人对 需求相关问题的关注。 2 1 需求的含义 2 1 1 需求的定义 “需求”这个概念并无一个明确的定义，它包含着多个层次；不同层次的需 求从不同角度在不同程度上反映着细节问题。1 i e e e 软件工程标准词汇表( 1 9 9 7 年) 中定义“需求”“1 为； ( 1 ) 用户解决问题或达到目标所需的条件或能力； ( 2 ) 系统或系统部件要满足合同、标准、规范或其它正式文档所需具有的 条件或能力； ( 3 ) 一种反映上面( 1 ) 或( 2 ) 所述的条件或能力的文档说明。 这个定义包括从用户角度( 系统的外部行为) ，以及从开发者角度( 一些内 部特性) 来阐述“需求”。 此外还有几种定义，对“需求”这个概念进行了解释： 从系统外部能发现系统所具有的满足于用户的特点、功能及属性等( 需求分 析专家a l a nd a v i s1 9 9 3 ) ； 用户所需要的并能触发一个程序或系统开发工作的说明( j o n e s1 9 9 4 ) “。； 指明必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开 发过程中对系统的约束( s o m m e r v i l i ea n ds a w y e r 1 9 9 7 ) “1 。 实际上，真正的“需求”存在于人们的脑海中，任何文档形式的需求仅仅是 一个模型、一种叙述或描述而已。也正是因为如此，软件开发者往往容易忽视这 个问题，想当然将自己对“需求”的理解强加于用户之上；而用户由于不熟悉信 息技术，可能提出非常含糊的“需求”；双方的差异不可避免地产生，这对软件 的开发有相当大的负面影响，甚至最终导致软件开发的失败。 北京工业大学工学硕士学位论文 因此我们需要特别注意：在软件项目的起始阶段，开发者与客户在对“需求” 这一概念的理解上务必达成共识，从而为项目的顺利进行奠定一个良好的基础。 2 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 ) ：定义了开发人员必须实现的软件功 能，使得用户能完成他们的任务，从而满足了业务需求。 软件需求各组成部分之间的关系如图2 1 所示。 图2 - 1 软件需求各组成部分之间的关系 f i g 2 - 1c o m p o s i t i o no fs o f t w a r er e q u i r e m e n t 业务需求由管理人员或市场分折人员确定。所有的用户需求必须与业务需求 一致。用户需求使需求分析者能从中总结出功能需求，以满足用户对产品的要求， 第2 章需求1 程概述 从而完成其任务；而开发人员则根据功能需求来设计软件以实现必须的功能。 功能需求充分描述了软件系统所应具有的外部行为，应在软件需求规格说明 ( s o f t w a r er e q u i r e m e n ts p e c i f i c a t i o n ，s r s ) 中加以说明。软件需求规格说 明在开发、测试、质量保证、项目管理以及相关项目活动中都起着重要的作用。 非功能需求作为功能需求的补充，描述了系统展现给用户的行为和执行的操 作等，也应包括在软件需求规格说明中。它包括产品必须遵从的标准、规范和合 约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓 约束是指开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对 产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都 极为重要。 需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些 没有关系，它关注的是如何充分的说明想要开发的软件或系统。 当然，软件项目也有其它方面的需求，如开发环境需求或发布产品及移植到 支撑环境的需求等等。 2 1 3 需求的特点 2 1 3 1 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实 现这些功能所需的全部必要信息。 2 1 3 2 正确性 每一项需求都必须准确地描述要开发的功能。若功能需求与相应的高层系统 需求相抵触，就是不正确的：只有用户代表才能确定用户需求的正确性。这就是 为什么一定要有用户积极参与的原因。 2 1 3 3 可行性 每一项需求在已知系统和环境的限制范围内必须是可以实施的。为避免不可 北京工业大学工学硕士学位论文 行的需求，最好在获取需求过程中，始终有一位软件开发小组的成员与需求分析 人员或市场人员在一起工作，由他负责检查技术的可行性。 2 1 3 4 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。 记录需求的必要性体现在使每一项需求都能回溯至某项客户的输入，如使用案例 或别的来源。 2 1 3 5 划分优先级 给每一项需求、特性或使用案例分配一个给定的优先级，以指明它在特定产 品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在协调项 目进度和成本时就失去了控制的自由度。 2 1 3 6 无二义性 无二义性，或者无歧义，是指对所有的需求说明都只有一个明确的统一的解 释。由于自然语言极易导致二义性，所以尽量把每一项需求用简洁明了的用户语 言表达出来。避免二义性的有效方法包括对需求文档的正规审查、编写测试用例、 开发原型、设计特定的方案脚本，或者采用形式化的规格说明。 2 1 3 7 一致性 一致性是指不同层次的需求，如：功能需求与用户需求或高层( 系统，业务) 需求之间不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番 调查研究，才能知道某一项需求是否确实正确。 2 1 3 8 可验证性 检查一下每一项需求是否能通过设计测试用例或其它的验证方法来确定产 品是否确实按需求实现了。如果需求是不可验证的，那么判断其实施是否正确就 成了主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求也是 第2 章需求上程概述 不可验证的。 2 1 3 9 可修改性 在需求变更时应该修订s r s 并维护每一个需求变更历史记录。这就要求每一 项需求要独立做标记，并与别的需求区别开来，从而无二义性。每一项需求只应 在s r s 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相 互参照列表方法将使软件需求规格说明更容易修改。 2 1 3 1 0 可跟踪i 生 应该能够在每一项软件需求与它的来源以及设计元素、源代码、测试用例之 间建立起链接，以方便需求变更时能够迅速确定其他需要修改的内容，从而使得 需求更容易维护。 2 2 需求工程的含义 2 2 1 需求工程的出现 对于计算机软件而言，软件开发方与软件客户方是贯穿软件整个生命周期的 两个最基本的要素。无论软件的规划、开发、测试，还是软件的使用、维护、废 弃，都需要二者不同程度的参与。正是由于二者自始至终的相互制约、相互合作， 才推动着整个计算机软件产业不断地向前发展。其中，需求是二者合作的基石和 关键所在。 在计算机软件发展的初期，软件规模不大，软件开发所关注的是代码编写， 需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其 第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过 程中越来越重要，直接关系到软件成功与否。人们逐渐认识到需求活动不再仅限 于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。上世纪8 0 年代中 期，作为软件工程的子领域，需求工程的概念正式形成。 如果说软件工程概念的形成是解决软件危机的必然结果，那么其子工程一一 北京工业大学工学硕士学位论文 需求工程的出现才真正体现出软件产品不同于其它产品的一个特性用户参 与整个产品过程的重要性。 因此，进入上世纪9 0 年代以来，需求工程自然成为计算机软件研究的热点 之一。 2 2 2 需求工程概述 目前”需求工程”还没有标准的定义，一般认为需求工程是指应用已证实有效 的原理、技术和方法，描述目标系统的外部特征和相关约束，从而确定客户需求， 帮助分析人员理解目标系统的一门学科：它通过合适的工具和记号系统地描述待 开发系统及其行为特征和相关约束，形成需求文档；并对用户不断变化的需求演 进给予支持。 需求工程可分为系统需求工程( 如果是针对由软硬件共同组成的整个系统) 和软件需求工程( 如果仅是专门针对纯软件部分) 。软件需求工程是一门分析并 记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子 系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究，把这些系 统需求转换成软件的需求描述和一些性能参数。本文以下如无特别说明，需求工 程主要是指软件需求工程。 需求工程是软件工程不可分割的重要组成部分，它贯穿整个软件工程的各个 阶段，不可能把两者完全分割开来，之所以专门提出“需求工程”的概念，完全 是为了在过程中更专注于需求的开发和管理。 2 23 需求工程的重要性 虽然需求工程的重要性不容质疑，然而并非所有软件开发者都能清楚地意识 到需求工程中的缺陷会给软件项目带来怎样的风险。 目前，尽管软件项目开发的相关知识不断扩充、技术不断进步、经验不断丰 富、可利用的工具也在不断增多，但仍然有相当比例的软件项目失败。s t a n d i s h g r o u d 研究显示大约3 1 的项目在完成之前被取消，5 2 7 的项目的成本是原来预 算成本的1 8 9 。究其原因，常常是因为在项目开始阶段没有正确的定义需求， 或是随着项目的展开没有正确的管理需求。数据显示虽然有些系统失败的原因是 第2 章需求工程概述 因为编程马虎造成的；但大量研究表明：不良的需求管理可能是项目失败的最主 要原因。s t a n d i s hg r o u p 公司( 1 9 9 4 ) 研究特别指出三种最经常提到的使项目 “遇到困难”的因素： 1 缺乏用户输入：占所有项目的1 3 ； 2 不完整的需求和规格说明：占所有项目的1 2 ； 3 不断改变的需求和规格说明：占所有项目的1 2 ； 由此可见，需求错误是项目开发中最常见的一类错误。 e s p i t i ( e u r o p e a ns o f t w a r ep r o c e s si m p r o v e m e n tt r a i n i n gi n i t i a t i v e ) 做了一次调查( 1 9 9 5 ) 已确定软件开发过程中哪些才是相对重要的软件问题“】， 调查结果如图2 2 所示。大约半数的被调查者回答的两个最“主要问题”是： 1 需求规格说明； 2 管理客户需求。 相对而言，编码“不是问题”。 图2 - 2 最大的软件开发问题分类 f i g 2 2m a i np r o b l e m so f s o f t w a r ed e v e l o p m e n t 另外，需求错误也是修复时花费最昂贵的错误。很多大公司如：i b m 、l i p 等 都在公司内部进行过一些研究，对修复项目生命周期的各个阶段错误的成本进行 了度量和计算。尽管这些研究是相互独立的，但它们都无一例外的得到相同的结 论m ：如图2 - 3 所示，如果把在编码阶段修复编码错误所需要的花费用一个成本 北京工业大学工学硕士学位论文 单元表示的话，那么需求阶段的错误在编码阶段修复的成本将是单元成本的5 到 1 0 倍( 1 。、。) ，如果到了维护阶段才发现并修复该需求阶段的错误，成本将超 过单元成本的1 0 0 倍。可谓失之毫厘，谬以千里。 修受的相对成本 图2 - 3 在生命周期不同阶段修复缺陷的相对成本 f i g2 3c o s to f r e p a i r d e f e c td u r i n gl i f e c y c l e sd i f f e r e n tp h a s e 也许有人会说像上面这样的错误不会经常发生，但事实恰恰相反。另一项对 t r m 公司所做的软件项目的分析结果表明：所有被检测出来的错误中，5 4 是在 编码和单元测试阶段以后才被发现的；而更糟糕的是此类错误中的绝大部分( 占 4 5 ) 是在需求和设计阶段发生的，编码阶段的错误只占9 ( l e f f i n g w e l l 1 9 9 7 ) 。 研究表明：修复需求错误将消耗掉整个项目预算的2 5 4 0 “1 。 从上面这些研究成果可以看出：需求错误是软件项目最常见的错误；需求错 误是修复起来花费最昂贵的错误。 凼此，需求工程在整个软件生命周期中是非常重要的，也是非常基础的。做 好需求的分析和管理，既可以减少软件开发中的错误，还可以减少修复错误的费 用，从而大大降低软件开发成本，缩短软件开发时间。 第2 章需求工程概述 2 3 需求工程包含的内容 2 3 1 需求工程层次分解 需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终 在验证的基础上冻结需求。上世纪8 0 年代，h e r bk r a s n e r 定义了需求工程的五 阶段生命周期0 1 ：需求定义和分析；需求决策：形成需求规格；需求实现与验证； 需求演进管理。之后又有m a t t h i a s 和k l a u sp o h l 提出了三阶段周期的说法：获 取、表示和验证“1 。 早期的需求工程研究主要侧重于需求的开发以及各个开发活动中使用的方 法。近年来，人们逐渐认识到如何对需求以及需求开发活动进行更好的管理也是 非常重要和值得研究的内容。c m m 中就特别把需求管理作为其可重复级( c m m 二 级) 中的一个关键过程域( k e yp r o c e s sa r e a s ，k p a ) 。需求管理是一种与需求 开发过程并行的需求工程活动，它支持系统的需求演进，如需求变化和可跟踪性 等问题。 综合各种观点，目前业内普遍认为把整个需求工程研究领域划分为需求开发 和需求管理两大部分更为合适，如图2 4 所示“1 。 图2 4 需求工程层次分解示意图 f i g 2 - 4d e c o m p o s i t i o no fr e q u i r e m e n te n g i n e e r i n g 需求开发和需求管理又各自包含一系列的活动。需求开发可进一步分为：需 求的获取( e l i e i t a t i o n ) 、分析( a n a l y s i s ) 、规格说明( s p e c i f i c a t i o n ) 和验 北京工业大学工学硕士学位论文 证( v e r i f i c a t i o n ) 四个阶段。需求管理又包含：变更控制、版本控制、需求跟 踪和需求状态跟踪四类主要活动。下面简要介绍各类活动的主要任务。 2 。3 2 需求开发 需求获取 在2 1 2 中我们介绍了需求的组成部分以及各部分之间的层次关系。在项目 中，我们需要在不同的时间用不同的方式从不同的来源获取诸如业务、用户、功 能以及非功能需求。 它涉及到一系列的相关活动，例如：确定项目的视图和范围；将用户分类并 归纳各自的特点；选择每类用户的代表；用户代表确认使用案例；分析业务流程： 确定质量属性和其他非功能需求；获取可重用需求等。 需求分析 提炼、分析和仔细审查己收集到的需求，以确保所有的涉众( s t a k e h o l d e r ， 受系统影w i g j 和对系统有直接或问接影响的人，例如：客户、用户、开发人员、市 场推广人员、监管机构等) 都明白其含义并找出其中的错误、遗漏或其它不足的 地方。 需求分析的目的在于开发出高质量和具体的需求，这样就能做出实用的项目 估算并可以进行设计、构造和测试。通常，需求是由多种形式来描述的，如同时 用文本和图形来描述。分析这些不同的视图可以揭示出一些更深层次的问题，这 是单一视图无法提供的( d a v i s1 9 9 5 ) 。1 。分析还包括与客户交流来澄清某些易 混淆的问题，并明确需求的优先级。其目的是确保所有涉众尽早地对项目达成共 识并对将来的产品有个统一而清晰的认识。 需求分析涉及到的活动包括：明确与外部实体的关系模型；建立用户接口原 型；分析需求可行性：确定需求优先级；建立图形分析模型如：数据流图、实体 关系图、状态变换图、对话框图、对象类及交互作用图；建立数据字典等等 需求规格说明 必须用统一的方式将需求编写成可视文档。业务需求要写成项目视图和范围 文档。用户需求要用一种标准的使用案例模板编写成文档。而软件需求规格说明 ( s r s ) 则包含了软件的功能需求和非功能需求( 业务需求和用户需求也可以作 第2 章需求工程概述 为s r s 的一部分) 。你必须为s r s 建立标准的书写规范以确保s r s 的统一风格。 需求规格说明涉及到的活动包括：定义标准的s r s 文档；指明需求的来源： 为每一项需求加上唯一的标识；记录业务规则：建立需求跟踪矩阵等等。 需求验证 验证是为了确保需求说明准确、完整地表达必要的质量特点。当你阅读软件 需求规格说明时，可能觉得需求是对的，但实现时，却很可能会出现问题。当以 需求说明为依据编写测试用例时，你可能会发现说明中的二义性。而所有这些都 必须改善，因为需求说明要作为设计和最终系统验证的依据。客户的参与在需求 验证中占有重要的位置。 需求验证涉及到的活动包括：审查需求文档；以需求为依据编写测试用例： 编写用户手册：确定测试合格的标准等等。 2 3 3 需求管理 变更控制 所有的需求变更必须遵循统一的变更控制过程。当接收到新的变更请求后， 下一步是评估该请求的技术可行性、代价、业务需求和资源限制。需要针对该请 求进行系统影响分析、风险分析、危害分析及其它评估。从这些分析能够看出接 受变更所带来的潜在影响，以及拒绝变更对业务和技术的影响。制定决策的人决 定是采纳或还是拒绝该变更请求。之后对每个采纳的需求变更设定一个优先级或 变更实现日期。将变更决定传达给所有涉及到的小组成员，相关人员修改相应的 工作产品，如软件需求规格说明文档、需求数据库、设计模型、用户界面、代码、 测试文档、用户文档等等。 版本控制 版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确 定。必须清楚地将需求变更写成文档，并及时通知到项目开发所涉及的人员。为 尽量减少冲突和误传，应仅允许特定的人来更新需求。 每一个需求文档应该包括一个文档变更履历，包括己变更的内容、变更日期、 变更人的姓名以及变更的原因。 北京工业大学工学硕士学位论文 版本控制的最简单方法是根据标准为每一次修改过的软件需求规格说明加 上版本号。例如第一版版本号为1 o ，经过次小的改动后，版本号升为1 1 ， 经过一次大的改动后，版本号升为2 0 。 更高级别的版本控制可以使用版本控制工具，例如c v s 来存储需求文档。而 最有力的方法莫过于用一个商业需求管理工具的数据库来存储需求，例如 r a t i o n a lr e q u i s i r e p r o 。 需求跟踪 c m m ( c a p a b i l i t ym a t u r i t ym o d e l ) 的第三层次要求具备需求跟踪能力 ( c m u s e i1 9 9 5 ) 。需求跟踪是为了保持软件工作产品，如：软件计划，软件需 求，软件设计，代码，测试计划等之间的一致性。 需求跟踪包括编制每个需求同系统元素之间的联系文档。这些元素包括别的 需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。跟踪 信息使得分析需求变更带来的影响变得十分方便，有利于确认和评估实现某个建 议的需求变更所必须做的工作。 需求状态跟踪 在整个开发过程中，跟踪每个需求的状态是需求管理的一个重要方面。如果 周期性地报告各需求状态类别在整个需求中所占的百分比将会改进项目的监控 工作。要使跟踪需求状态工作正常进行，你需要指定允许修改状态信息的人员和 每个状态变更应满足的条件。一些建议的需求状态见表2 - 1 ”1 。 表2 一l 建议的需求状态表 t a b2 - lp r o p o s i t i o n a ls t a t eo fr e q u i r e m e n t 状忠憾 定义 巴建议 渣需求已槌有权涟出衙求的人建娃 已m t 稚 媛崭水已城仆析估汁了其对瓶吲采f 部计眺膨响e 包插战盎 h 刘项目填糸帮井 的千隗，巴用一十确宅昨产研一版奉弓或剖翘编号升耐到辅戈的齄线巾般件开搜 脚融已| 叫盎蜜风涟颓篇堪 已寓地 二擞现衙，抟代码的没汁+ 编， 和单琵剖试 匕蛤1 l 他 所进辟晌直谊已粒征丁驾现的前求，例如袒l i 城们榆剽甫奇披篱求0 e 蹿与棚 l 遗用扫【删精荫衙求靴芷擞认为完成 竺型堕 | ：| ：型竺兰兰圣盐兰垡：! = 型墼：坚璺塑= 工竖型翌翌翌苎兰苎业! 盗重鎏生丝一 第2 章需求工程概述 2 3 4 需求开发与需求管理的关系 需求开发和需求管理之间的界限及关系如图2 - 5 所示。3 。 市妫 霄户瓣臻 鬻| 求 砸目环境 图2 5 需求开发与需求管理的界限 f i g 2 - 5b o u n d a r y b e t w e e nr e q u i r e m e n t d e v e l o p m e n t a n d r e q u i r e m e n tm a n a g e m e n t 需求开发侧重于软件产品中需求的收集、评价、编写文档等活动。需求开发 活动主要包括：确定产品所期望的用户类；获取每个用户类的需求；了解实际用 户任务和目标以及这些任务所支持的业务需求；分析源于用户的信息以区别用户 任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统 级的需求分为几个子系统，并将需求中的一部分分配给软件组件；了解相关质量 属性的重要性；商讨实施优先级的划分；将所收集的用户需求编写成规格说明和 模型；评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开 发小组接受说明之前将问题都弄清楚。 需求管理则侧重于“建立并维护在软件工程中同客户达成的契约”( c m u s e i 1 9 9 5 ) 。这种契约都包含在编写的需求规格说明与模型中。客户的接受仅是需求 成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。通常 的需求管理活动包括：定义需求基线；评审提出的需求变更、评估每项变更的可 能影响从而决定是否实旋它；以一种可控制的方式将需求变更融入到项目中：使 当前的项目计划与需求一致；估计变更需求所产生影响并在此基础上协商新的承 1 7 - 北京工业大学工学硕士学位论文 诺( 约定) ；让每项需求都能与其对应的设计、源代码和测试用例联系起来以实 现跟踪；在整个项目过程中跟踪需求状态及其变更情况。 2 4 需求工程