中科院需求工程 需求工程（第二讲）需求工程过程_.ppt

需 求 工 程,金芝中国科学院数学与系统科学研究院,第二讲：需求工程过程,目的：介绍为软件加强型系统中的复杂软件设计的需求工程过程，涉及抽取需求分析需求验证需求管理需求主要关注点：需求工程中要做些什么,主要内容,相关概念需求工程的输入与输出需求工程过程模型需求抽取和分析需求验证和管理,相关概念：需求工程过程,一组活动的有序集合，主要包括：需求抽取需求分析和协商需求验证定义过程为了能够组织和控制过程的进程，达到可控可预测的目的，为了便于发现并在发现问题之后能够改进过程存在普适的需求工程过程吗？不存在。根据要开发的系统、组织文化、参与需求工程的人员的经验水平定义自己的过程,活动的任务定义活动的计划安排执行活动的参与者活动的输入输出支持活动的工具,相关概念：需求文档,谁需要？客户、最终用户和软件开发者系统需求的陈述：正式的、确定的、官方的相互使用的表述词：需求定义、功能规格说明、软件需求规格说明,需求文档包含什么,系统应该提供的服务和功能系统运行环境的约束，比如，硬件平台系统的总体特性关于系统的应用领域的情况对用于开发系统的过程的约束,需求文档被谁需要,说明需求检查是否满足需要说明需求的变化,计划系统的标书计划系统的开发过程,理解要开发是什么系统,为系统开发验证测试,帮助理解系统帮助理解系统各部分之间的关系,系统客户,项目经理,系统工程师,系统测试工程师,系统维护工程师,需求文档的格式标准例,IntroductionPurpose of the requirements documentScope of the productDefinitions,acronyms and abbreviationsReferencesOverview of the remainder of the documentGeneral descriptionProduct perspectiveProduct functionsUser characteristicsGeneral constraintsAssumptions and dependenciesSpecific requirementsCovering functional,non-functional and interface requirements.These should document external interfaces,functionality,performance requirements,logical database requirements,design constraints,system attributes and quality characteristicsAppendicesIndex,相关概念：需求相关者,那类人?将受到待开发的系统影响的人或者组织和部门直接或间接影响系统需求的人具体地说系统的最终用户、经理以及受到待开发的系统影响的组织过程的参与者负责系统开发和维护的工程师将使用系统来提供服务的客户和组织打交道的外部机构,相关概念：需求相关者,自动铁路信号系统负责运行信号系统的火车公司运营者铁路经理旅客火车车组成员设备安装和维护工程师安全认证机构,外部机构,最终用户,受影响的人,相关概念：需求和设计的关系,需求：“什么”涉及系统的目的对计算机系统来说是外部的是问题域的特性设计：“怎样”涉及计算机系统的结构和行为对计算机系统是内部的是计算机系统领域的特性在某个抽象层次上的“怎样”形成下一个层次上的“什么”,相关概念：需求管理,管理需求变化的过程系统需求相关者的需要的变化系统将运行于其中的环境的变化系统将支持的业务的变化法则和规章的变化，等等变化管理的活动变化控制：采集、验证、评估变化变化影响评估：变化将怎样影响到整个系统某个需求的变化是否会影响到其它需求支持可追踪性,系统工程,为什么需要系统工程方法？软件加强型系统的涌现特性涌现特性包括：可依赖性可维护性性能可用性安全性，等等需求工程不仅仅涉及系统的功能性,所有子系统集成起来形成一个整体时才表现出来的特性,系统工程过程,系统工程过程活动,需求工程过程,过程模型需求工程过程中的角色过程支持过程改进,什么是过程,结构性：一组有组织的活动目的性：将输入转换成输出作用：结构性帮助处理复杂问题过程定义帮助问题求解知识的重用,过程的输入与输出,过程的输入,存在系统的信息：要被替换的系统或者目标系统将与之交互的系统的功能需求相关者的需要：系统的需求相关者在什么方面需要目标系统来支持他们的工作组织标准：组织中涉及系统开发实践和质量管理等方面的标准规章条例：适用于系统的诸如健康和安全条例等外部规定领域信息：关于系统的应用领域的一般信息,过程的输出,一致同意的需求：关于系统需求的描述，这个描述对需求相关者来说是可理解的，并且已经得到他们的同意系统的规格说明：在某些情况下可被实现的系统功能的更详细的规格说明系统模型：一组从不同方面描述系统的模型，比如，数据流模型、过程模型、等等,图书馆信息系统,已存在系统的信息：假设软件系统必须与条码机系统相连，现在条码机已经有了，而且可以在处理相关事务请求时产生条码的队列。来自条码机系统的需求可能会是：“图书馆信息系统将与条码机系统对接，并且每隔两秒钟处理完队列中的所有事务请求。”需求相关者的需要：假设需求相关者是图书馆的一个读者，他以前没有使用过这样的系统，他的需要可能会是：“系统应该提供读者指南，向图书馆的新读者解释系统的设施，从所有读者的使用界面上都应该能够看到这个指南。”,图书馆信息系统,组织的标准：假设这个图书馆的所有系统都使用相同的硬件平台，关于这一点的需求可能是：“系统将在Sun服务器Solaris 2.0操作系统上运行。”规章：诸如健康和安全这类的规章很可能对图书馆这类的系统有很大影响，数据产权保护法则也是如此，关于数据产权保护的需求可能会是：“这个系统将包括打印所有由图书馆用户自己维护的个人信息的设备。”领域信息：这是适用于所有起码是大多数图书馆系统的通用信息，领域需求的一个例子可能会是：“所有的书都由一个10位数字的国标码唯一地标识。”,需求工程过程模型,过程模型：过程的简化描述过程模型的类型粗粒度模型：活动的大致的序列、给出活动的上下文、显示过程的输入和输出细粒度模型：特定过程的细化模型、用于理解和改进存在的过程角色-活动模型：刻画参与过程的不同角色，以及他们进行的活动实体-关系模型：显示过程的输入、输出、中间结果、以及它们之间的关系，用于质量管理系统，作为过程活动的补充,粗粒度纯线性模型,粗粒度线形迭代模型,线形迭代模型中的活动,需求抽取：也叫需求获取和需求发现通过咨询发现系统需求咨询方：需求相关者、系统文档、领域知识、市场研究需求分析和协商：详细分析需求冲突不可避免，不同的来源、信息不完整、需求与项目预算不配套有一些需求是灵活的，不同需求相关者进行协商以确定那些是可接受的需求，解决冲突需求文档化：将一致接受的需求写成文档需求验证：检查需求的一致性和完整性，从文档中发现需求中的问题,粗粒度线形迭代模型,需求管理,需求工程过程的螺旋模型,非形式的需求陈述,一致同意的需求,需求文档草稿,需求文档和验证报告,过程模型：角色-活动模型,过程支持,建模和验证工具以结构化方法为基础，如：SADT，RSL以数学模型为基础，如：VDM，Z管理工具需求管理的CASE工具：DOORS，RML，Requisite Pro,一个需求管理系统,过程改进,目标：质量改进日程缩减资源缩减主要涉及的问题过程成熟度需求过程的成熟度模型初始级：经验式需求工程，常常出现需求的问题可重复级：标准化需求工程；较少的需求问题定义级：定义明确的基于最好的实践的过程，恰倒好处的过程改进,过程的作用,规定需求工程要进行的活动定义活动的输入/输出管理和控制需求工程进程明确岗位的职责和任务（过程和角色挂钩）通过过程控制保证需求的质量,需求抽取和分析,抽取和分析过程抽取技术需求分析和协商,抽取分析和协商螺旋,需求抽取过程,开始点存在一个“问题”需要解决，例如：对当前的事务处理方式不满意出现新的业务机会有可能节省开销、时间、资源的使用、等需求工程师是带来变化的代理人,W6H（记者的技巧）What、Where、Who、Why、When、How、Which,需求抽取过程的关键活动,设定目标：组织和业务目标获取背景知识：应用领域知识组织知识：将获取的知识组织起来采集需求相关者的需求：咨询需求相关者,需求抽取过程,需求分析过程,目标：发现初步需求中的冲突主要活动：必要性检查一致性和完整性检查可行性检查,需求协商过程,目标：确定能得到一致同意的需求主要活动：需求讨论需求优先化达成一致意见的需求的确认,需求分析和协商过程,需求抽取涉及的因素,应搜集什么信息从什么来源中搜集信息用什么机制或技术搜集信息,需求抽取的四个纬度,理解应用领域,理解问题,理解业务,理解系统需求相关者的需要和要满足的约束,需求抽取涉及的因素,应搜集什么信息从什么来源中搜集信息用什么机制或技术搜集信息,需求的来源,客户（实际的或潜在的）任何原有的解系统及其文档原有系统的用户新系统的潜在用户应用领域专家相关的技术标准和法规,与客户沟通的重要性,成功的项目都与客户有更多的联系,使用的联系与所有可能的联系的百分比,需求工程师要做什么,标识“问题”/“机会”那个问题需要解决？（识别问题边界）问题在什么地方？（理解上下文/问题领域）软件系统会起到怎样的作用？（采集一些情景）是谁的问题？（识别投资人）为什么需要解决它？（识别投资人的目标）它需要什么时候解决？（识别开发约束）什么会防碍我们解决它？（识别可行性和风险）抽取足够的知识（没有量化标准）足以分析需求：有效性、一致性、完整性变成问题领域的专家,功能需求,非功能需求,深层次需求,抽取的困难,领域知识非常薄弱知识可能分布在许多地方，并很少以显式的形式表示出来（写出来）来自不同地方的知识之间将会有矛盾不同的人有不同的目标，不同的人对问题的理解不同经验知识人很难描述他们日常使用的知识描述会是专家行为的不准确的理性化有限的观察问题拥有者可能太忙，没时间用存在的系统去解决它出现一个观察可能会改变这个问题偏见人可能不方便告诉你你需要知道什么人可能不想告诉你你需要知道什么,需求抽取涉及的因素,应搜集什么信息从什么来源中搜集信息用什么机制或技术搜集信息,需求抽取机制或技术,头脑风暴面谈法联合应用开发问卷法任务观察用例和场景,交谈法,类型结构式：需要提前准备，具有明确的日程，预先确定好问题，开放式：非正式会议、没有事先准备的问题和预计的目的、鼓励客户讲出他们自己的想法优点能采集到丰富的信息缺点大量定性的数据可能很难分析不同的回答难以比较交谈的技巧很难掌握注意三种问题需要避免：固执己见的问题、带偏见的问题、强加的问题经验性知识不好谈出来交谈者的态度会影响交谈的结果,直接表达了自己的关于这个问题的观点：“我们必须”,同上，但观点明显有偏见：“我们不做，对吗？”,假设了问题的答案：“你是用这种方式做，对吗？”,交谈形式举例,正向模拟：选择典型业务情景（初始情况），请用户说明工作过程；陈述过程中不断提炼并提问新情况案例分析：请用户选择有代表性的业务情景（初始情况），并说明工作过程；陈述过程中不断提炼并提问新情况局外评论：存在现有系统，请用户对正在进行的过程进行评论知识反教：在获取一些信息后，按照自己的理解表述给用户，请用户判断正确与否,交谈过程,准备：被咨询人咨询目标制定计划（按逻辑方式分组和排序的问题）记录检查和理解考虑的因素：影响效率的因素（持续的时间），信息确认（重复面谈）、被咨询人的因素、操作：简单友好的气氛、只关注技术上问题、提问技巧（问题不要影响合作态度）,交谈过程要考虑的问题,待解决的问题开发解决方案的过程谁出钱开发想要这个系统的基本原因是什么交付日期和成本之间的权衡是什么是否在某个日期之后系统将没有价值成本和可靠性之间的权衡是什么需求获取本身,交谈过程要考虑的问题,待解决的问题开发解决方案的过程需求获取本身我的问题看起来相关吗？你的回答正式吗？你是回答这些问题的最佳人选吗？我问的问题太多吗？还有其它问题需要问吗？我还应该见什么人？,问卷法,形式：事先准备好问卷，发给许多相关人员优点：快速地从多个客户中收集信息可以远程进行回答者有时间思考、回答可以匿名缺点：没有面谈法有效，是被动的按问题的简单分类，提供很少的上下文信息回答者不容易弄清楚问题的含义和出发点,问卷法,注意（问卷分析）样本选择中的偏差问卷回答人选择的偏差小样本规模、缺少统计上的意义要避免的问题引导性问题模糊的问题（不是每个人都回答同样的问题）一般采用的问题形式多项选择评分排序,观察法,任务：主要关注用户与某个先行系统的交互，解决人们面谈时对如何完成任务的描述的限制和不准确事先决定观察什么（目标、人员、地点）事后对观察结果进行分析形式：主动观察：浸入式观察（人种论：观察者必须融入到工作中）被动观察：旁观式观察注意：时间相对较长，分析非常耗时，因此非常昂贵选择不同时间段、不同工作负荷时的场景,组抽取技术,类型联合应用开发/快速应用开发具有关注点的组大脑风暴注意样本偏差支配地位和服从,优点比形式的面谈具有更自然的交互能够判定对一些初步设计的反映（原型、使用情节串联图、等）群体动力学原理、组协同（提高生产力、学得更快、制定更多理智的判断、消除更多的错误、）缺点组的构成可能不够自然（参与者在一起感到不舒服）对技术问题可能只提供粗略的反映要求有受过正规训练的组织者,联合应用开发（JAD）,特点：将所有的客户和开发人员召集到一起（不超过25到30人）形式：几个小时、几天、甚至一到两个星期的JAD会议参加者：领导：组织和召集这个会议的人（具有交流能力，很好的业务领域知识）文书：在计算机上记录JAD活动，能够使用CASE工具为活动生成文档，并开发出最初的解决方案模型客户（最终用户和经理）：是交流、讨论需求、作出决策、批准项目目标等的主要参与者开发人员：业务分析员等，他们听得多说得少，主要是收集信息,快速应用开发（RAD）,特点：组合了五个方面的技术进化原型技术带有代码生成，以及支持设计和代码生成循环工程的CASE工具拥有先进工具的专门人员SWAT（Skilled Workers with Advanced Tools）交互式JAD：一般JAD中的文书由具有CASE工具的SWAT小组代替时间表：具有固定的时间期限、严格禁止“范围扩张”、进展缓慢就削减方案、按时完成是第一位的,不仅仅是需求抽取方法，还是视软件开发为一体的方法。,需求抽取中的原型法,原型：演示型系统呈现图形用户界面提供对各种用户事件的模拟行为“丢弃”式原型目的：帮助抽取和开发系统需求对象：客户陈述有困难的需求，难以理解的需求进化式原型目的：快速开发可运行的系统对象：定义明确的需求，针对有用的功能的需求,文档的研究,组织文档业务表格、工作过程、职位描述、政策手册、业务计划、组织图、会议记录、财务报表、系统文档计算机屏幕、各类录入表单、各类打印报表、领域知识需求领域刊物、书籍、参考手册、,“硬数据”的采集,标识硬数据的集合事实、图表、财务信息、用于决策分析的报表、调查结果、市场数据、抽样抽样用来从中选择有代表性的集合有目的的抽样：选择不担心统计问题，你也认为是相关的部分简单随机抽样：每隔k项选择一个分层随机抽样：先分层次、再抽样聚簇随机抽样：选择一个有代表性的子数据集，再抽样样本规模非常重要要进行数据采集和分析的代价以及所需要的明显度之间的平衡,用例抽取,什么是用例？参与者与系统交互的每种不同的方式都是一个用例对一个特定的参与者，产生一个可观察的结果的系统执行的行为序列的描述所有的用例都需要枚举出来，否则需求将会不完整带有共同的目的的可能的情景的集合描述一般用自然语言书写不含系统的内部状态；只包含交互,组合用例的方式扩展/使用优点和缺点所有可能的与系统的交互的详细特征帮助画出系统的边界，和规定需求的范围用例并没有捕获领域知识不能将用例和精确的规格说明混为一谈,系统行为是当系统响应外部事件时所做的事情用例捕获从外表上可见并可测的系统行为一个用例执行一个业务功能，该功能对参与者来说是外表上可见的,用例图,图元：参与者用例连接：表示参与者和用例之间的关联,用例的用途,画系统边界识别系统边界外与系统发生交互的参与者对每个参与者，做：识别可能的用例做出示例每个用例的具体的情景将相似的情景组合起来成为一个用例对每个用例，做：将它写出来说明选择和循环的规则考虑其它选择和例外查看与其它用例的重叠和共同点,用例框架用例名：简述：参与者：前提条件：描述：例外：后置条件：,用例文档,用例：订购计算机简述：该用况允许Customer输入一份购物定单，该定单包括提供运送和发票地址，以及关于付款的详细情况参与者：客户前提条件：客户点击Internet浏览器进入计算机制造厂商的定单输入web页面，该页面显示已配置计算机以及它的价格的详细情况。主要的流：当客户在定单信息已经显示在屏幕上时选择继续（或相似命名的）功能键来确定订购所配置的计算机时，该用例开始。系统请求客户输入购买细节，包括：销售人员的名字（如果知道的话），运送信息（客户的名字和地址），发票细节（如果与运送地址不同的话），付款方法（信用卡或支票），以及任何其它注释。客户选择购买（或相似命名的）功能发送定单给制造厂商。系统给购买定单赋予一个唯一的定单号码和一个客户帐号，系统将定单信息存入数据库。系统将定单号和客户号与所有定单细节一起e-mail给客户，作为对接收定单的确认。其它的流：客户在提供所有要求录入的信息之前，激活购买（或相似命名的）功能，系统显示错误信息，它要求提供所漏掉的信息。客户选择恢复（或相似命名的）功能来恢复一个空白的购物表格，系统允许客户重新输入信息。后置条件：如果用况成功，购物定单记录进系统的数据库，否则系统的状态不变。,从用例文档中识别情景,情景（活动序列）参与者和系统之间交互的特定序列比较短的序列（一般为3到7步）可以是：正方的（需要的行为）和反方的（不想要的行为）可以是陈述的或希求的优点：非常自然：投资人喜欢使用短的情景对快速示例特定的交互非常好缺点：缺乏结构：需要用例或任务模型提供更高层的视点,活动图,几种常用方法的比较,需求抽取技巧和注意事项,评估系统可行性注意组织和行政方面的因素识别和咨询系统的项目相关人员记录需求源使用业务关系来驱动需求抽取寻找领域约束,记录需求理由从多视点收集需求原型化难以理解的需求使用场景来抽象需求定义操作过程复用需求,评估系统可行性,目的：揭示是否真正需要一个系统实施：问题举例我们真正需要这个系统吗？如果没有开发这个系统会产生什么影响？采用什么直接或间接方法会使系统对我们的业务目标有意？系统必须支持哪些关键过程？系统不必支持哪些关键过程？系统会如何影响其他已经安装的系统？我们可能会面对的技术限制是什么？可以在预算范围之内开发出一个有用的系统吗？时间期限：完全新的中型系统：一个月完成取代现有系统：较少的工作量,注意组织和行政方面的因素,目的：有助于理解一些需求被建议的原因实施：应该留意的因素不一致目标责任的丧失或转移组织文化组织的管理态度和士气部门差异,识别系统的项目相关人员,目的：发现所有可能的需求源实施：可以使用的方法：发现系统的潜在最终用户考虑系统打算支持的业务过程描述以及与这些过程相关的人与组织部门进行讨论，询问谁会受到系统引入的影响考虑使用系统的组织和客户考虑负责开发和维护系统的工程师和维护人员考虑可能希望给系统添加需求的监管机构和认证机构,记录需求源,目的：来自初始需求源的需求可跟踪性实施：在需求收集表中增加一个栏目记录需求源（可能包括：人员、角色等）一个单独需求记录一个需求源一组相关需求记录一个需求源,使用业务关系来驱动需求抽取,目的：使得交付系统没有安装问题实施：收集如下信息：平台信息接口信息软件依赖性其他关于系统的位置和物理布局的信息面对的问题环境的不稳定性（操作系统、软件版本的变化等）,寻找领域约束,目的：领域约束经常会导致识别出关键需求实施：两类领域需求和约束涉及到所有其他需求的总体约束从领域相关事项导出的特殊需求相关领域信息领域知识的一个非正式的陈述领域知识的较形式化描述领域知识可适用的系统的类型，异常情况知识分类术语领域信息源,记录需求理由,目的：提高对需求的理解实施：非形式的描述结构化、超文本形式注意事项：使人误解的理由不一致的理由,从多视点收集需求,目的：更好的需求覆盖率实施：几种视点：与和系统相互作用的人或者设备相关联的交互者视点与从系统受益的人相关联的项目相关人员视点与领域信息相关联的领域视点步骤：识别组织对系统所关注的主要目标识别视点和视点源使用上述目标作为驱动力和校验表来从视点源抽取需求在需求可用后，反复从不同视点核查这些需求是否有冲突从不同视点集成这些需求来产生需求文档,原型化难以理解的需求,目的：更好地理解系统用户的真正需要实施：三种系统原型化方法纸上原型化方法“Wizard of Oz”原型化方法：模拟系统自动原型化方法：第4代语言，自动代码生成工具,使用场景来抽象需求,目的：用户易于理解场景和描述相关需求实施：场景可以看作是解释如何使用系统的经历。关于场景的信息：在进入场景之前系统状态的描述场景中正常的事件流正常事件流的异常可以同时运行的其他活动的信息场景完成后系统状态的描述,定义操作过程,目的：揭示过程需求和需求约束实施：过程描述是特别复杂的活动，两种情形下操作过程的定义：打算用系统来支持一个完全新的活动，没有现成的过程可以研究。关注新过程和现有过程的交互，定义新过程打算用系统来支持一个现有的操作过程，它将取代现有的过程。研究、理解现有过程，导出操作过程,复用需求,目的：较低的需求成本，较快的需求抽取实施：间接复用：识别与正在研究的系统的项目相关人员的需求接近或重叠的需求把这些需求展示给项目相关人员，解释它们的含义请他们说出哪些合适哪些不合适根据提出的建议改写需求，直到项目相关人员满意直接复用识别现有系统和待开发系统之间的通用特征，找出可复用的部分识别现有系统中潜在的可复用需求与识别出的通用特征相对应的需求评估这些潜在的可复用需求在待开发的系统中是否有效和用户一起检验这些需求是否真正满足他们的需要,需求分析和协商,目的发现系统需求中的问题统一各参与方的意见，对需求和需求的变化达成一致的意见,需求分析的检查表,过早的设计：是否包含设计或实现信息组合的需求：单一的需求还是可划分的需求不必要的需求：是否不是真的需要非标准的硬件：需要另外了解硬件软件平台与业务逻辑是否一致：需求二义性：不同的人有不同的理解需求现实性：在目前的技术条件下是否能实现需求可测试性：系统是否满足需求是可判断的,冲突从何儿来？,问题本身的不一致问题理解的不一致对解决程度的期望的不一致建模中的错误,归结冲突的形式,解决冲突的方法：协商、竞争、仲裁、强迫、教育能够区别三大类归结方法合作式方法，包括协商和教育竞争式方法，包括斗争、强迫和竞争第三方方法，包括仲裁和求助于权威,冲突归结方法（协商）,出发点：合作探索可能性的范围参与者试图发现进可能满足各方的方案还被认为是：集成式行为或者构造式协商区别于分布式或竞争式协商,冲突归结方法（竞争）,出发点：对一个参与者来说，实现最大满足度不考虑对其他方的满足度但不需要是敌对的极端形式当所有一方的获得都是其他方的开销即：0和博弈,冲突归结方法（第三方归结）,参与者呼吁外援规则手册、权威的意见、投硬币可能在将协商和竞争作为归结方法都失败时出现第三方归结的类型审判的：每个参与者提出的案例都被考虑外部的审判：一个不是提交案例的参与者确定这个决定仲裁：比如：投硬币,冲突归结方法（叫价和讨价还价）,叫价参与者陈述他们想要的条款讨价还价参与者寻找叫价的满意的集成,社会心理学关于冲突的原因,原因：一种观点对资源的控制偏好和厌恶（一方侵犯另一方的活动）价值（声明某种价值观或某组价值观应该为主）信念（对事实、信息、现实等的辩驳）参与方之间的关系的本质原因：另一种观点沟通的（信息交换不充分，有干扰，有选择的察觉）结构的（目标相容性，领导的风格，司法澄清）个人因素的（个体价值系统，个体特征）,社会心理学中的冲突,有趣的结果有偏差的行为和冲突在小的组决策制定中是正常的在沟通受限时有更多的侵犯、更少的合作沟通的减弱会加大冲突经验上异构的组会有更多的冲突；但同构的组很有可能会得出高风险的决策个性的效果会被情景的和感觉的因素所掩盖,使用辩论结构,gIBIS由Conklin在1989年开发将辩论过程表示为一个超文本图基本过程标识观点标识每个人可以作为位置来考虑的位置将辩论论点以支持或反驳某个位置的形式连接进来,gIBIS辩论结构,使用辩论结构,Synoptic由Easterbrooks在1991年开发支持合作的面向任务的协商的工具 基本过程让每个参与者将他们的概念模型外观化找出这些模型之间的对应点将不匹配的地方进行分类为归结每个不匹配的地方产生侯选方案,使用预先存在的领域模型,Oz由Robinson在1992年开发使用预先存在的领域模型来比较冲突的视点基本过程识别视点（信念的集合）通过标注一个目标和目的的领域模型来记录视点领域将产品属性连接到目标选择产品属性的组合，来最大化参与者的满意度,使用预先存在的领域模型,WinWin由Boehm和同事们在90年代中期开发显式地为每个参与者标识出赢的条件结合质量需求和产品属性链的领域知识库基本过程为每个参与者输入赢的条件为赢条件标识属性策略为每个赢条件的每个策略确定副效果手工归结不一致性,需求验证,需求审查需求验证中的原型法模型验证需求测试,需求验证过程,需求分析需求抽取阶段的“粗”需求通常非形式化非结构化的表示不完整、存在不一致解决“我们得到了正确的需求吗？”需求验证检查需求文档，完整的系统需求明显的不完整和不一致已经去掉文档的表述符合规范解决“我们是否把需求搞对了？”,需求验证过程：输入和输出,需求审查,阅读文档,识别错误和其它问题,检查确定的需求相关行为是否进行,进行得如何,需求审查的行为,模糊的需求 进一步澄清需求不完整 补充缺失的需求需求冲突 协商和冲突归结不现实的需求 咨询需求相关者 修改或去掉这个 需求,需求审查表,可理解性冗余性完整性二义性一致性组织结构与标准的符合性可跟踪性,组织审查的注意事项,规模“足够的人，使得相关的经验都有”最少：3（4如果写的人在的话）最多：7（如果领导没有经验的话，可以少一些）期限不要超过2个小时如果太长了注意力会漂移输出所有的审查员必须同意这个结果接受；重新工作；重新审查所有的发现都应该写下来总结报告（为了管理）问题的详细列表,范围关注于一小部分的设计，而不要是整个事情时间表一旦作者完成了一件产品就开始检查它不要太早产品还没有准备好发现作者已经意识到的问题不要太晚产品已经在使用错误要该就要花费很大代价目的记住最大的好处是来自于固定这个过程采集数据以帮助你下次不要犯同样的错误,审查指南,在审查之前将形式的审查安排进项目规划中训练所有的审查人保证所有的出席人都要提前准备在审查期间审查产品，而不是它的作者使意见是构造性的、专业的、以及和任务相关的严格按照日程进行领导必须防止拖延限制辩论和反驳记录下问题留着以后讨论，只识别问题，当时不要去试图解决它全要写下来在审查之后审查这个审查过程,选择审查人,可能的候选人审查方面的专业人员（比如，QA人员）来自与作者同一个开发小组的人因为有专业经验而被邀请的人对产品有兴趣的人有什么东西可以贡献的访问人员来自组织中其它部门的人要排除的人负责审查作者本人的任何人（比如，产品线经理、等）任何已经知道与其他审阅者有个人冲突的人任何没有资格来做这件事的人所有的管理人员任何其出现会带来兴趣上的矛盾的人,将审查结构化,能够将审查结构化为不同的形式经验的依赖于审查人的经验检查表使用一个关于问题/观点的检查表检查表被裁剪为文档的形式主动审查（基于观点的阅读）每个审查者从一个特定的目的来阅读，使用专门的问卷不同的审查者有效地采用不同的观点这些不同是有含义的比如，研究指明主动审查比经验的和检查表方法能发现更多的错误在经验式和检查表方法之间没有明显的不同会议式审查可能会是多余的,审查的好处,形式审查对程序设计有用对应用程序设计比测试更有效大多数审阅过的程序第一时间正确运行比较：是测试/调试方法的10-50的功效来自大项目的数据错误以5的系数减少(在某些报告的案例中是10)生产力的改进：14%到25%由审查发现的错误的百分比：58%到82%减少V&V的代价50%-80%职工竞争力的效果增加士气、减少人员变动更好的估计和安排（更多的关于缺陷点的知识）更好的对职工能力的管理上的认识,模型验证,前提：需求文档中包含系统模型，如，系统功能的数据流模型、对象模型、事件模型、实体-关系模型、等等目的：证明每个个体模型是自一致的如果存在多个模型，证明这些模型是内外一致的证明模型准确地反映了系统需求相关者的真实需求方式：需要CASE工具支持,需求管理,稳定和变化的需求需求变化的管理可追踪性,程序进化的法则,连续变化任何反映某种外部现实的软件经历连续的变化，或者逐步变得越来越没有用这个变化过程是连续的直到它被判定为比整个替代这个系统花费更多增加复杂度随着软件进化，它的复杂度会增加除非采取了控制复杂度的策略程序进化的基本法则软件进化？组织稳定性的法则在软件系统的活动生命期间，一个开发项目的工作输出粗略地说是一个常量（不考虑资源）家族性的法则在一个程序的活动生命期间，连续发布中的变化的量粗略地说是一个常量,需求增长,Davis的模型用户需要连续地变化将它表示为一个展示需要随时间增长的图可能不是线性或连续的（因此没有显示尺度）传统的开发总是滞留在需要增长之后首先发布仅仅是初始需求的部分实现功能的提升加进了新的功能性最后，进一步的提升变得开销太大，就要计划一个替代品替代还只是它的需求的部分实现等等,变化管理,关注：管理系统需求变化的步骤、过程和标准目的：保证对每个变化都采集相同的信息对所提出的变化就代价和好处进行全面评估要保证一致的变化管理，需制订变化管理策略：变化请求过程、处理每个变化请求时需要的信息用来分析变化的影响和代价的过程、相关的可追踪性信息正式考虑变化请求的个体的成员关系，独立的个体可以做出比较客观的评估支持变化控制过程的软件,变化管理过程,活动：书写文档、报告、分析、代价评估和实现变化,问题来自对需求文档的分析、新的客户需要、系统操作上的问题分析需求，提出需求变化的提议,分析所提出的变化会影响多少需求分析改变这些需求所需要的时间和费用,对需求文档进行修补，得出新的版本进行正常的质量检查,变化分析和代价评估,检查变化请求的有效性/合理性找出受变化请求直接影响的需求利用可追踪信息找出被变化影响的需求通过和客户协商，提出必须作用在需求上的变化估计进行这些改变的代价（时间、人力、需要的资源）通过与客户协商，确定代价是可接受的,可追踪性,类型后向可追踪性：从需求到需求的来源前向可追踪性：从需求到设计和实现组件向后可追踪性：从设计和实现组件到需求向前可追踪性：从需求的来源到需求,可追踪性表,小结,需求工程过程是一组活动的结构化序列，它产生用来说明待开发系统的需求文档。需求工程过程涉及需求抽取、需求分析和协商、和需求验证等活动。需求工程过程模型是从某个特定的角度出发构建的简化过程描述。需求抽取涉及对包含应用领域、要解决的问题、组织的需要和约束、以及系统相关者需要的辅助功能等在内的所有问题的理解。可以采用的技术包括面谈法、问卷法、情景法、软系统方法、原型法等。当出现需求重叠和冲突时需要进行需求协商。需求抽取、分析和协商是相互交织在一起的过程，在需求被所有需求相关者接受前，可能需要多次的重复。需求验证关注于检查需求文档的最终草案以发现其中的错误。最常用的需求验证方式是需求审查，检查表在组织需求验证过程中是一种有用的方式。原型法是需求验证的另一种有效的方法。需求变化是不可避免的，因而要求有有效的需求管理机制来管理这些变化。可追踪性信息记录了需求与需求的来源之间，需求之间，需求和系统设计之间等的依赖关系，这些依赖关系对变化影响分析至关重要。,谢 谢！,