软件工程和开发技术第9章 需求分析和用例模型.ppt

第9章 需求分析与用例模型 9.1 需 求 分 析9.1.1 系统需求和需求描述　　根据来源的不同，需求可以分成用户需求、业务需求和系统需求，其中系统需求是用户需求和业务需求在系统中的反映，是综合各种需求因素以及系统约束之后确定的系统规格。需求描述是指系统的规格化描述，也称为软件需求规格说明(SRS)，其目的在于收集和组织有关项目的所有需求，包括功能需求和非功能需求。在RUP中，系统的功能需求由用例模型给出，非功能需求则由相关文档进行描述。 9.1.2 需求类型　　需求有多种类型，其中一种需求分类方法为FURPS+。F代表Functionality(功能)、U代表Usability(可用性或者可操作性)、R代表Reliability(可靠性)、P代表Performance(性能)、S代表Supportability(可支持性)。+表示还包含如下需求：设计约束、实现需求、接口需求、物理需求等。　　功能需求说明一个系统在不考虑物理约束的情况下必须要执行的行为，它在用例模型中可以得到很好的描述。功能需求也说明了系统的输入、输出行为(用户输入什么，系统响应什么)。除功能需求之外的其他需求都称为非功能需求。 　　关于非功能需求简单介绍如下。　　可用性需求包括文化因素、美学、用户界面一致性、在线帮助和上下文敏感帮助、向导和代理、用户文档、培训资料等。　　可靠性需求指的是产品失效的频率和严重性、可恢复性、可预测性、精确性、平均失效间隔(MTBF)。　　性能需求是指功能需求的条件和约束。例如：对于某个行为(功能)，可以制定其性能参数，如速度、效率、有效性、精确度、吞吐量、响应时间、恢复时间、资源用法等。 　　可支持性包括可测试性、可扩展性、可适应性、可维护性、可兼容性、可配置性、可服务性、可安装性、可本地化性(国际化)等。　　设计约束指定系统设计的约束，例如使用MVC模式、CORBA等。　　实现需求指定编码或者建造系统的约束，例如：需要的标准、实现的语言、数据库完整性策略、资源限制、操作环境等。　　接口需求是指系统和外部交互的需求，包括格式、时间及其他约束。　　物理需求说明系统的物理特性，如物质、形状、尺寸、重量等，也可以描述硬件需求，如物理网络配置等。 9.1.3 需求与用例模型　　用例(Use Case)是从使用者的角度或者说从系统外部观察系统的功能。它是系统功能抽象的使用案例，描述了系统功能的使用过程或者与用户的交互过程。用例可以看成是一种观察系统、描述系统的角度，从用例角度来看，系统被看成是黑盒，不涉及或者不关心系统内部如何实现，只关注系统做什么。这正符合需求分析阶段的主要任务，即定义系统做什么，而不是如何去做。 　　用例模型就是描述系统中所有功能的用例集合，定义了系统做什么。用例分析方法是一种和用户交流并获取需求的技术和手段，具有简单直观、容易上手的特点。与结构化分析方法(SA)中的数据流+数据字典方法、传统的面向对象软件工程(OOSE)方法中的对象模型方法相比较，用例模型更容易被用户和开发者理解，从而更便于对系统的需求取得共识，更适合作为系统分析人员和用户之间交流的工具。 　　用例模型本身是以系统功能为目标，从外部来观察其实现或者操作过程。从认识论角度来看，用例也可以扩充成从实现者的角度来观察用例的实现过程，即用例实现(Use Case Realization)，这正符合了从外至内、由表及里的认识规律，也比较适用于逐步改进的迭代式开发方法。　　在用例模型中仅包含有参与者(Actor)、用例(Use Case)及其关系等三种建模元素，因此比较简单，容易掌握，下面分别对三种元素进行说明。 9.2 Actor及其关系9.2.1 Actor　　从字面上看，Actor有演员、角色、参与者、作用者、行动者和行为者的意思。在RUP中，Actor被定义为一组系统用户扮演的用于和系统交互的角色(Role)。Rational Rose中对Actor的定义是：Actor代表系统用户，用来界定系统并给出系统应该做什么的清晰的图示。Actor只和用例交互，而并非控制用例。可以根据下面几点来确定Actor。　　(1) 使用系统并和系统交互。　　(2) 给系统提供输入或者从系统获取信息。　　(3) 是系统外部的因素，不控制用例。 图9.1 参与者图例 　　Actor可以代表系统用户，也可以代表系统之外其他的任何事物，如其他软件系统、打印机等。Actor可以是系统之外但和系统有关的任何元素，包括影响系统和受系统影响的任何元素。利用Actor可以帮助定义系统边界(定界或者界定系统)。凡是抽象成Actor的都是系统之外的元素，凡是抽象成Use Case的都是系统之内的功能。从而给出一个