第3章 需求分析与用例模型

1、 在软件工程中，需求分析指的是在建立系统时描写系统的目的、范围、定义和功能时要做的所有工作。 需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师要确定顾客的需求。需求层次内容业务需求 客户对系统、产品高层次的目标要求。通常问题定义就是业务需求用户需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求系统需求 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束。在统一过程（UP）中，需求按照“FURPS”模型进行分类。 功能性（Fun

2、ctional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 可靠性（Reliability）：故障频率、可恢复性、可预测性； 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。非功能性需求非功能性需求 在系统开发的初期阶段，基于以下目的做成用例图： 明确开发系统的主要功能 明确开发系统的范围 明确开发对象和外界的关系由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图（Use Case Diagr

3、am）。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。 要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不 在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用

4、例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。 获取需求、指导测试、对开发过程中的其他工作起指导作用。 用例图包含3方面内容： 用例图中可以包含注释、约束o参与者是系统外部的一个实体，以某种方式参与用例的执行过程。是为了完成一个事件与系统进行交互的实体，是与系统交互作用的外部用户、进程或其他系统的理想化概念。o在UML中，参与者用名字写在下面的人形图标表示。 参与者由它们参与用例时所担当的角色来表示。o 任何事物人、外系统、特殊的硬件、时间(到某一时间触发某一事件）等 在获取用例前要先确定系统的参与者，

5、可以根据以下的一些问题来寻求系统参与者。 （1）使用系统主要功能的人是谁？（2）需要借助于系统完成日常工作的人是谁？（3）谁来维护管理系统保证系统正常工作？（4）系统控制的硬件有哪些？（5）系统与哪些其他系统交互？（6）对本系统产生的结果感兴趣的人或事是哪些？ 多个参与者之间可以具有与类之间相同的关系。 在用例图中，可以使用泛化关系来描述多个参与者之间的。 例如，在图书馆管理系统中，借书者可以泛化成两类：学生和老师。 再如，航空售票系统接受客户预定机票，客户可以进行电话预定和网上预定，如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么必须使用实际的

6、参与者，即子类。学生借书者客户老师电话客户网上客户 更具一般的，可以由下图表示参与者之间的关系。特殊化参与者超类参与者特殊化参与者 用例是系统中的功能 一个用例表示一个功能，集中所有的用例，可完整描述如何使用该系统 可以通过关联线与参与者连接，一个用例至少与一个参与者相关联。 给用例取名字要站在使用者的立场上考虑 可以用系统边界把用例框起来以区分系统内外 在UML中，用例用一个椭圆来表示，用例的名字可以写在椭圆的下方。用例名 用例图对整个系统的建模过程非常重要，在绘制系统用例图前，有许多工作需要做。 系统分析者必须分析系统的参与者和用例，它们分别描述了“谁来做”和“做什么”这两个问题。 识别用

7、例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者。 在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。 参与者要从系统中获得哪种功能？参与者需要做什么？ 参与者需要读取、产生、删除、修改或存储系统中的某种信息吗？ 系统中发生的事件要通知参与者吗？或者参与者需要通知系统某事件吗？这些事件（功能）能干什么？ 用系统的新功能处理参与者的日常工作是简化了，还是提高了工作效率？ 还有一些与当前参与者的日常工作无关的问题，也能帮助发现用例 系统需要的输入、输出是什么信息？这些信息是从哪里来到哪里去？ 系统当前的这种实现方法要解

8、决什么问题（也许用自动系统代替手工操作）？ 用例图中，除了参与者与用例之间的关联关系外，参与者和参与者之间可以有泛化关系，用例和用例之间有泛化关系、包含关系和扩展关系。 参与者与用例之间通常用关联关系来描述。每个参与者可以参与一个或多个用例。 参与者与用例之间的关联关系使用带箭头或者不带箭头的实现表示。 如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。 如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个

9、三角箭头从子用例指向父用例。包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。在UML中，用例之间的包含关系含有关键字的带有箭头的虚线表示。如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。 一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统） 有助于将来实现系统时，确定哪些功能可以重用，在编写代码时就可以实现代码的重用，缩短开发周期。 注意：执行基用例时，每次都必须调用被包含用例。 扩展关系是一个用例被定义为基础用

10、例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。 在UML中，扩展关系用虚线箭头加表示，箭头指向基础用例，即被扩展的用例 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将放在它的扩展用例中。 用例的粒度指的是用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析

11、?会员?输入用户名?验证用户名和密码?会员?登录?身份验证查询订单建立数据库连接执行SQL语句 用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中。 用例模型指的也不仅仅是用例图，而是由用例图和用例的详细描述用例规约所组成的。用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，

12、称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。 说明用例如何开始和结束。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“

13、信息” 在事件流里要对事件流进行结构化说明基本事件流 描述每个情节的行为者:目标语句对的顺序 假设之前的每一步都是成功的备选事件流 异常情况非功能需求(URPS)可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）设计约束用Oracle数据库平台，用PB开发软件必须符合ISO标准本质上不是需求，只是从商业、行政、技术上的约束?软件需求?非功能需求?功能需求?设计约束用例编号UC01用例名称用户注册用例概述未注册用户注册成为会员参与者未注册用户前置条件用户在主页单击“注册”,进入注册程序后置条件注册时填写的用户信息保存

14、到系统中基本事件流1.系统显示注册页面；2.用户填写用户名、密码等相关信息后提交；3.系统处理该请求并显示注册成功；4.注册成功后跳转到登录页面；扩展事件流2a.如果填写的用户名已经存在，则提示错误信息：用户名已经存在 如果密码不符合要求，则提示错误信息：密码格式不正确；3a.注册失败 系统再跳转到注册页面，提示用户重新注册；规则与约束无用例编号UC02用例名称登录用例概述验证用户名和密码参与者系统的注册用户前置条件无后置条件登录的用户已经注册基本事件流1.用户填写用户名、密码，点击“登录”；2.系统验证用户名和密码；3.验证成功，系统跳转到用户主页；扩展事件流3a.验证失败 3a1:如果用户

15、名不存在，系统提示“用户名不存在”； 如果密码错误，则系统提示“用户名或密码错误”； 3a2:让用户重填用户名和密码规则与约束 无用例编号UC03用例名称新增书籍信息用例概述录入新购书信息，并自动存储建档参与者图书管理员前置条件用户进入图书管理系统中的“新增书籍信息”程序后置条件完成新书信息的存储建档基本事件流1.系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；2.图书管理员做出选择后，显示相应的页面，让图书管理员输入信息，并自动根据书号规则生成书号；3.图书管理员输入书籍信息，包括书名、作者、出版社、ISBN、定价；4.系统确认输的入信息中书名没有重名；5.系统将所输入的信息存储

16、建档扩展事件流5a.如果输入的书名有重名，则显示重名的书籍，并要求图书管理员选择修改书名或取消输入 5a1.图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2.图书管理员选择修改书名后，转到第5步规则与约束无“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。 （2）仓库管理员负责产品的库存管理。 包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。 仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时

17、，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。 （1）销售员：为客户客提供销

18、售产品的服务。 （2）仓库管理员：负责库存产品的管理活动。 （3）采购员：负责企业生产原料的订购。 （4）会计：负责企业经营状况的统计。 （5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。（1）销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。（2）仓库管理员能够通过该系统进行如下活动： 处理盘点：每天需要对库存产品信息进行盘点。 产品入库：当产品生产后，将产品进行入库。 产品出库：当产品销售发货后，进行出库处理。 管理设置：仓库管理员负责供应商信息、产品基本信息的管理设置。（3）采购员能够通过该系

19、统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。（4）会计负责产品的统计分析管理，它能够通过该系统进行如下活动： 查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。 查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。 查询供应商信息。会计能够查询供应商信息。 查询缺货信息。会计能够查询缺货信息。 查询报损信息。会计能够查询报损信息。（5）系统管理员能够通过该系统进行如下活动： 维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。 维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。 系统设置。系统管理员能够根据一些需要进行必要的系统设置。在每个新学年开始的时候都会有新生入学。这时： 管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、学生证号、身份证号等基本信息存入数据库。在日常的管理中： 系统管理员还可以对所有学生的基本信息进行查询、修改、删除等操作。 校领导可以查询、修改全校学生的基本信息 教师查询、修改自己