很多人在分析需求的时候,采用的是东扯葫芦西扯瓢的方式,列出了很多的需求点,但当你看完后,你还是不知道到底要干嘛!! ---- 写在前面
用例,英文名称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
================================================