第9章_面向对象的需求获取与分析.ppt

第九章 面向对象的需求获取与需求分析 本章提纲 面向对象的需求获取 面向对象分析（OOA） UML 面向对象的需求获取 需求工程的目标是定义构造系统的需求。需求工程主要包括两个活动： 1）需求获取，即导出用户可理解的系统规格说明 2）需求分析，其结论是给开发人员无二义性解释的分析模型 需求获取是获得系统必要的特征，或者获得客户能接受的、系统必须满足的约束。 9.1 面向对象的需求获取概述 需求获取是关于开发人员、客户和用户之间为了定义新系统而进行的沟通。 在需求获取过程中，如果无法及时发现所犯错误，将使得整个系统交付延迟。 错误可能包括： 遗漏了系统必须支持的功能， 不正确的功能描述， 引起误导或不可用的用户界面， 无用功能，等等 9.1.1 对需求获取的总的看法 需求获取将注意力放在系统目标的描述上。开发人员、客户和用户共同标识了一个问题域，定义了解决这一问题域的系统。这类定义称为需求规格说明，可用于开发人员和用户之间的沟通。 在分析过程，对需求规格说明形式化，产生分析模型 需求规格说明和分析模型之间的区别，仅仅在于其所用语言和记号的不同： 需求规格说明通常用自然语言来书写； 分析模型通常用形式化或半形式化方式表示出来 基于用例的需求获取过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例描述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 获取原始需求的技巧 需求获取包括如下活动： （1）标识参与者 （2）标识场景 为了获得未来系统将提供的典型功能，开发人员对用户活动进行观察并开发出一组带有细节的场景。 （3）标识用例 一旦用户和开发人员确认了一组场景，开发人员将从场景中导出一组能够完全表示未来系统的用例。 （4）求精用例 通过细化每一个用例，以及使用带有错误处理的用例和使用异常条件处理的用例，描述系统的行为。开发人员应确保需求规格说明是完全的。 （5）标识用例之间的关系 （6）标识非功能性需求 即对用户可见的非功能需求的方方面面进行标识。这些内容包括系统性能上的约束、文档、将要消耗的资源、其安全性和其质量等。 需求获取的信息来源 在需求获取期间，开发人员将访问不同的信息资源，包括： 客户提供的与应用域相关的文档和手册 (将被未来系统替换的)遗留系统的技术文档 用户和客户本人 9.1.2 需求获取概念 1. 功能需求 功能需求描述了系统与其独立于系统实现的环境之间的交互。环境包括： 用户 任何其它与该系统进行交互的外部系统 对卫星表系统的功能需求概述 卫星表是一种利用全球定位系统（GPS）显示使用者所在地时间的手表，该手表具有确定位置和时区转换功能 卫星表通过卫星将位置信息存储到手表中，使得手表拥有者无需留心对时间的调整。 当手表拥有者跨越时区时，或跨越执行夏令时的行政边界时，卫星表会自动调整时间和日期。 卫星表的显示面板有两行，上面一行显示时间（时、分、秒、时区），下面一行显示日期（星期、日、月、年）。 卫星表通过购买手表时配送的串行设备进行升级。 2. 非功能需求 根据Jacobson等人提出的FURPS+ 模型，非功能需求分四类： 可用性 （Usability） 可靠性 （Reliability） 性能 （Performance） 可支持性（Supportability） 1.可用性 用户是否能够比较容易地学会操作此系统，准备系统所需的输入，并理解系统的输出 2.可靠性使得使用者对系统提交的服务具有足够的信心。它包括 可靠性，即系统或构件在指定条件下和给定时间内完成其所要求功能的能力 健壮性，即在不正确输入提供或者压力环境条件的情况下，系统或构件能正确完成功能的程度 安全性，即当缺乏对灾难后果的考虑时，系统所能够承受的打击能力的程度等 3.性能需求是系统要考虑的定量属性，比如 响应时间，即对用户输入而言，系统响应的快慢程度 吞吐量，即在一个指定的时间量内，系统能完成的工作量 有效性，即当提出使用要求时，系统或构件的可操作性和可访问性程度和准确性 4.可支持性关注的是在部署改变后系统所处的状况，包括 可适配性，即改变系统以适应外部应用域的能力 可维护性，即改变系统以适应新技术或找出错误的能力 国际化，即改变系统以适应国际习惯的能力 非功能需求的其它分法 非功能性需求还可以被分为： 实现需求：对系统实现进行的约束，比如使用特定工具、编程语言和硬件平台 接口需求：由外部系统施加的约束，比如遗留系统、信息交换格式等 操作需求：系统管理和操作设置方面的约束 分包需求：系统实际提交方面的约束 卫星表的非功能需求 卫星表的质量需求 ?