需求工程期末复习.doc

第一章 ：需求工程导论
1. 需求工程定义：
是所有需求处理活动的和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。
2. 需求工程的基本活动：
1） 需求开发：需求获取，需求分析，需求规格说明，需求验证
2） 需求管理
3. 各个活动的目的：
1） 需求获取的目的是从项目的战略规划开始建立最初的原始需求；
2） 需求分析的目的是保证需求的完整性和一致性；
3） 需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来；
4） 需求验证的首要目的是保证需求及其文档的正确性，即需求正确的反映了用户的真实意图；另一个目标是通过检查和修正，保证需求及其文档的完整性和一致性；
5） 需求管理的主要工作是跟踪后继阶段中的需求实现与需求变更情况，确定需求得到了正确的理解并被正确的是想到了软件产品中。
4. 软件需求规格说明定义：
软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。
第二章 ：需求基础
5. 软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性。
6. 需求分类：
1） 功能需求：业务需求，用户需求，系统需求
2） 性能需求
3） 质量属性
4） 对外接口
5） 约束
第三章 ：（不考）
第四章 ：需求获取概述
7. 需求工程需要获取的内容主要有三种：
1） 需求
2） 问题域描述
3） 环境与约束
8. 需求获取信息的主要来源：
1） 涉众
2） 硬数据
3） 相关产品
4） 重要文档
5） 相关技术标准和法规
9. 获取信息的方法：
1） 传统方法：问卷调查，面谈，文档分析，文档检查，需求剥离
2） 集体获取方法：头脑风暴，专题讨论会，JAD，JRP
3） 原型
4） 模型驱动方法：基于场景，基于用例
5） 认知方法：任务分析，协议分析
6） 基于上下文的方法：观察，民族志，话语分析
10. 常见的组织方式是依照系统特性，确定系统的边界，建立上下文图或系统用例图，然后按照遍历上下文图和系统用例图的方式开展获取活动。
第五章 ：确定项目的前景和范围
11. 前景：
描述了产品的作用以及最终的功能，它将所有涉众都统一到一个方向上。
12. 范围：
指出了当前项目是要解决产品长远规划中的哪一个部分，范围声明它为项目规定了需求的界限。
13. 对于不明确的问题，直接抛弃是一种错误的做法，正确的做法应该是使用不同的方法发现涉众提出不明确问题的原因，理解不明确问题背后深藏的问题。
14. 需要注意的是问题解决方案的边界不是系统的边界，一个解决方案外部的输入可能来自于同一个系统中另一个问题解决方案的输出，即系统的内部。
15. 描述系统的边界，通常会用上下文图和系统用例图。
第六章 ：涉众分析与硬数据采样
16. 涉众定义：
所有能够影响软件系统的实现，或者被实现后的软件系统影响的个人和团体。
17. 四种常见涉众类型：
1） 参与者
2） 环境设定者
3） 被影响者
4） 观众（优先级最低）：领域专家和市场力量是比较常见的观众
18. 硬数据
1） 定量硬数据：数据收集表格，统计报表
2） 定性硬数据：整个组织的描述文档，业务指导文档，业务备忘
第七章 ：需求获取方法之面谈
19. 面谈结构：
1） 金字塔结构
2） 漏斗结构
3） 菱形结构
20. 面谈分为三种类型：
1） 结构化面谈
2） 半结构化面谈
3） 非结构化面谈
21. 调查问卷，头脑风暴（P130）
第八章 ：需求获取方法之原型
22. 原型：是一个系统，它内化了一个更迟系统的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者代替。
23. 原型的类别
1） 按照开发方法进行分类：演化式原型，抛弃式原型（探索式原型，实验式）
2） 按照构建技术进行分类：水平原型，垂直原型
24. 原型的需求内容：（三个）
1） 外观
2） 角色
3） 实现
第九章 ：需求获取方法之观察与文档审查
25. 常见的观察方法：
1） 采样观察
2） 民族志
3） 话语分析
4） 协议分析
5） 任务分析
26. 应用观察方法解决的问题：
1） 理解复杂的协同事件
2） 获取工作中的异常处理
3） 获取与用户认知不一致的实际知识
4） 了解用户的认知
5） 获取默认知识
27. 采样观察法：
1） 时间采样
2） 事件采样
28. 文档审查中文档分为三种类型：
1） 相关产品的需求规格说明
2） 硬数据
3） 客户的需求文档
29. 另外，需要注意的是，文档虽然来自于当前计算机或手工系统的产物，但这并不表示它就是正确的。
第十章 ：需求组织——需求获取中的模型驱动方法
30. 模型驱动方法：是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求工程方法。
31. 目标模型（P165）
32. 场景方法的分类框架：
1） 场景的形式：描述，外观
2） 场景的内容
3） 场景的目的：描述，探索，解释
4） 场景的生命周期
33. 用例描述
1） 用例是静态的结构化文本描述
2） 用例可以用于各种目的的应用，包括描述、探索、解释
34. 用例之间的关系：（三种）
1） 包含
2） 扩展
3） 泛化
35. 在需求工程中，主要产生三类重要的文档：
1） 项目前景和范围文档
2） 用户需求文档
3） 需求规格说明
36. 用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户期望的作用。在特殊的情况下，用例文档还可以用来代替需求规格说明，但总的来说这是一种并不值得提倡的方法。
第十一章 ：需求分析概述
37. 总的来说，需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差距，需求分析就是用来解决这个差距的需求工程活动。
38. 需求分析的根本任务：
1） 建立分析模型（分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息，这种分析活动被称为建模——建立需求分析模型。）
2） 创建解决方案（创造性）
39. 建模常用的两种手段：
1） 抽象
2） 分解
40. 两个世界与三种模型（P190）
41. 模型语言的三要素：
1） 语法
2） 语义
3） 语用
42. 需求分析方法：
1） 结构化方法
2） 信息工程方法
3） 面向对象方法（是目前工业界使用的主流方法）
43. 前期需求阶段分析的重点是理解问题世界，因此它关注的是整个问题世界，注重于系统的环境、开发组织的业务分析背景、涉众的特征以及目标等等，软件系统只是整个背景下的一个要素；后期需求阶段分析关注的是解系统解决方案的建立，因此它以软件系统为中心，注重于分析系统的内部功能以及它与环境的互动，是对系统功能的详细信息的分析。
44. 需求细化：
需求分析活动的一个重要任务是进行需求细化，明确用户需求的隐含信息，展开为明确的对软件系统的行为期望，即系统需求。
第十二章 ：过程建模
45. 过程建模定义：
过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程的集合，其中一些由人来执行，另一些由软件系统来执行。
46. 过程建模使用的技术：
1） 上下文图
2） 数据流图
3） 微规格说明（又称为过程规范）
4） 数据字典
47. 数据流图中的外部实体：
外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，它们不受系统的控制，开发者不能以任何方式操纵他们。所有的外部实体联合起来构成了软件系统的外部上下文环境，他们与软件系统的交互流就是软件系统与其外部环境的接口，这些接口联合起来定义了软件系统的系统边界。
48. 上下文图：
是DFD最高层次的图，是系统功能的最高抽象。
49. 0层图：
通常被用来作为整个系统的功能概图。0层图中不应该出现太过具体的过程和数据存储。
50. 微规格说明（P245）：结构化英语，行为图，决策树，决策表
51. 数据字典：
是一个存储库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当中数据流的数据存储的定义。
第十三章 ：数据建模
52. 数据模型：（P265）
53. 属性取值范围称为域。
54. 标识符（键），主键，替代键
55. 关系的度数是指参与关系的实体数量，是度量关系复杂度的一个指标:
1） 一元关系（递归关系）
2） 二元关系
3） 三元关系
56. 关系的基数：
1） 最大基数（键约束）
2） 最小基数（参与约束）
57. 被关系影响的实体：
1） 弱实体
2） 关联实体（常见形式：进程实体）
58. ERD的创建步骤：
1） 从描述信息中辨别实体
2） 确定实体的标识符
3） 建立实体之间的关系
4） 添加详细的描述信息
59. 复杂情况下的ERD创建步骤：
1） 发现系统的概念域
2） 建立对概念域的描述
3） 展开概念域
4） 合并概念域的局部数据结构
60. 功能/实体矩阵（P281）
第十四章 ：面向对象建模
61. 行为模型分为三种：
1） 交互图：依据交互行为进行的用例实现；
2） 状态图：依据处理流程（控制流和数据流）进行的用例实现；
3） 活动图：以状态机模型的方式进行的用例实现。
62. 交互图概念：
用于描述在特定上下文环境中一组对象的交互行为，该上下文环境就是被实现用例的某个场景。所以，交互图通常描述的是单个用例的典型场景。交互图中的每一个交互都描述了环境中的对象为了实现某个目标而执行的一系列消息交换。