需求管理最佳实践全解

变更控制步骤


每个变更控制步骤由4个组件组成： 开始条件：在执行过程或步骤前应该满足的条件 过程和步骤中所包含的不同任务及项目中负责完成它 们的角色 验证任务正确完成的步骤 结束条件：指出过程或步骤完成的条件
软件开发中的V字模型
用户需求 验收测试
功能需求
系统测试
概要设计 时间 详细设计
集成测试
单元测试
编码
需求评审：方法


非正式评审： > 同级桌面检查：请一位同事检查 > 轮查：同时请若干同事分别检查 > 走查：作者向评审人员描述，并要求做出评论 正式评审 > 同级评审(审查)：最有效的软件质量技术
需求审查：要点




工作量/费用
是否与目标相关 产品将维护一个查询表，记录一年中日出和日落时 间 检查验收标准 生产率 在限制条件下是否可行 是需求还是解决方案 需求蔓延的影响 顾客价值与镀金需求 新大小 需求蔓延
原规模
产品大小
变更管理应确保的事项

应仔细评估已建议的变更 挑选合适的人选对变更做出决定 变更应及时通知所有涉及的人员 项目要按一定的程序来采纳需求变更
需求管理最佳实践 5



标识全局系统需求：是在总体上说明了系统想要的或 者必须的属性。它们不能够赋予单独的子系统。 > 主要效益：找到变更成本最大的需求 > 引入成本：低 > 应用成本：低 标识易变的需求：应该维护一个易变的需求列表，即 那些最可能发生变更的需求。如果可能，应该对这些 需求的变更进行预测。 > 主要效益：简化需求变更管理 > 引入成本：低 > 应用成本：低 记录丢弃的需求 > 主要效益：当其再次提出时，保存再分析结果 > 引入成本：低 > 应用成本：低
需求管理最佳实践 3

使用数据库来管理需求：建立一个需求数据库，把单 个需求作为条目存储进数据库，而不要用文本文档来 维护需求。 > 主要效益：使管理大量的需求变得容易 > 引入成本：中等-高 > 应用成本：中等 > 实施指南：需求是怎么表达的？自然语言、图形模 型、数学表达式？一般需要管理多少需求？需求总是 由在同一地方工作、使用相同类型电脑的小组开发和 管理的吗？已经使用一个支持软件工程的数据库了吗 ？有内部的数据库专家吗？需求工程师负责数据库管 理吗？
需求管理最佳实践 1


惟一地标识每一个需求：应该给每一个需求分配一个 惟一的标识符或者引用数字，可以用于在需求文档的 其他部分或在其他系统文档中指向该需求。 > 主要效益：明确地引用特定需求是可能的 > 引入成本：很低 > 应用成本：很低 定义需求管理的策略：定义了需求管理的目标，应该 遵循的过程和应该使用的标准。 > 主要效益：对所有参与需求管理的人提供指导 > 引入成本：中等 > 应用成本：低
需求审查：开始标准

文档遵循标准模板 文档已经进行过拼写检查 作者已经检查了文档在版面上的错误 已经获得了审查前需要阅读的文档或参考文档 在文档中标上了行号，便于查阅 所有未解决问题已标上了TBD 主持人检查10分钟后，找不出3个以上重大错误
需求审查：主要阶段

控制项目范围的扩展


对许多项目而言，需求的改进是合理且不可避免 首先应把新系统的视图、范围、限制文档化并作为业 务需求的一部分 对于控制范围扩展的方法是要敢于说“不” 基线+变更过程是解决项目范围扩展的重要手段
变更控制过程


பைடு நூலகம்

好的变更控制过程给项目风险承担者提供了正式的建 议需求变更机制 变更控制过程并不是给变更设置障碍，而是提供一个 渠道和过滤器 控制需求变更同项目的其他配置管理决策是紧密相连 的，管理需求变更类似于跟踪错误和做出相应决定的 过程
需求评审：方法


非正式评审： > 同级桌面检查：请一位同事检查 > 轮查：同时请若干同事分别检查 > 走查：作者向评审人员描述，并要求做出评论 正式评审 > 同级评审(审查)：最有效的软件质量技术
需求审查过程


参与者 > 需求规格说明书的作者、同级伙伴 > 提供规格说明信息的人：分析员、客户 > 要根据规格书开展工作的人：开发人员… > 负责相关接口工作的人 > 总人数：<=6人 角色 > 作者 > 主持人 > 读者 > 记录员
规划：谁参加？准备什么材料？ 总体会议：确定审查的背景、假设及目标 准备：审查员阅读材料 审查会议：主持人引导 返工：审查结果修改 跟踪：确定错误已修正 规划
初始工作产品
总体会议
审查会议
准备
返工
跟踪
完成基线的产品
需求审查：要点


需求的完整性 > 是否存在遗漏的内容 > 是否对所有风险承担者都有考虑 需求的可追踪性 > 惟一标识符号 > 类型说明 > 对用例的引用 > 冲突描述 > 一致使用术语
变更控制策略




所有需求变更必须遵循的过程，按照此过程如果一个 变更需求未被采纳，则其后过程不再予以考虑 对于未批准的变更，除可行性论证之外，不应再做其 他设计和实现工作 简单请求一个变更不能保证能实现变更，要由项目变 更控制委员会（CCB）决定实现哪些变更 项目风险承担者应该能够了解变更数据库的内容 绝不能从数据库中删除或修改变更请求的原始文档 每一个集成的需求变更必须能够跟踪到一个经核准的 变更请求
需求管理最佳实践 4

定义变更管理策略：陈述了变更是以何种形式提出、 分析和评审的。然后实现已接爱的变更，产生一个新 版本的需求文档。 > 主要效益：提供一个系统地评估变更提议的框架 > 引入成本：中等-高 > 应用成本：低-中等 > 实施指南：应包括变更请求过程和处理每个变更请 求所需的信息；用来分析变更的影响和成本以及相关 的可跟踪性信息的过程；正式考虑变更请求的成员人 数；变更控制的软件支持
需求管理最佳实践 2


定义可跟踪性策略：应定义应用维护哪些可跟踪性的 信息以及该信息应该怎样表示，可跟踪性信息是可以 发现需求间、需求和系统设计、组件和文档间依赖性 的信息。 > 主要效益：维护所有系统的一致的可跟踪性信息 > 引入成本：中等 > 应用成本：中等-高 维护可跟踪性手册：它是对需求文档的一个补充，包 含了在项目中使用的特定的跟踪性策略和需求的可追 踪性信息。 > 主要效益：作为所有特定项目的可跟踪性信息的中 心记录 > 引入成本：低 > 应用成本：中等-高