软件项目需求管理课程 .ppt

确定需求开发过程 编写项目视图和范围文档 用户群分类 选择产品代表 建立核心队伍 确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用 2.2.2 需求获取 2.2.3 需求分析 需求分析包括提炼、分析和仔细审查已收集到的需求，以确保项目的参与者都明白其含义并找出其中的错误、遗漏或其它不足的地方。 需求分析的目的：获得高质量的、具体的需求 绘制关联图 创建用户接口原型 分析可行性 确定需求优先级 建立需求模型 编写数据字典 应用质量功能调配 2.2.3 需求分析 编写需求文档时，以下几点是应该注意的： 语句和段落尽量简短． 表达时采用主动语态． 语句要完整，且语法，标点等正确无误． 使用的术语要与词汇表中的定义保持一致． 陈述时要采用一致的样式． 避免模糊的，主观的术语，如性能＂优越＂ 避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证． 2.2.4编写需求文档 使用对象 需求文档的作用 软件项目客户 了解软件项目能够提供的软件产品，检查软件需求是 否 满 足需要 项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步 预测资 源的使用 软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系 软件发布人员 在需求文档的基础上编写用户文档，如用户手册 软件培训人员 在需求文档的基础上编写培训材料 需求文档的作用: 2.2.4编写需求文档 软件需求规格说明 (1)基本含义 规格就是一个预期的或已存在的计算机系统的表示，它可以作为开发者和用户之间协议的基础来产生预期的系统． 软件需求规格SRS也称为功能规格说明，需求协议或系统规格说明，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档． 软件项目管理者用SRS来对项目进行计划和管理。 除设计和实现上的限制外，SRS一般不包括设计、构建、测试或工程管理的细节。 2.2.4编写需求文档 SRS的基本内容包括功能需求和非功能需求。 功能需求定义系统需要“做什么”,描述系统输入输出的映射及其关联信息,完整地刻画系统功能,是整个软件需求的核心。 非功能需求定义系统的属性,描述和功能无关的目标系统特性,包括系统的性能、有效性、可靠性、安全性、易维护性及可见性等。 (2)IEEE标准830-1998 2.2.4编写需求文档 a 引言 a.1需求规格的目的 a.2软件产品范围 a.3定义、首字母缩写词语缩略语 a.4参考文献 a.5文档概要 b一般描述 b.1产品透视 b.2产品功能 b.3用户特征 b.4一般约束 b.5假设和依赖性 c专门需求 包括功能需求、非功能需求和接口需求 d附录 e索引 2.2.4编写需求文档 2.2.5需求验证 需求验证过程 确定合格的标准 编写用户手册 依据需求编写测试用例 审查需求文档 可读性 一致性 完备性 现实性 可检验性 可跟踪性 可调节性 有效性 验证的内容：在需求验证过程中,要对需求文档中定义的需 求执行多种类型的检查 2.2.5 需求验证 2.2.6 案例：某公司“船代”项目的需求开发 见课本P57 2.3.1 需求管理的必要性 2.3.2 需求管理的困难性 2.3.3 需求管理的目标和原则 2.3.4 需求管理活动 2.3.5 需求变更管理 2.3.6 需求状态 2.3.7 需求文档版本控制 2.3.8 需求跟踪 2.3.8 案例：需求变更的代价 2.3需求管理 需求供求双方固有的矛盾 　　 需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。 需求具有易变性和难以表述性 软件项目中４０％～６０％的问题都是在需求分析阶段埋下的祸根。 软件需求还很难以表述。 正是因为需求的易变性和难以表述性，所以需求需要有科学的分析方法和管理方法。 2.3.1 需求管理的必要性 需求错误出现的高频性和修复的高昂成本　　需求错误是软件项目开发中最常见的。 软件缺陷修复的高成本，如图2.5所示: 2.3.1 需求管理的必要性 一个在需求阶段出现的错误，在维护阶段修复它的成本约是需求阶段修复成本的１００～２００倍。 对于软件缺陷，修复的发现和修复的越早，则成本越低。 做好需求管理、减少需求错误的出现对降低软件项目的成本是至关重要的。 图2.5 软件缺陷修复的成本 2.3.2需求管理的困难性 需求不总是显而易见的，它可来自