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

需 求 工 程,金芝 中国科学院数学与系统科学研究院 zhijin,第二讲：需求工程过程,目的：介绍为软件加强型系统中的复杂软件设计的需求工程过程，涉及 抽取需求 分析需求 验证需求 管理需求 主要关注点：需求工程中要做些什么,主要内容,相关概念 需求工程的输入与输出 需求工程过程模型 需求抽取和分析 需求验证和管理,相关概念：需求工程过程,一组活动的有序集合，主要包括： 需求抽取 需求分析和协商 需求验证 定义过程 为了能够组织和控制过程的进程，达到可控可预测的目的， 为了便于发现并在发现问题之后能够改进过程 存在普适的需求工程过程吗？ 不存在。根据要开发的系统、组织文化、参与需求工程的人员的经验水平定义自己的过程,活动的任务定义 活动的计划安排 执行活动的参与者 活动的输入输出 支持活动的工具,相关概念：需求文档,谁需要？客户、最终用户和软件开发者 系统需求的陈述：正式的、确定的、官方的 相互使用的表述词：需求定义、功能规格说明、软件需求规格说明,需求文档包含什么,系统应该提供的服务和功能 系统运行环境的约束，比如，硬件平台 系统的总体特性 关于系统的应用领域的情况 对用于开发系统的过程的约束,需求文档被谁需要,说明需求 检查是否满足需要 说明需求的变化,计划系统的标书 计划系统的开发过程,理解要开发是什么系统,为系统开发验证测试,帮助理解系统 帮助理解系统各部分之间的关系,系统客户,项目经理,系统工程师,系统测试工程师,系统维护工程师,需求文档的格式标准例,introduction purpose of the requirements document scope of the product definitions, acronyms and abbreviations references overview of the remainder of the document general description product perspective product functions user characteristics general constraints assumptions and dependencies specific requirements covering functional, non-functional and interface requirements. these should document external interfaces, functionality, performance requirements, logical database requirements, design constraints, system attributes and quality characteristics appendices index,相关概念：需求相关者,那类人? 将受到待开发的系统影响的人或者组织和部门 直接或间接影响系统需求的人 具体地说 系统的最终用户、经理以及受到待开发的系统影响的组织过程的参与者 负责系统开发和维护的工程师 将使用系统来提供服务的客户 和组织打交道的外部机构,相关概念：需求相关者,自动铁路信号系统 负责运行信号系统的火车公司运营者 铁路经理 旅客 火车车组成员 设备安装和维护工程师 安全认证机构,外部机构,最终用户,受影响的人,相关概念：需求和设计的关系,需求：“什么”涉及系统的目的 对计算机系统来说是外部的 是问题域的特性 设计：“怎样”涉及计算机系统的结构和行为 对计算机系统是内部的 是计算机系统领域的特性 在某个抽象层次上的“怎样”形成下一个层次上的“什么”,相关概念：需求管理,管理需求变化的过程 系统需求相关者的需要的变化 系统将运行于其中的环境的变化 系统将支持的业务的变化 法则和规章的变化，等等 变化管理的活动 变化控制：采集、验证、评估变化 变化影响评估： 变化将怎样影响到整个系统 某个需求的变化是否会影响到其它需求 支持可追踪性,系统工程,为什么需要系统工程方法？ 软件加强型系统的涌现特性 涌现特性包括： 可依赖性 可维护性 性能 可用性 安全性，等等 需求工程不仅仅涉及系统的功能性,所有子系统集成起来形成一个整体时才表现出来的特性,系统工程过程,系统工程过程活动,需求工程过程,过程模型 需求工程过程中的角色 过程支持 过程改进,什么是过程,结构性：一组有组织的活动 目的性：将输入转换成输出 作用： 结构性帮助处理复杂问题 过程定义帮助问题求解知识的重用,过程的输入与输出,过程的输入,存在系统的信息：要被替换的系统或者目标系统将与之交互的系统的功能 需求相关者的需要：系统的需求相关者在什么方面需要目标系统来支持他们的工作 组织标准：组织中涉及系统开发实践和质量管理等方面的标准 规章条例：适用于系统的诸如健康和安全条例等外部规定 领域信息：关于系统的应用领域的一般信息,过程的输出,一致同意的需求：关于系统需求的描述，这个描述对需求相关者来说是可理解的，并且已经得到他们的同意 系统的规格说明：在某些情况下可被实现的系统功能的更详细的规格说明 系统模型：一组从不同方面描述系统的模型，比如，数据流模型、过程模型、等等,图书馆信息系统,已存在系统的信息：假设软件系统必须与条码机系统相连，现在条码机已经有了，而且可以在处理相关事务请求时产生条码的队列。来自条码机系统的需求可能会是：“图书馆信息系统将与条码机系统对接，并且每隔两秒钟处理完队列中的所有事务请求。” 需求相关者的需要：假设需求相关者是图书馆的一个读者，他以前没有使用过这样的系统，他的需要可能会是：“系统应该提供读者指南，向图书馆的新读者解释系统的设施，从所有读者的使用界面上都应该能够看到这个指南。”,图书馆信息系统,组织的标准：假设这个图书馆的所有系统都使用相同的硬件平台，关于这一点的需求可能是：“系统将在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% 职工竞争力的效果 增加士气、减少人员变动 更好的估计和安排（更多的关于缺陷点的知识） 更好的对职工能力的管理上的认识,模型验证,前提：需求文档中包含系统模型，如， 系统功能的数据流模型、 对象模型、 事件模型、 实体-关系模型、等等 目的： 证明每个个体模型是自一致的 如果存在多个模型，证明这些模型是内外一致的 证