连载:面向对象葵花宝典:思想、技巧与实践(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
================================================ 

你可能感兴趣的:(面向对象,需求分析,用例方法)