《第二章 需求管理与配置管理.doc》由会员分享，可在线阅读，更多相关《第二章 需求管理与配置管理.doc（5页珍藏版）》请在金锄头文库上搜索。
1、第二章 需求管理与配置管理1. 需求管理1.1. 为什么要做需求管理？1.1.1. 客户做的自己要什么，但表达不清。1.1.2. 客户也不知道自己要什么。1.1.3. 客户期望靠软件系统的实施，提高企业管理水平。1.2. 软件项目的需求管理包括 需求调研、需求分析、需求变更等几方面的工作。1.3. 需求规格说明书 1.3.1. 功能性需求：1.3.1.1. 功能性需求用来描述系统所应提供的功能和服务。包括系统应该提供的服务、对输入如何响应及特定条件下系统的行为。1.3.1.2. 对于功能性的系统需求，需要详细地描述系统功能、输入和输出、异常等，1.3.1.3. 系统的功能性需求应该具有全面性和
2、一致性。1.3.2. 非功能性需求1.3.2.1. 非功能性需求是指那些不直接与系统的具体功能相关的一类需求，他们与系统的总体特征相关，如可靠性、可扩展性、安全性、响应时间等，甚至包括界面易用程度和文档、代码规范性的要求。1.3.3. 用例 1.3.3.1. 用例，英文说法：Use Case。用例的定义：与系统使用者交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。1.3.3.2. 用例图：是由参与者、用例以及他们之间的关系构成的图，用例图表达系统中出现的各种事物处理或过程的图形，或者表达系统执行能够执行的各种功能。1.3.3.3. 用例图的各个组成部分：1.3.3.3.1. 系
3、统1.3.3.3.2. 参与者1.3.3.3.3. 用例1.3.3.3.4. 之间关系1.3.3.4. 用例图有助于：1.3.3.4.1. 将重点放在系统的可能用户上。1.3.3.4.2. 确定用户与系统交互时要扮演的角色。1.3.3.4.3. 确定用户出于各自的角色，期望从系统中获得死吗基本服务（用例）。1.3.3.4.4. 描述每个用户或角色与期望从系统中获得服务之间的交互。1.3.3.5. 用例之间的关系：1.3.3.5.1. 扩展关系(extends).1.3.3.5.2. “用”关系(uses)1.3.3.5.3. “泛化(继承)”关系1.3.3.6. 构建一个用例需要四个阶段：1.
4、3.3.6.1. 清晰定义系统或系统边界。1.3.3.6.2. 标识与各种过程或用例直接相关的参与者。1.3.3.6.3. 标识各个用例1.3.3.6.4. 确定参与者和用例之间的关系。1.3.4. 静态原型法：1.3.4.1. 原型的定义：原型（prototype）即把系统的主要功能和功能执行流程通过快速开发制作为“软件样式机”。1.3.4.2. 原型的主要价值：原型法的主要价值是可视化、强化沟通、降低风险，节省后期变更成本，提高项目成功率。1.3.4.3. 基本要求：1.3.4.3.1. 体现主要的功能。1.3.4.3.2. 提供基本的界面风格。1.3.4.3.3. 明确展示需求中模糊的部
5、分，便于与客户进行确认或进一步明确。2. 配置管理：2.1. 什么事配置管理：2.1.1. 配置管理就是让大家在项目开发过程中时刻保持一致的一系列举措。2.1.2. 配置管理包括项目源代码、文档的版本控制与管理。2.2. 配置管理的工作内容：（6个任务）2.2.1. 任务一：配置标识2.2.1.1. “配置管理”管理的主要对象是文件，那首先要定义那些文件时需要纳入管理，也就是定义那些是“配置项”。2.2.2. 任务二：版本管理2.2.3. 任务三：变更管理2.2.4. 任务四：配置审核2.2.4.1. 配置审核包括两个方面的内容：“配置管理活动审核”、“基线审核”。2.2.4.1.1. “配置
6、管理活动审核”用于确保项目组成人员的所有配置活动，遵守已批准的软件配置管理方针和规程。2.2.4.1.2. “基线审核”要保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。2.2.5. 任务五：报告配置状态2.2.6. 任务六：发布管理3. 总结：3.1. 需求规格说明书通常由功能性需求和非功能性需求两部分组成。3.2. 用例被用来描述一个系统外在可见的需求情况，常被用作项目的需求分析阶段。3.3. UML用例图通常由系统，参与者和用例组成。3.4. 用例之间常见的两种关系：用关系和扩展关系。3.5. 作为需求规格说明书的附件，原型具有同等的效力。3.6. 要学会配置管理工具Vss的使用，如何离线修改，使用Vss的注意事项。
