基于用例的需求分析模式 PPT课件

4
角色与用例
❖ 角色：在系统之外与系统进行交互的某人或某事； ❖ 用例：系统执行的，外部可见的，产生对角色有价
值结果的动作序列。 ❖ 用例命名：能够说明目标的动名词组
use case 的识别应 从角色开 始
5
用户识别常考虑的问题
uc 用例图
边界如何确定用例
价值
每个角色的目标是什么？
➢为什么该角色想要使用该系统？
Use Case
➢该角Act色or 是否要创建、保存、更改、移动或读取系统的数据？
如果是。为什么？
➢该角色是否要通知系统外部事件或变化？
1.谁使用系统的主➢要该功能角？色是否需要知道系统内1.使部用业的务语特言而定不事是技件术语？言；
系统是否向业务提供了所有的正确的行为？ 2.谁改变系统的数据
3.谁从系统获取信息
67..系系统统需需要要应和付哪些（外处我部理认系）统哪为交些互硬：设？备一？个用例应该是完掩5.关盖成于真达C实R的U到D业务最。 小一个业务目标功能
89..谁有没（有或集自什动么，发）生对如的系事统：件运行？验产证生的用结果户感兴（趣达？ 到身份验证的警所惕有业业CR务务U最D泛目后滥都标；会成）为C是UR一D 个用例， 而用户信息输入，密码验证就不是用多问例一下。：为什么要CRUD，光是CRUD能为actor提供价值Βιβλιοθήκη ？6用例的有效性测试
❖ 1．老板测试：
如因果 为老 你板 的问 回你 答不“整具天有都可在量做化什的么价”，值而。你不的具一 能回有般 算答可是量来 是：化说 有“的登， 效价陆通 用值系就过 例统是”以 ，，不上但这具显三是有然提个也不高测存能工试在让作老才着效板率高、兴产，生 有价值结果的操作，即该操作对老板来说例没外有价。值。如果你写的用例不具有可量化的价值， 则不能通过老板测试，也就不是一个有效如用：例。老板测试是最低级别的用例有效性测试。
即在一个用例中是包括了业务的描述、系统功能的描述、业务流程的 描述、业务规则的描述；
2、从原则上来讲，用例之间都是并列的，它们之间 并不存在着包含从属关系。
但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例 之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这几 种关系
❖ 2．EBP测试（Element过aEry分BPB析测u、试s查；in询e、ss统计Pr类o不ce能s通s）：
一值个 ，人 并于 且某 以个 持时 久间 状某 态个 保地 留点 下，数为据响，应则业可务以事通件过用所EB户执P行测身的试份任。认务证，如不果能能通增过加可老量板化的业务价 测试；
EBP测试用一种更加精确的方式量化了用例的有效性。它除了要求进行有价值的业务操作 以外，还必须产生有价值的、持续保留的数据。同时，它还要求了完成这个任务的时效性， 即必须在一个会话中完成。持续数日或跨越多个会话的用例都不能通过这个测试。
❖ 3．规模测试：
即一个用例必须达到一定的规模才能算有效。必须达到什么样的规模呢？通常必须包含多 个步骤，在详述形式的用例说明通常会持续数页。不能通过规模测试的一个典型错误，就 是将一系统步骤中的一个作为用例。
7
用例包括那些
1、用例包括了：actor、case、使用场景、事件流、 输入、输出、前后置条件、约束等。
8
包含关系（include）
❖ 如果许多用例中都有一种共同行为，把该行为通过用例来模 型化，被其他用例重用，则这种关系称为“包含”关系。
❖ 被包含的用例不能自己独立存在。它只能作为包含它的用例 的一部分。
2.发自用户观点而不是系统观点; 3.从参与者的角度：状语 动词 （+（+定语）宾语）;
那么，怎么确定一个用例呢？ 4.谁需要系统的支持以完成日常工作任务？
5.谁负责维护、管理并保持系统正常运行？
4.小心：慎用弱动词（进行、使用、复制、加载、重复…） 和弱名词（数据、报表、表格、表单、系统…），否则：会
需求管理之
基于用例的需求分析模式
1
本次课程的结构
❖ 1、回顾一下需求调研的方法和过程，及关于一个 BUG管理系统的基本需求；
❖2、介绍use case的各种概念和建模方法和技巧 ❖ 3、课堂练习BUG管理系统的用列建模； ❖ 4、分析和讨论大家的用例； ❖ 5、介绍常见的各种用例错误；
2
回顾一下需求调研的过程
❖ 在需求的调研的过程中我们得到了什么？ ❖ 假设我们要为公司做一个BUG管理系统 ❖ 通过需求调研我们可以确BUG管理系统的哪些东西？
▪ 目标、涉众、主要工作流程、业务规则？
目标
1、构建一个系统可以很好的管理各项目中的BUG，并方便测试人员和开发人员处理 BUG； 2、该系统可以通过对BUG的统计和分析，来辅助项目经理管理项目的质量，评价开 发人员的工作质量和效率； 3、该系统可以为公司管理人员评价项目的质量和效率； 4、该系统可以作为开发人员和测试人员的绩效评价的依据；
涉众：
程序员、项目经理、部门经理、测试人员，测试部经理、质量管理员、公司领导
3
如果进行需求分析
❖ 需求分析目标是将用户的模糊的业务需求转化成精确的系统需求模型， 并以一种开发人员和用户都能看懂的方式表达出来；
❖ 常❖用什的需么求是分用析例方建法：模法 ▪ 功❖能分捕解捉法等、原开型发法系、功用统例能行法分为解的法方的缺法点 ❖ 非表常达容易系混统淆需行求为和设的计方的界法限，这样的表述实际上已经包含了部分 的设❖计识在内别。谁由此或常什常导么致与这样本的系迷惑统：交系统互需，求应和该本详细系到统何种应程该度？做一什 个极端么就是需求可以详细到概要设计，因 为这样的需求表述既包含了外部需 求也❖包验含了证内所部设有计的。 需求都已经被捕捉到 ❖ 用分例割的了各特项点系统功能的应用环境，从各项功能项入手，你很难了解到这 些功❖能外项是部如可何相见互：关联用来户实现行一为个完、成系的系统统响服务应的。所以在传统的SRS 文档❖中有，我价们值往往需要另外一些章节来描述系统的整体结构及各部分之间的 相互❖关详联，细这程些内度容：使得能SR让S需主求要更象涉是众一个对设需计文求档达。 成共识 ❖ 语言精确，使用无岐义的词汇