软件需求与需求管理PPT课件.ppt

软件需求与需求管理2002 4 4 内容 软件发展的三个时期软件生存期过程软件开发软件需求需求工程需求变更及其控制CMM2级需求管理关键过程域 一 软件发展的三个时期 表一 二 软件生存期过程 ISO IEC12207信息技术 软件生存期过程 基本过程 支持过程 组织过程 软件生存期过程 图1 1 供应过程 开发过程 运行过程 基本过程 获取过程 维护过程 图1 2 基础设施过程 改进过程 培训过程 组织过程 管理过程 图1 4 三 软件开发 1 计算机系统 人员 硬件 软件 数据 传输机构 执行机构 剧作家 导演 舞台 剧本 演员 道具 图2计算机系统 2 软件开发过程 活动 任务 系统需求分析 系统结构设计 软件需求分析建立软件需求评价软件需求联合评审 软件结构设计 软件详细设计 软件编码和测试 软件集成 软件鉴定测试 系统集成 系统鉴定测试 软件安装 软件验收支持 软件开发面临的实际问题 软件开发面临的实际问题 软件开发面临的实际问题 3 当前软件开发项目的特点 规模大 LOC1万 几十万 HP激光打印驱动软件4万 110万 复杂 质量要求高 满足客户需求和期望 客户满意度统计 开发和维护成本 缺陷后期发现 返工成本 延误交付期 四 软件需求1 系统需求分析 软件系统需求 1 系统需求 分配 软件工程组 硬件系统需求 2 其它成分系统需求 n 软件需求 客户 最终用户 系统工程组 图3系统需求分配 2 软件需求 定义 IEEE STD 610 用户为解决某个问题 或为实现某一目标 要求软件必须满足的条件或能力 软件需求的三个层次业务需求用户需求功能需求和非功能需求 非功能需求 过程需求 交付需求 实现需求 遵循的标准性能需求 速度 容量 可靠性外部需求 互操作性 伦理性 机密性 安全性 使用要求 业务需求 业务说明 使用实例 用户需求 功能需求 约束条件 非功能需求 软件需求规格说明 图4软件需求的层次 质量功能展开 QFD QualityFunctionDevelopment 客户需求 常规需求 客户明确提出期望需求 并未明确提出的潜在需求 不言而喻的需求兴奋需求 客户未想到 若实现客户感到意外 分配需求的实例 系统需求ACCS应能使汽车保持在预期车速的 2KM H范围内行驶 分配给硬件的需求硬件应能使车速在规定的精确度 1 5KM H范围内 分配给软件的需求软件应能在车速超出预期车速 0 5KM H时给硬件加 减速命令 软件需求软件应能 读入当前车速值 计算当前车速与预期车速之差 若差值 0 5KM H给出加 减速命令 图5汽车限速系统ACCS的需求分配 3 CMM2级关键过程域需求管理 KPARM 中对软件需求的解释 分配需求 allocatedrequirements 分配给软件的系统需求 1 分配需求包括 影响和确定软件项目活动的非技术性需求 在合同条款中规定 如 要交付的产品交付日期里程碑 软件的技术需求 如 最终用户 操作人员 支持或集成的功能性能需求设计约束条件编程语言界面需求 用于确认软件产品满足分配需求的验收准则 2 分配需求应当是 以软件来实现是可行的 而且是适合的 已得到清晰而正确的阐述 相互之间是一致的 可以测试的 同时 分配需求应当 被管理和控制 如必要可纳入软件配置管理 是制定软件开发计划SDP的基础是制定软件需求的基础 3 与分配需求相关的组 软件评估组系统工程组系统测试组软件质量保证组SQA合同管理组文档支持组 五 需求工程 1 需求工程 需求开发 需求管理 获取需求 分析需求 定义需求 验证需求 需求变更控制 需求跟踪 需求状态跟踪 需求文档版本控制 需求开发 需求管理 需求工程 图6需求工程的构成 用户 系统 市场 管理者 初始需求 变更的需求 获取 分析 定义 验证需求 控制需求变更 需求规格说明 项目环境 需求开发 需求管理 图7需求开发与需求管理 2 需求开发 1 获取需求确定目标用户 服务对象明确用户代表用户培训了解实际业务和业务需求 2 分析需求分清功能需求 性能需求 使用需求 必要性可行性 3 定义需求编写软件需求规格说明 SRS 作用要求 完整 正确 可行 无歧意 可验证形式 图 表 文字 4 验证需求联合评审 六 需求变更 1 难于完全避免 初始需求 变更的需求 对问题的初始理解 对问题的新理解 时间 图8需求的变更 2 需求变更原因分析 单纯的用户因素市场形势变化系统因素工作环境和要求变化需求开发的缺陷 需求分析 定义和评审不充分 与用户沟通不畅 3 需求变更对软件开发的影响 使变更前开发工作和成果失效 返工成为被迫采取的对策 工作量及资源投入的增加使开发成本提高 项目完成时间后延 4 需求变更失控可能导致的后果 未受控的需求变更引起需求和实现不一致 受控的需求变更使需求和实现一致 图7未受控及受控的需求变更 5 降低需求变更风险的策略 与用户充分沟通 与用户共同明确确定的需求的意义 向用户说明需求不确切或频繁变更对开发工作的冲击 使用户理解过多变更最终对用户不利 与用户共同确定需求 作为合同附件 签字生效 合同中含有对需求变更的条款 采用原型方法开发 或螺旋模型开发 项目计划中适当留有余地 时间进度 人力投入 费用等 严格实施变更控制 七 需求变更控制要求 1 变更控制的策略 1 所有需求变更必须遵循需求变更控制规程实施变更 2 需求变更提出后是否被接受 应由专门的组织 变更控制委员会 CCB ChangeControlBoard 审查决定 3 不得以任何理由删除和修改需求变更的原始文件 4 应将已接受的需求变更通知到所有相关人员 5 已接受的需求变更应能追溯到批准的变更请求 6 对项目的需求赋予状态属性 以利于需求变更的控制 2 需求变更影响的控制 按CMM2级RMKPA的要求 由于分配需求的变更导致软件计划 工作产品和活动的变更 都应对其作 识别评价风险分析编制文档制定计划传达给受影响的小组和人员跟踪直至结束 3 变更控制的步骤 1 提出变更请求 2 审理变更请求 进行变更影响评估 评估内容包括 变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加 3 批准变更请求 4 取得用户的认可 5 修订项目计划 6 实施变更 7 验证变更 八 需求变更控制实施 1 需求变更请求 1 内容申请号变更说明变更类别影响分析变更请求状态变更请求日期 2 需求变更请求实例 表三 2 需求变更累积影响的跟踪 1 需求变更累积影响跟踪的意义和作法累积影响变更累积表 2 需求变更累积表实例 表四 表四需求变更累积表 3 需求控制流 1 需求状态及其演变软件需求在后继阶段开发工作中将逐步展开 加以实现 在不同的开发阶段软件需求以不同的形式进行着状态的演变 例如 需求阶段 从获取的需求到定义的需求 建议阶段 制定出项目计划以后演化为承诺的需求 设计阶段 设计工作完成并在验收后成为设计的需求 编码阶段 完成编码和单元测试后成为实现的需求 测试阶段 完成确认测试后成为完成的需求 开发阶段 需求状态 需求 建议 设计 编码 测试 获取 定义 承诺 设计 实现 完成 图11生存期各阶段需求状态的演变 九 可追溯性管理 1 需求可追溯性与需求变更控制随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系可追溯性矩阵2 可追溯性管理的目标使每一项需求均能追溯到前后继承关系的脉络清晰可见3 两类不同的追溯 1 向前追溯 2 向后追溯 4 可追溯性矩阵 1 矩阵的作用可防止遗漏为评审提供方便便于进行变更影响追踪 分析和检查 2 矩阵的建立与维护 3 矩阵的应用完整性检验 考察有无需求遗漏的情况 有无冗余代码 检查所有性能需求是否已被测试用例测试 对集成测试计划和系统测试计划进行交互检查需求变更控制 需求变更后相关的工作产品受影响的部分应随之变更 更新需求规格说明 同时要更新追溯矩阵 每增加一项需求 应在追溯矩阵中得到体现 表五追溯矩阵实例 十 CMM2级RMKPA 需求管理 RM RequirementsManagement 是CMM2级的第1个关键过程域 需求管理的目的是要在客户和将处理客户需求的软件项目之间形成共同的理解 这种共同理解应该体现在 客户需求的文档和对客户需求的控制中使项目的计划 产品和活动都应与需求一致 2级 RM SPP SPTO SSM SQA SCM 目标 G1G2 约定 能力 活动 测量 验证 C1 Ab1 Ab2 Ab3 Ab4 Ac1 Ac2 Ac3 M1 V1 V2 V3 图13RMKPA结构 1 目标与活动 目标1 分配给软件的系统需求应是受控的 以利建立软件工程和管理的基线活动1 在分配需求被纳入软件项目之前 软件工程组应对其进行评审目标2 软件计划 产品和活动要与分配给软件的系统需求保持一致活动2 软件工程组将分配需求作为软件计划 工作产品和活动的基础活动3 评审对分配需求的变更 并将变更纳入软件项目 2 约定与能力 约定1 项目要遵循一个书面的组织方针来管理分配给软件的系统需求能力1 为每个项目规定分析系统需求并将其分配给硬件 软件和其它系统成分的职责能力2 编制分配需求文档能力3 为管理分配需求提供足够的资源和资金能力4 软件工程组人员和与软件相关的其它组人员要接受培训 以利于完成