第四章初始不是需求阶段.ppt

第四章 初始不是需求阶段 　　　　　暨南大学计算机系 黄战 目标 定义初始阶段的步骤 动机 需求进化 用例 其它需求 初始 初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤 它包括： 10％的用例进行分析 关键的非功能需求的分析 业务案例创建 开发环境的准备　 什么是初始阶段？ 考虑以下几类问题： 项目的设想和业务案例是什么？ 是否可行？ 购买还是开发？ 粗略估计一下成本？ 项目应该继续下去还是停止？　　 定义 大多数需求分析是在细化阶段进行的，并且伴以具有产品品质的早期编程和测试 初始： 预见项目的范围、设想和业务案例 要解决的主要问题： 涉众是否就项目设想基本达成一致；项目是否值得继续进行认真研究？ 初始阶段 初始阶段主要是为项目目标建立一些初始的共同构想，确定项目是否可行，并决定是否值得进入细化阶段加以认真研究 可能只包含第一次需求研讨会，并为第一次迭代制定计划，然后就快速地进入细化阶段 初始阶段制品 设想和业务用例 高阶目标和约束 用例模型 功能需求（１０％的用例） 补充性规格说明 关键的非功能需求对架构的主要影响 词汇表 关键领域术语和数据字典 风险列表和风险管理计划 风险及应对和缓解的方法 原型和概念验证 澄清设想，验证技术思路 迭代计划 第一个细化迭代的任务 阶段计划和软件开发计划 对细化阶段的持续时间和工作量进行粗略估计 开发案例 就特定项目，对ＵＰ步骤和制品进行定制的描述　　 进化式需求 　　　　　　暨南大学计算机系 黄战 目标 阐述进化式需求的动机 定义ＦＵＲＰＳ＋模型 定义ＵＰ需求制品 需求 定义： 需求就是系统必须提供的能力和必须遵从的条件 ＵＰ推崇用“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求” 挑战： 寻找、沟通和记住什么是真正需要的，并能够清楚讲解给客户和开发团队的成员 进化式需求和瀑布式需求 ＵＰ能够包含需求中的变更，并将其作为项目的基本驱动力 ＵＰ：产品品质的编程和测试要远早于大多数的需求的分析和规格化 规范的ＵＰ 警告： 在开始编程和测试之前指定大多数或所有需求，则意味着这并非是规范的ＵＰ和迭代项目 折中的方法： 结合早期时间定量的迭代开发，进行迭代和进化式需求分析，并且引入频繁的涉众参与、评估和对局部结果的反馈 寻找需求 除了变更，我们需要去寻找需求 需求管理： 一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求 ＦＵＲＰＳ＋模型 在统一过程中，需求按照“FURPS+”模型分类： 功能性：特性、功能、安全性 可用性：人性化因素、帮助、文档 可靠性：故障频率、可恢复性、可预测性 性能：响应时间、吞吐量、准确性、有效 性、资源利用率 可支持性：适应性、可维护性、国际化、可配置性 ＦＵＲＰＳ＋模型 “ＦＵＲＰＳ＋”中的“＋”是指一些辅助性的次要的因素，比如： 实现－资源限制、语言和工具、硬件等 接口－强加于外部系统接口之上的约束 操作－对其操作设置的系统管理 包装－例如物理的包装盒 授权－许可证或其他方式 ＦＵＲＰＳ＋ 使用“ＦＵＲＰＳ＋”分类方案作为需求范围的检查是有效的，可以避免遗漏系统某些重要方面 某些需求可以统称为： 质量属性 质量需求 这些需求包括：可用性、可靠性、性能和可支持性 需求可以被分类为： 功能性（行为的） 非功能性（其他所有的行为） 质量属性对系统架构具有极大影响 UP制品如何组织需求 关键UP需求制品 用例模型－一组使用系统的典型场景。主要用于功能（行为的）需求 补充规格说明－基本上是用例之外的所有内容。主要用于所有非功能需求，例如性能或许可发布。 该制品也用来记录没有表示(或不能表示）为用例的功能特性，例如报表生成 词汇表－定义重要的术语，数据字典记录了关于数据的需求，例如有效性规则，容许值等。对象属性、操作调用的参数、报表布局等。 设想－高阶需求，业务案例 业务规则－领域规则，例如政府的税收法规 制品 在UP中，所有制品都是信息的抽象 它们可以存储在Web页，板报，或各种可以想象到的载体上。在线的RUP文档产品含有制品模板，但有些模板只是可选的辅助工具，可以忽略 * *