| 需求工程:基础、原理和技术7 |
| 波尔(Klaus Pohl) |
| 计算机科学丛书 |
| 19：概念模型基础、20：基于模型的需求与文本化需求之间的关系、21：需求抽取基础、22：抽取技术、24：需求协商基础、25、冲突管理 |
第19章 概念建模基础
**注：本章简单解释了概念建模的基础信息，未深入讲解建模语言。
需要了解相关信息，可以寻找UML的书籍，以及领域驱动模型等。
19.1 物理模型vs.概念模型
区分两类模型：
❑物理模型：创建系统的物理模型的目的在于更好地理解和分析系统的属性。
❑概念模型：创建符号化的模型而非物理模型，以更好地理解和分析系统的属性。概念模型常使用图形化符号来刻画。
概念模型是对于当前或所构想的(即未来)的现实的抽象的(部分)描述。
用模型表达的当前或所构想的现实中的部分通常被称为“领域(domain)”或“论域(the universe of discourse)”:
定义19-1:论域
论域由所考虑到的当前或所构想的现实中的所有部分或方面而组成。
定义19-2:模型
模型是为特定的(使用)目的创建的论域的抽象表述。
概念模型则可以用于可视化地描述软件密集系统的特定方面。
19.2模型属性
概念模型展现了特定论域的信息。
描述性模型与指示模型二者均具有与论域的表示相关的两个核心属性：
❑精简：概念模型精简了所描述的论域信息。
❑扩展：概念模型通常通过定义附加的属性来扩展所描述的论域信息，这些附加属性在论域中是不可观测的。
其中，扩展或精简不应使模型对所表达的论域进行扭曲，即扩展和精简不应损害模型的质量。
19.2.1 消除无关细节
一个模型通常仅表达关于论域的部分信息。
精简由使用模型的意图驱动，并主要通过以下3种抽象机制来实现：
❑选取：选取论域的某些方面来用概念模型表示，并完全忽略其他方面。
❑聚合：将论域中的不同方面综合起来，并在模型中用浓缩的方式表达所聚合起来的方面。
❑分类/泛化：这种抽象机制识别出论域中一组方面的共性，同时消除它们之间的差异。
19.2.2 定义附加属性
附加属性的引入使得模型针对特定使用目的具有更好的易理解性和可管理性。
第20章 基于模型的需求与文本化需求之间的关系
20.1需求模型
需求制品可以使用自然语言或者概念建模语言进行文档化。
定义20-1:需求模型
需求模型是使用概念建模语言描述需求(目标、场景或者面向方案的需求)的概念模型。
| 表20-1 本书中所介绍的概念建模语言概览 | ||
| 需求类型 | 模型类型 | 所属章节 |
| 目标 | AND/OR目标树和图 | 8.4节 |
| i*模型 | 8.5节 | |
| KAOS目标模型 | 8.6节 | |
| 场景 | IL/SysML顺序图 | 11.5节 |
| L/SysML活动图 | 11.6节 | |
| L/SysML用况图 | 11.7节 | |
| 面向方案的需求：数据 | 增强的实体-关系模型 | 14.1.1节 |
| UML类图 | 14.1.2节 | |
| 面向方案的需求：功能 | 数据流图 | 14.2.1节/14.2.2节 |
| 面向方案的需求：行为 | 有限自动机 | 14.3.2节/14.3.3节 |
| 状态图 | 14.3.4节 | |
| UML/SysML状态机图 | 14.3.5节 | |
基于模型的需求描述的优点
与使用自然语言描述的需求相比，需求模型能够被更好地理解和记忆。
抽象化是建模语言的固有属性,有助于降低所构造模型的复杂度(与论域的复杂度相比),因此对论域复杂度的管理提供了支持。
通过提供预定义的抽象化机制，概念建模语言支持涉众关注于论域中相关的细节方面，同时消除不重要的细节。
对于用自然语言描述的需求规约，进行正确性、完整性以及一致性等质量属性的检查通常十分耗时且容易出错。
概念模型中定义的关系通常要比文本化需求文档中定义的关系更 加明显和易于理解。因此，涉众评审使用概念模型定义的需求时要比评审文本化的需求时更容易发现其中遗漏的和错误的关系定义。
20.2 需求模型与文本化需求的相互关系
使用自然语言和使用概念建模语言描述需求各有其优缺点。可以 通过同时使用这两种方式进行需求的文档化，从而将这两种文档化方式的优点结合起来。
20.3 可追踪性元模型
文本化需求和基于模型的需求制品之间的关系可以通过追踪关系进行描述。
可追踪关系类型
文本化需求制品和基于模型的需求制品之间存在不同类型的追踪关系。
表20-2 可追踪关系类型
| 关系 类型 | 解 释 | |
| 条件 | 约束 前置条件 | 这类可追踪关系表示一个(需求)制品为另一个(需求)制品定义了一种约束。例如，目标可以为场景定义约束 |
| 内容 | 相似 相比 矛盾 冲突 | 这类可追踪关系描述了相关的需求制品的内容之间或者需求制品与开发过程中的其他类型制品之间的依赖关系。例如，此关系类型可用于描述两个目标之间的冲突关系 |
| 抽象化 | 分类 聚合 泛化 | 这类可追踪关系描述需求制品之间的抽象化依赖。例如，这类关系可以描述一个目标对一组面向方案的需求的分类关系 |
| 演化 | 替代 满足 基于 形式化 精化 派生 | 这类可追踪关系描述了相关需求制品之间或者与开发过程中的其他制品之间的一种时序关系。例如，这类关系可以描述一个面向方案的需求是基于某个场景的 |
| 杂项 | 提供示例 验证 原理 负责 提供背景 注释 | 这类关系包括其他可以在开发制品之间定义的可追踪关系类型。例如，这类关系可以描述一个场景为一组面向方案需求的动态方面提供了具体的示例交互序列 |
20.4 概念模型和文本化需求之间的关系
模型元素和文本化需求之间的关系
通过使用可追踪关系，可以将单个模型元素关联到一个或者多个文本化需求上。
与目标相关的文本化需求可以更详细地定义需求，或者描述与该目标相关的上下文信息。
一组模型元素与文本化需求之间的关系
一个或者多个文本化需求可以与需求模型的一部分(甚至整个模型)相关联。
文本化需求和模型元素之间的关系
文本化需求也可以与单个模型元素或者模型的一个部分相关联。
一组文本化需求和模型元素之间的关系
可追踪关系也可用于关联一组文本化需求和一个(部分)需求模型甚至单个模型元素。 图20-11描述了3个文本化需求到目标模型中的两个目标的关联关系。例如，可以用这种关系说 明这些文本化需求包含了对两个目标的原理性解释。
模型元素的注解
概念性模型中的一个元素、一个概念需求模型的部分或者整个模型；都可以通过使用(部 分)概念模型与文本化注解之间的可追踪关系进行文本注解。因而，这种注解为模型元素提供 了额外信息。文本化注解可以包含概念模型无法描述的信息。
第21章 需求抽取基础
21.1 需求抽取的目标
需求抽取的目标是通过抽取新的需求以及细化现有需求的信息，从而在内容维度上取得进展。抽取活动的主要目标是在所要求的细节层次上为待开发系统抽取所有的需求。
需求以各种不同的形式存在，所需抽取的需求具有多种不同的来源。
在需求抽取期间考虑所有相关需求来源对于需求工程过程乃至整个开发过程的成功而言是根本性的。
3个子活动：
1寻找相关的需求来源
抽取活动的主要目标是从已知的需求来源中抽取现有的需求。
这一子活动致与系统分析中的当前状态分析相对应。
21.2 需求抽取的定义
定义21-1：需求抽取
需求抽取是3个核心需求工程活动之一。抽取活动的目标是：
1）识别相关的需求来源；
2）从所识别的来源中抽取现有的需求；
3）开发新的创新性需求。
21.3 需求抽取中目标和场景的使用
目标和场景非常适合于支持需求抽取
目标能够使得涉众可以快速、容易地刻画他们对于待开发系统的意图
原则上，目标模型非常适合在抽象层次上描述系统的目的。
场景描述了具体的系统交互，使得涉众可以描述满足所识别目标的具体示例。场景将需求置于上下文环境中，支持了涉众对需求的理解。
分析已描述的场景经常会导致发现新的目标和（或）对已描述的目标的调整。相反，目标
定义的变化通常也会导致新场景的抽取和（或）已描述的场景的修改。
提示21-1：使用目标和场景来抽取详细需求
>与各种不同涉众一起抽取和开发目标。
>通过描述目标满足的具体示例为已识别的目标定义场景。同时考虑相关目标未能满足的场景。
>分析场景并识别可能的新目标和/或目标精化.
>为新识别出来的和（或）精化得到的目标定义场景，并建立一种迭代的目标一场景开发周期。
>从已定义的目标和场景中导出面向方案的需求（即功能需求、质量需求和约束）。
>基于所识别的目标和场景描述面向方案的需求：系统必须具有哪些属性以满足相关的目标和场景？
21.4 子活动：识别相关的需求来源
如果相关的需求来源没有被识别出来，那么很显然在需求抽取过程中很难将其考虑进来。在需求抽取过程中没有考虑相关的需求来源通常会导致所得到的系统质量低下。
21.4.1 识别潜在的需求来源
迭代的过程：
步骤1识别新的潜在的需求来源（从已知的需求来源出发）：
– 向已识别出的涉众询问是否还存在其他潜在的需求来源
– 检查已经识别的文档以获得新的潜在需求来源
– 分析现有的系统以获得新的潜在需求来源
步骤2将新识别出来的潜在需求来源记录在一个列表中。
步骤3对每一个新识别出来的需求来源再次执行步骤1。
建议迭代执行以上这些步骤，直到新识别出来的潜在需求来源变得很少（甚至为零）为止，即直到所识别出的需求来源集合变得（基本）稳定。
建议为每一个上下文刻面定义一个检查表
提示21-2：在识别潜在需求来源时考虑所有的4个上下文刻面
>检查主体刻面以识别潜在的需求来源；
>检查使用刻面以识别潜在的需求来源；
>检查IT系统刻面以识别潜在的需求来源；
>检查开发刻面以识别潜在的需求来源。
21.4.1 识别潜在的需求来源
所有识别出的潜在需求来源都要在需求抽取过程中进行考虑。
实践中，可以考虑的需求来源的数量通常受限于可用于需求抽取的资源。因此，在抽取过程中只能考虑所识别的潜在需求来源的一个子集。
关于在需求抽取过程中是否要考虑或忽略一个已识别出的需求来源的决策，应该基于该需求来源的相关性做出。
评价潜在需求来源相关性的技术
1.每位参与需求来源相关性评价的涉众从主持人那里获得一些相关性点数。
2.每位涉众基于他或她的知识和直觉主观地评价每一个需求来源的相关性。
3.每个涉众都将自己的相关性点数分配出去后，可以通过得到的相关性点数对候选需求来源排序。
相关需求来源的选择和需要考虑的需求来源的数量都需要根据特定项目、领域、系统类型等的情况而定。因此，这些决策应该由有经验的需求工程师和其他涉众共同确定。
考虑所有4个上下文刻面
当选择相关的需求来源时，应当明确考虑4个上下文刻面。
>在选择后检查所选择的需求来源是否充分代表了4个上下文刻面。
>根据4个刻面对需求来源的分类，分别为每一个刻面执行相关需求来源的选择技术。
提示21-4：对每个上下文刻面分别评价需求来源的相关性
21.5 子活动：抽取现有需求
21.5.1 从涉众中抽取现有需求
现有的需求可以通过交谈、问卷调查或观察从涉众那里抽取。
通过观察相关的涉众，那些涉众无法直接表达的需求。
应该注意潜在的验收准则，即需要明确地满足以通过系统验收测试的可度量需求。
21.5.2 从文档中抽取现有需求
为了从文档中抽取现有的需求，需求工程师必须阅读和分析相关的文档。
在面临有限的资源的情况此，可以采用基于视角的阅读。
21.5.3 从现有系统中抽取现有的需求
已经在现有系统中实现的需求可以从现有系统、熟悉该系统的涉众、或者现有系统的文档（如用户文档或错误报告）那里直接抽取。
需求可以从现有系统的文档中抽取
21.6 子活动：开发新的创新性需求
新的创新性需求的开发是一个创造性的过程。
创新性需求一般会在聚集具有不同观点的不同涉众、产生一些新想法（或许最初是非常含糊的）时候出现，甚至来自于一些看似冲突但可以通过一个新的创新性的解决方案实现的需求。
第22章 抽取技术
22.1 技术评价
用于3种子活动抽取技术的适应性
| 技术对于子活动的适用性 | 开发新的创新性需求 | |||
| 抽取现有需求 | ||||
| 识别需求来源 | ||||
| 技术 | 工作量 | |||
| 访谈 | 中到高 | √ | √ | √ |
| 研讨会 | 高到很高 | √ | √ | √ |
| 专题小组 | 中到高 | √ | √ | |
| 观察 | 高到很高 | √ | ||
| 调查问卷 | 低到中 | √ | √ | |
| 基于视角的阅读 | 中到高 | √ | ||
22.2 描述技术的模板
通过一个公共的模板来描述在本章中介绍的抽取技术
该模板由下面的几节组成：
1.准备：描述准备执行该技术时必需的动作。
2.执行：描述执行技术的要点。介绍并解释该技术的步骤。
3.后续：描述执行该技术后需要执行的动作。
4.应用该技术的检查表：一个全面的列表将针对该技术的准备、执行和后续的动作综合在一起。
5.对于需求工程活动的作用：以何种方式支持特定的需求工程活动
6.工作量：给出了应用该技术所需工作量的粗略估计
7.关键成功要素：成功应用该技术所需考虑的关键因素
22.3 访谈
访谈的目的是从一个或一组涉众那里抽取待开发系统的需求和上下文信息。
访谈基本上可以分为3类：标准化访谈、探索性访谈和非结构性访谈。
在标准化访谈期间，访谈员向受访者询问一些准备好的与某方面相关的问题。不管得到什么样的答案，访谈员都不要偏离所准备的问题。标准化访谈适用于需要广泛了解许多涉众关于相同问题的观点时。由于采用标准化的问题列表，对于不同涉众的标准化访谈结果可以容易地进行比较。
探索性访谈是一种交谈，通过这种方式访谈员可以抽取出受访者对于一些问题的观点或视角的信息。这种访谈的基础是访谈员向受访者提出一个准备好的问题列表。在探索性访谈期间，访谈员可能会偏离准备好的问题。这种访谈的结果是定性的。关注相同问题的不同探索性访谈的结果很难相互比较。
非结构化访谈通常不会使用准备好的问题目录。建议在需求抽取中采用标准化访谈或探索性访谈。
访谈还可以分为个别访谈和小组访谈
不管采用何种类型的访谈，访谈的准备、执行和后续动作都是一样的。
用一种通用的方式描述访谈的准备、执行和后续动作，并在需要时指出采用不同访谈种类和参与者数量时的差异。
22.3.1准备
定义访谈的目标
访谈目标的定义应该包含进行访谈的原因，并指出期望的结果。
选择和邀请参与者
基于访谈的目标，从一组潜在的涉众中选择访谈的参与者。
建议还应通知参与者系统开发的状态和依据，以及访谈结果的计划用途。
涉众能够认识到期待他们为系统开发过程做出什么样的贡献。
选择访谈地点
进行访谈需要一个不受干扰的环境，从而使访谈的参与者可以全神贯注于访谈。
定义访谈问题
基于访谈的目标，开发适当的问题交由受访者回答。
访谈问题可以分为两个基本类型：
>封闭式问题：对于每个问题提供不同的答案选项，受访者可以选择一个或多个答案。
>开放式问题：不向受访者提供预定义的选项，而是用受访者自己的话回答问题。
封闭式问题可以快速轻松地回答。受访者只能选择特定的可选答案。这简化了结果的分析。封闭式问题的缺点是不能抽取到新的答案或想法。
如果访谈的目的是深入探讨话题，那么应该尽量减少使用布尔问题。布尔问题是消除受访者回答的歧义的有用工具。
开放式问题适合于调查那些还未很好理解的问题。
建议将问题置于一个尽可能具体的上下文中。
需要注意在访谈中不要询问具有导向性的问题。
访谈准备
在实施访谈之前，访谈员应尽可能了解受访者。
访谈员应当在访谈之前学习这些术语，从而避免访谈过程中对术语的误解。
22.3.2执行
我们将访谈的执行划分为开场、工作要素和总结3个阶段。
工作要素
访谈期间，访谈员应该不断就所抽取的信息向受访者提供反馈。为此，访谈员可以就所抽取的信息询问一些更深入的问题（即，进行探究），或者对受访者提供的答案进行简要概括
使用简单的概念模型来描述所陈述的事实
使用场景来描述这些信息。
访谈的结果必须以某种合适的方式进行记录。
总结
访谈员要简要地总结从受访者访谈中获得的重要成果。
22.3.3后续
整理会议纪要、描述所抽取的需求、确认所创建的模型和场景。明确记录所识别的缺陷、矛盾或不一致的地方。
建议将分析结果发送给受访者，并请他们检查和确认结果。
22.3.4应用该技术的检查表
| 访谈检查表 |
| 准备——访谈的目标： |
| ❑明确定义访谈目标。 |
| 准备——访谈参与者： |
| ❑基于访谈目标选择参与者； |
| ❑预先邀请所有参与者; |
| ❑与参与者沟通访谈的目标和基本原理。 |
| 准备——访谈地点： |
| ❑选择一个不受干扰的环境，可容纳所有与会者的访谈场所。 |
| 准备——访谈的问题： |
| ❑使用开放式的和封闭式的访谈问题； |
| ❑尽可能具体描述与所有问题相关的上下文， |
| ❑避免导向性问题。 |
| 准备——访谈员准备： |
| ❑熟悉访谈伙伴； |
| ❑学习参与者们所熟悉的术语; |
| ❑如果有多个访谈员参与，那么要建立起他们对访谈问题的共识。 |
| 执行——开场： |
| ❑在开始时向受访者概述访谈的目标和基本原理； |
| ❑如有可能，提供邀请时所未提及的信息； |
| ❑用一个引导性的问题开始访谈。 |
| 执行——工作要素： |
| ❑通过对受访者陈述的总结以及对不清楚的问题的澄清确保所抽取的信息是正确的； |
| ❑在访谈过程中创建模型和/或场景，以获得受访者的即时反馈； |
| ❑要注意受访者的非语言表达； |
| ❑每隔一段时间休息一下（大约每45分钟）； |
| ❑不要脱离主题； |
| ❑记录访谈的结果。 |
| 执行——总结： |
| ❑总结所抽取的知识； |
| ❑指出受访者贡献的重要性； |
| ❑向受访者表达感谢。 |
| 后续: |
| ❑完成访谈会议记录； |
| ❑描述所抽取的需求； |
| ❑对所创建的模型和场景进行修订； |
| ❑在待办列表中收集开放式问题； |
| ❑将结果分发给受访者； |
| ❑请受访者检查和确认结果； |
| ❑从访谈结果中识别需求冲突，使用第四部分C中介绍的技术解决冲突。 |
22.3.6 工作量
执行访谈所需的工作量从根本上讲主要取决于受访者的人数、所问问题的数量和类型，以及采取何种记录方式。
22.3.7 成功的关键因素
访谈结果的质量主要取决于访谈员的交流技巧。
不应该提出包含对于所期望答案的暗示的访谈问题。
对于预期结果具有清晰的目标和清晰的设想是成功访谈的基础。
使用公共的术语可以避免误解。
访谈员应该熟悉自己的访谈合作伙伴。
22.4 研讨会
在研讨会中，一组涉众共同开发系统需求。需求来自于集体工作的结果。
22.4.1准备
定义研讨会目标
建议在沟通研讨会目标时明确说明期望通过研讨会开发得到的需求制品类型。
定义工作结果和工作过程
定义如何达到研讨会目标以及如何产生所计划的工作成果。
选择参与者、邀请参与者，就目标达成一致
对于任何能为实现研讨会目标、获得期望成果做出贡献的涉众，都应该邀请其参加研讨会，建议一次研讨会邀请5~15名参与者。
应该将4个上下文刻面中相关的涉众邀请到研讨会中来。
选择研讨会的地点
任命一个主持人
主持人负责控制研讨会的进行过程。注意参与者之间的意见冲突，并为多与者的冲突解决提供支持。冲突和矛盾应作为开发创新性思路和解决方案的机遇。解决冲突和矛盾可以建立起对系统的共识。
任命会议记录员
22.4.2 执行
开场
定义好明确的行为规则。
工作要素
提示22-3：在一个记录想法的库中收集开放议题
用一个各种想法的共享库来收集无法进一步探讨的开放议题和问题。
所有相关的结果都应当进行记录。除了最终结果外，还应包含所有的中间结果。
在研讨会过程中会做出一些决策，建议明确地记录决策。
提示22-4：明确的决策记录
对于一个决策的内容，应当记录以下几个方面：
>决策的可选方案；
>所选择的方案；
>决策依据；
>如果适用，还包括负责实现该决策的人。
记录决策的依据定义负责实现决策的人对于确保决策的实现尤为重要。
总结
第24章 需求协商基础
24.1 需求协商的目标
待开发的系统应当尽量考虑并实现不同涉众的所有要求和愿望。涉众之间的要求和愿望经常会存在冲突。
必须要检查是否所有涉众都对所描述的需求表示赞同。协商目的是让所有涉众在需求上达成一致，必须处理需求冲突。
定义24-1：冲突（需求工程中）
如果不同涉众（或涉众组）对于系统的要求和愿望互相矛盾，或者一些要求和愿望无法考虑进来，那么就出现了需求工程中的冲突。
未解决的冲突会对由涉众执行的系统验收带来不利影响。
不应当消极看待需求工程中的冲突。它们也可以成为新的想法以及创新性需求的源泉。
需求协商是需求工程的3个核心活动之一。需求协商的目标是通过识别冲突、分析冲突和解决冲突在共识维度上取得进展。
应该与相关涉众一起共同解决所有报告的冲突。在需求工程期间解决需求冲突通常有利于系统的验收。
24.2 需求协商：定义
定义24-2：需求协商
需求协商是需求工程中3个核心活动之一。协商活动的目标是：
（1）识别冲突；
（2）分析每个冲突的原因;
（3）通过适当的策略解决冲突；
（4）记录冲突解决方案和原理。
24.3需求协商中目标和场景的使用
明确定义目标可以对冲突的解决提供支持。
目标刻画了面向方案需求的原理。涉众在相关日标上达成一致后，关于面向方案需求中的冲突就会更容易解决了。
应该对冲突进行识别、记录和分析，并尽可能在目标层次上解决。
通常在目标层次上比在面向方案的需求层次上更容易找到冲突的解决方案。为目标冲突解决识别创造性的解决方案可以通过寻找替代的目标分解方案来实现。
选择替换方案中与其他目标冲突最少的那个来代替。
当涉众必须从不同的实现中进行选择时，目标可以用来支持决策的制定。
场景的使用有助于冲突分析：场景可以使用描述一个包含冲突的交互序列来阐明冲突。
涉众可以开发并讨论各种可以减少或甚至完全避免冲突的场景。
第25章 冲突管理
25.1 子活动：识别冲突
需求冲突可能在所有需求工程活动中出现。
在单个需求工程活动中，冲突通常是不明显的。
相似的冲突应当进行合并，以方便在冲突分析与解决阶段对这些冲突共同进行考虑。
25.2子活动：分析冲突
冲突分析的目标是确定所识别冲突的类型。冲突分类:
数据冲突：数据冲突是由于缺少信息、错误的信息或者对同一问题的不同理解而引起的。
利益冲突：利益冲突是由涉众主观或客观上的不同利益或者目标引起的。
价值冲突：价值冲突是由涉众评价问题时采用的不同准则（如文化差异）引起的。
25.2.1 数据冲突
如果涉众得到的需求是被误导或不完整的，或者涉众对需求的含义产生了不同理解，那么就会产生数据冲突。
25.2.2利益冲突
如果涉众之间对于待开发系统的利益或目标相互矛盾，那么就会出现需求的利益冲突。
25.2.3价值冲突
如果不同涉众对待开发系统需求的评价不同，或者认为其重要性不同，就会存在需求的价值冲突。
25.2.4 冲突分析的启发式方法
建议首先检查数据冲突，然后是利益冲突，最后考虑价值冲突。冲突的类型可以通过以下3个步骤来确定：
1.检查数据冲突：必须确定涉众所得到的需求是否被误导或是不完整的。
2.检查利益冲突：必须识别冲突相关方的利益并将它们放在一起。建议对涉众的目标进行详细描述，随后，比较不同的目标模型。如果在不同涉众的目标中发现冲突，那么就存在利益冲突。
3.检查价值冲突：必须找出涉众按照他们自己的方式评价需求的原因。接着，需求工程师必须检查涉众不同的评价背景是否是导致相互矛盾的评价的原因。
提示25-1：冲突分析的启发式方法
（1）检查数据冲突
❑让涉众解释冲突需求。
❑是否存在与实际需求不相符的解释？若如此，则存在数据冲突。
（2）询问涉众利益：
❑询问涉众关于冲突需求的目标。
❑检查所得到目标中的矛盾。如果存在矛盾，则存在利益冲突。
（3）阐明涉众的评价背景：
❑询问涉众为什么使用他们所使用的方式来评价需求。
❑检查不同涉众评价背景的差异，这些差异可能是导致所发现的冲突的原因。若存在这种差异，则存在价值冲突。
25.3子活动：解决冲突
为了解决冲突，可以使用以下3种基本策略之一:
❑协商：冲突各方通过协商商定解决方案。
❑创造性的解决方案；抛开冲突各方最初的观点，提出能协调好冲突各方的创造性解决方案。
❑决定：由上级做出支持某个冲突方的决定。
25.3.1 通过协商解决冲突
协商策略的目的在于通过交换信息、论据和观点来解决冲突。
如果某一个冲突方的观点被其他方所接受，或者找到一个介于不同观点之间并且各方都接受的折中方案，那么冲突就被解决了。
优点是，所有冲突各方的观点都得到了考虑，建立了双赢的局面。
通过协商的方法解决冲突可能会非常耗时。从客观的角度看，折中方案可能并不是最好的解决方案。
25.3.2通过创造性的解决方案解决冲突
冲突各方需要抛弃他们原来的观点，寻求各方都能接受的新观点。一个新的方案将独立于此前的观点开发出来。
优点是，由于方案为各方所接受，所有冲突各方都是赢家。不利的是，开发一个创造性的方案可能十分耗时，而且可能会对其他需求产生影响。
25.3.3通过决定解决冲突
有些冲突是永远无法达成共识的。在这些情况下，冲突必须通过决定来适时解决。
冲突由决策者解决。决策者基于当前情况决定系统采纳哪种观点。在有些情况，决策者自身可能也是冲突的一方。
由于不用进行讨论，冲突可以快速解决而不用消耗过多的资源。
会对被忽略的冲突一方的积极性产生不良影响。应首先尝试通过协商或创造性的方案而不是通过上级决定来解决冲突。另一种可能的决策方法是对所有相关涉众的观点进行投票。
25.3.4冲突解决策略的评价
冲突解决策略评价
| 冲突类型 | 协商 | 创造性方案 | 决定 |
| 数据冲突 | 适用 | 不适用 | 不适用 |
| 利益冲突 | 适用 | 有条件适用 | 适用 |
| 价值冲突 | 有条件适用 | 适用 | 有条件适用 |
解决数据冲突
数据冲突应通过协商来解决。协商过程中，相关的冲突各方进行信息交换。此外，冲突双方可能得到额外的相关信息。
创造性方案将会基于不完全或不正确的信息做出。
数据冲突不适合通过选择支持某个冲突方的决定来解决，所做出的决定可能会支持错误的观点。
解决利益冲突
对于利益冲突，每个冲突方都应向其他方说明其利益，以识别各方之间的共同利益。
在共同利益基础上，各方应当首先尝试通过协商策略来解决冲突。冲突方之间应就一方的哪些冲突利益对于其他方是可接受的这问题达成共识。
对于冲突中无法用协商解决的方面，建议由决策者来决定。
解决价值冲突
协商策略仅有条件适用于解决价值冲突，因为价值通常深深根植于涉众的个性中。在冲突的协商过程中，这些价值不可能轻易改变或放弃。对于价值冲突，应争取创造性方案。
如果冲突各方的价值是不可调和的，那么冲突应通过决定来解决。
25.4子活动：记录冲突解决方案
涉众识别出一系列冲突，并尽可能解决这些冲突。
建议对它们进行文档化。
建议将已实现的冲突解决方案、冲突各方的观点以及各种观点的优缺点都一起记录下来。
如果重新考虑一个冲突解决方案，其修订同样必须记录下来。