（计算机应用技术专业论文）关于改良需求工程过程模型的研究.pdf

摘要 摘要 获得准确的需求是软件项目成功的基础。自软件危机出现以来，人们意识到 使用工程化的方法从事软件开发可以大大提高软件开发的质量，于是软件工程的 概念产生。然而经调查，仍旧有三分之一的项目中途搁浅，一半以上的项目实际 成本是预算的近两倍。研究发现，导致这种现象的最主要原因大都来自需求分析 阶段。 为解决需求问题，需求工程的概念被正式提出，相关研究也随之进行。经过 近二十年的研究，需求工程在方法、技术、工具等各个方面都逐渐成熟。j a m e s r o b e r t s o n 和s u z a n n er o b e r t s o n 夫妇共同开发的v o l e r e 需求过程模型就是这些 成果的一个集中展示。v o l e r e 需求过程模型包含了r o b e r t s o n 夫妇在多年帮助 客户改进需求的过程中积累的经验，同时也融入了很多在需求过程中有效的解决 方法。v o l e r e 需求过程模型向我们展示了一个经过业界检验的需求收集和验 证过程。 但是建立过程模型并不是我们追求的目标，我们的目标是要使需求双方在利 用过程模型指导建立的需求过程中，能够对需求达成一致的理解。对于某些特定 的使用者根据模型建立需求过程时，v o l e i 也模型会表现出了一些局限性。对 于软件组织需求过程成熟度低，客户缺少需求过程经验的情况，一种可能的办法 是在需求过程中引入一种以循环校验的方式构建原型架构，从而逐步产生高质量 的最终需求。这种方法在实际项目中使用后，得到了良好的效果。 本文主要描述了一个新的需求过程模型，它引入了循环构建原型架构、逐步 逼近需求本质的思想，并使用了很多从v o l e r e 需求过程模型继承并改造而形 成的思想和方法。新过程模型经过实践验证和持续改进后，一定可以指导需求过 程经验与能力不足的软件组织进行良好的需求收集与分析工作。 关键宇需求工程过程：需求过程模型；原型架构 北京工业大学工学硕士学位论文 a b s t r a c t t h eb a s eo fs n c c e s si st h a tt h es o f t w a r eo r g a n i z a t i o nc a no b t a i n e de x a c t r e q u i r e m e n t s s i n c et h es o f t w a r ec r i s e sc a m ef o r t h 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 y w o u l db ei m p r o v e db yu s i n gt h em e t h o do fe n g i n e e r i n g ，a n dt h e nt h ec o n c e p to f s o f t w a r ee n g i n e e r i n g ( 嘲c a m ei n t ob e i n g b u t ，a ni n v e s t i g a t i o ns h o w e dt h a to n e t h i r do ft h ev r o i 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 ep r o j e c t s a 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 e h i n gr e s u l ts h o w st h a t t h em o s t i 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 l em o s t l yf r o mt h er e q u i r e m e n t sp h a s e 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 yb r o u g h tf o r w a r d a 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 te v e r ya s p e c ts u c ha s m e t h o d ，t e c h n o l o g y a n dt o o l sa f t e r t w e n t yy e a r s r e s e a r c h t h e v o l e r e r e q u i r e m e n t sp r o c e s sm o d e lt h a tw a si n v e n t e db yt h ec o u p l eo fj a m e sr o b e r t s o na n d s u z a n n er o b e r t s o ni so n ei n s t a n c eo u to fm a n ya b o v e i tt a u g h tb ym a n yp r a c t i c a l e x p e r i e n c e st h a tw e r eg o tt o g e t h e ri nt h ep r o c e s so fh e l p i n gc l i e n ti m p r o v et h e i r r e q u i r e m e n t sp r o c e s sb yt h ec o u p l eo fr o b e r t s o nf o rm a n yy e a r s ，a n di n c l u d e dm a n y e f f e c t i v e l ym e t h o d s t h a tw e r eu s e di n r e q u i r e m e n t sp r o c e s s t h ev o l e r e r e q u i r e m e n t sp r o c e s sm o d e ls e to u tav e r i f i e dp r o c e s st h a tw a su s e dt oc o l l e c ta n d c h e c kr e q u i r e m e n t s n e v e r t h e l e s s ，i ti s n tt h ef i n a lp u r p o s et ou st h a tf o u n do n er e q u i r e m e n t sp r o c e s s o u r p u r p o s ei sm a k i n gt h eb o t hs i d e so fr e q u i r e m e n th a v e h a dc o m m o n c o m p r e h e n s i o na b o u tr e q u i r e m e n ti n t h er e q u i r e m e n t sp r o c e s st h a tw a sf o u n d e d a c c o r d i n ga st h ep r o c e s sm o d e l t h ev o l e r em o d e ls h o w ss o m el i m i t a t i o n sw h e n s o m es p e c i a lu s e r sf o u n dr e q u i r e m e n t sp r o c e s sa c c o r d i n g 弱t h em o d e l f o rs o m e s o f t w a r eo r g a n i z a t i o n sw i t hl o wp r o c e s sc a p a b i l i t ya n dc l i e n t sw i mf e we x p e r i e n c e s o f r e q u i r e m e n t sp r o c e s s ，o n ep o s s i b l em e t h o dc o u l di m p r o v et h er e q u i r e m e n t sq u a l i t y t h a tw em a k ep r o t o t y p eo fa r c h i t e c t u r ec i r c u l a r l ya n dp r o d u c er e q u i r e m e n t ss t e pb y s t e p w eh a v eh a dag r e a te f f e c tw h i l ew eu s e dt h i sm e t h o di np r a c t i c a lp r o j e c t t h em a j o ro b j e c ti n t h i st h e s i si st h en e wr e q u i r e m e n t sp r o c e s st h a ts h o w st h e i f a b s t r a c t i d e am a n n gp r o t o t y p eo fa r c h i t e c t u r ec i r c u l a r l ya n dp r o d u c i n gr e q u i r e m e n t ss t e pb y s t e pa n di n c l u d e sm a n yi d e a sa n dm e t h o d st h a tw e r ei n h e r i t e df r o mt h ev o l e r e r e q u i r e m e n t sp r o c e s sm o d e l s o f t w a r eo r g a n i z a t i o nw i t hl o wp r o c e s sc a p a b i l i t yc o u l d c o l l e c ta n da n a l y z ee f f e c t i v e l ya c c o r d i n ga st h en e wp r o c e s sm o d e la f t e rt h em o d e li s v e r i f i e db yp r a c t i c a lp r o j e c ta n dp e r s i s t i n gi m p r o v 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 gp r o c e s s ；r e q u i r e m e n t sp r o c e s sm o d e l ： p r o t o t y p eo f a r c h i t e c t u r e 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同t 作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 签名：开期 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 签名： 导师签名：日期 第1 章绪论 1 1 课题研究背景 第1 章绪论 随着信息时代的飞速发展，各行各业对计算机信息系统的需求量猛增，同时 对信息系统的要求也越来越高：系统越来越复杂：规模也越来越大。并且，随着 企业业务的发展以及业务流程的重组，系统需求变更己成必然。在这样的环境下， 人们对软件产品的质量提出了更高的要求。 然而，软件危机持续了近4 0 年之久，至今仍无法得以很好地解决。经常出 现用户对“己完成”的系统不满意，软件产品b u g 不断，频繁的打补丁，甚至项 目失败搁浅等情况。究其原因，除了与软件本身所具有的复杂性的特点有关之外， 缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关 键的原因。 因此，人们逐渐意识到以工程化的原则和方法组织软件开发工作是解决软件 危机的一个重要出路，它可能不是能够解决一切问题的“银弹”但它是对软件 生产方式的一种变革，这种变革的方向最终必然会使软件的生产成为高质量的过 程。 需求分析是软件生命周期的第一个阶段，并贯穿于整个软件生命周期，其重 要性越来越突出。到二十世纪8 0 年代中期，逐步形成了软件工程的予领域 需求工程。进入9 0 年代后，需求工程成为软件界研究的热点之一。 有关需求工程的研究国外起步较早，也有一些很好的理论以及理论指导下的 方法和工具。国内在这方面的研究才刚刚起步，很多企业或软件开发商还没有认 识到需求工程的重要性。 在需求工程的实践过程中，通常我们会得到一些理论性的指导。但是这些理 论要么是对部分实际问题的简化，缺乏完整性，能起到的指导作用有限：要么是 理论过于抽象、庞大和复杂，让人感觉无从下手。于是，需求工程研究现状中出 现了一个明显的不足，即理论研究与实际应用的脱节。要获得需求工程的进一步 突破，改善需求工程的开发质量和效率，需要有识之士共同探索更为有效的解决 北京t 业大学工学颀i 。学位论文 途径和方法，以缩小理论与实践之间的距离，使研究出来的理论、系统或模型切 实满足实际应用的需要。 在建立一个实际可操作的需求过程方面，j a m e sr o b e r t s o n 和s u z a n n e r o b e r t s o n 夫妇作出了非常大的贡献。他们共同开发的一个需求工程过程模型， 即v o l e r e 需求过程模型。它既是r o b e r t s o n 夫妇在多年帮助客户改进需求的过 程中积累而得的产物，同时也融入了很多在需求过程中有效的解决方法。它向我 们展示了一个经过业界检验的需求收集和验证过程。 1 2 课题主要研究内容和目标 尽管如著名的t o md e m a r c o 所说的，v o l e r e 需求过程模型的建立，在需 求过程领域里引入了科学的开端，而在此之前，这个领域有手工艺所主宰。但是 由于v o l e r e 模型存在着过程环节多而且复杂、参与过程的角色问关系不明确、 各个过程环节之间缺乏在时间上的联系以及缺少实际可操作的需求分析和检验 的手段等问题，使得它在实际工程环境中使用时会产生局限性。特别是对于国内 大多数中小型软件开发组织，他们愿意花费巨资用于修改或调整没有很好规定需 求的产品，但却不愿意投资相对很少的费用来使需求从一开始就正确。这些软件 组织缺乏软件需求过程方面的经验。同时，他们面对国内的大量软件客户也缺少 或根本没有信息化建设的经验，在需求收集和分析过程中无法给与有效地配合。 因此在这种情况下，直接依据v o l e r e 模型建立需求过程必然对软件客户和软 件开发组织造成困难和混乱。 本课题主要就是针对于上面提出的这种特定的实际工程环境，论证v o l e r e 模型产生局限性的原因并加以改良。同时，根据国内、外的理论总结，以及根据 实践经验，论证并引入了制作原型架构的方法，建立一个新的需求过程模型。这 个新的需求过程模型以原型架构为核心，以迭代的方式逐步产生最精确的需求定 义。 新的需求过程模型是基于特定使用环境开发出来的。因此，如果说v o l e r e 需求过程模型是宏观层次的需求过程工作的指导，那么本课题中生成的新需求过 程就是一个更贴近实际应用的过程模型，它更加适于国内大多数缺乏需求过程经 验的软件组织使用，可以直接指导软件组织进行有效地需求过程活动，产生准确 第1 章绪论 的需求定义，从而提升这些软件组织生产软件产品的质量。 1 3 课题依托的项目背景 本课题的研究依托于数字工大综合信息平台项目，并从项目的工作中获得实 践经验。下面对该项目的相关情况做简单介绍。 随着北京工业大学学校信息化工作的进一步推动，校园网上的信息越来越 多，应用也越来越多，迫切需要对学校的各种资源进行统一管理，对各层次人员 提供信息的集成化服务和面向用户的“个性化”服务；迫切需要统一的用户认证 机制并建立一个统一的电子身份体系；随着网络技术的发展和网上应用的不断增 多，j n t e r n e t 上原有的安全隐患也不断暴露出来，建立一个覆盖全校的网络安 全体系也成为迫切任务。 “数字工大”就是试图用层次化、整体的观点来规划、实施学校的信息化建 设，为北京工业大学教育信息化确定一个清晰的目标。“数字工大”的建设将对 学校所有信息资源进行统一的、科学的组织与管理，对校园网上的信息进行更好 的组织和分类，让用户在网上快速发现自己需求的信息，为师生提供优质的网上 信息交流环境，让管理人员科学地、规范地管理自己的数据，并将这些信息以最 有效的方式、更方便地发布，提供给用户服务。 数字工大主要的建设内容包括以下几个层次： 1 网络基础设施建设 2 基本网络服务建设：包括电子邮件、网络存储、网络计费、域名服务等： 3 综合信息平台建设：建立一个“北工大综合信息标准数据库”，以教育部 部颁标准为依据，创建一套北工大校园信息建设的数据标准，以规范校内信息交 流，以及与校外合作单位及上级管理单位的信息交换。同时支持建立一套北工大 数字校园决策支持系统，开展校级综合查询应用的丌展；建立一套数据交换机制， 实现统一标准下的教务、人员、后勤等校园管理信息的交流机制，实现自动化的 信息交换方式，规范各业务系统之| 、日j 的数据一致。 4 管理信息系统的建设：目前正在建设或将来需要建设的职能部门的管理信 息系统； 5 校园一卡通建设：包括校内金融结算系统，卡务管理系统，一卡通身份识 北京t 业人学工学硕上学位论文 别系统； 6 统一身份认证：提供全校师生的统一身份认证； 7 学校门户建设：面向互联网提供全校综合信息服务的统一门户。 其中本人参与了综合信息系统从需求分析、系统框架设计、技术方案选定以及详 细设计、实现和测试的工作。 1 4 本文的组织 本文的结构是按照提出问题、分析问题、解决问题的顺序进行论述的。首先 在第2 章简要介绍了一些需求工程过程涉及到的理论和概念，而后在第3 章介绍 了一个经典的需求过程模型，并分析了此模型在特定环境中应用的局限性。本论 文的核心思想集中在第4 章中描述，本章中描述了一个对v o l e r e 需求过程模 型改良后的需求过程模型。新的需求过程模型按照模型汇总介绍、模型子过程和 每个子过程包含的活动的层次，并以被执行的时间上的先后顺序进行描述，也就 是说对模型的每个层次的描述都是按照时间的先后顺序进行的。在第5 章描述了 新的过程模型在实际项目中使用得到的经验，最后对全文作了总结，并提出了课 题今后的可能发展方向。 第2 章需求： 程过程概述 第2 章需求工程过程概述 2 1 需求的含义 “需求”这个概念并无一个明确的定义，它包含着多个层次；不同层次的 需求从不同角度在不同程度上反映着细节问题。 i e e e 软件工程标准词汇表( 1 9 9 7 年) 中定义“需求”为； ( 1 ) 用户解决问题或达到目标所需的条件或能力； ( 2 ) 系统或系统部件要满足合同、标准、规范或其它正式文档所需具有的 条件或能力： ( 3 ) 一种反映上面( 1 ) 或( 2 ) 所述的条件或能力的文档说明。 这个定义包括从用户角度( 系统的外部行为) ，以及从开发者角度( 一些内 部特性) 来阐述“需求”。 此外还有几种定义，对“需求”这个概念进行了解释： 从系统外部能发现系统所具有的满足于用户的特点、功能及属性等( 需求分 析专家a l a nd a y is1 9 9 3 ) ； 用户所需要的并能触发一个程序或系统开发工作的说明( j o n e s1 9 9 4 ) ； 指明必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开 发过程中对系统的约束( s o m m e r v i1 1 ea n ds a w y e r1 9 9 7 ) 。 实际上真正的“需求”存在于人们的脑海中，任何文档形式的需求仅仅是 一个模型、一种叙述或描述而已。也正是因为如此，软件开发者往往容易忽视这 个问题，想当然将自己对“需求”的理解强加于用户之上；而用户由于不熟悉信 息技术，可能提出非常含糊的“需求”：双方的差异不可避免地产生，这对软件 的开发有相当大的负面影响，甚至最终导致软件开发的失败。因此，需求活动在 整个软件活动中的的重要性已经越来越被人们所认识。为了使需求活动成为一个 有序、稳定、可控的活动，从而生产出高质量的需求，需求工程的概念逐渐引入 了软件工程领域。 北京工业大学工学颧：学位论文 2 2 需求工程概述 2 2 1 需求工程的含义 目前“需求工程”还没有标准的定义，一般认为需求工程是指应用已证实有 效的原理、技术和方法，描述目标系统的外部特征和相关约束，从而确定客户需 求，帮助分析人员理解目标系统的- f 3 学科：它通过合适的工具和记号系统地描 述待开发系统及其行为特征和相关约束，形成需求文档；并对用户不断变化的需 求演进给予支持。 需求工程可分为系统需求工程( 如果是针对由软硬件共同组成的整个系统) 和软件需求工程( 如果仅是专门针对纯软件部分) 。软件需求工程是一门分析并 记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子 系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究，把这些系 统需求转换成软件的需求描述和一些性能参数。本文以下如无特别说明，需求工 程主要是指软件需求工程。 需求工程是软件工程不可分割的重要组成部分，它贯穿整个软件工程的各个 阶段，不可能把两者完全分割开来，之所以专门提出“需求工程”的概念，完全 是为了在过程中更专注于需求的开发和管理。 2 2 2 需求工程的重要性 虽然需求工程的重要性不容质疑，然而并非所有软件开发者都能清楚地意识 到需求工程中的缺陷会给软件项目带来怎样的风险。 目前，尽管软件项目开发的相关知识不断扩充、技术不断进步、经验不断丰 富、可利用的工具也在不断增多，但仍然有相当比例的软件项目失败。s t a n d i s h g r o u p 研究显示大约3 1 的项目在完成之前被取消，5 2 7 的项目的成本是原来预 算成本的1 8 9 。究其原因，常常是因为在项目开始阶段没有f 确的定义需求， 或是随着项目的展开没有正确的管理需求。数据显示虽然有些系统失败的原因是 因为编程马虎造成的：但大量研究表明：不良的需求管理可能是项目失败的最主 要原因。s t a n d i s hg r o u p 公司( 1 9 9 4 ) 研究特别指出三种最经常提到的使项目 第2 章需求t 程过程概述 “遇到困难”的因素： 1 缺乏用户输入：占所有项目的1 3 ； 2 不完整的需求和规格说明：占所有项目的1 2 ： 3 不断改变的需求和规格说明：占所有项目的1 2 ； 由此可见，需求错误是项目开发中最常见的一类错误。 而且，需求错误也是修复时花费最昂贵的错误。很多大公司如：i b m 、h p 等 都在公司内部进行过一些研究，对修复项目生命周期的各个阶段错误的成本进行 了度量和计算。尽管这些研究是相互独立的，但它们都无一例外的得到相同的结 论：如图2 1 所示，如果把在编码阶段修复编码错误所需要的花费用一个成本 单元表示的话，那么需求阶段的错误在编码阶段修复的成本将是单元成本的5 到 1 0 倍，如果到了维护阶段才发现并修复该需求阶段的错误，成本将超过单元成 本的1 0 0 倍。可谓失之毫厘，缮以千里。 恬夏的相封成奉 图2 - 1 在生命周期不同阶段修复缺陷的相对成本 f i g 2 1c o s to fr e p a rd e f e c td u r i n gl a f e c y c l e sd i f f e r e n t p h a s e 也许有人会说像上面这样的错误不会经常发生，但事实恰恰相反。另一项对 t r m 公司所做的软件项目的分析结果表明：所有被检测出来的错误中，5 4 是在 编码和单元测试阶段以后才被发现的；而更糟糕的是此类错误中的绝大部分( 占 4 5 ) 是在需求和设计阶段发生的，编码阶段的错误只占9 ( l e f f i n g w e ii1 9 9 7 ) 。 研究表明：修复需求错误将消耗掉整个项目预算的2 5 。4 0 。 7 北京工业人学工学硕上学位论文 从上面这些研究成果可以看出：需求错误是软件项目最常见的错误；需求错 误是修复起来花费最昂贵的错误。 因此，需求工程在整个软件生命周期中是非常重要的，也是非常基础的。做 好需求的分析和管理，既可以减少软件丌发中的错误，还可以减少修复错误的费 用，从而大大降低软件开发成本，缩短软件开发时间。 2 3 需求工程过程的含义和现状 2 3 1 过程与软件过程 过程( p r o c e s s ) 是一个在各个领域中都非常重要且应用广泛的词语。我们 先从它的中英文定义来理解它的含义。 高级汉语词典中定义过程为：事物发展所经过的程序；阶段。这个定义强调 的是做事的步骤。 美国传统词典中定义p r o c e s s 为：as e r i e so fa c t i o n s ，c h a n g e s ，o r f u n c ti o n sb r n g i n ga b o u tar e s u l t 导致某一结果的一系列动作、变化或 功能。相比中文的定义，英文的解释更强调目的性，即导致某一结果。 在这里我们引用r u p 2 0 0 0 中对过程的定义：实现某个耳标所需的一系列顺序 相对固定的步骤。 过程具有以下一些特征： 1 过程为实现目的服务。过程的一系列事件或操作，为实现预期的目的服务， 或客观上会产生特定的结果。过程应该具有目的性，没有无目的的过程。 2 过程中事件或操作的序列对能否实现过程目的以及实现目的之效率至关 重要。实现同一个目的可以定义不同的过程，过程的好坏直接影响最终实现目的 的效率和效果。 3 过程可以分解。过程中的事件或操作可以分解成更小的过程。例如：需求 工程过程是软件过程( s o l 。t w a r ep r o c e s s ) 的一个子过程。 4 过程可以并行。复杂过程所包含的多个子过程可以同时进行。 我们定义过程为实现某个目标所需的一系列顺序相对固定的步骤。那么在软 件工程( s o f t w a r ee n g i n e e r i n g ) 中，我们的目标是高质量、低成本、高效率的 第2 章需求工程过程概述 开发软件产品，或改进现有软件产品。因此，软件过程，简言之，就是为达到软 件工程的这一目标所遵循的步骤和指南。 这里我们定义软件过程为：为高质量、低成本、高效率的开发软件产品，或 改进现有软件产品，在软件的整个生命周期中所有相关人员的相关活动的序列。 对于软件过程，除了具有上节描述的过程的特点之外，还有其他一些特点： 1 过程中事件或操作的主体是人，而且过程的设计、验证和改进主体也是人。 2 过程设计时，需要对过程的事件或操作进行取舍，抓住重点和关键，剔除 对于实现过程目的不利或效果微小的事件或操作。 3 必须对过程的结果或效果进行度量和检验，用以改进过程。 软件过程的这些特征决定了过程是需要设计、验证和不断改进的。 2 3 2 需求工程过程的含义和作用 需求工程过程是用来导出、确认和维护高质量需求产品( 如：需求文档) 的 一组结构化活动。完整的过程描述包括：要执行的活动、活动的组织或调度、活 动的负责人、活动的输入输出、支持的工具。过程不能照搬，要根据组织、项目 类型等实际情况定义。 需求工程过程的定义和实施的效果关系到需求工程的结果是否能实现其目 标。这个目标的实现程度，换句话说，需求工程产品的质量又关系到软件过程中 后续的很多技术活动( 如：测试、构建等) 和管理活动( 如：项目计划、变更控 制等) 能否顺利进行。 同软件过程一样，为实现需求工程的目标，可以定义不同的需求工程过程。 一个定义完备的需求工程过程能够帮助我们高质量、低成本、高效率的实现需求 工程的目标；相反，一个定义粗糙的过程( 甚至根本没有定义) 不只会对我们实 现目标产生阻碍，而且还会给整个项目带来灾难性的后果。 而实际情况是，很少有软件组织具备明确定义的、标准化的需求工程过程。 大多数组织只是简单的定义了过程的结果，例如：s r s ，而由参与过程的人来决 定什么时候、做什么事情、怎么做，以及需要什么信息、使用什么工具支持等等。 明确定义一个良好的、适合于组织的需求工程过程，可以指导相关人员开展工作， 并减少对某些过程活动的忽视甚至遗忘的可能性。 北京工业大学工学硕上学位论文 2 4 小结 本章介绍了需求、需求工程和需求工程过程的概念，同时强调了需求工程以 及一个好的需求工程对于生成良好需求的重要性，从而为下一章的介绍奠定了基 础。 0 第3 章v o l e r e 需求过程模型概述及问题分析 第3 章v o l e r e 需求过程模型概述及问题分析 3 1v o l e r e 模型概述 v 0 l e r e 需求过程模型是由j a m e sr o b e r t s o n 和s u z a n n er o b e r t s o n 共同开发 的一个需求工程过程模型( 简称v o l e r e 需求过程模型，或v o l e r e 模型) ， 是他们在多年帮助客户改进需求的过程中积累而得的产物。它向我们展示了一个 经过业界检验的需求收集和验证过程，如图3 1 所示。v o l e r e 模型包含了丰富 的需求过程要素，它可以指导我们正确的进行需求过程活动。下面，简要的介绍 一下v o l e r e 模型。 3 1 1 项目启动 项目启动过程主要的活动集中在启动会议上。启动会议是一个联合应用开发 会议，会议确定所有风险承担者，并使所有风险承担者的代表一起，收集足够的 事实以确保项目有一个有价值的目标，同时确保组织有能力构建和操作该产品， 而且也要取得风险承担者关于承担义务的许诺。 在项目启动过程中，有三个最为重要的部分，分别是确定风险承担者、定义 产品目标和确定工作上下文。v o l e r e 模板给出了分析风险承担者的模板，根 据模板，可以发现风险承担者的确认工作直都是需求工作中的一个最薄弱环 节。风险承担者是那些在产品中涉及其利益并且在需求收集过程中需要他们提供 输入信息的人。他们构件产品、管理产品、使用产品或以某种方式受到产品用途 的影响，如果忘记考虑他们就可能导致产品在开始使用后一连串的修改要求。工 作上下文的确定与风险承担者间存在依存关系，而定义产品目标是本阶段过程最 重要的工作产品，它将作为后期需求分析的重要约束。 北京工业大学工学硕士学位论文 图3 - 1v o l e r e 需求过程模型汇总 f i g 3 1r e q u i r e m e n t sp r o c e s sm o d e lc o l l e c t i o n 2 第3 章v o l e r e 需求过程模型概述及问题分析 3 1 2 网罗需求 项目启动完成后，分析团队要和风险承担者代表们一起，开始对工作的学习 和需求收集分析工作。这里的对工作的学习中的工作( w o r k ) 是指，我们所必 须理解的组织的一个业务领域；它也指用户打算完成的工作。组织要开发的产品 将成为工作的一部分。网罗活动使用了一些来自启动阶段活动的输出结果。启动 阶段确定了工作的上下文范围，产品的目标和任何解决方案都必须满足的限制条 件。这些对分析团队研究和收集需求起到了指导作用。在网罗活动中占主导位置 的工作是对业务事件的收集和分析。业务事件是指业务上或工作上发生的一些要 求作出响应的事件。v o l e r e 模型提供了很多从实际工作中总结出来的非常有 用的网罗技巧，如了解当前系统、作用户的学徒、与用户访谈、以结构和模式的 方法找出系统本质，以及业务事件研讨会、头脑风暴和文档挖掘等。分析团队使 用这些方法，研究目前响应业务事件要完成的工作，或响应一个新的业务事件需 要完成的工作，确定期望的响应是怎样的。在v o l e r e 模型在网罗需求中强调 指出的一点是，网罗活动既是对工作进行学习，也是找到一种完成工作更好的方 法的过程。 3 1 3 编写需求 在v o l e r e 模型中，编写需求的活动并不是一项独立的需求活动。实际上， 它与围绕它的一些活动( 如网罗需求、做原型和质量关) 是集成在一起的。编写 需求是为了正确的记录下业务需求，所以要使用业务语言，这样客户才能够理解 这些需求并检验这些需求的正确性。然而为了保证设计者可以精确构建用户想要 的产品，在编写需求时还需要为每项需求添加一个验收标准。验收标准是需求的 一种度量方式，它的目的是对需求进行量化，这样测试人员可以精确确定产品是 否满足了需求。在记录需求方面，v o l e r e 模型提供了需求规格说明书模板和 需求项框架这两个模板使需求规格说明的编写更加容易。验收标准作为编写需求 活动的重要工作，它可以量化行为、性能，或者其它需求的质量。验收标准既适 用于功能性需求，又适用于非功能性需求。使用验收标准使参与需求分析的团队 认识到这样一个事实一除非有一种方法知道解决方案是否满足需求，否则不可能 北京工业大学1 = 学硕上学位论文 针对需求设计出解决方案。需求规格说明书的编写是否正确将影响到产品开发的 整个生命周期，因此，在没有通过质量关之前，这里所写下的任何需求都只能被 称为“潜在需求”。 3 1 4 质量关 质量关是每项需求正式进入到需求规格说明书的地方。使用质量关的原因是 因为在网络需求阶段，通过不同的网罗方式，需求可能在任何时候、以任何方式 被捕获，它虽然按照模板和需求项框架变成了形式上的一致但是它依然有可能 不适合产品的目标、需求限制条件等的缺陷。要阻止这些问题需求进入设计和实 现阶段，把它退回其来源除进行澄清、订正或被放弃。在质量关中，要对需求的 完罄性、可追踪性、术语一致性、与目标是否相关、在限制条件下是否可行以及 是否镀金需求等方面进行检查。镀金需求指的是那些对产品的成本的增加要多于 对产品功能的增加的特征和需求。其中还特别描述了对于需求蔓延的关注。需求 蔓延指的是在大家认为需求过程已经结束以后又进入规格说明书的需求，通常因 为它打乱了开发进度，增加了提交产品的成本。因此在v o l e r e 模型的质量关 活动中，对需求蔓延的检查特别成为了一个环节。 3 1 5 为需求制作原型 在v o l e r e 模型中认为原型是潜在产品的一个快速而不完整的版本。原型 的意图是向用户表达需求的一种模拟。制作原型有时是必要的，因为需求收集活 动是困难的。需求收集活动是在要求客户和用户想像他们将来的产品需要完成什 么，这样的活动极大地受限于人们的想象力。使用一个原型的想法是要给人们一 些真实的东西，或者至少是表面上看上去真实的东西。原型让产品足够真实，这 样潜在用户可以想到一些需求，不然就有可能遗漏这些需求。v o l e r e 模型中 原型的方法有时也被用于演示需求的顺序。但是，原型方法并不是应用在所有的 需求收集过程中，它只应用在用户与需求收集者都对此类产品没有经验、用户难 于清晰说明需求或需求分析师在理解需求上有困难等情况中。有两种原型制作方 法可以被提供使用，高保真的( 使用某些自动化的技术) 和低保真的( 主要是用 铅笔和纸，或其他一些类似方式) 构建需求原型。然而不论哪种方法，这项活动 1 4 第3 章v o l e r e 需求过程模型概述及问题分析 的输出都是一些需求，他们应当被记入需求规格说明书。 3 1 6 鉴定需求规格说明书 在v o l e r e 模型中，鉴定需求规格说明书活动作为需求真正进入开发阶段 的最后检查点，在整个需求过程中有着重要的作用。质量关活动的目的是拒绝接 受不好的需求，而且每次只处理一项需求。而鉴定需求规格说明书的活动要检查 需求规格说明书是否完整、是否有遗漏的需求，保证所有的需求协调一致，需求 与需求之间没有悬而未决的冲突。这种复查的过程是迭代式的，直到问题得到解 决。 同时，在鉴定需求规格说明书这个阶段，由于需求分析团队拥有一份完整的 需求，他们比项目启动时对产品知道得更多。因此，在复查之后，他们要对产品 的范围和功能进行重新评估，并以此计算出产品的费用。并且，他们还要基于己 知的需求，重新评估产品的开发风险，决定是否继续进行丌发工作以及直到后期 开发工作的注意事项。 3 1 7 进行需求事后分析 v o l e r 模型建议进行简单的过程改进活动，即进行需求事后分析的活动， 它对于需求过程的过程改进是有益的。通过与一系列的风险承担者的访谈，与开 发者进行小组会谈来进行事后分析。总结出需求过程中哪些活动是有效的，哪些 是不太有效的，从而改进以后的需求分析活动。把这些事后的分析工作作为一种 规范的公司证明了这种方法可以使它们在过程改进方面取得长足的进展 在说明需求过程的各个活动的同时，v o l e r e 模型中还强调了重用需求的 重要性。它从事后分析中收集需求过程经验以及产品和领域的知识，使这些知识 形成重用库，为以后的需求过程提供参照，从而提高效率和准确性。 3 2v o l e r e 需求过程模型在实施中的局限性 v o l e r e 模型已经建立了软件需求过程所要经历的基本过程环节( 在下面 的论文描述中，过程环节一词代表的是模型中任何层次中的单独工作部分，因此 北京工业大学工学硕士学位论文 任何的活动或子过程都可以统称为过程环节) ，并且基于经验提供了大量的收集、 分析需求的方法。但是，如果使用模型在实际的工程中进行实施，将会遇到以下 主要困难。 3 2 1 各子过程及活动间没有明确的时间顺序 实际的需求收集与分析是一个过程，过程中各环节的工作是按照时间逐渐展 开的。虽然会有迭代式的过程，但也必然会存在时间上的先后顺序关系。v o l e r e 模型为我们刻画了每个需求过程环节，它注重的是对每个环节应做工作的描述， 但是各个环节应该在时间上如何衔接，作为一个统一的过程，在单一的时间发展 上它们如何协同工作? 比如编写需求在整个过程中应该何时出现，它与制作原型 在过程实施中是怎样的顺序? 不对各个环节做单一时间上的过程安排，模型就无 法真正得到工程上的实施。 3 2 2 参与需求过程的角色作用以及角色间关系定义不清晰 需求收集和分析是个活动的过程，它的活动是由不同的角色参与和推动发展 的。在实际的环境中，角色的关系是影响他们工作的重要因素。因此，过程管理 中对于参与过程活动的角色的管理是十分重要的。虽然角色管理有时候由于包含 大量人文色彩，会超出过程管理的范畴。但是，如果没有清晰的角色定位，必然 造成过程中活动运行的混乱。v o l e r e 模型中定义了众多的参与活动的角色， 描述了他们对于需求过程的贡献。但是却缺少对这些角色间相互作用的定义，也 缺少对推动需求过程发展的需求小组职责的描述。致使软件组织难以组成需求小 组并使它开展正常的工作。 3 2 3 子过程和活动过于繁杂 v o l e r e 模型在最概括的层次，即顶层，描述了9 个过程环节( 其中7 个 为主要过程环节) ，而这些概括层次描述的环节展开后，扩展为几十个过程环节。 比如v o l e r e 模型中对于网罗需求过程中的学习工作子过程的描述，有多达1 0 个活动。如图3 2 所示。 第3 幸v o l e r e 需求过程模型概述及问题分析 图3 - 2 学习工作 f i g 3 - 2l e a r n i n gw o r k 尽管v o l e r e 模型对这些环节应做的工作、参与的角色和过程产品都作了 比较详细的刻画，但是，过多的环节设置，容易使需求收集与分析组织迷失方向。 在需求收集与分析阶段经验不足或者软件过程能力比较低的软件组织，他们需要 一个脉络清晰的过程模型，否则会使经验不足的组织失去需求过程的重点。同时 我们知道，实际的需求活动每进行一个环节都是要付出代价的，过多的环节虽然 提高软件需求的质量，但是质价比是否合理以及组织的资源限制都是实际工程中 需要考虑的问题。 北京工业大学工学硕上学位论文 3 2 4 缺少建立需求直观参照物以及检验需求有效性的方法 v o l e r e 模型基于大量工作经验，总结了很多需求收集和分析的方法，比 如头脑风暴、制作需求录像带等。但是，其中大量的方法是需要有使用经验的人 才能准确掌握的，那些缺乏经验的人难于利用这些方法得到好的效果。相对于某 些需要一定使用技巧的方法来说，更加直观、易于使用的方法就是制作原型的方 法。原型的制作过程使需求团队更加关注需求本身，而且缺少经验与技巧的需求 分析人员使用这种方法，更容易生成有效需求。 3 3 对v o l e r e 模型中关于原型方法的思考 对于制作原型v o l e r e 模型提出了两种方法，即低保真的和高保真的构 建原型方法。两种原型构建方法的主要区别就在于是否在代码一级构建原型。低 保真原型是需求分析人员使用的一种比较随意的辅助需求分析方法，没有必要针 对它进行事前筹划、事后评估的繁琐工作，它应该在网罗需求环节中随时被使用。 而所谓的高保真构建原型的方法，如果在需求阶段后被抛弃，则意味着软件组织 多承担了大量的资源代价。而如果保留其中的结构作为后期开发产品的一部分， 那么由于早期开发的代码质量粗糙，会为后期的融合与测试带来非常大的麻烦。 因此，我认为v o l e r e 模型中把原型看作是潜在产品的一个快速而不完整的版 本，认为原型的