《第二章 需求管理与配置管理.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的注意事项。