《软件开发方法与案例分析》- 第 3 章 软件项目的需求分析 - b

软件开发方法与案例分析,授课教师：刘伟电 话 件：bme_ QQ：1071271580办 公 室：长安校区东区教研楼 FZ136 室 （软件工程系办公室）,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,3.4.2 面向对象分析方法,用例方法收集客户的需求从问题域或用例描述中抽取相应的对象，并从中抽象出类UML 建模：静态结构、动态行为,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,需求分析不是一项一蹴而就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程。在需求分析的初期，对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。按照这个思路，对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,案例：订餐系统。需求：一家公司向其员工提供了免费午餐。平常都是由前台收集员工点餐信息，然后报餐厅。现在遇到一些问题，前台觉得每天问员工吃什么饭比较麻烦，人少还好说，人多了效率太低。而员工又觉得正在工作的时候问他点餐又影响了他正在进行的工作。公司经理提出是否可以做一个订餐系统？员工想吃什么通过系统提交然后前台直接打印出来报表，交递餐厅。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,需求分析过程：要求分析员深度挖掘客户背景。（1）以前没有系统前订餐存在哪些问题？期待使用系统可以解决哪些问题？系统成功的标准是什么？（2）不要认为客户是不可理喻的，那是因为还没有挖掘到客户背后真正想要什么。也不要一上来就让客户牵着我们的鼻子走，客户往往都是精明的；（3）客户往往提出的是解决方案。所以我们要首先了解客户的项目背景，比如员工订餐标准 8 块，员工人数 20 人左右，很少有员工出差，中午休息 1 个半小时，使用本系统都有哪些人，系统带给他们的又是什么，老板希望解决的是什么问题，员工需要解决的是什么问题。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,和客户深入交谈后，麻烦事又来了：（1）某员工点餐了，结果餐厅今天恰好没有这个菜了；（2）订餐标准 8 块，能不能 10 块呢？（3）有些员工出去了，不能上网，不能通过该系统订餐；（4）能不能多提供几家餐厅的菜谱？（5）能不能显示菜的图片？（6）是否可以一次提交多天的订餐信息，每天都登录太麻烦；（7）否做一个连接，可以一次性提交定餐，不然要点很多页面才能提交定餐信息；（8）是不是加上一个营养分析功能？根据员工身体健康状况推荐点餐？,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,需求分析的经验教训大名鼎鼎的东软在做某个项目时，整个过程经历了 10 多次结构性的大变更，局部性的调整更是不计其数。某天早上客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是整个项目组的成员都离开了东软。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,有开发人员常常抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢？当对客户的需求没有真正理解清楚时，做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道。于是就一点一点再试，这种反复变更就这样发生了。如果明白了这一点，深入地去理解客户的业务，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，一定不能被客户牵着走。要从业务角度深入的去分析，他为什么提出变更，提得合不合理，有没有更合理的方案满足这个需求。当分析员提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,“乳腺癌筛查系统”的需求对话,下面是一个真实的软件开发中的需求对话场景，分析员和该系统的用户（调查员、放射科医师、数据分析员）直接的对话（考虑到说明问题的需要，做了部分简化及修改）。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,用例驱动的需求分析方法,对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是贯穿整个面向对象分析/设计（OOA / OOD）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,在一个用例图中通常有如下一些元素：角色或参与者（Actor）、用例（Use Case）、通讯关联（Communication Association）、系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；角色或参与者，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个人形符号；通讯关联，用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的；系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。通常情况下系统边界只是一个概念而不用真正绘制出来，因为被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,用例图示例,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,需求分析的第一个问题谁是这个产品的用户？或者谁是这个产品系统中的角色（Actor）？,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,什么是角色（ Actor ，参与者）（1）与系统发生交互作用的、系统之外的任何东西都是角色 可以是人 也可以是机器（2）角色不等同于使用者（二者不能划等号！）（3）使用者是行驶某个角色职责的系统的使用人员 如小王是个采购员（4）角色存在于系统外部（5）角色不是活动的准确描述,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,（1）每个 Actor 都通过不同的方式使用系统，除非他们是相同的 Actor（2）Actor 使用系统的每一种方式就是一个 Use Case,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,主动角色：Use Case 的动作序列是由他先发起的，通常系统返回最后结果 主叫方，采购人员，票据录入员等被动角色：系统通过调用角色来完成 Use Case 的动作序列（或其中的某一个动作） 不是初始动作的发起者 当系统需要它们帮助的时候 最终是为了满足主动角色的需要 通常是机器或其他系统,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,确定角色（参与者）参与者往往有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。 第三类参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,确定角色（参与者）在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者：（1）谁将使用该系统的主要功能。（2）谁将需要该系统的支持以完成其工作。（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。（4）系统需要处理哪些硬件设备。（5）与该系统那个交互的是什么系统。（6）谁或什么系统对本系统产生的结果感兴趣。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,在对参与者建模的过程中，开发人员必须要牢记以下几点：（1）参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。（2）参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。（3）参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。（4）每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。（5）每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。（6）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。（7）和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,角色（参与者）之间的关系因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与 UML 中类之间的返还关系符号相同。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,被绘制成用例的必然是系统内部的功能，被绘制成参与者的必然是系统外部事物。从这个意义上讲，用例图中的参与者不仅包括人，还包括那些外部系统和自动触发器。如果把外部系统和自动触发器绘制成一个小人，这常常令客户感到困惑。可以将外部系统和自动触发器绘制成另一种表达形式 - 类元符号表示法，并在构造型上标注为 Actor。这样便于和客户交流。,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,脚本（ Script）（1）脚本是一个角色与系统之间的一组交互作用（2）通常具有详细的真实数据及实际的期望输出值（3）一个应用系统可能具有成千上万个脚本（4）即使同一件事，所得到的脚本可能也会有细微的区别（5）脚本是描绘 Use Case 的重要的背景信息,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,脚本示例,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,脚本与 Use Case,（1）一个 Use Case 代表一组潜在的脚本（2）通过研究一组相似的脚本，可以得到它们内在的逻辑（3）相似的脚本通常遵循相似的模式工作，并提供相似类型的结果（4）一个 Use Case 通常关注某一个目标 例如：查询存折余额,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,通过 Use Case 描述系统功能需求,（1）一个系统具有无限个潜在的脚本（2）但一个系统可以被有限的 Use Case 完整说明（3）系统的每一个 Use Case 都必须列举，否则系统将会遗漏功能,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,用例（Use Case）,描述系统提供的交互功能 一个 Use Case 可以被其他的 Use Case 调用 Use Case 可以组合完成某一项更大的功能Use Case说明系统需要提供什么而不是怎么提供 用户并不关心你如何给他们提供所需要的功能Use Case一般是用“动宾”短语命名,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,Use Case不是分析设计文档 虽然它们支持后续的分析设计工作Use Case不是操作脚本 它不是用户使用系统时实际操作的具体步骤的记录 虽然它可能是通过操作脚本得来的,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,Use Case 是很好的测试单元,Use Case 清晰地描述了系统的功能界面测试人员可以在开发初期制定测试计划每一个 Use Case 都严格地说明了系统的某一项功能 它的输入 它的输出 期间的交互作用Use Case 是黑盒测试的基准,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,Use Case 的阐述,（1）应该包含 Use Case 的所有重要细节（2）应该包括角色与系统交互的关键步骤，可以使用顺序图（Sequence Diagram）（3）要表述有关角色的信息（4）要分清哪些是角色所具有的职能、哪些是系统所应提供的（5）要列清使用这些功能是所应满足的前提条件（6）如果某些功能具有质量上的要求（如性能），也要列出来,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,Use Case 标记,西安邮电大学计算机学院,第 3 章 软件项目的需求分析,Use Case：主动角色,西安邮电大学计算机