软件项目需求与变更管理.ppt

第8章软件项目需求与变更管理 第2页 软件项目需求管理概述 1 软件项目任务分解 软件需求的变更控制 第3页 本章学习目标 掌握软件需求的概念熟悉需求管理的方法与过程掌握任务分解的方法与步骤了解需求变更的原因掌握需求变更控制的策略 第4页 8 1软件项目需求管理概述 一 软件需求定义需求是来源于用户调查 即客户的需要 需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿 分析出软件系统的功能 性能 数据等诸方面应该达到的目标 从而获得有关软件的需求规格定义的过程 第5页 明确的需求是项目的基础 1 需求的生命周期 需求产生 变化 内部 外部 需求认识 现存 潜在 超前 前景分析 需求表达 让提出需求的人尽可能清楚地说明他们的需求 对需求提出下列一系列问题 见下页 作一些必要的研究工作 更好地理解需求根据以上三步得出结论 尽可能清楚地描述这个需求听听用户对你的阐述的反映 并作适当修改 第6页 对需求提出下列一系列问题 提出需求的人是如何描述需求的 需求真实吗 是真正需求还是表面现象 我们能满足这个需求吗 其他人能满足吗 是不是真的有解决方法 需求重要吗 值得去满足他吗 满足需求的关键问题在那里 会不会有新的需求产生 还要进一步满足其他需求吗 新的需求能取代目前这个需求吗 需求直接涉及什么人 他们认为这是一个必要的需求吗 满足需求后对他们有什么影响 他们的反映会怎么样 需求对机构的影响是什么 对我的影响是什么 第7页 功能和技术要求把需求变成功能要求 功能要求应描述项目最终交付产品的特征技术要求根据功能要求产生功能要求应用日常语言陈述清楚 第8页 定义需求时的问题 含糊的需求 1 不断变化的需求 人员变化 预算变化 技术变化 商业环境变化 2 误解需求 我说不清楚我所需要的是什么 但我见到东西时就会知道 感觉会随环境变化 过早作出结论 截断需要表达过程 需求分析需要耐心和自我控制 与真正的用户讨论需求多种用户 多种需求 确定优先级 即需求层次 曲解用户的需求需求镀金对用户的需求有选择的过滤包办代替 第9页 需求和目标 基本需求 项目实施范围 质量要求 利润或成本目标 时间目标以及必须满足的法规要求等期望要求 如一种新产品性能之外的外形 使用舒适 第10页 项目需求包含面向用户的需求和面向开发者的系统需求两个方面的内容 1 用户需求特点 1 用户需求直接来源于用户 2 用户需求需要以文档的形式提供给用户审查 3 可以把用户需求理解为用户对软件的合理请求 4 用户需求主要是为用户方的管理层 用户方的技术代表 操作者以及开发方的高层技术人员撰写的 第11页 2 系统需求 1 功能需求全面性 一致性 可理解 可维护 可追踪 2 非功能性需求性能需求 可靠性 可用性需求 系统安全以及系统对开发过程 时间 资源等方面的约束和标准 关心系统的整体特性 3 数据要求输入数据 输出数据 加工中的数据和保存在存储设备上的数据等 第12页 3 需求规格说明书需求规格说明书的描述要求 1 清晰2 完整3 一致4 可测试 第13页 二 需求管理需求管理就是一种获取 组织并记录系统需求的系统化方案 以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程 1 需求管理复杂性分析需求的描述问题需求的完备程度问题需求开发的工期问题需求的细致程度问题需求的变化问题 第14页 2 需求管理的基本原则需求管理必须与需求工程的其它活动紧密整合需求必须是文档化的 正确的 最新的 可管理的 可理解的只要需求变化了 需求变更的影响就必须被评估需求必须分优先级需求一定要分类管理 第15页 3 需求管理的方法确定需求变更控制过程进行需求变更影响分析建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性 第16页 三 需求管理过程1 定义需求2 需求确认3 建立需求状态4 需求评审评判需求优劣的主要指标有 正确性 清晰性 无二义性 一致性 必要性 完整性 可实现性 可验证性 可测性 第17页 5 需求承诺6 需求跟踪正向跟踪 以用户需求为切入点 检查 需求规格说明书 中的每个需求是否都能在后继工作产品中找到对应点 逆向跟踪 检查设计文档 代码 测试用例等工作产品是否都能在 需求规格说明书 中找到出处 7 需求变更控制 第18页 8 2软件项目任务分解 一 工作分解结构 WBS 项目的分解结构就是将项目的产品或服务 组织 过程这3种不同的结构综合为项目分解结构的过程 也就是给项目的组织人员分派各自角色和任务的过程 基于成果或功能的分解方法 以完成该项目应该交付的成果为导向 确定相关的任务 工作 活动和要素 基于流程的分解方法 以完成该项目所应经历的流程为导向 确定相关的任务 工作 活动和要素 第19页 1 图表形式 第20页 分解层次与结构工作包是完成一项具体工作所要求的一个特定的 可确定的 可交付以及独立的工作包 可为项目控制提供充分而合适的管理信息 WBS编码设计 第21页 2 清单形式需求分析计划流程优化编写需求说明书编写需求规格词汇表绘制业务流程抽象业务类建立数据模型将需求分析图示加入规格文档需求规格测试需求规格确认 第22页 任务分解过程1 分解步骤 1 确认并分解项目的主要组成要素 2 确定分解标准 3 确认分解是否详细 分解结果是否可以作为费用和时间估计的标准 明确责任 4 确定项目交付成果 5 验证分解正确性 验证分解正确性后 建立一套编号系统 第23页 2 分解的标准一般不能采用双重标准 选择一种项目分解标准之后 在分解过程中应该统一使用此标准 避免因使用不同标准而导致的混乱 3 分解结果的检验核实分解的正确性 更低层次的细目是否必要和充分 最底层要素是否有重复 每个细目都有明确的 完整的定义吗 是否每个细目可以进行适当的估算 谁能担负起完成这个任务 第24页 4 任务分解的注意事项注意收集与项目相关的所有信息 任务分解结果必须有利于责任分配 最底层的工作包一般要有全面 详细和明确的文字说明 并汇集编制成项目工作分解结构词典 避免不必要的过细 最好不要超过7层 按照软件项目的平均规模来说 推荐任务分解时至少分解到一周的工作量 40小时 第25页 5 责任分配及成本分解 项目责任分配与成本估算表 第26页 8 3软件需求的变更控制 需求变更原因分析1 范围没有圈定就开始细化2 没有良好的软件结构适应变化3 用户改变需求管理变更请求1 控制需求渐变的策略需求一定要与投入有显然的联系 否则如果需求变更的成本由开发方来承担 则项目需求的变更就成为必然了 所以 在项目的开始无论是软件开发方还是出资方都要明确这一条 需求变化 软件开发的投入也要变化 第27页 需求的变更要经过出资者的认可 这样才会对需求的变更有成本的概念 能够慎重地对待需求的变更 小的需求变更也要经过正规的需求管理流程 否则会积少成多 精确的需求与范围定义并不会阻止