14-软件项目需求分析阶段管理.pptVIP

* 业务或市场形势变化：原先的需求文档已经不能适应用户实际业务的发展要求、或跟不上当前市场的变化。 * 任何项目的利益相关人员都可以提出项目变更申请 * 在整个开发实施过程中，需求获取可能是最困难、最关键、最易出错及最需要沟通和交流的重要方面。 需求变更是不可避免的 * * （7）需求分析的结束控制： 通过项目的合同条款，做好项目的范围规划，明确项目的工作内容 做好分析阶段的工作计划，明确工作进度、人员分工及各自的工作职责 做好各部分需求条款的签字验收工作和定期的工作总结与工作汇报 做好目标系统的介绍或原型系统的演示 * 需求分析的质量管理与控制 （1）积极认真进行调研准备 设定需求调研主题 确定需求调研方法 对调研产生结果的应对措施 （2）正确理解用户的需求描述及非二义性的需求文字记录 （3）做好各需求项的用户签字认可工作 将需求分析阶段的所有需求调研及会议讨论结果形成书面文件，经用户审核签字后，纳入需求管理 * 质量管理与控制 （4）做好需求管理工作 完成需求文档的版本控制及需求变更的控制工作 （5）定期会议交流和评审 将需求分析结果通报全体用户人员 将需求分析中问题提出，供全体人员讨论 形成“相对锁定”的用户需求 * 需求工程 （1）需求工程 所有与需求直接相关的活动通称需求工程 包括：需求开发和需求管理 需求开发的过程有四个主要活动： 1）需求获取： 分析、修正用户对目标系统的需求，提炼出解决问题的用户需求，产生《用户需求说明书》 2）需求分析： 分析各种需求信息并抽象描述，为目标系统建立一个概念模型 3）需求定义： 根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》 4）需求验证： 双方审核需求文档，签字确认 * 需求开发 需求管理 需 求 获 取 需 求 分 析 需 求 验 证 需 求 定 义 需求 跟踪 需求 变更 控制 版本 管理 需求 复用 需 求 工 程 需求工程结构 * 软件缺陷总结 缺陷来源 潜在缺陷 剩余缺陷 排除效率(%) 需求 0.20 0.046 77 设计 0.25 0.0375 85 编码 0.35 0.0175 95 建档 0.12 0.024 80 修复 0.08 0.024 70 总计 1 0.149 85.1 * 软件缺陷修复成本 需求阶段 0.1---0.2 设计阶段 0.5 编码阶段 1 单元测试阶段 2 集成测试阶段 5 维护阶段 20 * 需求管理过程中的活动 需求管理过程有以下几个主要活动： 1）需求跟踪 2）需求变更控制 3）版本管理 4）需求复用 * 用户需求调查 需求分析 系统需求定义 需求确认 需求跟踪 需 求 复 用 需求 变更 控制 用户需求说明书 系统需求规格说明书 用户需求调查 用户需求调查 确认的需求分析结果 需求开发与需求管理活动业务流程图 * （2）需求跟踪 目的是建立与维护“需求---设计---编程---测试”间的一致。 方式：双向跟踪 正向跟踪：检查《需求规格说明书》中的每个需求，在后继工作成果中找到对应点 逆向跟踪：检查设计文档、代码、测试用例等工作成果，看是否都能在《需求规格说明书》中找到出处 * （3）需求变更控制 需求变更原因： 对需求认识的深入 业务或市场形势变化 需求变更控制基本原则： 需求变更带来的好处要大于坏处，允许变更 需求变更带来的坏处要大好处，拒绝变更 * 需求变更控制流程 提出变更申请 审批 修改需求文档 重新需求确认 变更结束 * 第一步：需求变更申请 申请变更的需求文档 输入需求文档的名称、版本、日期等信息 变更的内容及其理由 评估需求变更将对项目造成的影响 申请人签字 第二步：审批 开发方负责人审批 审批意见： 签字，日期 用户审批 （限于合同项目） 审批意见： 签字，日期 第三步：更改需求文档 变更后的需求文档