需求管理培训.ppt

需求管理的流程 涉众(需求)请求管理中的活动： 涉众(需求)请求提交 来自客户的新的需求或缺陷,由技术支持部通过《产品问题表》 提交给产品经理(项目组长) 产品经理(项目组长)确认解决版本（1.0），文秘(相关人员)录入 反馈问题－不改需要协商 出差情况跟踪表 整理涉众(需求)请求 － 涉众(需求)请求状态跟踪 　　 根据状态转移矩阵 业务需求定义 业务需求定义的方式 产品经理(项目组长)确定业务需求定义方式 业务陈述:一般升级版/过渡版 业务建模:新产品/升级版 业务分析员确定是否需要调研及其调研的方式 调研:新产品/重大升级版 工作产品 《业务需求陈述》 《业务用例模型》 《业务用例规约》 《业务词汇表》--可选 《业务构架文档》 业务需求定义 业务需求评审 组织业务需求评审 评审方式:评审会议 评审级别： 　　　　A级评审－QA组织 　　　　B级评审－产品经理(项目组长)组织 参加人员 　　　　A级评审 　　　　B级评审－专家参加 评审计划 评审工件 　　　　评审报告 　　　　缺陷跟踪 业务需求定义 需求任务下达 产品经理(项目组长)编制产品协同管理任务书并签字确认 生成需求跟踪矩阵 项目组的活动以需求列表以及业务需求工件为基础 注意： 　　预立项评审PPT－－预发版阶段任务安排 　　VSS-需求跟踪 业务需求变更来源 外部来源：由外部涉众(需求)产生的需求变更 来自客户的需求变更请求(缺陷和新需求) ,由技术支持部传达给开发产品经理(项目组长) 变更负责人:产品经理(项目组长) 内部来源：由项目组内产生的需求变更 涉及业务需求的变更,由项目经理(项目组长)传达 变更负责人:产品经理(项目组长) 不涉及业务需求变更，只涉及项目内软件需求变更 变更负责人:项目经理(项目组长) 业务需求变更申请 　需求变更状态：修改、增补、删除、变更被拒绝 　工作产品：《需求变更表》 　注意：变更工时、是否延期发版、是否需要业务需求分析 业务需求变更通过 业务需求变更执行 　整理涉众请求库 　维护需求跟踪矩阵 　业务需求分析工件变更－评审 　软件需求分析工件变更－评审 　测试用例变更－评审 　项目进度表调整 　测试进度表调整 需求跟踪 业务需求追溯 需求列表确定后,初始建立需求跟踪矩阵 　　　标识业务需求的初始状态 项目经理指派人员维护需求跟踪矩阵 　　　建立业务需求和软件需求，分析设计和测试用例的追溯关系 相关负责人定期或不定期的更新跟踪各需求的状态 QA人员检查需求状态是否和现状保持一致 需求跟踪 业务需求状态度量 跟踪业务需求的进展状态；统计需求模型或功能数量和变更数量，设计模型或模块数量和变更数量，测试用例数量变更数量。 各种状态下业务需求的度量数据包括： 未批准数量，已批准数量，已设计数量，已实现数量，已测试数量，待确认数量，已增加数量，已删除数量 开发状态：已分析，已设计，已下达，已实现，测试通过，已发版 QA每周度量发布 《项目组需求实现情况统计表》 需求跟踪 对执行A级评审的需求实现情况进行评审 在需求分析阶段，QA组织对执行A级评审的需求实现情况的评审会议 需求抽查 公司组织相关人员对需求抽查,检查开发的质量,并反馈, 　　 发版－详述描述新增需求,变更需求. 　　 评审的N种方式 评审会议：比较正式和规范化的评审过程，参加评审人员教多（5-15人），范围教广；适用于公司级的立项，计划和需求等重要工件评审； 小组评审：项目组内实施的一些技术工件评审，参与人员以组内成员为主（3-7人），过程和角色教简单，参与人员数量也教少；适用于除需求基线和产品基线以外的技术工件评审。 会签：针对一些不是很重要的工件，或者是在无法召开会议的情况下，可以采用发电子邮件的会签的评审方式； 伙伴审查：主要用于代码评审，参与人员为2人左右，通常为项目组内成员； 审批：主要用于需要进行上级签字确认的工件； 同行评审 业务需求分析文档评审 开发人员需求抽查 6个CHECKLIST： 需求实现完整性 软件界面友好性 软件查询方便性 软件录入方便性 软件引导信息正确性 软件UI一致性 同行评审 需求抽查流程说明 项目开发过程中，由产品经理(项目组长)抽取开发人员已经实现的功能进行检查 每个开发人员在开发过程中被抽检