《编写有效用例》阅读笔记之一

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)

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

时间: 2024-12-25 21:41:48

《编写有效用例》阅读笔记之一的相关文章

软件工程书籍阅读计划——《梦断代码》

我选择的书籍<梦断代码>: 我计划在1—5周内认真的阅读这本书,本书共有12章,我将其分为三部分进行阅读 第一部分: 0—2章         阅读时间 3.5—3.12日,并在阅读完后发表阅读笔记 第二部分: 3—9章         阅读时间 3.13—3.27日,并在阅读完后发表阅读笔记 第三部分: 10—11章         阅读时间 3.28—4.4日,并在阅读完后发表阅读笔记 期间阅读计划可能稍有改变,但是不会落下阅读,并根据阅读进度和感想,不定时发表阅读笔记

一名在校学生关于阅读书籍《梦断代码》的美好计划

由于专业知识的需求以及专业技能的养成,在今后的一个月中计划完成<梦断代码>这本书的精心阅读,希望可以获得一定知识,进一步激发对软件开发的兴趣. 本书从第0章开始到第11章,一共12章节的内容,计划四周时间看完,每周三章节的内容: 第一个星期:0-2章 第二个星期:3-5章 第三个星期:6-8章 第四个星期:9-11章 最后完成对整本书的阅读,进一步整体把握.期间,在每一个阅读阶段,也就是每个星期的周末都要发表该阶段的读书感受以方便总结. 希望自己能严格遵循计划,不拖拉,不应付,能够通过阅读得到

阅读计划----《梦断代码》1

记得最初看这本书的名字时就想到了电影<魂断蓝桥>,那是个经典的悲剧,不知不觉便也觉得这本书充满了悲剧色彩.大致来说,是记录了一群牛人一起开发邮件,结果经历了三年苦苦探究,却以失败告终.这本书的简介上说:软件是人类自己创造的,也是人们自以为最有把握,实则最难掌控的技术.本书作者罗森伯格对Chandler项目进行田野调查,跟踪经年,试图借由Chandler的开发过程揭示软件开发中的一些根本性大问题.本书是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.任何一个在软件领

阅读计划---《梦断代码》2

这是说一群人们怀抱着改变世界的理想上路了,却在追寻时发现,那些近在眼前的理想之峰,变得那么的遥不可及:每当翻过一座横亘在面前的山峰时,总以为已经来到理想之峰的脚下,却发现这又是另一座需要攀越克服的阻隔之峰.软件开发过程有时就是这样的一种体验,目标看是唾手可得,却又总是在你伸手摘取时,发现还有一段距离要走,问题随着开发的深入而不断涌现:这就像是坐在大象背上的训象师,用吊在大象鼻子前的香蕉,给大象耍的把戏.是什么原因,导致软件开发有时会进入这样一个令人惋叹的黑洞?书的作者没有,也不可能给我们一个答案

阅读计划---《梦断代码》3

计算机严格的逻辑性和精确性,同人类不严密的逻辑,模糊多变的思维模式之间的矛盾,造成的人与机器之间沟通的障碍.      开发团队之间相互沟通协作的成本,导致产生<人月神话>作者布鲁克斯法则的悖论-往已延误的项目中补充人力,只会使其继续延误.      项目目标不明确,标靶变来变去,因此有时决定说什么,比怎么说更困难.      项目目标不切实际,从一开始就想做一个适合所有人的,能做所有事的系统,造成就如要做永动机一样的结局.

01梦断代码阅读笔记之一

在看完构建之法之后,我又开始了梦断代码的阅读. 在梦断代码的第0章就写作者从15岁的玩游戏,但是对于当时的他来说,并不是在沉迷于游戏,而是为了做到打补丁.使得自己的少年的梦想得到浇筑.其实他的做法正应该体现在我们现在学习软件人的身上,我们现在就应该学会怎样的去做自己的梦想,更重要的是练习自己对于软件的好奇心以及热爱,在作者40岁的时候,我们体现的又是另一种的感觉,其实他们和我们没有差别,就像我们在做一个软件的时候,我们在到达最后的期限的时候,其实在哪个时候我们才发现我们什么都没有做出来,问自己为

梦断代码阅读笔记有感之二

08梦断代码阅读笔记有感之二 在梦断代码的一开始我们就学会了如何去写代码,如何成功的去做一个软件工程师. 在现在人的严重,也许软件工程师写出的代码只是让人在玩游戏,在用一些简单的用代码写出的软件.只是认为工程师在不断地重复着一个动作:写代码.但我只能说你们大错特错,就像在文章中说的那样,其实软件工程师是在:“改变世界”,他们利用他们的手用键盘在电脑上打出一行一行的代码,程序产生了,一个新的软件也就产生了.而且,众所周知的,工程师做一个软件,总是在无限制的更新他的内容,让我们的软件更加的先进化,就

梦断代码阅读笔记有感之三

09梦断代码阅读笔记之三 这是最后一篇的阅读笔记,我发现时间真的过的好快好快. 想想以前,我们总是在应付一切的差事,但是真正的到最后,我们才发现,到最后吃亏的还是我们自己. 从前的我们,我们总是对自己大脑中的东西一片一片的特别的混乱.其实我们就像作者所说的,我们就像放任胡乱的cd随地的乱放,到最后不知道哪是哪.我们应该学会分类去放置,例如:我们可以根据歌唱者的名字,音乐的类型等等,其实这些东西对于我们写代码也同样的试用,刚开始的上大一时候,我们第一次的学习C++,我们只是随时随地的在写代码,并不

《梦断代码》第0章阅读笔记

通过对<梦断代码>的初步阅读,感觉以前订的阅读计划似乎并不能满足笔记的需要,因为就第0章便让我感到书中有很多话值得我去记下来,无论是将来工作或者生活或许都有点用处吧. 就像作者说的书是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.读完第0章书给我的感觉没有了课本上的枯燥,有了我喜欢的故事情节,让我了解了一个程序员的真实生活与成长.第0章作为编过程的我们或许已经想到为啥不从第一章开始了吧,因为我们要记住从0开始计数. 兴趣很重要!Sumer或许就是让主角爱上编程的

梦断代码阅读笔记之一

最近阅读了罗森伯格的<梦断代码>,算是近距离观察了十几年前软件开发的状态.这本书是作者对OSAF主持的Chandler项目进行田野调查  而写的一本书.本书是在讲一事,也是在讲百千事:是写一软件,也是在写千百软件.在描述Chandler项目的过程当中亦提出了很多观点,带给我们很多思考.让我们这些软件工程专业的学生对软件开发有了一个更深层次的认知. 在本书第一章,作者为我们介绍了一个布鲁克斯法则:"往已延误的项目里补充人力,只会使其继续延误". 布鲁克斯曾是IBM的资深程序经