连载:面向对象葵花宝典:思想、技巧与实践(18) - 用例分析

很多人在分析需求的时候,采用的是东扯葫芦西扯瓢的方式,列出了很多的需求点,但当你看完后,你还是不知道到底要干嘛!!  ---- 写在前面

用例,英文名称Use Case,英文和中文都是很好理解,因为大家都这么用,我们暂且不去追究名称上的问题,只要知道“用例是用来描述需求的流程”,即:描述5W1H中的How

 

看起来用例应该很好写,因为用例是描述需求的流程的,而需求的流程一般都是客户根据自己的业务总结出来,然后告诉我们的。我们只要将客户描述的内容记录下来即可,既简单又轻松!

 

但现实与理想总是有差距的,你可能会遇到一个对业务并不十分熟悉的客户,又或者和你交流的人员是客户的临时工,还有可能和你交流的人马上要休婚假了,他巴不得赶快了结这个无聊的事。。。。。。总之,各种各样的情况都可能出现,就是完美的情况不会出现!

 

这种情况下,我们如何才能做到完善的分析呢?我们怎么知道我们的分析是否正确,是否有遗漏,是否足够了?

 

一般的情况下,公司里负责需求分析得人员都是资深的员工,对领域、对系统有一定的积累和经验,即使面对这些情况,也可以通过自己的经验来弥补。

 

但对于一个菜鸟,遇到这种情况应该怎么办呢?难道菜鸟就不能做需求分析了么?

 

别慌,菜鸟虽然没有经验,但只要掌握正确的方法,一样可以做出很好的需求分析,这就是我总结的用例三部曲方法,又或叫做NEA方法。

 

我总结出的用例方法三段法(NEA方法):

1) 正常处理(Normal):通过和客户沟通,分析需求的正常流程;

2) 异常处理(Exception):在正常处理流程的步骤上,分析每一步的各种异常情况和对应的处理;

3) 替代处理(Alternative):在正常处理流程的步骤上,分析每一步是否有其它替代方法,以及替代方法如何做;

 

经过这简单三步后,How可以说分析得八九不离十了。

【用例的具体写法】

前面我们学习了518需求分析方法,而一个完整的用例,正好体现了518需求分析方法中涉及的内容。

一个完整的用例应该包含如下几个部分:

【用例名称】

一般情况下,用例的名称即需求的名称。

【场景】

场景即用例发生的环境,正好对应5W中的3个W:Who、Where、When

【用例描述】

描述详细的用例内容,对应5W中的What和How,即用户应该怎样做,以及每个步骤中的输出。但并不要求每个步骤都一定有输出,可以有也可以没有,也可以有多个。

【用例价值】

描述用例对应的客户价值,对应5W中的Why。

【约束和限制】

即整个需求流程中相关的约束和限制条件,对应518方法中的8C。

 

 

我们来看一个简单的样例:POS机。

【第一步:正常处理】


【用例名称】

买单

【场景】

Who:顾客、收银员

Where:商店的收银台

When:营业时间

【用例描述】

1. 顾客携带选择好的商品到收银台;

2. 收银员逐一扫描商品条形码,系统根据条形码查询商品信息;

3. 扫描完毕,系统显示商品总额,收银员告诉顾客商品总额;

4. 顾客将钱交给收银员;

5. 收银员清点钱数,输入收到的款额,系统给出找零的数目;

6. 收银员将找零的钱还给顾客,并打印小票;

7. 买单完成,顾客携带商品和小票离开;

【用例价值】

顾客买完单以后,就可以携带商品离开,而超市也将得到收入;

【约束和限制】

1. POS机必须符合国标XXX;

2. 键盘使用中文,因为收银员都是中国人;

3. 一次买单数额不能超过99999RMB;

4. POS机要非常稳定,至少一天内不要出现故障;

 

 

【第二步:异常处理】

在第一步的基础上,我们增加相关步骤的异常情况说明和处理,例如如下的黑体字:


【用例名称】

买单

【场景】

Who:顾客、收银员

Where:商店的收银台

When:营业时间

【用例描述】

1. 顾客携带选择好的商品到收银台;

(这一步没有异常)

2. 收银员逐一扫描商品条形码,系统根据条形码查询商品信息;

2.1 扫描仪坏了,必须支持手工输入条形码;

2.2 商品的条形码无法扫描,必须支持手工输入条形码;

2.3 条形码能够扫描,但查询不到信息,需要收银员和顾客沟通,放弃购买此产品

3. 扫描完毕,系统显示商品总额,收银员告诉顾客商品总额;

(这一步没有异常)

4. 顾客将钱交给收银员;

4.1 顾客的钱不够,顾客和收银员沟通,删除某商品

4.2 顾客的钱不够,顾客和收银员沟通,删除某类商品中的一个或几个(例如买了5包烟,去掉两包)

4.3 顾客觉得某个商品价格太高,要求删除某商品;

5. 收银员清点钱数,输入收到的款额,系统给出找零的数目;

(这一步没有异常)

6. 收银员将找零的钱还给顾客,并打印小票;

7. 买单完成,顾客携带商品和小票离开;

【用例价值】

顾客买完单以后,就可以携带商品离开,而超市也将得到收入;

【约束和限制】

1. POS机必须符合国标XXX;

2. 键盘使用中文,因为收银员都是中国人;

3. 一次买单数额不能超过99999RMB;

4. POS机要非常稳定,至少一天内不要出现故障;

 

有的人可能会认为第3、第5、第6步都应该有异常,例如系统坏了应该怎么处理。

但实际上我们没有必要这么写,因为用例分析的目的是为了详细分析为了实现客户价值,系统应该怎么做,如果系统本身都坏了,这个就不是用例关注的内容了。

 

需要注意的是:用例分析中的“异常”是指流程的异常情况,而不包含系统本身的的异常。

 

【第三步:替代处理】

在第二步的基础上,我们增加替代处理。即:有的步骤可以换一种方式来实现。例如如下用例中的付款方式,可以有信用卡支付、会员卡支付、购物卡支付等。


【用例名称】

买单

【场景】

Who:顾客、收银员

Where:商店的收银台

When:营业时间

【用例描述】

1. 顾客携带选择好的商品到收银台;

(这一步没有异常)

2. 收银员逐一扫描商品条形码,系统根据条形码查询商品信息;

2.1 扫描仪坏了,必须支持手工输入条形码;

2.2 商品的条形码无法扫描,必须支持手工输入条形码;

2.3 条形码能够扫描,但查询不到信息,需要收银员和顾客沟通,放弃购买此产品

3. 扫描完毕,系统显示商品总额,收银员告诉顾客商品总额;

(这一步没有异常)

4. 顾客将钱交给收银员;

4.1 顾客的钱不够,顾客和收银员沟通,删除某商品;

4.2 顾客的钱不够,顾客和收银员沟通,删除某类商品中的一个或几个(例如买了5包烟,去掉两包)

4.3 顾客觉得某个商品价格太高,要求删除某商品;

4-A:顾客使用信用卡支付

4-A.1 信用卡支付流程(请读者自行思考完善,可以写在这里,如果太多,也可以另外写一个子用例)

4-B:顾客使用购物卡支付

        4-B.1 购物卡支付流程

4-C:顾客使用会员卡积分支付

        4-C.1 会员卡积分支付流程

5. 收银员清点钱数,输入收到的款额,系统给出找零的数目;

(这一步没有异常)

6. 收银员将找零的钱还给顾客,并打印小票;

7. 买单完成,顾客携带商品和小票离开;

【用例价值】

顾客买完单以后,就可以携带商品离开,而超市也将得到收入;

【约束和限制】

1. POS机必须符合国标XXX;

2. 键盘使用中文,因为收银员都是中国人;

3. 一次买单数额不能超过99999RMB;

4. POS机要非常稳定,至少一天内不要出现故障;

 

经过上面步步为营,逐步细化和求精,我们已经得到了一个比较完善的需求了,这个过程中并没有高深的技巧,也没有涉及需要丰富的经验。

 

有的读者可能会有疑问:我怎么知道第4步有那些异常、那些替代方案呢? 

其实很简单:问你的客户!客户是最清楚了,但如果你不问,嘿嘿,客户倒不一定会告诉你:)

 

但只要我们掌握了NEA用例分析方法,即使客户忘记了,或者没有意识到,我们也会将需求挖出来,这样需求就不会遗漏。

 

【要画图么?】

大家可以看到,我们在前面进行用例分析的时候,并没有看到任何图,而是纯文本!

 

对于那些UML狂热分子来说,这可能是难以接受的,怎么能没有图呢?UML中的用例图不就是用来分析需求的么?

 

我们当然不怀疑UML的权威性,但任何东西都有局限性,UML也不例外。UML的局限就在于UML是一个建模的语言,就像汉语、英语一样,只是一种表达形式,而不是一种分析和创作方式。

 

比如说你会汉语,但并不代表你就能写小说,你会画UML用例图,但并不代表你就能做需求分析。相反,必须是有了需求和用例之后,才有用例图,说白了,用例图是用例的图形化描述,但是它并不能取代用例。

 

除了UML本身的局限性外,还有另外一个更重要的原因:用例是客户和公司关于产品的一个共同认识!一般情况下,市场人员和客户沟通交流,了解客户的需求,然后和客户一一确认,最后形成需求文档。在这个过程中,主要是客户和市场人员参与,而没有研发的人员参与。

 

对于客户来说,他肯定是以自然语言,而不会用UML来描述需求;对于市场人员来说也一样,他可能对UML一窍不通,甚至他以前可能都是卖医疗器械,甚至有可能是狗皮膏药的,他还管你什么软件工程,什么UML?

 

所以,采用用例方法分析需求的时候,我们都是采用纯文本来描述需求的,而不会采用用例图来分析需求

================================================ 
转载请注明出处:http://blog.csdn.net/yunhua_lee/article/details/21372929
================================================ 

时间: 2024-10-01 05:25:11

连载:面向对象葵花宝典:思想、技巧与实践(18) - 用例分析的相关文章

反病毒技巧:以Word为例分析和解决宏病毒的侵害

宏病毒主要在办公软件Office中出现,给广大用户造成不小的损失.通过以下三招可以远离宏病毒(本文以Word为例). 第一招:设置宏安全级别 打开Word,选择"工具→选项→安全性→宏安全性"命令.这样就打开了宏的安全级别属性设置选项,将安全级别由默认的"高"修改为"非常高",最后单击"确定"即可.这样可以防止除Word默认的宏以外的其他宏运行. 第二招:运行宏病毒自动提示 打开Word,选择"工具→选项→安全性→宏

连载:面向对象葵花宝典:思想、技巧与实践(28) - 设计原则:内聚&耦合

前面通过实例讲解了一个一环扣一环的面向对象的开发流程:用例模型 -> 领域模型 -> 设计模型(类模型 + 动态模型),解答了面向对象如何做的问题.接下来我们就要讲"如何做好面向对象设计"的技巧了 =================================================================== [内聚] 参考维基百科的解释,内聚的含义如下: cohesion refers to the degree to which the eleme

连载:面向对象葵花宝典:思想、技巧与实践(1) - 程序设计思想的发展

史前时代:面向机器 最早的程序设计都是采用机器语言来编写的,直接使用二进制码来表示机器能够识别和执行的指令和数据.简单来说,就是直接编写0和1的序列来代表程序语言.例如:使用0000 代表 加载(LOAD),0001 代表 存储(STORE)等.  机器语言由机器直接执行,速度快,但一个很明显的缺点就是:写起来实在是太困难了,一旦你发现自己写错了,改起来更蛋疼!这样直接导致程序编写效率十分低下,编写程序花费的时间往往是实际运行时间的几十倍或几百倍.  有一个关于机器语言和比尔盖茨的笑话,是说比尔

013_《Delphi面向对象编程思想》

<Delphi面向对象编程思想> Delphi 教程 系列书籍 (013) <Delphi面向对象编程思想> 网友(邦)整理 EMail: shuaihj@163.com 下载地址: Pdf 作者: 刘艺 [作译者介绍] 丛书名: Borland核心技术丛书 出版社:机械工业出版社 ISBN:7111127722 上架时间:2003-10-10 出版日期:2003 年9月 开本:16开 页码:476 版次:1-1 内容简介 这是一本纯粹讨论dlephi面向对象编程的力作. 本书以精

Silverlight游戏设计:(五)面向对象的思想塑造游戏对象

传说,面向对象的开发模式最初是因为程序员偷懒而不小心诞生的.发展至今,人们从最初的热忠于 讨论某某语言是否足够面向对象到现在开始更广泛的关注面向对象的思想而不是具体内容.面向对象的思 想其实并不深奥,它存在的目的只有一个:让程序开发更贴近我们的现实世界. 还记得猫.猫叫:狗.狗吃东西吗?无数的程序员都喜欢将此类似的情形设计当作面向对象最好的例 子.是的,非常生动且形象:但实际运用中你是否能真正做到举一反三? 回述到游戏设计中,大家是否时常会感觉游戏世界与我们的真实世界如此贴近?游戏中的精灵好比我

java语言学习002_面向对象编程思想

      人类在认识世界时,为了方便自己和智慧提升,很自然的对事物进行了分类.对世界进行了抽象,若把所有各个事物看做对象,纵观所有对象,这些对象具有各自的或共有的特征,并且又有共有的或各自的的能力,这样就可以对具有相同一些特征和一些能力的事物进行了归类.       比如,车,有汽车,火车他们都有哪些属性?                  汽车,特征:长度,颜色,速度,轮胎,载重,平面行走--能力:移动,载东西,--                  火车,特征:长度,颜色,速度,轮胎,载重

求助、面向对象的思想查找字符串中的数字

问题描述 要用面向对象的思想来查找字符串中的数字.实现判断某个字符是否位数字的方法如下:publicstaticboolgetNumeric(stringstr){boolb=false;string[]ArrayInt=newstring[]{"1","2","3","4","5","6","7","8","9","

将面向对象的思想带入TC

写TC貌似是很简单的工作,但当动手写的时候往往会出现,不知道写什么,又感觉有一堆的东西需要写,即使一个简单的日常也会觉得里面的逻辑非常复杂,然后就是晕得不知所向. 个人认为,写TC没有固定的模式,也没有唯一的答案,每个人的方式不同,习惯不同,TC中的如何分类归纳也就自然不相同.但目标是一致的,基本目标是覆盖需求.无盲区:加强目标是加深测试点,完善用户友好性等. 下面分享下我写TC的几种思路. 第一种思路--先对象,后流程 面向对象是在平常入门学习中 首先接触到的概念,它不仅仅存在于代码的编写中,

重温面向对象的思想——构造器和重载

1.this关键字 this表示这个对象的参考名称:例如this.age1=age2;表示将age2的值,赋值给这个对象的私有属性age1. 2. .重温面向对象的思想--构造器和重载 构造器:创建一个对象时,有时候需要对在实例化一个对象时,对这个对象进行初始化,这个时候我们就需要构造方法来进行这种初始化. 重载:当这种初始化需要按照不同的语境,不同的参数的构造器来进行初始化. 总结--方法的重载是多种构造器,用以完成不同的初始化. -注意:构造器==构造方法,两者一样 3.构造方法和自定义方法