需求工程期末知识点复习

需求工程第一章

软件的模拟特性 P6

软件的模拟特性来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致，即软件“模拟”了现实。
“模拟性”具体指：

1. 目的性
2. 正确性
3. 现实可理解性

需求工程基本活动 P12

需求工程包括需求开发和需求管理
需求开发包括需求获取、需求分析需求规格说明和需求验证
需求获取：从项目的战略规划开始建立最初的原始需求
需求分析：保证需求的完整性和一致性
需求规格说明：将完整、一致的需求与能够满足需求的软件行为已文档的方式明确的固定下来
需求验证：保证需求及其文档的正确性，通过检查和修正，保证需求及其文档的完整性和一致性
需求管理：对需求开发所建立的需求基线的管理

需求工程的复杂性 P16

1. 处理范围广泛：连接现实世界和计算机世界
2. 涉及诸多参与方：客户、用户、领域专家、需求工程师、软件开发者和系统维护者
3. 处理内容多样：用户的功能需求和非功能需求，软件所处的环境及其约束
4. 处理活动互相交织：需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的
5. 处理结果要求严苛：正确性、完整性和一致性

需求工程师需要具备的技能 P18

• 软件技术
• 认识学和社会学等方面的知识
• 哲学知识
• 专业技能
• 分析技能

需求工程师需要重视的软技能 P18

1. 交流技能：交谈和提问的技巧，倾听的技巧
2. 观察技能观察用户的工作环境和工作过程，观察得出用户的真实的感受和情感反馈
3. 抽象分析与问题解决技能：抽象能力，整合全局的能力，系统化思想
4. 写作技能：文档组织能力，语言驾驭能力
5. 关系协调和团队工作技能：促成相关方的有效协商，以最终达成一个合理的解决方案

需求工程第二章

模拟与共享现象 P26

软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性
共享现象就是解系统所模拟的问题域部分，该部分在两个系统中同时存在

需求问题都有层次性 P28

1. 业务需求 战略问题
2. 用户需求 任务问题
3. 系统级需求 系统行为问题
   业务需求具有明显的目的性和较高的抽象性
   用户需求经过明确和细化的处理，可以转化为系统及需求
   用户可以直接将系统及需求映射为系统行为
   
   
   

优秀需求的特性 P44

1. 完备性：是否描述了开发人员设计和实现这项功能所需的所有信息
2. 正确性：真实反映用户的意图
3. 可行性：需求必须能够在系统及其运行环境的已知条件和约束下实现
4. 必要性：满足用户的业务需求所必需的
5. 无歧义：每一项需求都应该有而且只能有一种解释
6. 可验证：通过分析、检查、模糊或测试等方法能够判断需求是否被满足

需求工程第三章

需求获取的主要任务 P54

1. 收集背景资料：先收集系统的背景资料以形成一个基础的知识框架，如需深入，就需要应用相关的需求分析方法（如领域分析等）对收集的资料进行整合与处理
2. 获取问题与目标，定义项目前景与范围：了解用户的需要、期望和关注点，推定用户在业务中所遇到的高层次问题，确定软件产品未来的形式，定义项目的前景
3. 识别涉众，选择信息的来源：将用户分成不同的类型，在理解每种类型用户特征的情况下为其选择合适的用户代表
4. 选择获取方法，执行获取，获取功能与非功能需求：获取用户需求，了解用户在完成任务时遇到的问题与期望
5. 记录获取结果：记录业务需求、项目前景和范围、用户需求以及问题与特性

需求工程第四章

需求获取中的常见困难 P75

• 用户和开发人员的背景不同，立场不同

1. 知识理解的困难
2. 默认知识现象

• 普通用户缺乏概括性、综合性的表述能力
• 用户存在认知困境
• 用户越俎代庖

1. 用户提出的不是需求，而是解决方案
2. 用户固执的坚持某些特征和功能

• 缺乏用户参与

1. 用户数量太多，选择困难
2. 用户认识不足，不愿参与
3. 用户情绪抵制，消极参与
4. 没有明确的用户

需求获取活动 P79

• 获取活动主要步骤

1. 研究应用背景，建立初始的知识框架
2. 根据获取的需要，采用必要的获取方法和知识
3. 先行确定获取的内容和主题，设定场景
4. 分析用户的高（深）层目标，理解用户的意图
5. 进行涉众分析，针对涉众的特点开展工作

• 实质步骤

1. 确定待获取信息的内容
2. 确定待获取信息的来源
3. 确定采用的获取方法
4. 执行获取
5. 记录成果

获取信息的内容 P80

1. 需求：涉众的问题、期望、观点、看法和态度
2. 问题域描述：承载和解释需求的问题域特性，主要是现实世界的业务运行状况
3. 环境与约束：属于一种特殊的问题域特性

获取信息的来源 P81

1. 涉众
2. 硬数据
3. 相关产品
4. 重要文档
5. 相关技术标准和法规

获取信息的方法 P81

1. 传统方法：问卷调查、面谈、文档分析、文档检查、需求剥离
2. 集体获取方法：头脑风暴、专题讨论会、JAD、JRP
3. 原型：在需求模糊和不确定性较大的情况下，原型方法尤其有效
4. 模型驱动方法：定义明确的模型，模型的定义方式确定了所要收集的信息类型，模型建立和完善的过程就是需求获取的过程
5. 认知方法：已认知的方式获取用户无法表达的潜在知识，任务分析，协议分析
6. 基于上下文的方法：用户在一定环境下表现出来的行为，通过分析用户的行为得到信息

需求工程第五章

问题分析 P96

1. 获取问题：收集背景资料或涉众沟通
2. 明确问题：
   2.1对问题达成共识
   2.2收集背景资料，判断问题的明确性
   2.3分析不明确问题，发现问题背后的问题
   
   
   
3. 发现业务需求：确定每一个问题对应目标的过程
4. 定义问题解决方案及系统特性：
   4.1建立问题解决方案
   4.2确定系统特性和解决方案的边界
   4.3确定解决方案的约束
   
   
   

目标分析过程 P113

1. 高层目标的获取：将识别出来的目标、系统特性等组织为相互联系的目标模型
2. 目标精化：
   2.1获取对高层目标的描述
   2.2从高层目标描述中发现AND精化关系
   2.3从高层目标描述中发现“候选方法”，发现OR精化关系
   2.4考虑阻碍目标实现的情况
   2.5发现目标冲突关系
   2.6对高层目标问“How”，对底层目标问“Why”，完善层次结构
   
   
   
   
   
   
3. 目标实现：将最底层的目标分配给主题，设计实现最底层目标的操作（任务）

需求工程第六章

信息系统

1. 小型系统：能够支持组织的部分工作，但又不会影响整个组织基础工作的信息系统
2. 组织级系统：其功能能够影响整个组织基础工作的系统，它的功能在质量上和小型系统有着明显的差异
3. 战略信息系统：作为组织战略决策而得以开发的系统
4. 组织间系统：通过系统自身的实施来建立或增强组织之间的合作关系

涉众分析的过程 P147

1. 涉众识别：寻找软件系统的涉众类别
2. 涉众描述：
   2.1描述不同涉众类别的简单特征，包括个人特征和工作特征
   2.2描述不同涉众类别的复杂特征，包括关注点和兴趣取向、重要性和影响力，输赢条件和受影响程度
   
   
3. 涉众评估：
   3.1为涉众类别划分优先级
   3.2评估不同涉众类别的风险，化解风险
   3.3分析涉众冲突，实现共赢
   
   
   
4. 涉众代表选择：从每种涉众类别中选择代表
5. 指定涉众代表参与需求开发乃至软件系统的参与策略

识别涉众的方法P150

1. 先膨胀后收缩的方法
   1.1 膨胀：收集到背景资料后，凭借自己的经验，尽可能多的列出涉众类别
   1.2 收缩：判断是否有两类或多类涉众的立场是一样的，将一样的多个类别进行合并
   
   
2. 检查列表方法：
   常见的涉众类别：
   2.1 用户：最终使用和操作产品的人
   2.2 客户：为软件系统开发付费的人
   2.3 开发者：负责实现软件系统的人
   2.4 管理者：参与软件系统开发事务管理的人
   2.5 领域专家：在问题域中具有丰富知识的专家
   2.6 政府力量
   2.7 市场力量：组织中的市场部门人员
   2.8 维护人员：系统管理员
   
   
   
   
   
   
   
   
   
3. 涉众网络方法：
   3.1 寻找最容易识别的初始涉众
   3.2 将初始涉众集中起来，进行一次头脑风暴，尽可能列出一个涉众类别列表
   3.3 对涉众类别列表进行分析，判断他们和软件系统的相关性，找出其中的关键涉众类别
   3.4 为各个涉众类别选择代表，集中起来进行进一步的头脑风暴，列出新的涉众类别列表
   
   
   
   

涉众评估 P156

1. 优先级评估：要优先考虑涉众的基本特征，尤其是任务特征
2. 风险评估：分析涉众的态度，涉众的关注点和兴趣取向。化解风险：提高环境设定者对系统的关注，将他们转变为参与者；消除强反对者的反对原因，将他们变为强支持者；给予被影响者一些充分发表和实现自身意见的权力，化解弱反对者的忧患
3. 共赢分析：为了保证软件系统的最终成功，应该尽可能地解决这些冲突，而且最好是在冲突发生之前能够消除

涉众代表采样 P160

1. 涉众采样：
   1.1完整采样
   1.2态度积极
   1.3数量适中
   1.4比例恰当
   
   
   
   
2. 用户替代源：
   2.1拥有类似系统经验的系统分析人员
   2.2与用户直接联系的技术支持人员
   2.3服务咨询人员
   2.4内部或者外部的顾问，通常是指领域专家
   2.5用户方的管理者
   2.6市场人员
   2.7拥有相关知识的开发人员
   如果能找到真正的涉众代表，就不要使用替代源，因为替代源的效果比真实涉众代表要差得多
   
   
   
   
   
   
   
   

硬数据 P166

1. 定量硬数据：经过仔细设计、具有严格贵伐要求的格式化文档
   1.1数据收集表格
   1.2统计报表
   
   
2. 定性硬数据：使用自然语言进行的文本描述
   2.1整个组织的描述文档
   2.2业务指导文档
   2.3业务备忘
   
   
   

需求工程第八章

准备面谈 P198

准备工作

1. 阅读背景资料
2. 确定面谈主题和目标
3. 选择被会见者
4. 通知被会见者做准备
5. 确定问题和类型

问题类型

1. 两种基本问题类型
   1.1 开放式问题：被会见者对答复的选择可以是开放的和不受限制的
   优点：感到自在；可以收集被会见者的词汇，这反映他的教育、价值标准、态度和信念；提供丰富细节
   缺点：产生很多不相干的细节，面谈可能失控；花费大量时间获得有用的信息
   1.2 封闭式问题：对答案有基本的形式，被会见者的回答是受到限制的
   优点：节省时间；切中要点；保持控制；快速讨论大范围问题；得到贴切的数据
   缺点：使被会见者厌烦；得不到丰富细节；失去主要思想；不能建立友好关系
   
   
   
   
   
   
2. 程序性提示：避免面谈过程中的一些认知问题
   1.1 总结与反馈
   1.2 重复和改述
   1.3 建立场景和细节
   1.4 抗辩
   
   
   
   
3. 其他重要的问题类型
   3.1 探究式问题
   3.2 诱导性问题
   3.3 双筒问题
   3.4 元问题
   
   
   
   

问题准备

1. 保证面谈能达成目标，就应该有所准备
2. 高效利用时间，面摊前就要花费更多的时间进行准备
3. 事先准备好面谈的主题与线索
4. 让会见者更好集中精力主导面谈过程

主持面谈 P204

面谈开始阶段

1. 握手
2. 概要说明会谈的原因
3. 准备好笔记本、录音机或其他记录设备
4. 开始时采用一些非常一般的、轻松的、开放式的问题

面谈主体阶段

1. 保持有礼貌的倾听
2. 控制面谈过程
3. 保持面谈主题
4. 使用探究式问题
5. 观察被会见者
6. 使用道具支持

面谈结束阶段

1. 45~60分钟结束
2. 总结面谈的要点
3. 感谢被会见者，并且给他们时间让他们询问自己关心的问题
4. 握手告别

记录面谈

1. 记录的内容
   1.1 事实和问题
   1.2 被会见者的观点
   1.3 被会见者的感受
   1.4 组织和个人的目标
   
   
   
   
2. 记录的方式
   2.1 笔录：
   优点：使会见者专心和集中精力；帮助回忆重要的问题；表现会见者对面谈的兴趣；表明会见者是有准备的
   缺点：丢失语调、停顿等语音信息；做笔记时，会让会见者说话犹豫；对事实注意过多，对感觉及观点注意过少
   2.2 录音和摄像
   优点：记录了更多信息；会见者能轻松倾听并快速响应；完整重现面试过程
   缺点：被会见者可能紧张；数据采集代价极高；信息寻找难以定位
   
   
   
   
   
   

整理面谈报告 P207

1. 复查面谈报告
2. 总结面谈信息：评估面谈中所得到的信息
3. 完成面谈报告：
   3.1 参与者、时间和地点
   3.2 会见者对被会见者的印象
   3.3 面谈中发现的观点和要点
   3.4 会见者对面谈的基本评价
   
   
   
   

面谈的类别 P208

1. 结构化面谈：会见者会完全按照事先的问题和结构来控制面谈
2. 半结构化面谈：实现需要根据面谈内容准备面谈的问题和面谈结构，但在面谈过程中会见者可以根据实际情况采取一些灵活的策略
3. 非结构化面谈：没有事先预定的议程安排

面谈的优点和局限性 P209

优点：

1. 条件简单，经济成本低
2. 能获得包括事实、问题、被会见者观点和被会见者信仰等各种信息类型在内的广泛内容
3. 可以和涉众建立友好关系
4. 被会见者会产生一种主动为项目做出贡献的感觉，提高涉众的项目参与热情

缺点：

1. 耗时，时间成本高
2. 在被会见者地理分散的情况下难以实现
3. 面谈参与者的记忆和交流能力对结果影响较大，面谈的成功很大程度上依赖于需求工程师的人际交流能力
4. 交谈过程中的各种问题容易导致错误数据
5. 在会见者不了解被会见者的认知结构的情况下，面谈不会令人满意

群体面谈 P210

概述

群体面谈的方法就是将所有的涉众代表集中起来，选择一个合适的地点，集中一段时间，召开一个多方共同参与的会议，一起进行需求的讨论、分析和获取
优点：

1. 节约时间，时间成本低
2. 在一个集中连续的时间内完成，能够加速项目的开发进度
3. 涉众之间可以直接交流，提高了冲突的处理能力和处理效率
4. 提高涉众的项目参与度
5. 常常会有创造性的信息内容出现

缺点：

1. 要求所有参与方都要在一个集中的时间内抽出大量的时间和精力，难以实现
2. 群体面谈获得的信息难以分析
3. 主持群体面谈更加复杂

计划面谈

• 确定参与人员：

1. 涉众
2. 主持人
3. 负责人
4. 分析人员
5. 记录人员
6. 观察员

• 安排面谈时间

1. 2~4天全职参与面谈
2. 拟定一份议程

• 选择面谈地点

1. 充足的空间
2. 道具支持
3. 良好的餐饮服务

• 准备面谈内容：

1. 确定面谈的主题和范围
2. 确定面谈的议程
3. 建立需求的预期和面谈的目标
4. 提前准备各种材料

主持面谈

1. 建立基本规则
   1.1 按时开始和结束
   1.2 中途休息后尽快进入状态
   1.3 一次只讨论一个主题
   1.4 期望每个人都做出贡献
   1.5 关注问题，不人身攻击
   1.6 限制发言时间
   
   
   
   
   
   
2. 保持面谈气氛
3. 确保每个人都积极地参与讨论
4. 控制面谈的主题

分析结果

记录员要完整记录下会谈的内容
记录员需要和参与的技术人员一起对记录内容进行整理
整理的工作：

1. 按照主题组织参与者的讨论
2. 建立粗略的模型，分析每个主题已经获得信息内容
3. 指明下一步的努力方向

和面谈相关的其他需求获取方法 P213

调查问卷

格式设计：

1. 提供足够的空白空间
2. 提供足够的答复空间
3. 要求回答者清楚地标出他们的答复
4. 使用目标帮助确定格式
5. 保持风格一致

头脑风暴

鼓励参与者在无约束的环境下进行某些问题的自由思考和自由讨论，以产生新的想法

• 需要采用的典型情况

1. 发明并描述以前不存在的全新的业务功能
2. 明确模糊的业务
3. 在信息不充分的情况下做出决策

• 头脑风暴的两个决策

1. 想法产生阶段：产生出尽可能多的新想法
   头脑风暴的基本规则：
   1.1 充分发挥想象力，不要有羁绊
   1.2 产生尽可能多的想法，想法重在数量不是质量，不要顾及想法是否荒诞
   1.3 自由讨论，目的是产生新的想法，不要争吵和批评
   1.4 在自由讨论中，可以转换和组合所有已提出的想法，以产生新的想法
   
   
   
   
   
2. 想法精简阶段：
   2.1 去除那些不值得进一步讨论的想法
   2.2 把类似意见归类
   2.3 主持人遍历每一个未被删除的想法，确保所有参与者都对其有共同的理解，利用投票或类似方法，评估先有想法的优先级
   2.4 根据评估的数据，从中筛选符合一定标准的想法作为头脑风暴方法的成功
   
   
   
   

需求工程第九章

原型及原型法

• 如果在最终的制品产生之前，一个中间制品被用来在一定广度和深度范围内表现这个最终制品，那么这个中间制品就被认为是最终制品在该广度和深度上的原型
• 原型通常仅仅是真实系统的一个部分或一个模型，重要的不在于使用什么材料和工具来创建他们，而是人们怎么利用他们来探索和论证未来物件的某个方面
• 原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代
• 包括书面描绘、场景叙述、故事板、幻灯演示、动画模拟、屏幕快照和程序代码等在内的各种被用来探索和论证软件系统功能的物件都是软件的原型
• 在系统开发中利用这些原型的行为都属于原型法

使用原型法进行需求获取

基本过程

1. 确定原型需求
2. 原型开发
3. 原型评估
4. 原型修正

确定原型需求

如果发现产品的需求存在不确定性，就可以考虑使用原型法

1. 可能发生的需求变更
2. 存在冲突的地方
3. 信息不充分：
   3.1 产品的部分需求从前从未存在过，而且难以可视化
   3.2 产品的涉众对相关的产品功能没有经验，而且对将要采用的技术也没有经验
   3.3 涉众进行自己的工作已经有一段时间了，但在完成工作的方式上仍然存在障碍
   3.4 涉众在清晰说明某些需求方面存在困难，如默认需求或者潜在需求
   3.5 需求工程师在理解涉众的部分需求上存在困难
   3.6 部分需求的可行性值得怀疑，即具体需求的可满足性存在着不确定性
   
   
   
   
   
   

原型开发

注意事项：

1. 将探索不确定功能需求的原型构建得易于修改
2. 让探索可行性的原型收集充分的数据
3. 控制开发成本

原型评估

1. 使用脚本指导评估过程
2. 创造无偏见的评估环境
3. 引导评估者从恰当的角度进行评价
4. 观察评估者的行为
5. 手机评估者的反馈

原型修正

1. 让用户能够较早感受到系统功能并及时提出反馈
2. 根据评估者的反馈迅速调整错误的或不完善的想法，并在连续的反馈和调整之中逐步接近正确的和完善的需求

需求工程第十章

观察 P234

概述

常见的观察方法：

1. 采样观察
2. 民族志
3. 话语分析
4. 协议分析
5. 任务分析

情境性的重要性质

1. 突现：集体促成，互动的基础上突显的
2. 局部：特定的上下文环境
3. 暂时：依赖于当时的情况
4. 涉身：参与者具有一定的认知和能力
5. 开放：对事件的解释必须保持开放，以在得到进一步的分析之后可以进行进一步完善
6. 模糊：基于一些当然的潜在知识

需要应用观察方法解决的问题

1. 理解复杂的协同事件：突显 民族志
2. 获取工作中的异常处理：局部 采样，民族志
3. 获取与用户认知不一致的实际知识：暂时 采样，民族志
4. 了解用户的认知：涉身 民族志，话语分析法
5. 获取默认知识：模糊 采样观察，协议分析，民族志

采样观察

1. 时间采样：允许需求工程师建立指定的时间间隔来观察用户的活动情况
2. 事件采样：通过有目的的选取整个时间进行观察，而不是随机采样时间段

民族志

• 优点：

1. 深度理解信息
2. 能够让真实世界的社会因素可见化
3. 打破人们已有的一些错误假设观念

• 缺点：

1. 耗费很长时间
2. 调研结果很难传递到开发过程

• 针对复杂协同问题的民族志

1. 分布式协同：注意那些利用物件实现的协同和创建这些物件的文书工作
2. 计划和程序：关注他们在组织活动中的应用方式，发现实际工作和文档化程序之间存在的偏离
3. 工作的意识：活动可以对协同中的其他人可见或可理解

• 使用普通民族志的规则

1. 定期记录他们的发现
2. 尽快记录可能会在观察工作中发生的面谈
3. 定期复查和更新自己的想法
4. 确定该问题的应对策略

文档审查 P242

1. 需求方法：相关产品的需求规格说明
2. 文档分析：硬数据
3. 需求剥离：客户的需求文档

需求工程第十六章

需求验证的方法 P418

需求评审

由作者之外的其他人来检查产品问题，主要的静态分析手段，每一条需求都应该进行评审

• 参与评审的人员

1. 组织者
2. 仲裁者
3. 作者
4. 阅读人员
5. 记录人员
6. 收集人员
7. 评审人员（领域专家+用户代表）
8. 技术人员
9. 观察员

• 评审过程

1. 规划
2. 总体部署
3. 准备
4. 评审会议
5. 返工
6. 跟踪

• 评审的检查方法

1. 自由方法
2. 检查清单
3. 缺陷
4. 功能点
5. 视角
6. 场景
7. 逐步提升

• 评审的类型

1. 审查
2. 小组评审
3. 走查
4. 轮查
5. 临时评审

原型与模拟

需求涉及复杂的动态行为时
成本较高

开发测试用例

如果无法为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷

用户手册

1. 对软件系统功能和实现的描述：帮助进行功能需求的验证
2. 系统没有实现的功能部分：帮助进行项目范围的验证
3. 问题和故障的解决：帮助进行异常流程需求的验证
4. 系统的安装和启动：帮助进行环境与约束需求的验证

利用跟踪关系

1. 业务需求（系统特性）
2. 用户需求（业务、任务）
3. 系统级需求（分析模型）

问题的修正 P425

1. 需求澄清：
   1.1 已经获得需求信息，理解当中出现偏差：需求工程师重新进行分析工作
   1.2 已经获得需求信息，没有被纳入需求分析或者文档化工作：重新分析和文档化这部分信息
   1.3 使用了不恰当的表达方式：重新以合适的方式修改对需求的表达
   
   
   
2. 发现需求缺失：
3. 解决需求冲突
4. 修正不切实际的期望

需求工程第十七章

需求管理的作用 P431

1. 增强了项目涉众对复杂产品特征在细节和相互依赖关系的理解
2. 增进了项目涉众之间的交流
3. 减少了工作量的浪费，提高了生产力
4. 准确反映项目的状态，帮助进行更好的项目决策
5. 改变项目文化，是需求的作用得到重视和有效发挥

需求管理的活动 P432

1. 维护需求基线
2. 实现需求跟踪
3. 控制变更