基于用例的需求分析模式.pptx

1 需求管理之 基于用例的需求分析模式 本次课程的结构 1、回顾一下需求调研的方法和过程，及关于一个BUG管理系统的基本需求； 2、介绍use case的各种概念和建模方法和技巧 3、课堂练习BUG管理系统的用列建模； 4、分析和讨论大家的用例； 5、介绍常见的各种用例错误； 2 回顾一下需求调研的过程 在需求的调研的过程中我们得到了什么？ 假设我们要为公司做一个BUG管理系统 通过需求调研我们可以确BUG管理系统的哪些东西？ 目标、涉众、主要工作流程、业务规则？ 3 目标 1、构建一个系统可以很好的管理各项目中的BUG，并方便测试人员和开发人员处理BUG； 2、该系统可以通过对BUG的统计和分析，来辅助项目经理管理项目的质量，评价开发人员的工作质量和效率； 3、该系统可以为公司管理人员评价项目的质量和效率； 4、该系统可以作为开发人员和测试人员的绩效评价的依据； 涉众： 程序员、项目经理、部门经理、测试人员，测试部经理、质量管理员、公司领导 如果进行需求分析 需求分析目标是将用户的模糊的业务需求转化成精确的系统需求模型，并以一种开发人员和用户都能看懂的方式表达出来； 常用的需求分析方法： 功能分解法、原型法、用例法 4 功能分解法的缺点 非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因 为这样的需求表述既包含了外部需求也包含了内部设计。 分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。 什么是用例建模法 捕捉等开发系统行为的方法 表达系统行为的方法 识别谁或什么与本系统交互，和本系统应该做什么 验证所有的需求都已经被捕捉到 用例的特点 外部可见：用户行为、系统响应 有价值 详细程度：能让主要涉众对需求达成共识 语言精确，使用无岐义的词汇 角色与用例 角色：在系统之外与系统进行交互的某人或某事； 用例：系统执行的，外部可见的，产生对角色有价值结果的动作序列。 用例命名：能够说明目标的动名词组 5 use case的识别应从角色开始 用户识别常考虑的问题 6 每个角色的目标是什么？ 为什么该角色想要使用该系统？ 该角色是否要创建、保存、更改、移动或读取系统的数据？如果是。为什么？ 该角色是否要通知系统外部事件或变化？ 该角色是否需要知道系统内部的特定事件？ 系统是否向业务提供了所有的正确的行为？ 那么，怎么确定一个用例呢？ 我认为：一个用例应该是完成达到最小一个业务目标功能集，如：验证用户（达到身份验证的业务目标）是一个用例，而用户信息输入，密码验证就不是用例。 如何确定用例 用例的有效性测试 1．老板测试： 如果老板问你“整天都在做什么”，而你的回答是：“登陆系统”，这显然不能让老板高兴，因为你的回答不具有可量化的价值。不具有可量化的价值就是不具有提高工作效率、产生有价值结果的操作，即该操作对老板来说没有价值。如果你写的用例不具有可量化的价值，则不能通过老板测试，也就不是一个有效用例。老板测试是最低级别的用例有效性测试。 2．EBP测试（Elementary Business Process）： 一个人于某个时间某个地点，为响应业务事件所执行的任务，如果能增加可量化的业务价值，并且以持久状态保留下数据，则可以通过EBP测试。 EBP测试用一种更加精确的方式量化了用例的有效性。它除了要求进行有价值的业务操作以外，还必须产生有价值的、持续保留的数据。同时，它还要求了完成这个任务的时效性，即必须在一个会话中完成。持续数日或跨越多个会话的用例都不能通过这个测试。 3．规模测试： 即一个用例必须达到一定的规模才能算有效。必须达到什么样的规模呢？通常必须包含多个步骤，在详述形式的用例说明通常会持续数页。不能通过规模测试的一个典型错误，就是将一系统步骤中的一个作为用例。 7 一般来说，通过以上三个测试才能算是有效用例，但是也存在着例外。 如： 分析、查询、统计类不能通过EBP测试； 用户身份认证不能通过老板测试； 用例包括那些 1、用例包括了：actor、case、使用场景、事件流、输入、输出、前后置条件、约束等。 即在一个用例中是包括了业务的描述、系统功能的描述、业务流程的描述、业务规则的描述； 2、从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。 但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(inc