软件需求分析方法研究进展

李 超，谢坤武

(1.湖北民族学院 科技学院,湖北 恩施 445000； 2.湖北民族学院 信息工程学院,湖北 恩施 445000)

软件需求分析方法研究进展

李 超1,2，谢坤武1*

(1.湖北民族学院 科技学院,湖北 恩施 445000； 2.湖北民族学院 信息工程学院,湖北 恩施 445000)

近年来软件需求分析技术获得了长足的发展.需求分析是软件定义期的最后阶段,软件系统的成功构造极大地依赖软件需求分析的质量.不同的需求获取技术、需求分析与建模方法和需求管理与控制手段,对于软件的开发与维护、软件质量和复用影响很大.对软件需求的研究,具有重要的意义.本文系统地分析和总结了软件需求的获取方法、需求分析及建模技术、需求管理等内容,指出了软件需求研究发展的方向.

软件工程；需求管理；需求分析

近年来软件需求分析技术获得了长足的发展.需求分析是软件定义期的最后阶段,软件系统的成功构造极大地依赖于需求分析.软件需求阶段分为需求获取、分析与建模、确认等步骤,涉及权衡分析、质量度量、风险评估、可行性评估、变更控制、缺陷分析及需求分析工具构建等内容.不同的需求获取技术、分析与建模方法和需求管理与控制手段，对于软件的开发和维护以及软件质量、复用影响很大.对软件需求的研究,具有重要的意义.本文系统地分析和总结了软件需求的获取方法、需求分析及建模技术、需求管理、需求的评审等内容,最后指出了软件需求研究发展的方向.

1 需求获取方法

软件需求[1-3]是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望.需求分析是软件定义期的最后阶段,侧重于系统必须做什么,涉及对应用问题及环境的理解与分析,为问题所涉及的信息、功能、系统行为建模,将用户需求精确化、完全化等一系列活动,最终形成需求规格说明.

无论是特定系统还是软件包的开发,都离不开需求获取.需求获取是一个取得用户对目标软件需求的过程,是一项困难的工作,它要求开发人员应具备相应的领域知识，用户提供相应的材料及信息,最终结果能解决用户面临的问题.本节先对常用的需求获取方法作简要的介绍.

1)访谈与会议

分析人员一般以个别访谈或小组会议的形式与用户进行初步沟通.在访谈和会议前，分析人员精心准备一系列问题,通过用户对问题的回答获取有关问题及环境的知识,逐步理解用户的要求.访谈与会议过程中，所提问题应该循序渐进，不限制用户在回答过程中进行发挥，组织问题时应客观公正，提出的问题汇总后应能反映应用问题全貌,覆盖用户的要求.

2)观察用户工作流程、与用户组成联合小组

观察用户工作流程,可以获得用户与组织系统交互的第一手资料,对用户所做事情及过程有一个准确客观的评价.在其过程中，要将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界面等作为软件目标.分析人员要结合自己软件开发和应用经验,主动地指出不合理的用户需求,从软件角度改进操作流程和规范,提出新的潜在的用户需求.

分析人员和用户以问答和文档方式进行沟通，抑制了用户在分析过程中的主动精神,阻碍了协同工作,易导致误解和遗漏.以“联合小组”方式进行需求，用户也是需求分析人员,对分析工作负有与软件开发方相同的责任.20世纪70年代末出现的联合应用程序设计(JAD)方法,它实质是对“联合小组”方法的扩展.主要思想是让所用关键人员在同一时间处于同一地点以会议方式进行,需求分析人员可以看到一致和有冲突的领域，从而从系统的主要用户那儿同时收集系统需求,是一个紧张而且高度组织化但又非常有效的过程.

3)分析程序和其他文档

由于访谈和观察具有局限性,可以通过分析系统和组织的文档来加强,发现当前系统及其支持组织的更多详情.通过对组织任务声明、业务规划、业务表单、报表、组织结构图、经营方针指南、作业描述、内部与外部函件和来自之前组织研究报告等文档,可以获取构建新系统所关注的一些信息.

4)原型法、Demo版系统法

原型法是一个反复的过程,分析员和用户根据用户反馈构建一个信息系统的初步版本.要为原型开发确立需求,分析员仍然不得不访问用户和收集文档,原型开发允许分析员很快地将基本需求转换成所期望的信息系统的一个可运行版本,之后检查和测试这个原型，通过不断地丰富逐渐实现目标系统.与原型法的不同，Demo版系统法是在已有项目基础上进行修改得出可运行系统,通过“可运行原型系统”达到彻底挖掘项目需求.原型法需要构造原型,而Demo版系统法已有相似的可运行的系统基础.

5)问卷调查

问卷调查又称调查表或询问表,是以问题形式系统地记载调查内容的一种文件.设计问卷是询问调查的关键.问卷可以是表格式、卡片式或簿记式.问卷须具备两个功能,即能将问题传达给被问的人和使被问者乐于回答.

6)敏捷方法

敏捷方法强调对变化的快速响应,通过引入迭代式的开发手段,较好的解决变化问题. 敏捷方法的两大主要特征便是对“适应性”的强调与对“人”的关注.它将整个软件生命周期分解为若干个小的迭代周期,通过在每个迭代周期结束时交付阶段性成果来获取切实有效的客户反馈.其目的是希望通过建立及时的反馈机制,对需求变更做出调整,增强对软件项目的控制能力.

7)基于知识的方法

基于知识的需求分析方法用软件开发者积累的经验或领域分析的结果,来帮助软件开发者理解应用和定义需求.比较典型如工作[4-6].它们都以企业信息系统为研究背景,试图以企业本体和领域本体作为需求获取过程的基本线索,引导领域用户全面描述现实系统,并通过重用领域模型来构造应用软件的需求模型.该方法特点是通过深化领域知识使得需求获取过程更系统更有效.目前还没有系统性的研究成果出现.

2 需求分析及建模方法

因需求分析对象的抽象粒度、关注点等因素不同而呈现出了如面向对象、面向数据、面向数据流、面向agent、用例驱动、场景驱动、基于多视点、面向方面、用户驱动、市场驱动、基于本体等需求分析方法.它们各有利弊，下面分别进行阐述.

1)面向对象需求分析

面向对象方法是一种运用对象、类、维承、封装、聚合、消息传递、多态性等概念来构造系统的软件开发方法.20世纪80年代,面向对象思想开始渗透到软件工程的前期阶段,即在系统分析和设计阶段就运用面向对象思想.90年代,图形化建模语言UML的出现,被认为是最重要的具有划时代意义的重大成果之一.OOSD在一定程度上提高了开发者的效率和控制复杂系统能力.OO方法强调从系统中抽象类与对象,标识它们之间的关系,即用自底向上方法构造系统，但它没有充分地描述这些类与对象如何协作完成系统功能,难以从全局把握系统.它强调对现实世界的客观认识,力求与客观一致,但缺乏主动性,用此方法开发出来的系统没有自动适应现实世界的能力.

2)面向数据及面向数据流需求分析

以面向数据结构的系统开发方法(DSSD)和Jackson系统开发方法为代表的面向数据的需求分析方法,以信息对象及其操作为核心,对复合信息对象按照层次结构进行分解并映射为程序结构. Warnier提出的DSSD方法利用顺序、选择和循环结构表示信息的层次分解,利用信息层次结构推导出程序结构.后来,Ken Orr对他的工作进行了扩充,引入了数据流和处理功能,从而发展成为一种需求分析方法.20世纪80年代,Jackson提出了软件工程领域中著名的Jackson方法,最初只用于设计,后来不断进行扩充和完善,成为了一种需求分析方法.

面向数据流的分析方法属于结构化分析方法,具有鲜明的结构化特征.1979年DeMarco将结构化分析方法作为一种需求分析方法正式提出,此后它得到了迅速发展和广泛的应用.后来Ward&Mellor和Hatley&Pirbhai在结构化分析中引入了实时系统分析机制,Harel研制了面向复杂实时反应式系统的开发环境STATEMATE[7]等,这些是对传统结构化分析方法的扩充.

结构化方法的思想基础是认为任何系统在建立之前都能被充分理解,开发人员和用户在系统开发初期对系统功能有全面的认识,并制定出详细计划和说明书规范后期各项工作.它着眼于处理方法和过程，分离数据结构和处理方式,用过程抽象方式来应付系统的要求.系统其结构具有稳定性,行为具有易变性,而结构化方法把基点放在功能行为上,难以适应系统的变化.结构化方法主要由数据流程图及控制结构图等图表工具来描述,一般只能表达顺序流程和平面结构,且不精确,无法全面描述信息系统模型.从某种意义上来说,结构化方法是强调从开发人员而不是用户的角度来思考要实现的信息系统.

3)面向Agent需求分析

传统的软件需求分析与设计,着重对系统功能的理解、表达及具体实现,无法把握系统的总体结构和实体组成.随着Agent技术的发展,面向Agent软件工程(AOSE)已经成为Agent技术研究中一个非常活跃的领域.因智能Agent具有反应性、自主性、合作性和知识级的通信能力,软件开发者可利用Agent更自然地去开发复杂系统,从而实现实体抽象.基于Agent的需求分析建模是面向实体的,能从根本上隔离需求分析和实际的软件实现,在脱离软件具体实现约束的情况下得到更全面更抽象的需求域信息处理模型,从而综合体现系统结构、实体行为和系统功能.这样的模型更接近实际组织，易于理解,同时具有很强的适应性,当实际的操作流程改动时能方便快速地对模型进行修改.

随着对Agent技术研究的不断深入,各种基于Agent的需求分析方法及建模工具逐渐涌现出来,如纯Gaia[8]方法、AUML[9]、KAOS[10]等，在多个大型项目中应用并取得了良好的效果.

4)用例驱动需求分析

用例驱动[11-13]的需求分析方法目前得到了广泛的应用.用例图被认为是获取、描述需求较好的策略[14]，捕获需求一个比较流行的方法是基于用例[15].用例和用例驱动的开发一经Jacobson首次提出，就被成功应用到许多项目里面，已成为捕获关注点的一个标准方法[16].在UML中,Use Case图用来表示参与者、用例、用例与用例、用例与参与者间关系的图.参与者(Actor)定义了与系统进行交互的实体角色的抽象.参与者可以是人,也可以是应用系统,它与系统中特定的角色进行关联.用例表示系统某些功能,用例间关系涉及关联、泛化、扩展、集合和组合等.用例驱动的分析，是从行为者的角度出发建立用例，在复杂的需求分析中起到了巨大的作用[11]，使软件的开发从以代码为中心转为以用例为中心.

对用例进行描述可以使用自然语言、结构化以及形式化技术.使用自然语言进行描述,分析人员和领域专家便于进行沟通,但也增加了模糊性、不一致性和不完整性[17].为此如Leite等[18]用表来描述用例,Hsia[19]和Glinz[20]等用到了语法和状态图等形式化(形式化方法优缺点具体见后面小节)来描述用例.但采用用例方法也存在很多问题，如不能从更深层次来理解要开发的系统在功能和非功能外的特征,如依赖性、并发性和反应时间等.

5)场景驱动需求分析

为了弥补基于用例方法在非功能描述方面的不足，出现了基于场景的需求分析.如Saiedian等[21]基于场景模型来分析实时软件系统及关键的系统需求，很好地反映了系统依赖性、并发性、反应时间等特征.由于情景实例的采集是随机的,不能保证某组情景实例能覆盖整个现实系统和产生完全的需求.

6)基于多视点(观点)需求分析

大型复杂软件系统的开发,往往涉及到众多的来自不同背景、具有不同知识和职责的项目人员,他们对待系统的看法和要求不尽相同.为了在系统开发的早期全面获取项目相关人员的需求信息,确保开发要求的全面性,上世纪90年代,提出了面向多视点的需求工程方法[22-23].采用视点的形式分散、独立地获取和表示项目相关人员的需求，最终将与各视点对应部分的规格说明集成为一个统一整体,生成完整的规格说明书.目前,在视点定义及抽取[24-25]、视点表示[26-27]、视点一致性[28-29]、视点间冲突处理[30-31]、视点集成[32-34]等方面已有较广泛和深入的研究.

7)面向方面需求分析

由于需求变化性及软件本身性能要求等因素,面向对象程序设计不能很好地解决横切关注点的有效分离,造成代码分散、混乱和难以维护[35].面向方面程序设计使用Aspect的概念解决了横切关注点的有效分离和局部化,提供了一系列方法来系统性地界定、分离、实现、组合横切关注点,更好地处理横切关注点.在需求分析阶段即采用面向方面方法,更早地分离捕捉到横切关注点,以降低需求分析到设计直接映射的难度,从而建立更好的模块结构,降低后期重构升级维护成本.

8)目标驱动需求分析

许多需求分析方法把需求看成是过程、数据或实体,系统和环境的关系用活动和实体来表达，在澄清需求,处理需求变更与需求验证,跟踪需求背后的决策依据等方面都存在许多不足. KAOS方法[36]认为,分析用户需求的最有效的方法应该从整个系统的实现目标开始,逐步分解目标直到其责任能够被分配到构成系统的基本组件单元中,最终完成设计目标.基于目标的分析方法,是把需求与组织和业务环境联系起来,方便冲突处理,驱动后续设计过程,实现需求复用.在目标驱动的需求分析过程中涉及目标求精问题.目标求精是通过目标求精树中的部分目标推导完整的目标求精树的过程,目前目标求精主要涉及形式化[37]和非形式化方法[38].如李勇华[39]等提出了谓词驱动的目标求精方法,通过对目标谓词描述的分类来指导整个求精过程的进行.同传统的求精方法相比,该方法具有对需求分析员的依赖较小、自动化程度高等优点.

9)用户主导、市场驱动、产品线需求分析

受知识背景、资源和经验等方面因素的限制,软件开发人员往往难以充分理解用户的问题空间,交流困难[40].用户通常对问题仅具有模糊、局部的认识和理解,难以系统、全面地表达出自己需求,并且通常对于软件开发领域知之甚少，按照传统的软件工程方法和技术难以从用户处获得正确的需求.对于涉及领域知识性强、角色多且结构复杂的系统,让用户在需求过程中发挥主导作用是解决该问题的一个很直接的办法[41].事实上,用户的参与程度对于项目成败的重要影响已得到公认[42-43].

市场驱动的需求分析主要是为了在软件包的基础上,孕育发展新的需求以确保其产品的竞争力,它强调需求的连续性、重要性以及专家对开销的评估,在此基础上实现软件发布计划.软件包通常也就是集成的构件.常见的特定软件不同,项目用户定义明确,开发方和客户间的需求以需求规格说明的方式形成合同, 而软件包的开发面向市场,要求能够预见终端用户的需求,在其基础上选择特定的需求集,实现具有竞争力的软件产品.

软件产品线方法[44]是软件体系结构和软件复用技术发展的结果,集中体现了一种大规模、大粒度的软件复用实践.在软件产品线的开发过程中,软件产品线的需求分析占据重要的作用.产品线的需求分析是分析整个产品线的需求,其中包括共性需求和变化需求，需求分析过程涉及领域需求分析和特定产品的需求. 领域需求分析是对领域内需求进行获取、分类以及分析的过程,反映的是领域中多数用户对各系统的需求.产品线需求定义了产品线中的产品及其特性,涵盖了整个系列的共同特性,是产品线重要的核心资产.根据STARTS[45]软件产品线的双生命周期模型,产品线需求分析过程也分为领域工程中的领域需求分析和应用工程中的产品需求分析两个过程.

10)形式化方法需求分析

形式化方法是一种用于规范、设计和验证计算机系统的基于数学的方法,它包括各种语言、技术和工具等. 形式化方法有助于发现需求中隐含的不一致性、二义性和不完整性,能对其进行更深入精确的理解和规范化管理,并为软件生产自动化奠定基础,能对目标系统和规格说明等价性进行有效证明.当前用于需求分析的形式化方法及语言主要有B方法[46]、Z语言[47]、VDM以及Petri网[48]等.

除了上面所给出的需求分析方法外，还存在许多需求分析方法，如基于本体、领域本体的需求分析方法等.

11)需求建模工具的比较

当前常用的需求分析及建模工具有Rational Rose、Microsoft Visio、Sybase Power Designer，Sparx Systems Enterprise Architect，Borland Together等.关于这几个工具在绘图功能、数据集成、文档自动化、双向工程、稳定性、效率、易用性及价格方面的特点可以参考文献[49]及各公司发布的相应信息.

3 软件需求管理与控制

软件需求不断地变更是软件开发困难的根源之一，需求的管理贯穿于整个软件开发周期中.软件的需求管理与控制涉及质量度量与控制、复杂性度量、有效性度量、优先级划分、风险性分析、依赖性分析、需求缺陷管理及管理工具.

1)需求质量度量与控制

软件系统的成功极大地依赖软件需求分析的质量.软件需求的质量度量主要是针对软件需求规格说明(SRS)的度量.文献[50-51]给出了质量度量指标,甘早斌等[52]基于此借助于模糊数学的基本理论，在分析SRS及其质量特性的基础上，提出了软件需求的质量度量指标体系，并讨论了有关数据的获取以及模糊综合评价方法.

2)需求复杂度性及有效性度量

软件需求(空间)的复杂度直接决定着软件的复杂度.需求的复杂度与需求条目多少、需求的领域性、需求的获取及表示环境、工具紧密相关以及相关人员的知识背景相关.由于软件需求具有模糊性、不确定性、变化性和主观性，软件需求复杂性和有效性的度量当前比较困难，相应成果较少.

3)需求优先级划分

需求优先级的确定对于项目进度甚至成功与否的影响很大，需求优先级排序需要考虑多种因素,如用户核心业务的价值、需求之间的依赖关系、开发团队可用资源、开发者和用户对系统目标和限制的理解程度、环境的演化等诸多因素都会影响到需求优先级的划分，这使得在迭代开发过程中需求优先级排序变得非常复杂.黄[53]等提出了一种风险驱动的需求优先级自适应排序方法，将自适应计划方法学与风险驱动相结合,将风险作为排序决策的依据,以自适应的过程为迭代开发排序需求优先级，增强了迭代开发中对需求的控制,降低了项目失败可能性.

4)需求依赖性分析

依赖性对于系统的最终实现起着非常重要的作用，需求之间往往存在着各种类型的关联和依赖.Robinson[54]和Van Lamsweerde等[55]针对需求分析阶段消除消极依赖性工作方面做了大量研究, Carlshamre等[56]对依靠需求依赖性来制定软件产品的发布计划作了一个工业调查.Giesen和Volker[57]深究了需求的依赖性如何能帮忙满足风险投资者个人偏好的问题.Von Knethen等[58-59]展示了基于需求依赖性来实现需求复用和改变需求的方法.Wei Zhang等[60]在部分基于观察特征运转和责任分配基础上,提出了特征间多种依赖类型.

5)需求风险评估

软件开发存在着多种风险,其中需求分析风险(RAR)是最重要的,如果不加以足够的重视就可能达不到预期要求,甚至导致项目开发失败[61].因此,对于项目开发中的RAR必须作出合理评估.传统评估方法如层次分析法、领域专家打分法、模糊数学法等都是针对整个项目进行风险评估,主要靠专家根据经验和历史数据来分析识别,主观因素较大，数据需要人工整理,容易出错，不适合RAR的客观分析.针对此问题文献[61]提出基于支持向量机(SVM)的需求分析风险评估模型,定义了13种风险指标,然后对各个风险指标采用多位专家按量化标准打分再统计分析方法,并把这些指标转换为向量作为SVM训练样本,以建立RAR评估模型,并对RAR进行了科学预测.作者通过模拟试验论证了其方法的可行性.

6)需求缺陷分析与管理

Kamata[62]指出,40%-60%的软件缺陷都由需求缺陷引起.缺陷修正越早,付出的代价就越小，在软件开发后期才修正缺陷比起在需求阶段修正,代价可能要高上百倍[63].文献[64]从社会因素和技术因素两大方面分析了需求工程阶段缺陷产生的原因,对缺陷进行了分类.建立了需求(模型)缺陷列表、缺陷需求分析模型和基于需求缺陷管理的需求过程模型.

7)需求管理工具的比较

限于篇幅仅对需求管理工具Telelogic DOORS，Ratioanl RequisitePro 和Borland CaliberRM作一个简单的对比分析.

表1 需求管理工具的比较

4 需求的评审

需求分析以系统规格说明和项目规划作为分析活动的基本出发点,需求规格说明是软件设计、实现、测试直至维护的主要基础.良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率、降低开发成本、改进软件质量.目前，需求的评审及验证除了人工方法外，往往借助一定的工具实现.具有代表性的工具如QuARS[65]、ARMm[66]和Sytwo[67]等.

5 软件需求研究的趋势

近年来软件需求分析技术获得了长足的发展.软件需求获取方法、分析及建模技术以及面向对象的工具平台比较成熟，但在需求优先级的确定，基于需求的软件规模度量，需求的质量度量方法及度量工具的开发，需求描述工具，需求到设计再到软件的实现平台的研究，需求的重用特别是特定领域需求的重用，需求粒度，需求协同分析等许多方面将有许多工作要做.

总结语 不同的需求获取技术、分析与建模方法和需求需要管理与控制,对于软件的开发、维护以及软件质量、复用影响很大.对软件需求的研究,具有重要的意义.本文系统地分析和总结了软件需求的获取方法、需求分析及建模技术、需求管理与控制等内容,同时指出了软件需求分析方面要作的工作.

[1] 齐治昌,谭庆平,宁洪,等.软件工程[M].北京：机械工业出版社,2004.

[2] 龚晓庆,张远军,陈峰,等. 面向对象系统分析与设计[M].北京：清华大学出版社,2008.

[3] 刘伟琴,刘洪涛.软件需求[M].北京：清华大学出版社,2009.

[4] Sutcliffe A,Maiden N.The domain theory for requirements engineering[J]. Software Engineering, IEEE Transactions on,1998,24(3):174-196.

[5] Dardenne A,Van Lamsweerde A,Fickas S.Goal-directed requirements acquisition[J]. Science of computer programming,1993,20(1):3-50.

[6] 金芝. 基于本体的需求自动获取[J].计算机学报,2000,23(5):486-492.

[7] Harel D, Lachover H, Naamad A, et al. Statemate: A working environment for the development of complex reactive systems[J]. Software Engineering, IEEE Transactions on, 1990, 16(4): 403-414.

[8] Jennings N R. Agent-oriented software engineering[M].Multi-Agent System Engineering[J].Springer Berlin Heidelberg,1999:1-7.

[9] Parunak V, Bauer B, Bradshaw J M, et al. Suggested UML Extensions for Agents [J].Intellicorp OMG Document,1999,3(2):1-15.

[10] Letier E. Reasoning about agents in goal-oriented requirements engineering[D]. Université catholique de Louvain, 2001.

[11] Regnell B, Kimbler K, Wesslén A. Improving the use case driven approach to requirements engineering[C]//Requirements Engineering,1995,Proceedings of the Second IEEE International Symposium on. IEEE,1995:40-47.

[12] 刘庆海，周国新，唐旭，等.城镇宗地地介评估信息系统的研究与实现[J].湖北民族学院学报：自然科学版，2010，28(1)：98-104.

[13] Dano B, Briand H, Barbier F. A use case driven requirements engineering process[J]. Requirements Engineering, 1997, 2(2): 79-91.

[14] Cockburn A. Writing effective use cases[M]. Reading: Addison-Wesley, 2001.

[15] Regnell B, Kimbler K, Wesslén A. Improving the use case driven approach to requirements engineering[C]//Requirements Engineering,1995,Proceedings of the Second IEEE International Symposium on. IEEE,1995:40-47.

[16] Jacobson I, Ng P W. Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series)[M]. Addison-Wesley Professional, 2004.

[17] Kulak D, Guiney E. Use cases: requirements in context[M]. Addison-Wesley Professional, 2004.

[18] Leite J C S P, Rossi G, Balaguer F, et al. Enhancing a requirements baseline with scenarios[C]//Requirements Engineering,1997,Proceedings of the Third IEEE International Symposium on. IEEE,1997:44-53.

[19] Hsia P, Samuel J, Gao J, et al. Formal approach to scenario analysis[J]. Software, IEEE, 1994, 11(2): 33-41.

[20] Glinz M. An integrated formal model of scenarios based on statecharts[M]//Software Engineering—ESEC'95. Springer Berlin Heidelberg, 1995: 254-271.

[21] Saiedian H, Kumarakulasingam P, Anan M. Scenario-based requirements analysis techniques for real-time software systems: a comparative evaluation[J]. Requirements Engineering, 2005, 10(1): 22-33.

[22] Kotonya G, Sommerville I. Requirements engineering with viewpoints[J]. Software Engineering Journal,1996,11(1):5-18.

[23] Finkelstein A, Sommerville I. The viewpoints FAQ[J]. BCS/IEE Software Engineering Journal,1996,11(1):2-4.

[24] Kaiya H, Saeki M. Weaving multiple viewpoint specifications in goal oriented requirements analysis[C]//Software Engineering Conference, 2004. 11th Asia-Pacific. IEEE, 2004: 418-427.

[25] Aoyama K, Ugai T, Yamada S, et al. Extraction of viewpoints for eliciting customer's requirements based on analysis of specification change records[C]//Software Engineering Conference,2007.APSEC 2007. 14th Asia-Pacific,IEEE,2007:33-40.

[26] Silva A. Requirements, domain and specifications: a viewpoint-based approach to requirements engineering[C]//Proceedings of the 24th International Conference on Software Engineering. ACM, 2002: 94-104.

[27] 梁正平,毋国庆,王志强.一种基于问题框架的视点表示模型[J].计算机工程,2007,33(15):67-69

[28] Nentwich C, Emmerich W, Finkelstein A, et al. Flexible consistency checking[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2003, 12(1): 28-63.

[29] Bernon C, Gleizes M P, Peyruqueou S, et al. Adelfe: A methodology for adaptive multi-agent systems engineering[M]//Engineering Societies in the Agents World III. Springer Berlin Heidelberg, 2003: 156-169.

[30] Nuseibeh B, Kramer J, Finkelstein A. ViewPoints: meaningful relationships are difficult![C]//Software Engineering, 2003. Proceedings. 25th International Conference on. IEEE, 2003: 676-681.

[31] 江敏,毋国庆.多视点间不一致性的认知推理[J].小型微型计算机系统,2007,28(2):322-327

[32] Sommerville I, Sawyer P. Requirements engineering: a good practice guide[M].John Wiley & Sons,Inc,1997.

[33] 牟克典,金芝,陆汝钤.视点合成中重叠需求的不一致优先级处理[J].计算机学报,2004,27(10):1379-1387.

[34] 梁正平,明仲,毋国庆. 多视点需求工程中视点集成过程的研究[J].计算机科学,2009,36(8):138-144.

[35] 方义秋,冉华锋,葛君伟.基于用例的面向方面需求建模[J].计算机工程，2009,35(12)：44-46.

[36] Van Lamsweerde A, Willemet L. Inferring declarative requirements specifications from operational scenarios[J]. Software Engineering, IEEE Transactions on, 1998, 24(12): 1089-1114.

[37] Dardenne A, Van Lamsweerde A, Fickas S. Goal-directed requirements acquisition[J]. Science of computer programming, 1993, 20(1): 3-50.

[38] Sutcliffe A. Scenario-based requirements engineering[C]//Requirements engineering conference, 2003. Proceedings. 11th IEEE international. IEEE, 2003: 320-329.

[39] 李勇华,王锋,毋国庆.一种谓词驱动的目标求精方法[J].计算机工程,2007，33(2l):58-60.

[40] 舒风笛,赵玉柱.个性化领域知识支持的用户主导需求获取方法[J].计算机研究与发展，2007,44(6)：1044-1052.

[41] Ming-shu L. A new methodology for user-driven domain-specific application software development[J].Journal of Software, 2000, 11(7): 863-870.

[42] Johnson J, Boucher K D, Connors K, et al. Collaborating on project success[J]. Software Magazine,2001, 7(2): 15.

[43] Kujala S, Kauppinen M, Lehtola L, et al. The role of user involvement in requirements quality and project success[C]//Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference on. IEEE, 2005: 75-84.

[44] 江瑜. 基于软件产品线的需求分析研究[J].计算机工程与设计，2007,28(8):1778-1780.

[45] 崔巍,曾广周.面向组件的软件需求协同分析研究[J].山东师范大学学报，2002,17(3):19-22.

[46] Cansell D, Méry D. Foundations of the B method[J].Computing and informatics, 2012,22(3/4):221-256.

[47] Potter B, Till D, Sinclair J. An introduction to formal specification and Z[M].Prentice Hall PTR,1996.

[48] 孙未来,白雪峰.Z和VDM规格说明的差异比较,计算机科学,1997,24(4)：74-79.

[49] 吴伟敏,UML建模工具的比较- ROSE,Visio和PowerDesigner[J].现代计算机,2003(6):1-6.

[50] Leffingwell D, Widrig D. Managing software requirements: a unified approach[M].Addison-Wesley Professional,2000.

[51] Nuseibeh B, Easterbrook S. Requirements engineering: a roadmap[C]//Proceedings of the Conference on the Future of Software Engineering. ACM, 2000: 35-46.

[52] 甘早斌,陈正勇.SRS及其质量模糊度量方法的研究[J].计算机科学,2003,30(4):131-133.

[53] 黄蒙,舒风笛,李明.一种风险驱动的迭代开发需求优先级排序方法报[J].软件学，2006,17(12):2450-2460

[54] Robinson W N, Pawlowski S D, Volkov V. Requirements interaction management[J]. ACM Computing Surveys (CSUR),2003,35(2):132-190.

[55] Van Lamsweerde A, Darimont R, Letier E. Managing conflicts in goal-driven requirements engineering[J].Software Engineering, IEEE Transactions on,1998,24(11): 908-926.

[56] Carlshamre P, Sandahl K, Lindvall M, et al. An industrial survey of requirements interdependencies in software product release planning[C]//Requirements Engineering, 2001，Proceedings. Fifth IEEE International Symposium on. IEEE, 2001: 84-91.

[57] Giesen J, Volker A. Requirements interdependencies and stakeholders preferences[C]//Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on. IEEE, 2002:206-209.

[58] Knethen A. A trace model for system requirements changes on embedded systems[C]//Proceedings of the 4th international workshop on Principles of Software Evolution. ACM, 2001: 17-26.

[59] von Knethen A, Paech B, Kiedaisch F, et al. Systematic requirements recycling through abstraction and traceability[C]//Requirements Engineering, 2002. Proceedings. IEEE Joint International Conference on. IEEE, 2002: 273-281.

[60] Zhang W, Mei H, Zhao H. Feature-driven requirement dependency analysis and high-level software design[J]. Requirements Engineering,2006,11(3):205-220.

[61] 藩梅森,熊齐. 基于SVM 的软件需求分析风险评估模型[J].计算机工程，2007,33(12):78-81.

[62] Kamata M I, Tamai T. How Does Requirements Quality Relate to Project Success or Failure?[C]//Requirements Engineering Conference, 2007. RE'07.15th IEEE International. IEEE, 2007: 69-78.

[63] Leffingwell D. Calculating your return on investment from more effective requirements management[J]. Available from Rational, URL http://www. rational. com/media/whitepapers/ roi1. pdf, 1997.

[64] 严玉清,李师贤,梅晓勇.缺陷需求分析与管理模型[J].计算机科学，2009,36(4):140-144.

[65] Fabbrini F,Fusani M,Gnesi S,et al.An automatic quality evaluation for natural language requirements[C]//Proceedings of the Seventh International Workshop on Requirements Engineering: Foundation for Software Quality REFSQ，2001,1:4-5.

[66] Rosenberg L, Hammer T F, Huffman L L.Requirements, testing and metrics[C]//15th Annual Pacific Northwest Software Quality Conference，1998.

[67] Fantechi A, Gnesi S, Lami G, et al. Applications of linguistic techniques for use case analysis[J]. Requirements Engineering,2003,8(3):161-170.

ASurveyofSoftwareRequirementsAnalysis

LI Chao1,2,XIE Kun-wu1*

(1.Science and Technology College of Hubei University for Nationalities,Enshi 445000, China; 2.College of Information Engineering,Hubei University for Nationalities,Enshi 445000,China)

Software requirements analysis technologies have got considerable development. Requirements analysis is the final phase of software definition and the successful structuring of the software system greatly depends on its quality. Different requirements elicitation technology, requirements analysis and modeling methods, and management technology have a great influence on the software development, maintenance, quality and reuse. It is important for us to study the software requirements. We systematically analyzed and summarized the software requirements acquisition methods, requirements analysis and modeling techniques and requirements management,and predicted the future research issues.

software engineering;requirements management;requirements analysis

2013-03-14.

国家自然科学基金项目(61040006);湖北省自然科学基金项目(2009CDB069);湖北恩施州科技局项目(2011)；湖北民族学院科技学院项目(K201001).

李超(1979- )，男，讲师，硕士，主要从事软件工程等的研究;*

：谢坤武(1974- )，男，教授，主要从事软件工程、数据挖掘等的研究.

TP311.5

A

1008-8423(2013)02-0204-08