第03章软件需求管理new.ppt

项目范围管理过程 项目启动—启动项目，管理组织开始着手项 目下一阶段的工作。 范围计划--写出一份书面报告，作为未来项 目决策基础。 范围定义--把主要的项目工作细目分解成更 小、更易管理操作的单元。 范围核实—项目干系人正式认可项目范围。 范围控制--对项目范围的变更进行控制。? 谢谢！ 需求管理工具 —— 使用RequisitePro 步骤1： 使用RequisitePro定义一个项目的常用词汇表 目的：定义一个公共词汇表的目的是在团队成员中减小词汇的不确定性,并在谈及要建立的系统时，使用共同的语言。公共词汇表可以用于系统的所有文本说明，尤其是用例说明。词汇表提供了在要建立的系统的有关说明中常用的所有术语的定义。每个项目都有一个 Glossary 文档。 1、创建Glossary 文档： Glossary 文档包含了在项目活动中确定的术语和定义，尤其是在活动：获取涉众请求之中。 2、完成Glossary 文档：在新创建的 Glossary 文档中，为每个要定义的术语，输入术语名及其定义。可以考虑使用具有同一定义的常用术语的别名（例如：操作员 - 请参见机械师）。我们建议您使用斜体来表示 Glossary 中的术语。 3、在Glossary 文档中标记需求：词汇表本身并不包含需求，但其中的术语可能会用作类名，特别是一些实体类的类名。请参见类的设计。将这些术语标记为需求，您可以使用 Rational Synchronizer，在 Rational Rose 中自动创建类名为这些术语的类。 您也许还想跟踪术语在词汇表中重定义的情况以及一些需要更新的文档，以便反映词汇表中的变化。将这些术语标记成需求，以后即可在词汇表术语和产品特性或系统需求之间设置可追踪性链接。这里提及的系统需求在词汇表术语定义修订和得到认同之后，可能需要重新编写。 （3）软件构件技术是解决软件危机的重要途径 软件危机 已经持续了三十多年 表现为 软件的产品质量难以保障 软件的开发效率难以提高 如今人们已经认识到： 软件复用 是解决软件危机的现实途径 而 软件构件技术 是软件复用的核心技术 软件构件技术内容 CASE技术 软 件 过 程 非 技 术 因 素 领域工程 构件、构架 获取 软件构件技术 应用系统 领域 软件再工程 软件构架技术 开放系统技术 构件模型 构件分类、 存储与检索 构件组装 遗产软件 系统 构件库系统 问题探讨： 决定软件构架的最关键因素是什么？是软件的功能需求吗？ 实际上，对于电信软件等企业级核心应用软件而言，其构架在更大的程度上会决定于其质量、性能、操作环境等非功能特性。 例如：高性能与高可靠性的需求，决定了电信等行业应用逐渐向集中型的业务平台模式转变，系统也最终采用了动态均衡的服务集群架构；而支持浏览器用户环境则决定了产品的B/S多层架构。 同时，从软件构架的层次结构角度来看，不同层受各类需求影响是完全不一样的： 应用层受功能性需求的影响最大 业务实体层本质上由业务领域模型所决定 业务逻辑层具体的内容受功能需求影响，但其基本结构对功能不敏感 数据访问层等下层架构基本上由非功能需求因素决定，与功能性需求关系不大 需求的形式化与需求基线的建立 在前面部分，我们已经介绍，需求一旦确定，就需要把它文档化。 为了便于需求实现和变更控制管理，它还被要求进行数据库化。 所有这些努力的目的，就是逐步地使需求形式化。 形式化的形式，则可以根据项目和管理的不同而不同。 形式化的目的是：首先通过记录（纸质的文字或数据库记录等），使需求固定下来。任何口头的传误，在文字记录上，会被减少。 其次，形式化最主要的追求，是解决完整性和无歧义性。 形式化的需求是需求分解、分配、追踪、评估的条件。 20世纪80年代的一项研究表明，20%的错误是对需求的错误解释造成的。IBM公司对需求描述的形式化研究，已经提出了一种保证需求文档更一致的需求描述方法学，使通过使用这种规定的方法建立的需求，不同人写的需求之间的差异，已经降到最小。 需求实现——需求属性化是形式化的基础 需求属性 含义 说明 名称 * 需求名称 用最简洁的语言表示需求的核心含义 描述与定义 * 对需求的描述和定义 需求的最本质内容、可以用模型、图、表表示 编号（层/序） * 需求的顺序号 可根据系统结构或任务的WBS编排 来源 * 需求的提出来源 用户需求的更高层依据、来源 提出/决策人 需求的提出人 当需求变化或受到影响时最易于讨论和决定的人 优先级 需求的优先级 表明高、中、低，以备需要取舍或先后响应时 实体 * 需求实现的实体 表明需求与实现实体的对应关系 状态 * 需求所处的状态 包括：提出、批准