需求工程期末复习解析.docVIP

：需求工程导论 需求工程定义： 是所有需求处理活动的和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。 需求工程的基本活动： 需求开发：需求获取，需求分析，需求规格说明，需求验证 需求管理 各个活动的目的： 需求获取的目的是从项目的战略规划开始建立最初的原始需求； 需求分析的目的是保证需求的完整性和一致性； 需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来； 需求验证的首要目的是保证需求及其文档的正确性，即需求正确的反映了用户的真实意图；另一个目标是通过检查和修正，保证需求及其文档的完整性和一致性； 需求管理的主要工作是跟踪后继阶段中的需求实现与需求变更情况，确定需求得到了正确的理解并被正确的是想到了软件产品中。 软件需求规格说明定义： 软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。 ：需求基础 软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性。 需求分类： 功能需求：业务需求，用户需求，系统需求 性能需求 质量属性 对外接口 约束 ：（不考） ：需求获取概述 需求工程需要获取的内容主要有三种： 需求 问题域描述 环境与约束 需求获取信息的主要来源： 涉众 硬数据 相关产品 重要文档 相关技术标准和法规 获取信息的方法： 传统方法：问卷调查，面谈，文档分析，文档检查，需求剥离 集体获取方法：头脑风暴，专题讨论会，JAD，JRP 原型 模型驱动方法：基于场景，基于用例 认知方法：任务分析，协议分析 基于上下文的方法：观察，民族志，话语分析 常见的组织方式是依照系统特性，确定系统的边界，建立上下文图或系统用例图，然后按照遍历上下文图和系统用例图的方式开展获取活动。 ：确定项目的前景和范围 前景： 描述了产品的作用以及最终的功能，它将所有涉众都统一到一个方向上。 范围： 指出了当前项目是要解决产品长远规划中的哪一个部分，范围声明它为项目规定了需求的界限。 对于不明确的问题，直接抛弃是一种错误的做法，正确的做法应该是使用不同的方法发现涉众提出不明确问题的原因，理解不明确问题背后深藏的问题。 需要注意的是问题解决方案的边界不是系统的边界，一个解决方案外部的输入可能来自于同一个系统中另一个问题解决方案的输出，即系统的内部。 描述系统的边界，通常会用上下文图和系统用例图。 ：涉众分析与硬数据采样 涉众定义： 所有能够影响软件系统的实现，或者被实现后的软件系统影响的个人和团体。 四种常见涉众类型： 参与者 环境设定者 被影响者 观众（优先级最低）：领域专家和市场力量是比较常见的观众 硬数据 定量硬数据：数据收集表格，统计报表 定性硬数据：整个组织的描述文档，业务指导文档，业务备忘 ：需求获取方法之面谈 面谈结构： 金字塔结构 漏斗结构 菱形结构 面谈分为三种类型： 结构化面谈 半结构化面谈 非结构化面谈 调查问卷，头脑风暴（P130） ：需求获取方法之原型 原型：是一个系统，它内化了一个更迟系统的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者代替。 原型的类别 按照开发方法进行分类：演化式原型，抛弃式原型（探索式原型，实验式） 按照构建技术进行分类：水平原型，垂直原型 原型的需求内容：（三个） 外观 角色 实现 ：需求获取方法之观察与文档审查 常见的观察方法： 采样观察 民族志 话语分析 协议分析 任务分析 应用观察方法解决的问题： 理解复杂的协同事件 获取工作中的异常处理 获取与用户认知不一致的实际知识 了解用户的认知 获取默认知识 采样观察法： 时间采样 事件采样 文档审查中文档分为三种类型： 相关产品的需求规格说明 硬数据 客户的需求文档 另外，需要注意的是，文档虽然来自于当前计算机或手工系统的产物，但这并不表示它就是正确的。 ：需求组织——需求获取中的模型驱动方法 模型驱动方法：是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求工程方法。 目标模型（P165） 场景方法的分类框架： 场景的形式：描述，外观 场景的内容 场景的目的：描述，探索，解释 场景的生命周期 用例描述 用例是静态的结构化文本描述 用例可以用于各种目的的应用，包括描述、探索、解释 用例之间的关系：（三种） 包含 扩展 泛化 在需求工程中，主要产生三类重要的文档： 项目前景和范围文档 用户需求文档 需求规格说明 36. 用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户期望的作用。在特殊的情况下，用例文档还可以用来代替需求规格说明，但总的来说这是一种并不值得提倡的方法。 ：需求分析概述 总的来说，需求获取得到的