3 、业务场景法:
a) 考虑用例的调用者;考虑每一个用例提供的服务是供哪些外部用例或者系统调用,找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。(一般和外部有交互的用例出错的概率比较大,需要重点关注)
b) 考虑系统内部各个用例之间的交互,形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件,组织出各种业务流程图。
4 、功能分解法
a). 业务功能:与用户实际业务直接相关的功能 或细节。
b). 辅助功能:辅助完成业务功能的一些功能或者是细节,比如,设置过滤条件。
c). 数据约束:功能的细节,主要是用于控制在执行功能时,数据的显示范围、数据之间的关系等。
d). 易用性需求:功能的细节,产品中必须提供了,便于功能操作使用的一些细节,比如快捷键就是典型的易用性需求。
e). 编辑约束:功能的细节,在功能执行时,对输入数据项目的一些约束性条件,比如只能输入数字。
f). 参数需求:功能的细节,在功能中,需要根据参数设置不同,进行不同处理的细节。
g). 权限需求:功能的细节,这里的权限是指在功能的执行过程,根据根据不同的权限进行不同处理的,不包括直接限制某个功能的权限。
一个有趣的例子
某日,老师在课堂上想考考学生们的智商,就问一个男孩:“树上有十只鸟,开枪打死一只,还剩几只?”
男孩反问:“是无声枪么?”
“不是。”
“枪声有多大?”
“80~100分贝。”
“那就是说会震的耳朵疼?”
“是。”
“在这个城市里打鸟犯不犯法?”
'不犯。“
“您确定那只鸟真的被打死啦?”
“确定。”老师已经不耐烦了,“拜托,你告诉我还剩几只就行了,OK?”
“OK。鸟里有没有聋子?”
“没有。”
“有没有关在笼子里的?”
“没有。”
“边上还有没有其他的树,树上还有没有其他鸟?”
“没有。”
“方圆十里呢?”
“就这么一棵树!”
“有没有残疾或饿的飞不动的鸟?”
“没有,都身体倍棒。”
“算不算怀孕肚子里的小鸟?”
“都是公的。”
“都不可能怀孕?”
“………,决不可能。”
“打鸟的人眼里有没有花?保证是十只?”
“没有花,就十只。”
老师脑门上的汗已经流下来了,下课铃响起,但男孩仍继续问:“有没有傻的不怕死的?”
“都怕死。”
“有没有因为情侣被打中,自己留下来的?”
“笨蛋,之前不是说都是公的嘛!”
“同志可不可以啊!”
“…………,性取向都很正常!”
“会不会一枪打死两只?”
“不会。”
“一枪打死三只呢?”
“不会。”
“四只呢?”
“更不会!”
“五只呢?”
“绝对不会!!!”
“那六只总有可能吧?”
“除非你他妈的是猪生的才有可能!”
“…好吧,那么所有的鸟都可以自由活动么?”
“完全可以。”
“它们受到惊吓起飞时会不会惊慌失措而互相撞上?”
“不会,每只鸟都装有卫星导航系统,而且可以自动飞行。”
“恩,如果您的回答没有骗人,”学生满怀信心的回答,“打死的鸟要是挂在树上没掉下来,那么就剩一只,如果掉下来,就一只不剩。”
老师当即倒!
举例说明如何进行测试需求分析
先看一段关于日志文件的需求描述如下:“软件要将所有的访问者都要记录下来,对每次访问要记录访问开始时间、访问结束时间、访问者的IP地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。
在这段需求描述中,我们首先要想象自己是日志模块的开发者,根据这段需求描述,是否能够开发出日志模块来呢?日志文件要记录的信息内容上面都提到了:访问开始时间、结束时间、IP地址。乍一看好像可以根据这个需求描述进行开发。
但仔细来分析一下这段需求的话,就会发现并不是想象的那样乐观。先找出需求中涉及的三个显性元素:
1、访问者
2、访问记录
3、日志文件
首先对访问者和访问记录这两个元素进行分析,先看访问者有那些属性,除了描述中提及的访问时间和IP地址外,访问者还有那些属性呢?显然访问者 的访问内容是最重要的属性,仅记录访问时间和访问者的IP地址是否足够呢,从日志能分析出什么有用的信息呢?从时间信息上最多只能看出那段时间访问的人数 较多,得到用户的时间分布规律,但很难对用户的行为有深入的分析,只有知道访问者在访问那些内容才能得到更有价值的信息。象Web服务器软件要记录下访问 的URL信息以便知道访问者访问的内容,所以访问记录中遗漏了关于访问内容的信息。
从访问记录这个元素来分析,访问记录主要属性是记录格式,每条记录是以什么格式来记录呢?没有描述出来。有经验的开发者就知道日志记录格式是一 个很重要的问题,因为日志记录的分析一般是需要使用专门的分析软件或者写专门的分析程序来分析的。如何设计合理的记录格式来利用已有的日志分析软件来进行 分析是首要考虑的问题。
原文转自:http://www.blogjava.net/qileilove/archive/2013/05/20/399492.html