有效用例模式(五)

 

第五章 用例

5.1 CompelteSingleGole

不适当的目标,会使编写人员不能确定什么时候一个用例结束,什么时候另一个用例开始。

原因:

太大的用例可能会因细节过多占去涉众的大部分精力;

大的用例限制重用;

过小的用例仅能描述某些价值实现的一部分;

所以:

编写每个用例,用来描述一个完整而且定义良好的目标。

初速目标的特性为:

?         它与一个定义良好的参与者相关;

?         它对参与者或参与者代表的涉众是有价值的;

?         它与在这一级别上为系统确定的其他目标一致;

?         避免与具体的借口细节联系到一起,而编写出完成目标片断的用例;

5.2 VerbPhraseName

没有意义的普通名称不会使读者有什么期望,也不会提供一个方便的参考点。

原因:

名称为读者确定了基调和关联,并能够为编写人员提供一个焦点;

适当的用例名称能够使读者看到大的概貌,并且对整个用例集有效;

所以:

用一个代表主参与者目标的主动动词短语来命名用例。

5.3 ScenarioPlusFragments(主场景+分支片断)

读者必须能够非常轻松的阅读具体的场景或他们感兴趣的故事;否则,他们可能会变的沮丧,或遗漏重要的信息。

原因:

一个有趣的用例需要捕获主成功场景的分支;

将每个分支编写为一个完整的故事将会模糊故事变体之间的差别;

将每个变体分离出来也会使编写人员的工作变得非常困难;

需要清晰的确定主成功场景;

所以:

将成功的故事情节编写为简单场景,不考虑任何可能的失败。在该场景下面,放上展示会发生什么情况的故事片断。

5.4 ExhaustiveAlternatives

用例可以有很多分支,遗漏一些分支意味着开发人员会误解系统的行为,这样的系统是不完善的。

原因:

开发人员需要知道如何处理错误;

进度压力限制了开发人员可以识别各种变化的时间;

拥有关于变化的信息有助于开发人员构建一个健壮的设计;

所以:

必须捕获在用例中处理的所有分支和失败情况。

5.5 Adornments

在用例中包含非功能需求很难快就会将用例搞乱并模糊用例。

原因:

用例的目的是清晰的表达系统的功能需求;

不应该遗漏有助于理解用例或对开发人员来说有价值的信息;

所以:

在用例模板的场景文本之外创建额外的区域,来容纳对关联用例有用的补充信息;

用例和其他补充需求紧紧相扣,例如:性能需求、用户界面说明、约束条件、业务规则、数据字典等。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

5.6 PreciseAndReadable

对非技术性读者来说太复杂,或对开发人员来说太不精确的用例是不完善的,很可能或导致构建不良且不适当的系统。

原因:

对涉众和开发人员来说,用例应该是可读的;

开发人员有一种添加细节和解决方案的倾向;

非技术性涉众可能会遗漏一些必要的考虑;

为客户和开发人员提供不同的需求文档集合是很糟糕的;

所以:

用例需要足够可读,以便使涉众可以阅读和作出评估;

用例需要足够精确,以便开发人员可以理解他们正在构建的系统。

 

阅读更多
文章标签: 文档 工作
个人分类: 软件工程
想对作者说点什么? 我来说一句

编写有效用例 经典(pdf)

2008年11月24日 16.38MB 下载

编写有效用例(中文版、英文版)

2011年03月15日 17.34MB 下载

有效用例模式

2008年05月22日 4.14MB 下载

有效用例模式part2

2010年04月06日 443KB 下载

编写有效用例----------

2009年10月14日 18.68MB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭