SPI-E-REQM-P01(需求管理过程文件).doc

编码 编码 XX SPI E REQM P01 XXXX 有限责任公司有限责任公司 需求管理过程文件需求管理过程文件 拟制人拟制人 XXXX 日期日期 20062006 年年 0707 月月 1212 日日 审核人审核人 XXXX 日期日期 20062006 年年 0707 月月 1414 日日 批准人批准人 XXXX 日期日期 20062006 年年 0707 月月 1414 日日 需求管理过程文件 编码 XX SPI E REQM P01 更改控制页更改控制页 序号序号版本号版本号更改时间更改时间更改内容描述更改内容描述填写人填写人 010 12006 04 20 新建 初稿 020 22006 07 11 修改 完善三个过程活动的部分内 容 031 02006 07 12 定稿 形成 1 0 版本 需求管理过程文件 编码 XX SPI E REQM P01 目目 录录 1目的 1 2范围 1 3术语定义 1 4职责 2 5裁剪指南 2 6过程 3 6 1依据需求建立跟踪矩阵 3 6 1 1概要图 3 6 1 2启动条件 4 6 1 3输入 4 6 1 4活动 4 6 1 4 1学习和理解 需求开发 阶段的产生的需求文档 4 6 1 4 2获得对需求的承诺 5 6 1 4 3建立需求跟踪矩阵 5 6 1 5输出 5 6 1 6关闭标准 5 6 2需求不一致跟踪 6 6 2 1概要图 6 6 2 2启动条件 7 6 2 3输入 7 6 2 4活动 7 6 2 4 1接收当前阶段工作产品 维护矩阵 7 6 2 4 2发现不一致 7 6 2 4 3分析不一致 制定解决方案 8 6 2 4 4执行纠正活动 8 6 2 4 5需求管理的记录 9 6 2 5输出 9 6 2 6关闭标准 9 6 3需求变更管理 10 6 3 1概要图 10 6 3 2启动条件 10 6 3 3输入 11 6 3 4活动 11 6 3 4 1收集需求变更请求 11 需求管理过程文件 编码 XX SPI E REQM P01 6 3 4 2分析变更申请 11 6 3 4 3评审变更请求及解决方案 11 6 3 4 4获得对变更的承诺 12 6 3 4 5执行需求变更活动 13 6 3 4 6记录所有变更 14 6 3 5输出 14 6 3 6关闭标准 14 7审核 14 8度量 14 9技能要求 15 10参照文件 15 需求管理过程文件 编码 XX SPI E REQM P01 第1 页 1 1目的目的 对需求进行管理 维护需求 识别与项目计划和工作产品之间的不一致之处 确保把对需求的更改反映到项目计划 活动和工作产品中 确保项目经过确认的用户需求 能被有效的管理 维护 跟踪 并正确的实现 最终满足用户的需要 2 2范围范围 从 需求开发 的 需求确认 结束开始 直到项目结束为止 有些项目可能 只到通过 用户验收 为止 3 3术语定义术语定义 EPGEPG 工程过程组 组织 执行 维护软件过程改进的所有活动 CCBCCB Change Control Board 变更控制委员会 项目经理 客户 高级经理 技术专家等 CCB 的参加范围可以根据不同的情况而有所变更 当变更的影响非常小 对项 目的阶段性进度和阶段内的各项活动的影响也非常小 甚至可以忽略不计时 CCB 可由项目经理和客户组成 当变更的影响仍非常小 对项目的阶段性进度的影响也 非常小 甚至可以忽略不计 但在阶段内的活动需要有所变动时 投入的资源相对 不发生变化时 CCB 可以项目经理 项目组成员和客户组成 其他的情况 CCB 应 由项目经理 项目内的主要成员 高级经理和客户组成 技术管理委员会技术管理委员会 对有关技术问题进行评审 审查的组织 一般执行同行评审 的活动 成员为项目经理 技术专家等 项目总监 技术副总可以以技术专家的身 份参加技术管理委员会 针对具体的项目时 客户的技术专家也可以临时加入这个 组织 需求跟踪矩阵需求跟踪矩阵 用于维护项目实现客户需求的跟踪工具 Comment l1 如果不需要需求反讲 需要去掉相关活动和文档 需求管理过程文件 编码 XX SPI E REQM P01 第2 页 需求不一致需求不一致 需求与项目计划和工作产品之间的差异 工作产品工作产品 用于指由过程产生的任何人工制品 这些人工制品包括文档 产品 的一部分 服务 过程 规范等 需求基线需求基线 需求开发结束时发布的与需求相关的一组工作产品 这组工作产品 一般包括需求开发的全部工作产品 需求文档 评审记录及参考文档 是项目计 划以及其他附属计划的参考依据 4 4职责职责 RMRM GP2 4 角色角色 活动活动 需求小组项目组客户高级经理 CCB 技术管理 委员会 获得需求获得需求 承诺 理解需 求 承诺承诺 讲解需求讲解需求理解需 求 反讲 建立跟踪矩阵建立 需求跟踪 发现不一致 识别 跟踪 维护矩阵 解决解决 参与评审 解决 参与评审 必要时参 与评审 管理变更 管理 协调 实施 了解 实施变 更活动 提出 评 审 评审评审评审 5 5裁剪指南裁剪指南 根据项目实际情况 包括需求明确程度 项目规模 工期 变更情况 项目经 理可对本过程进行裁剪 需求管理过程文件 编码 XX SPI E REQM P01 第3 页 根据项目已定义的过程对需求管理的过程阶段和工作产品进行裁剪 6 6过程过程 6 16 1 依据需求建立跟踪矩阵依据需求建立跟踪矩阵 需求小组 一般包括项目经理 系统分析员 依据经过 需求开发 而形成的 需求文档 建立 需求跟踪矩阵 6 1 16 1 1概要图概要图 RMRM GP3 1GP3 1 需求管理过程文件 编码 XX SPI E REQM P01 第4 页 6 1 26 1 2启动条件启动条件 需求开发活动已经执行 并得出 系统需求规格说明书 6 1 36 1 3输入输入 RMRM GP2 3GP2 3 用户需求说明书 系统需求规格说明书 项目已定义的软件过程 6 1 46 1 4活动活动 6 1 4 16 1 4 1学习和理解学习和理解 需求开发需求开发 阶段的产生的需求文档阶段的产生的需求文档 RMRM SP1 1SP1 1 6 1 4 1 1 讲解需求 需求小组在 需求开发 阶段产出了 需求文档 用户需求说明书 一般 是经过组织 提炼 概括后的用户提出的需求 系统需求规格说明书 是经过转 化后形成的可供操作的 可开发的系统需求说明 一般能满足所有的用户需求 需求小组对 需求文档 的内容进行讲解 被讲解人一般为项目经理 后续阶 段活动的项目组成员 例如 系统设计阶段的系统设计员 开发阶段的编码人员 测试阶段的测试人员 实施过程的实施人员和验收人员等 在这一过程中一定要 达到被讲解人能够完全理解 需求 的内容 6 1 4 1 2 反讲需求 项目经理认为必要时可组织项目组成员对需求进行反讲 加深对需求的了解 系统分析员与项目经理组成需求小组 当系统分析员完成需求开发 系统分析 工作后离开项目组时 项目经理必须有能力对需求进行维护 项目经理必须在系统 分析员的帮助下熟知需求 系统分析的内容 任务等 在项目运行过程中 当需求发生变更后 重新进行 需求开发 后产生新的 需求文档 时 系统分析员应对需求的变化情况以及变化产生的影响进行讲解 需求管理过程文件 编码 XX SPI E REQM P01 第5 页 6 1 4 26 1 4 2获得对需求的承诺获得对需求的承诺 RMRM SP1 2SP1 2 需求小组与客户 各个项目参与者达成共识 确保项目的各个阶段的参与者能 够对当前的 需求 做出承诺 每个项目参与者都在理解了需求的基础之上 做出 对 需求 的承诺 需求小组维护对于需求变更后的重新 需求开发 阶段之后的所有项目相关人 员的重新确认 重新承诺的过程 需求小组获得 需求开发 的后续阶段的各个参与者对 需求 的确认和承诺 确保 需求 的连续性 一致性 完整性 需求小组组织签订 维护有 需求承诺 的 用户需求说明书 系统需求 规格说明书 文档 6 1 4 36 1 4 3建立需求跟踪矩阵建立需求跟踪矩阵 RMRM SP1 4SP1 4 需求小组依据最初的经过 需求开发 阶段得到的被确认的 需求文档 项目已定义的软件过程 来建立 需求跟踪矩阵 确定跟踪的时间 频率 间 隔等 需求小组从 需求文档 中识别出各个需求项目 并按 需求文档 中定义好 的需求项编号或需求项名称 一一填写在 需求跟踪矩阵 中 需求小组将 需求跟踪矩阵 作为 需求管理安排计划 列入项目计划的从属 计划 参与项目计划的评审 需求管理安排的时间一般是里程碑或周这样的阶段性 时间 6 1 56 1 5输出输出 RMRM GP2 3GP2 3 需求跟踪矩阵 6 1 66 1 6关闭标准关闭标准 需求小组建立了 需求跟踪矩阵 并将需求讲解给项目组 至少 项目策划 阶段的项目组成员已经理解了需求 需求管理过程文件 编码 XX SPI E REQM P01 第6 页 6 26 2 需求不一致跟踪需求不一致跟踪 RMRM SP1 5SP1 5 需求小组跟踪在项目运行过程中需求的状态 工作产品与需求之间的不一致等 内容 并且采取措施维护工作产品与需求的一致性 6 2 16 2 1概要图概要图 RMRM GP3 1GP3 1 需求管理过程文件 编码 XX SPI E REQM P01 第7 页 6 2 26 2 2启动条件启动条件 项目运行到里程碑点 或达到 需求跟踪矩阵 中的下一跟踪时刻 6 2 36 2 3输输入入 RMRM GP2 3GP2 3 需求跟踪矩阵 当前阶段的工作产品 6 2 46 2 4活动活动 本活动是个持续 反复执行的过程 项目没有结束 就要一直执行下去 6 2 4 16 2 4 1接收当前阶段工作产品 维护矩阵接收当前阶段工作产品 维护矩阵 RMRM SP1 4SP1 4 需求小组在 需求开发 的后续过程中 按 需求跟踪矩阵 中计划好的时间 接收后续阶段过程的工作产品 后续阶段过程的执行人或参与者 例如设计阶段的 系统设计员 应将当前阶段的工作产品为需求小组讲解 直到需求小组理解为止 需求小组对比 需求跟踪矩阵 的内容 将当前阶段的工作产品的细节理清 形成子模块等并填入 需求跟踪矩阵 填写后续过程的内容 当 需求变更 被执行后 需求小组依据所有的 需求变更 的结果 修改 需求跟踪矩阵 的内容 如果 需求变更 影响到了 项目计划 和 进度安排 时 需求跟踪矩阵 中的时间安排也应相应发生变化 变化后的 需求跟踪矩阵 也应同变化的 项目计划 一同进行评审 6 2 4 26 2 4 2发现不一致发现不一致 RMRM SP1 5SP1 5 需求小组审查项目计划 活动和工作产品 看其是否与需求和需求变更一致 需求小组依据已获得的项目阶段性工作产品 利用 需求跟踪矩阵 对需求 进行不一致检查 逐条检查需求 看当前阶段的工作产品是否实现了全部的需求 需求管理过程文件 编码 XX SPI E REQM P01 第8 页 逐条检查工作产品 看当前阶段的工作产品是否都能满足 需求 中的某个或 某几个需求项 需求小组将在检查中发现的不一致内容填写在 不一致报告 中 6 2 4 36 2 4 3分析不一致 制定解决方案分析不一致 制定解决方案 RMRM GP2 2GP2 2 6 2 4 3 1 分析不一致 需求小组分析 不一致 确定不一致的原因 类型 来源 严重性等 6 2 4 3 2 制定解决方案 需求小组依据分析的结果 召集与不一致有关的项目相关人员制定解决方案 当重大不一致发生时 有必要召集技术管理委员会来分析 需求不一致 制定和 确认解决方案 解决方案一般可分为如下几种 修改需求 经过技术管理委员会与客户的讨论协商确定通过修改需求来解决不 一致 这种情况发生的可能性非常小 修改阶段性工作产品 需求小组召集项目当前阶段的相关人员 确定一个修改 方案 项目相关人员依据这个方案进行修改 不作修改 经过技术管理委员会与客户的讨论协商确定 对不一致不作解决 也就是客户对不一致给予认同 当后续阶段产生的不一致是因为这个不一致引起的 都不认为是不一致 但要给予标明出处 6 2 4 46 2 4 4执行纠正活动执行纠正活动 RMRM GP2 9GP2 9 需求小组识别出由于对需求基线的变更而导致的必须对项目计划 活动和工作 产品做出的变更 活动参见 需求变更 流程 需求管理过程文件 编码 XX SPI E REQM P01 第9 页 6 2 4 4 1 管理纠正活动 需求小组依据已确认的解决方案 通知 监督项目组或其他相关方来消除不一 致 6 2 4 4 2 执行纠正活动 项目的其他工程组或其他相关方依据已确认的解决方案来消除不一致 并将消 除不一致的结果通知需求小组 6 2 4 4 3 关闭不一致 消除需求不一致直到需求小组认为这个不一致被解决 或技术管理委员会认可 当前的需求不一致为止 需求小组组织与需求不一致有关的相关方 或召集技术管理委员会评审不一致 处理的结果 认同不一致的解决结果 则关闭不一致 否则重新解决不一致 或重 新分析不一致 需求小组将评审活动 结果填入 不一致报告 中 需求小组将不一致发现 分析 处理的过程和结果填写在 不一致报告 中 需求小组将修改的结果及时反应到 需求跟踪矩阵 中 6 2 4 56 2 4 5需求管理的记录需求管理的记录 CMCM SG2SG2 需求小组将需求跟踪活动的过程 结果 需求的不一致以及原因 解决方法等 分别记录在 个人周报 或相关的文档中 提交给项目经理 项目经理对这些内容 进行总结 记录在 项目周报 中 并通报给项目总监和技术副总 6 2 56 2 5输出输出 RMRM GP2 3GP2 3 需求跟踪矩阵 不一致报告 6 2 66 2 6关闭标准关闭标准 项目结束 需求管理过程文件 编码 XX SPI E REQM P01 第10 页 发现的需求不一致得到解决 6 36 3 需求变更管理需求变更管理 RMRM SP1 3SP1 3 需求小组接收由客户提出的需求变更请求 与相关人员一起分析请求 给出解 决措施 并将变更实施体现到需求文档和各项项目活动和工作产品中 6 3 16 3 1概要图概要图 RMRM GP3 1GP3 1 6 3 26 3 2启动条件启动条件 项目的客户提出了需求变更的请求 需求管理过程文件 编码 XX SPI E REQM P01 第11 页 6 3 36 3 3输入输入 RMRM GP2 3GP2 3 需求变更的请求 6 3 46 3 4活动活动 管理需求变更是个事件驱动型的活动 6 3 4 16 3 4 1收集需求变更请收集需求变更请求求 RMRM SP1 1SP1 1 需求小组收集项目相关方 主要是客户 的需求变更请求 客户提出需求变更的 可能的方式 电话 传真 邮件 会议纪要等 并且这些记录的文件或其他的方式 被客户给予确认 填写 需求变更申请 变更的提出人应在 需求变更申请 上签字确认 6 3 4 26 3 4 2分析变更申请分析变更申请 RMRM GP2 2GP2 2 需求小组会同变更的提出人一起分析变更申请 确定影响 拟定解决方案 同 时需求小组应有拟定解决方案时与项目组其他成员一同来完成 这样可以保证解决 方案的正确性 执行的可操作性 顺利性 解决方案一般为如下几种 不解决 否决需求变更申请 立即解决 暂停项目的当前正常的进行 修改需求 修改计划 修改设计 修 改编码 修改集成等来解决问题 一般会对项目产生很大的影响 以后解决 将变更请求作为维护项目处理 作为项目的后续项目执行 6 3 4 36 3 4 3评审变更评审变更请求及解决方案请求及解决方案 RMRM GP2 8GP2 8 依据影响需求小组确定 CCB 的组织范围 当需求的变更对项目的影响被认为是微乎其微 对各项工作的进展及阶段的进 度影响非常小 CCB 可以由需求小组和客户组成 需求管理过程文件 编码 XX SPI E REQM P01 第12 页 当需求的变更对项目的影响被认为是很小 对各项工作的开展的影响是有的 但对阶段性的进度的影响是可以不计的 CCB 的组成就可以由需求小组 项目成员 及客户组成 6 3 4 3 1 评审 需求小组组织 CCB 对需求变更申请 变更的预期影响和拟定的解决方案进行评 审 预期的影响包括 对于进度的影响 其他功能模块的影响 系统非功能性指标 稳定性 的影响 对系统质量的影响 对风险的影响 否决了变更申请 结束这一流程 接受变更申请 未通过解决方案 刚退回到分析变更申请的过程 直到通过为 止 6 3 4 3 2 评审结果 需求小组依据需求变更的影响 完善 需求变更申请 可以将解决方案及评 审的过程 结果记录作为附件记录下来 当需求变更影响比较大时 应将解决方案及评审的过程 结果记录在单独的 评审报告 中 6 3 4 3 3 接纳否决结果 当否决了需求变更请求时 需求小组应将结果通知客户 通知方式可以是任意 一种双方认可的方式 可以是电话 传真 电子邮件 正式的文档等 6 3 4 46 3 4 4获得对变更的承诺获得对变更的承诺 RMRM SP1 2SP1 2 需求小组应向本次变更涉及的相关方获得相应的承诺 承诺方式可以双方认可 的方式 可以是电话 传真 电子邮件 正式的文档等 需求管理过程文件 编码 XX SPI E REQM P01 第13 页 6 3 4 56 3 4 5执行需求变更活动执行需求变更活动 6 3 4 5 1 管理变更 一旦需求被变更了 其可能影响的项目过程也会一起发生变化 受 需求变更 影响的可能的过程包括 需求开发 及以后的所有过程 需求小组要控制整个变更过程 需求小组依据确认的解决方案 召集项目组成 员通知执行解决方案 6 3 4 5 2 开发新的需求 如需重新开发需求 则重新执行 需求开发 过程 形成新需求文档 6 3 4 5 3 修改项目各阶段的工作产品 各受需求变更影响的工程小组执行解决方案 如果需求变更影响到 项目计划 则重新执行 项目策划 过程以及其后续 过程 6 3 4 5 4 维护与原工作进度的一致性 各受需求变更影响的工程小组将执行需求变更后的影响与当前工作相结合 将 变更对工作的影响降到最小 6 3 4 5 5 调整需求跟踪矩阵 需求小组重新确定 需求跟踪矩阵 重新执行 需求不一致跟踪 维护 需求跟踪