《编写有效用例》

1、完整正式的用例格式:(1)单列文字(不是一个表格)(2)步骤编号(3)没有条件语句(4)扩展部分的编号规则是数字和字母的组合

完整正式的用例模板<名字>

<用例名应该是一个用主动语态动词短语来表示的用例目标>

使用语境<目标较长的描述,如果需要,还包括触发事件>

范围<设计范围,在设计时将系统作为一个黑盒来考虑>

级别<概要、用户目标、子功能三者之一>

主执行者<主执行这的角色名称或主执行者的描述>

项目相关人员和利益<用例中项目相关人员和关键利益的列表>

前置条件<我们所希望的,周围环境已经达到的状态>

最小保证<在所有退出操作前,如何保证得到必须的信息>

成功保证<目标完成时环境的状态>

触发事件<什么引发了用例,可能是时间事件>

主成功场景

<在这里写出从触发事件到目标完成以及清楚的步骤>

<步骤编号#><动作描述>

扩展

<在这里写出扩展,每次写一个扩展,每一个扩展都指向主场景中的特定步骤>

<被改变步骤><条件>:<动作或子用例>

<被改变步骤><条件>:<动作或子用例>

技术和数据变化列表

<在这里写出场景中因技术或数据变化而引起的可能分支>

<步骤或变化编号#><变化列表>

<步骤或变化编号#><变化列表>

相关信息

<项目所需要的所有附加信息>

2、图形符号有两个可用性方面的问题,第一,最终用户和业务执行者不可能熟悉这些符号,也不会有耐心来学习这些符号;第二,图形不能完全表示你所需要的意思。用例本身就是文字的,任何图形都只是为了帮助读者找到他们所要阅读的文字。

3、影响用例书写格式的因素

1)矛盾的因素:业务环境、社会作用、不同文化

这个列为第一因素真的不为过,特别在中国,地大物博,很多项目可能是北方公司的人到南方做项目,文化背景不同,语言也不是很一致,这个会直接影响需求获取的精确度

2)理解层次

本来开发人员和业务人员就存在理解层次不一致的问题,开发人员没业务人员懂业务知识,业务人员没开发人员懂软件开发知识,所以要降低这个因素的影响必须找到一个共同的具有标准格式的“语言”(如通用的用例格式)和很好的分工与协作方式。

3)项目相关人员的要求

每个涉众(即项目相关人员)都有自己关心的方面,所以他们的要求也不相同,所谓众口难调,在这里体现的淋漓尽致。

4)经验与格式

5)覆盖面

6)一致性

7)复杂度

8)完整性

9)目标与任务——完成什么与怎样完成

10)资源

11)其他因素

存在着这么多因素,所以需求调研就不能以一种固定的模式推广,只能在一个比较大的框架上,通过调研人员发挥主观能动性与涉众一起完成需求的调研,但这些因素是提醒人们在需求调研过程中应该注意的问题。

4、五种项目类型的标准,五种情况:

1)了解需求,甚至包括用例根本不在最后的需求文档中使用的情况(模板见p108)

你的用例通常作为一个黑盒,大多数都是用户目标级别。你可以用一个较高层的用例来描述语境,但是你最好不要经常使用海平面级别以下的用例。

2)业务过程建模(模板见p108)

阅读这些用例的人往往是一些高层人员、部门经理和高级执行官,因此尽量使这些用例可读性强,减少细节的内容。步骤的编号突出了活动的时间顺序。一定要在扩展中描述错误的处理,这样才能揭示重要的业务规则。

3)设计和量化系统需求(模板见p109)

当你为估计系统大小和结构而分析需求时,使用这个模板。以后,你可以细化需求知道完成这个完整的用例。

4)在一个短期、高强度的项目中编写功能需求(模板见p110)

由于时间和经济的原因,需要避免编码的开销和编写完整模板;因此你可以使用非正式的格式。但你还是必须了解前置条件、保证条件和扩展。

5)在一个长期、大型项目中,在增量式开发开始时编写详细的功能需求。(模板见p110)

当你收集行为需求,并且需要完整正式的用例格式中的所有信息时,可以使用上述模板。这种模板可能应用在大型、关键、昂贵的项目中;或者应用在有固定预算的项目中;或者应用在开发组分步在不用地方,在增量式开发的开始阶段需要扩充和检查以前设计的量化用例时;或者这样做时你的习惯(最后一句有意思,呵呵,“我就是喜欢”

 

这一章其实是总结这本书第一部分,把之前10章所阐述的用例体各个部分汇总起来,然后根据不用的项目提出不同的用例模板,这样是科学的,因为每个项目都不同,不能用一种不变的用例格式来对付,要因项目而异。到这章为止,这本书的第一部分——用例体部分,已经结束,通过仔细阅读这十一章,使我更深入的了解了用例,结合以前做的项目,发现以前写的用例很多问题都没有考虑到,在以后的项目的需求调研中,我把这本书所强调的一些观点运用到调研中去

你可能感兴趣的:(《编写有效用例》)