第03章 需求工程.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,软件工程,第,3,章 需求工程,内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,Alan Davis,把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”,Herb,定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理,Matthias Jarke,和,Klaus Pohl,提出了三阶段周期的说法：获取、表示和验证,需求工程,本书将软件需求工程细分为：,需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理,需求工程,需求获取,系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定,:,系统或产品范围的限制性描述,与系统或产品有关的人员,特征列表,系统的技术环境的描述,系统功能的列表及应用于每个需求的领域限制,描述不同运行条件下系统或产品使用状况的应用场景,为更好地定义需求而开发的任意原型需求获取的工作产品为进行需求分析提供了基础,需求分析与协商,需求分析：,对需求进行,分类组织,，,分析,每个需求之间的关系,，,检查,需求的一致性,、,重叠和遗漏,的情况，,并根据用户的需要对,需求进行排序,。

需求协商：,在需求获取阶段，经常出现以下问题：,用户提出的要求超出软件系统可以实现的范围或实现能力；,不同的用户提出了相互冲突的需求,系统建模,建模工具,在用户和系统分析人员之间建立了统一的语言和理解的,桥梁,.,系统分析人员借助建模技术，对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图常用的分析和建模方法有,:,面向数据流方法,面向数据结构方法,面向对象的方法,需求规约,需求规约是分析任务的最终产物，通过建立完整的,信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,，给出对目标软件的各种需求需求规约作为用户和开发者之间的一个,协议,，在之后的软件工程各个阶段发挥重要作用需求验证,作为需求开发阶段工作的复查手段，需求验证对功能的,正确性、完整性和清晰性,，以及其它需求给予评价为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行在实际的开发过程中，,获取、分析、建模、编写规约和验证,这些需求开发活动不会是线性地、顺序地完成实际上，这些活动是交叉的、递增的和反复的需求分析过程,需求管理,需求工程包括,获取、分析、规定、验证和管理软件需求,，而“软件需求管理”则是对所有相关活动的规划和控制。

换句话说，需求管理就是：,一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求，达成并保持一致的过程内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,软件需求包括,功能需求,性能需求,用户或人的因素,环境需求,界面需求,文档需求,数据需求,资源使用需求,安全保密要求,可靠性需求,软件成本消耗与开发进度需求,其他非功能性要求,需求获取方法与策略,建立顺畅的通信途径,访谈与调查,观察用户操作流程,组成联合小组,用况,（,Use Case,）,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性一般按照如下原则进行准备：,所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；,不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；,提问和回答在汇总后应能够反映用户需求的全貌观察用户操作流程,到用户的实际工作环境中,:,对用户的工作流程进行观察,了解用户实际的操作环境、操作过程和操作要求,对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

组成联合小组,便利的应用规约技术,(Facilitated Application Specification Techniques,FAST),：,打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，,发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调,FAST,基本原则,在中立的地点举行由开发者和用户出席的会议；,建立准备和参与会议的规则；,建议一个足够正式的议程以便可以进行自由的交流；,一个“协调者”,(,他可以是用户、开发者或其他外人,),来控制会议；,使用一种“定义机制”,(,它可以是工作表、图表、墙上胶黏纸或墙板,),；,目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求FAST,会议 步骤,1),确定一个,FAST,会议的时间地点，并在会议日之前将产品请求发布给所有的与会者2),要求每个,FAST,出席者，会前列出一组围绕系统环境、对象的操作、对象之间的交互功能，并列出约束列表,(,如，成本、规模大小、权重,),和性能标准列表,(,如，速度、精度,),这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。

3),进行,FAST,会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想在建好所有主题的组合列表后，开始讨论活动缩短、加长或重新组合列表以适当地反映将被开发的产品FAST,会议 步骤,(,续,),一旦创建了意见一致的列表,应该将团队分为更小的小组，,每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）每个小组然后将他们开发的每个小规约提交给所有的,FAST,出席者讨论，进行添加、删除或进一步的精化等工作在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用5),在小规约完成后，每个,FAST,小组提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表这个列表作为需求获取的结果，为需求分析和建模提供基础信息用况,（,Use Case,）,当需求收集起来后，分析员就可以创建一组标识串，构造系统的使用场景创建用况模型的主要步骤如下：,确定谁会直接使用该系统，即参与者（,Actor,）,选取其中一个参与者,定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况,对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程,描述该用况的基本过程,内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求分析原则,1,必须能够表示和理解问题的信息域,2,必须能够定义软件将完成的功能,3,必须能够表示软件的行为,(,作为外部事件的结果,),4,必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节,5,分析过程应该从要素信息移向细节信息,信息域,信息域：,包括,信息内容、信息流、以及信息结构,。

信息内容,表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等,信息流,表示了,数据和控制,在系统中流动时的变化方式，输入对象被变换为中间信息,(,数据和,/,或控制,),，然后进一步被变换为输出,信息结构,表示了各种数据和控制项的内部组织,数据或控制项将被组织为,n,维表还是树形结构？,在结构的语境内，什么信息是和其他信息相关的？,信息包含在单个结构中，还是使用不同的结构？,在某信息结构中的信息如何和在另一个结构中的信息相关？,信息域,抽象、分解与多视点分析,问题抽象方法,要求分析人员在分析过程中捕捉用户描述或问题本身固有的,一般,-,特殊关系,首先关注一般问题的解决途径，进而指导特殊问题的解决方法问题分解,的目的是要能以层次化的方式对问题进行分解和不断细化较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析,分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分,例如,横向分解,纵向分解,抽象、分解与多视点分析,需求协商,协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案,协商不是简单的逻辑或技术上的争论,要注意组织和行政方面的因素,不一致的目标,责任的丧失或转移,组织文化,组织管理态度和士气,部门差异,通常会议是解决冲突最快的方式,参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员,会议应该讨论那些非正式讨论不能解决的问题,通常会议分为三个阶段：,叙述阶段,讨论阶段,决策阶段,需求协商,需求建模,在软件需求分析阶段，所创建的模型，要着重于描述系统要,做什么,，而不是,如何去做,目标软件的模型不应涉及软件实现细节,常用的分析方法：,面向数据流的结构化分析方法,(SA),面向数据结构的分析方法,面向对象的分析方法,(OOA),需求建模,内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求规约的原则,1,从现实中分离功能，即描述要“做什么”而不是“怎样实现”。

2,要求使用面向处理的规约语言，定义一个行为模型，从而得到“做什么”的规约3,整个系统都包括在规格说明的描述之中4,规约必须包括系统运行环境需求规约的原则,(,续,),5,规约必须是一个认识模型，而不是设计或实现的模型6,规约必须是可操作的7,规约必须允许不完备性并允许扩充8,规约必须局部化和松散耦合需求规约,.,引言,A.,系统参考文献,B.,整体描述,C.,软件项目约束,.,信息描述,A.,信息内容表示,B.,信息流表示：,数据流,控制流,.,功能描述,A.,功能划分,B.,功能描述：,处理说明,限制局限,性能需求,设计约束,支撑图,C.,控制描述,控制规约,设计约束,.,行为描述,A.,系统状态,B.,事件和响应,.,检验标准,A.,性能范围,B.,测试种类,C.,期望的软件响应,D.,特殊的考虑,.,参考书目,.,附录,需求验证,需求验证目的是要检验需求是否能够反映用户的意愿,评审人员评审时往往需要检查以下内容：,系统定义的目标是否与用户的要求一致；,系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；,被开发项目的数据流与数据结构是否确定且充足；,主要功能是否已包括在规定的软件范围之内，是否都已充分说明；,设计的约束条件或限制条件是否符合实际；,开发的技术风险是什么；,是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

内容摘要,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求管理,需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动,需求跟踪有两种方式，正向跟踪与逆向跟踪,正向跟踪：,以用户需求为切入点，检查,需求规约,中的每个需求是否都能在后继工作产品中找到对应点,逆向跟踪：,检查设计文档、代码、测试用况等工作产品是否都能在,需求规约,中找到出处,软件需求工程：,需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理,本章小结,。