搜索
需求工程与形式化研究综述万海2005年5月11日讨论课第一部分需求工程第二部分形式化研究1.需求工程的研究动机与重要性2.需求分析的内容3.需求分析的难点4.需求工程研究现状5.相关会议与杂志第一部分第一部分Slide3Slide31.需求工程的研究动机与重要性SeparatetheproblemfromthesolutionButdesignchangestheworld需求工程要解决软件开发的问题具有的特性：—复杂性,不一致性,可变性,不可见性软件工程固有的困难•理解问题—抽取、需求获取、等•形式地描述问题—规格说明、建模、等•获得对问题本质的一致意见—证明有效、矛盾归结、协商—需求管理——维护一个一致的意见Slide4Slide41.需求工程的研究动机与重要性—需求是软件的基础：没有需求就没有软件—一半以上的软件项目失败都涉及需求上的问题—项目规模的大小决定错误的代价举例说明：1.PerformingRightsSociety（演出权益协会）,PROMS项目，花费1100万英镑之后被放弃（1992年）。其中糟糕的需求工程是项目失败的一个主要因素，包括未能以常人能够理解和检查的形式表达软件需求。（与客户沟通的问题）2.WessexRegionalInformationSystemsPlan（地区信息系统）,RISP项目，花费了4300万英镑之后被放弃（1990年）。其主要原因包括缺乏对RISP项目范围的清晰定义。（需求的边界问题）3.LondonStockExchange（伦敦股票交易）,TAURUS项目，花费了7500万英镑后被取消（1993年）。许多问题起源于未能协调那些不一致的需求。（不一致需求的管理问题）4.LondonAmbulanceServiceDespatchSystem（伦敦救护车服务派遣系统），在运行两天后被关闭（1992年），源于社会服务领域糟糕的需求分析。（需求不清晰的问题）5.SwanickAirTrafficControl（空中交通控制），计划在1998年完成，但2001年还未完成（额外开支1.8亿英镑）。主要原因包括：缺乏健壮的需求规格说明而继续进行系统实现。（需求没弄清楚就匆忙开始后续工作）6.失败的后果花费很高的代价。比如，IntelPentiumBug：$475millionSlide5Slide51.需求工程的研究动机与重要性—现在软件开发的特点:–软件在规模上越来越复杂，规模上，应用深度上–软件是不可见的和抽象的–没有构造性的步骤：软件是可修改的！—但，早期的建模和分析非常重要–缺陷发现的越早消除它的代价就越低—当前的情况是：早期的建模和分析还不够–需要向每个人传递需求–需要得到所有投入者的同意–需要理解系统的所处的环境–需要理解开发过程所处的环境–需要随需求的进化保持不断的更新需求的内容有哪些？Slide6Slide62.需求分析的内容•软件需求可以包括三个不同层次:业务需求(Businessrequirement),用户需求(Userrequirement),功能与非功能性需求(Functionalandnonfunctionalrequirement).—业务需求反映了组织机构或客户对系统,产品高层次的目标说明;—用户需求描述了用户使用产品必须完成的任务,这在使用实例中予以说明;—功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求;—非功能需求是作为功能需求的补充,用来描述系统展现给用户的行为和执行操作,包括产品必须遵从的标准,规范和合约,外部界面的具体细节,性能要求,设计或实现的约束条件及质量属性等.Slide7Slide72.需求分析的内容Slide8Slide82.需求分析的内容变更控制版本控制需求跟踪需求状态跟踪Slide9Slide92.需求分析的内容•需求获取：对问题领域及客户需求进行调查，获得关于需求的信息。三个主要问题：—应当收集什么信息—能从什么来源中来收集—可以通过什么机制或技术来收集•需求分析：通过对问题领域的研究，获得对该领域特性及存在于其中的问题特性的透彻理解。特点：—关注于问题领域及其建模，而不是解系统—主要目标是获得问题领域及存在于其中的问题本质的理解—在本质上先于对目标系统行为的规格说明•规格说明：创建并定义目标系统的一种行为，使之在问题领域中产生所需的效果。特点：—创造性的任务，是一个设计任务（但不是内部设计任务）—成为投入者之间交流的契约•需求验证：试图保证定义了目标系统的正确的功能性Slide10Slide102.需求分析的内容需求规格就是一个预期的或已存在的计算机系统的表示.它可以作为开发者和用户之间协议的基础,来产生预期的系统.规格定义系统所有必须具备的特性,同时留下很多特性不做限制.通常,我们要求规格比组成特定系统的实际的软件和硬件更简洁、更全面、更易于修改.需求工程的主要结果是软件需求规格(softwarerequirementspecification,SRS),SRS是对外部行为和系统环境(软件、硬件、通信端口和人)接口的简洁完整的描述性文档.项目管理者用它来对项目进行计划和管理,在许多情况下,它也被作为是用户的使用手册或帮助用户理解系统的文档.它广泛地适用于对各类应用领域中的客户问题进行理解与描述,实现用户、分析员和设计人员之间的通信,为软件设计提供基础,并支持系统的需求验证和演进.Slide11Slide113.需求分析的难点①问题的复杂性.由于用户需求所涉及的因素繁多,如运行环境和系统功能等,而导致了问题的复杂化.可能描述出现矛盾：例如，规格说明书的某一部分可能规定系统必须监控化学反应容器中的温度，而另一部分(可能由另一位系统分析员撰写)却规定只监控在一定范围内的温度②交流障碍.需求工程涉及人员较多,如软件系统用户、问题领域专家、需求工程师和项目管理员等,这些人员往往具有不同的背景知识,且处在不同角度,扮演不同角色,从而不可避免地造成了他们之间相互交流的困难.③不完备性和不一致性.由于种种原因,用户对问题的陈述往往是不完备的,其各方面的需求还不可避免地存在着矛盾.需求工程的主要活动之一便是从初始的需求陈述中获取隐含信息,并消除其矛盾,昀终形成完备且一致的需求定义,为后继开发打下基础.例如：系统每小时从安放在水库中的深度传感器获取一次水库深度数据，这些数值应该保留6个月。④需求易变性.用户需求的变动是一个极为普遍的问题,即使是部分变动,也往往会影响到需求定义之全部,从而可能会导致不一致性和不完备性.Slide12Slide124.需求工程现状需求工程方法学软件工程的生命周期模型,如瀑布型、渐增型、快速原型及螺线型.Lano提出的操作概念规格,在需求产生前由开发者写成,既能满足开发者希望需求规格精确的要求,又能满足用户希望其易于理解的要求.Howes提出用用户手册的方法来解决用户和开发者之间的通信问题.Sutcliffe,Maiden提出从领域知识的角度出发在需求工程的环境中定义通用的领域语义模型和组合模型.Alford提出的“任务分割”的概念,大大降低了需求分析的问题复杂度.Chou和Eckert讨论了面向对象的需求工程方法学的概念和模型.Drake提出用于确定系统需求边界的限定过程.Gotel对需求跟踪性问题进行了阐述.Rosca,Krogsite,Jaffe,Zave,Robinson,Basili,Yu,Mathalone等人也分别从不同方面对需求工程方法学进行了论述.Slide13Slide134.需求工程现状需求工程方法1.面向过程的分析方法的主要研究系统输入输出转化的方式,对数据本身及控制方面并不很重视.SA(structureanalysis),SADT(structureanalysisanddesigntechnique)就属于这一范畴;另外还有可执行/操作模型如PAISley和Descartes;以及形式方法如VDM(Viennadesignmethod)和Z2.面向数据的方法强调以数据结构的形式描述和分析系统状态JSD和关系实体(ER)模型都是面向数据.3.面向控制的方法强调同步、死锁、互斥、并发以及进程激活和挂起.数据流图就是典型的面向控制的方法.SADT是以面向控制的方法为辅的Slide14Slide144.需求工程现状需求工程方法4.面向对象OO的方法把分析建立在系统对象以及对象间交互的基础之上,使得我们能以3个昀基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求.对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)如:Yourdan和Coad的OOA方法、Booch的方法、Jacobson的OOSE、Rumbaugh的OMT方法，UML方法。5.面向目标的分析方法在需求分析的不同阶段引入了目标的概念，不同的基于目标需求分析方法中目标的作用和地位是不同的，它是近几年来兴起的一种需求分析方法，目前尚未建立一个统一的面向目标的需求分析方法。Slide15Slide154.需求工程现状需求工程方法6.面向方面的程序设计（AOP）AOP是一种关注点分离技术，通过运用aspect这种程序设计单元，允许开发者使用结构化的设计和代码，反映其对系统的认识方式。要使设计和代码更加模块化、更具结构化，使关注点局部化而不是分散于整个系统中。同时，需使关注点和系统其他部分保持良好定义的接口，从而真正达到“分离关注点，分而治之”的目的。通过将横切关注点集中到aspect中，AOP就取得一种单一的结构化行为，该行为在传统程序中分布于整个代码里。在AOP中，aspect是一阶实体，aspect之于AOP，正如class之于oop。自1997年首次在欧洲面向对象会议上提出,自2002年起，每年春天分别在欧洲和美国轮流召开专门的面向方面软件开发（AOSD）国际学术会议。Slide16Slide164.需求工程现状需求工程工具1.基于操作方法需求工程工具GIST:是一种非确定性规格说明语言.使用它可为一个有待原型化的系统产生一个形式化的、可执行的规格.PAISLey:由PamelaZave在马里兰大学及后来在AT&T贝尔实验室开发的需求分析工具STATEMATE:由I-logic公司在1980年于曼彻斯特开发,是为了获得一个被Harel称为状态流图(statechart)的有限状态机的扩充.此外：JSD,RSL/RSA方法。共同特点即它们昀终结果是严格的形式化需求规格,对快速原型提供支持,需求能得到及时的验证和反馈.可执行规格和原型技术无疑为RE提供了很好的实现途径.Slide17Slide174.需求工程现状需求工程工具1.基于操作方法需求工程工具GIST:是一种非确定性规格说明语言.使用它可为一个有待原型化的系统产生一个形式化的、可执行的规格.PAISLey:由PamelaZave在马里兰大学及后来在AT&T贝尔实验室开发的需求分析工具STATEMATE:由I-logic公司在1980年于曼彻斯特开发,是为了获得一个被Harel称为状态流图(statechart)的有限状态机的扩充.此外：JSD,RSL/RSA方法。共同特点即它们昀终结果是严格的形式化需求规格,对快速原型提供支持,需求能得到及时的验证和反馈.可执行规格和原型技术无疑为RE提供了很好的实现途径.Slide18Slide184.需求工程现状需求工程工具2.基于知识的需求工程工具RA-RequirementApprentice:由MIT研究人员开发的基于知识的系统,为需求的开发提供了一个智能助手.TMMRP-TechnologytoManageMultipleRequirementPerspective:基于元模型(metamodel)对各种不同需求进行管理的工具.QARCC-QualityAttributeRiskandConflictConsultant:用于系统生命周期的早期以检测潜在的冲突.PROMIS:是中国科学院数学所设计的一个MIS开发环境,其