软件工程与开发技术（西电第二版）第9章_需求分析与用例模型教材教学课件.ppt

第9章 需求分析与用例模型 ; 9.1 需 求 分 析9.1.1 系统需求和需求描述　　根据来源的不同，需求可以分成用户需求、业务需求和系统需求，其中系统需求是用户需求和业务需求在系统中的反映，是综合各种需求因素以及系统约束之后确定的系统规格。需求描述是指系统的规格化描述，也称为软件需求规格说明(SRS)，其目的在于收集和组织有关项目的所有需求，包括功能需求和非功能需求。在RUP中，系统的功能需求由用例模型给出，非功能需求则由相关文档进行描述。 ;;　　关于非功能需求简单介绍如下。　　可用性需求包括文化因素、美学、用户界面一致性、在线帮助和上下文敏感帮助、向导和代理、用户文档、培训资料等。　　可靠性需求指的是产品失效的频率和严重性、可恢复性、可预测性、精确性、平均失效间隔(MTBF)。　　性能需求是指功能需求的条件和约束。例如：对于某个行为(功能)，可以制定其性能参数，如速度、效率、有效性、精确度、吞吐量、响应时间、恢复时间、资源用法等。;　　可支持性包括可测试性、可扩展性、可适应性、可维护性、可兼容性、可配置性、可服务性、可安装性、可本地化性(国际化)等。　　设计约束指定系统设计的约束，例如使用MVC模式、CORBA等。　　实现需求指定编码或者建造系统的约束，例如：需要的标准、实现的语言、数据库完整性策略、资源限制、操作环境等。　　接口需求是指系统和外部交互的需求，包括格式、时间及其他约束。　　物理需求说明系统的物理特性，如物质、形状、尺寸、重量等，也可以描述硬件需求，如物理网络配置等。 ;9.1.3 需求与用例模型　　用例(Use Case)是从使用者的角度或者说从系统外部观察系统的功能。它是系统功能抽象的使用案例，描述了系统功能的使用过程或者与用户的交互过程。用例可以看成是一种观察系统、描述系统的角度，从用例角度来看，系统被看成是黑盒，不涉及或者不关心系统内部如何实现，只关注系统做什么。这正符合需求分析阶段的主要任务，即定义系统做什么，而不是如何去做。 ;　　用例模型就是描述系统中所有功能??用例集合，定义了系统做什么。用例分析方法是一种和用户交流并获取需求的技术和手段，具有简单直观、容易上手的特点。与结构化分析方法(SA)中的数据流+数据字典方法、传统的面向对象软件工程(OOSE)方法中的对象模型方法相比较，用例模型更容易被用户和开发者理解，从而更便于对系统的需求取得共识，更适合作为系统分析人员和用户之间交流的工具。 ;　　用例模型本身是以系统功能为目标，从外部来观察其实现或者操作过程。从认识论角度来看，用例也可以扩充成从实现者的角度来观察用例的实现过程，即用例实现(Use Case Realization)，这正符合了从外至内、由表及里的认识规律，也比较适用于逐步改进的迭代式开发方法。　　在用例模型中仅包含有参与者(Actor)、用例(Use Case)及其关系等三种建模元素，因此比较简单，容易掌握，下面分别对三种元素进行说明。 ;　　定义Actor需要给出Actor的名字及其描述，例如学生，使用选课系统的用户之一。更详细的描述可以给出该Actor与其他Actor的关系(一般是泛化关系)，还可以利用UML的扩展机制，如tag来对其进行扩充，例如author,version等。　　Actor举例：用户、客户、仓库管理员、学生、打印机、财务系统、信用系统。　　每个参与者应该给出适当的说明。如用户：使用系统的各种人员；客户：订购公司产品的人员；财务系统：处理日常帐务的系统，等等。 ;9.2.2 如何发现Actor　　Actor是和系统有关的外部事物或者元素。我们可以从将要使用系统的具体用户开始分析，将其分类，抽象其类型。还可以从和系统有关的人或者环境方面进行分析，逐一识别出使用系统和维护系统的人(如提供、使用、删除信息的人)、使用系统功能的人、对系统需求感兴趣的人(投资商、管理者等)、系统所在的环境、系统在哪个部门被使用、系统使用的外部硬件和资源、需要和系统交互的其他系统，等等。 ;　　对于一个组织(如企业)来说，为了实现组织的目标，需要定义相应的岗位，每个岗位都有自己相应的职责，然后根据这些岗位来聘用员工，即所谓定岗定编。对于企业来说，也可以从某个业务的系统实现过程的描述开始，将所涉及到的系统之外的因素都找出来，作为参与者的候选对象。Rational Rose的帮助文档中指出，可以通过检查下面元素来发现参与者：　　(1) 直接使用系统的人。　　(2) 负责维护系统的人。　　(3) 系统使用的外部硬件。　　(4) 其他需要和该系统交互的系统。 ;　　根据Actor的职责和需求来开发系统功能或者用例，可以保证系统需求将是用户所希望的，也是和系统运行环境一致的。很多组织(企业