第17章.需求管理解说.ppt

5. 需求管理的实践调查——需求管理工具 非常需要需求管理工具 通用的文本处理器（Word Processor）和电子表格（Spreadsheet）使用最为广泛 部分组织自己开发了专用需求管理工具 很少有组织使用专用的商业需求管理工具 无法和软件的开发过程以及其他辅助工具进行有效的集成 实例分析 经常出现一个模块的需求刚刚整理完毕或者程序编写了一半，业务已经发生变化的情况。在一年的开发过程中，我们陆续接到的业务变更行政命令多达几十条，这给整个软件开发和推广都带来了很大困惑。为了保证软件正常运行，省局信息中心不得不专门成立了软件推广维护小组，不断就新业务改写程序，各地也不得不在后续的过程中不停的从省局下载新的升级包，这件事情已经经历了很多年，大家都已经习惯了。 本章小结 需求管理是发生在需求开发之后的需求工程活动，贯穿于余下的产品生命周期，用于确保需求作业的有效实现 需求管理是一项重要的活动，包括维护需求基线、需求跟踪和需求变更控制 实践调查表明需求管理工作仍然有待人们的努力 思考题 如何有效的处理需求的变化是很多现代软件开发技术的主题，对此现象你有什么看法？结合本章内容，你将怎样做以控制一个需求多变的项目？ * 第17章.需求管理 主要内容 需求管理 需求基线 需求跟踪 需求变更控制 需求管理的实践调查 1. 需求管理——意图 需求的影响力 整个后续的产品生命周期 VS 需求开发阶段 需求规格说明文档 后续的开发工作都应该以软件需求规格说明文档的内容为标准和目标来进行 需求管理 在需求开发之后的产品生命周期当中保证需求作用的有效发挥 1. 需求管理——作用 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解 增强了项目涉众对需求（尤其是复杂需求）的掌握。 增进了项目涉众之间的交流 减少了可能的误解和交流偏差。 减少了工作量的浪费，提高了生产力 需求管理能够更加有效的处理需求的变更 准确反映项目的状态，帮助进行更好的项目决策 需求跟踪信息能够更加准确的反映项目的进展情况 改变项目文化，使得需求的作用得到重视和有效发挥 使得项目涉众认识到需求在项目工作中的重要性 1. 需求管理——任务 交流涉众需要什么； 将需求应用、实施到解决方案； 驱动设计和实现工作； 控制变更； 将需求分配到子系统； 测试和验证最终产品； 控制迭代式开发中的变化； 辅助项目管理 1. 需求管理——活动 主要内容 需求管理 需求基线 需求跟踪 需求变更控制 需求管理的实践调查 2. 需求基线 已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改它 是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合 2. 需求基线——描述内容 标识符（ID），为后续的项目工作提供一个共同的交流参照。 当前版本号（Version），保证项目的各项工作都建立在必威体育精装版的一致需求基础之上。 源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。 理由（Rational），提供需求产生的背景知识。 优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。 状态（Status），交流和具体需求相关的项目工作状况。 成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的设计和实现提供参考信息，驱动设计和实现工作。 需求创建的日期； 和需求相关的项目工作人员，包括需求的作者、设计者、实现者、测试者等； 需求涉及的子系统； 需求涉及的产品版本号； 需求的验收和验证标准； … 2. 需求基线——维护活动：配置管理 标识配置项 递增数值，例如1，2，…x； 层次式数值编码，例如1.1.1，1.2.1，…x.y.z； 层次式命名编码，例如Order.Place.Date，Order.Place.Register，…Task.Step.Substep 版本控制 每一条单独的需求需要进行版本控制 相关的需求文档也需要进行版本控制 变更控制 访问审计 记录和审计访问的情况 状态报告 反映需求基线的成熟度（变化的幅度越大，成熟度越低）、稳定性（改变的次数越多，稳定性越差）等 2. 需求基线——维护活动：状态维护 状态 定义 已提议（Proposed） 该需求已被有相应权限的人提出 已批准（Approved） 该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本的基线中。关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求 已实现（Implemented） 实现这一需求的系统组件已经完成了设计和实现。这一需求已经被跟踪到相关的设计元素和实现元素 已验证（Verified） 已在集成产品中确认了这