关于用例的理解和疑问

[showerXP]

先发表一下我对用例的理解。用例能对参与者提供一定的功能。他是站在参与者角度的。用例是分析功能性需求的好手。而很大一部分系统都是以解决功能性需求为核心。用例也是系统开发的驱动力。本人还认为，如果用例编写的足够细致，在测试阶段也可以用来作为系统功能是否实现的准则。
系统开发人员依次是系统分析人员，设计人员，用例说明人员，用户界面设计人员，coder。他们都是使用用例，是捕获，分析，精化，设计需求的阶段。到最后coder拿到用例实现（包括类图，时序图或者协作图等）实施。当然，实际上一个人可以兼顾几个角色，但是总是有这几个角色所起的作用所在。

我的疑问：
如何编写有效用例？
我看过一本书，他的观点：用例是精确的反应系统功能片断。如果真要是“精确”的反应，那整个需求分析过程就是灾难。可要是大概的描述一下，能捕获需求吗？这个问题可能还是用例粒度问题。

比如：
用例1：浏览页面
主执行者：浏览者
范围：公司业务运作
层次：业务概要
前置条件：浏览者打开浏览器，进入到网站任何一个页面
触发事件：通过链接或直接进入网站
主成功场景：
1.系统识别访问者身份，并根据身份显示页面
2.浏览者根据自己的爱好和需要浏览页面，点击链接
3.系统根据用户要求显示页面
4.浏览者购买书籍
说明一下，这个系统是类似www.china-pub.com的网站。这里引用了一小段，只做讨论之用，并没有其他什么意思，希望原作者不要见怪。

首先我觉得“浏览页面”不是一个有效用例。
“1.系统识别访问者身份，并根据身份显示页面”。其中“显示页面”包括什么，应该是该用例提供给浏览着一个信息列表吧。具体地说应该是该用例向浏览着提供一类书籍的列表。
“2.浏览者根据自己的爱好和需要浏览页面，点击链接”。前面半句可以完全不需要，或者说不是系统关心，解决的问题。“浏览者根据自己的爱好和需要浏览页面”这个应该是参与者的行为，不在用例的范围内。“链接”又是一个什么呢？这里不能精确的说明，会有歧义。
最后一点不在该用例的范围之内。

[许野平]

showerXP(小阿！) :

用户在看到可以运行的程序后会发现自己对软件系统了解更深入了，于是还会要我们做得更好。这就导致需求在交付代码后还会变化。因此，尽可能早地让用户接触到可运行的实际系统。

一般，用户只对可以实际运行的程序感兴趣，而不会对书面文档感兴趣。

RUP中里程碑的概念就是基于这样一种策略，每开发一个增量，都要保证系统能够运行。

我仍主张不要把大量精力放在编写详尽的用例方面，只要相关人员能够正确理解需求，应该尽可能早地编写代码。当然这应当以增量开发模式为前提，先开发最关键的部分，然后是次要的部分等等。

我曾经做过两份非常详尽的用例，结果表明，除了数据流图和工作流程图外，其它数百页的用例说明简直就是垃圾。在项目开始阶段提供详尽的用例除了能导致工程延期数月外，几乎得不到任何好处。比较一下完工后的软件系统和最初的需求，会发现最初的想法早已经面目全非。

[许野平]

theoldsod2000(蝈蝈) :“用例是用来获取用户需求的方法。我们同样可以用其他方法获取用户需求。用例驱动说到底是需求驱动。使用用例不能为用例而用例。”

这句话有些画龙点睛！

需求也好，用例也好，最终目标就是要让用户知道他将要得到的软件是什么样子。问题的关键是如何用较小的代价达到这个目标。

在许多企业你都会发现产品的生产速度比设计速度还快。有些定制的产品，图纸还没设计出来，用户就已经把货提走了。编写程序也是这样，如果编写用例耗费掉的时间过多，还不如直接编写程序合算。

记得有一个投标项目，我花费了一个月的时间编写了一套演示程序，在投标方案答辩的时候用投影仪给用户演示，用户很喜欢。其实许多情况下编写可以演示的软件原型比任何纸上谈兵的用例都有效。

用力尽可能地简单粗略，够用就行了，千万别多费笔墨，否则就像打太极拳一样，效率太低了。

[laypeople]

严重同意quicmous(快鼠)同志在俺这个回复之前的所有观点，quicmous(快鼠)同志的言论表现出一个真正有经验、真正理解软件开发中“方法”和“目的”之间的关系的观点。俺以为，无论在什么时候，方法都是为目的服务的。在条件允许的情况，俺觉得：构建原型->交付、反馈、修正（里程碑）->增量构建->交付、反馈、修正（里程碑）这样的循环方式是相对高效和低成本的，在条件不允许的情况下（客户参与较少），则每次的构建量相对就要大一些，因此项目能否按照计划健康进行要更多的依赖于调研、分析人员对客户的需求理解能力和经验，呵呵，即便是条件很好，用户积极参与，每次的原型构建/增量构建后，循环的下一个过程：“修正”的工作量多少，同样依赖于调研、分析人员的需求理解能力和经验。

俺外行人以为，使用“用例”来精确反映系统功能是一个美好的愿望，至于为什么仅仅是愿望，要打的字太多了，嘿嘿，另外quicmous(快鼠)同志也说过了，至于“用例”所表达的信息产生歧义仿佛似乎大概也是不可避免的，只能努力的减少歧义。幻想用户能够通过用例图理解你想给他做什么，好像很难，期望不沟通就能够让开发人员“正确”的理解分析员画的用例图似乎也很难，并且大概是非常冒险的，熟悉哲学的人一定知道曾有人提出该创造一种称之为“元语言”的东东，用以无二义性的描述一切，但是最终发现，这种“元语言”的复杂度趋近于无穷大，因而这个“伟大的创意”破灭了。

俺举个小的例子玩，大伙有兴趣，针对这个小例子中出现的现象，发表发表观点，比如谈谈责任归谁，是否可以避免这类问题，不要大话空话，俺听不懂，欢迎用实在话说说。

需求调研会上，用户要求A窗体内的“时间”数据可以修改并可以保存，调研人员追问：“在这个窗体上，是否有其他的功能要求呢？”用户发誓：“俺向耶稣大哥保证，肯定没有了！”然后分析员拿到调研记录后，增加了一个“查询”功能，因为分析员的分析结果表明，这个A窗体的目标数据随时间膨胀，一年以后将达到20000条，没有查询功能，很难定位要修改的记录上，开发人员拿着需求说明书去开发了。开发完成拿着成果交付用户，用户试用3个月后，客户服务人员被叫去了现场，用户暴跳如雷：“我每天使用这个破功能20多次，每次要修改几百条记录（并且还在递增），要修改的仅仅是一个‘时间’字段，并且99%的时候是把一批记录修改为同一个‘时间’值，你们‘朱’（这个带引号的字是某种以肥胖和不聪明著称的动物，这地方好像不让写原字，嘿嘿，俺只好变通）啊？怎么不给提供一个批量修改功能？”客户服务人员安抚完客户，哭着去找调研人员，并对其一顿狂骂，并将用户免费赠送的“朱”（还是动物）这个高级职称送予调研人员，调研人员心里特委屈，哭着去找客户，拿出当时调研的录音，客户听完录音后，再次暴跳如雷（这次跳的更高）：“这个是秃子头上的虱子——明摆着的功能需求，你们还真够‘朱’（这个带引号的字还是那种以肥胖和不聪明著称的动物）的，这很明显是每次都需要批量修改的嘛，我没说你们就不作？我要是什么都说了，要你们的系统分析员干嘛吃的？”客户服务人员和调研人员一起哭着去找系统分析员：“这么明显的功能需求你咋没分析出来呢？你这只‘朱’（这个带引号的字也是那种以肥胖和不聪明著称的动物）！！”系统分析员也哭了，骂调研人员：“这能怪我吗，你调研的结果里从来没说这里的数据一般都是维护成同一个值啊？我怕无法快速定位到要维护的数据，还特意增加了‘查询’功能啊！我容易吗我！！！”三人互相对望，抱头痛哭。

[michaelleebj]

写得很详细当然是好，但是老板会给你时间吗？

[showerXP]

还是从up说起吧。
up分四个阶段：初始、细化、构造、移交。初始就是我上面说的建立软件系统的可行性，编写业务用例，编写10%得系统用例，确定关键任务。细化是构造系统基线，进一步分析、设计系统，实现80%系统用例。构造的目标是完成所有的需求、分析、设计。移交阶段进行测试，完成最终的部署。
每一个阶段都可以分五个工作流迭代开发。这五个工作流：需求、分析、设计、实施、测试。但是，每一个阶段的工作流焦点是不一样的。从上面可以看出，90%的用例是在初始、细化阶段完成的。所以，一个系统大体上还是要在需求和分析之后再作设计。

quicmous(快鼠) ：
“用户在看到可以运行的程序后会发现自己对软件系统了解更深入了，于是还会要我们做得更好。这就导致需求在交付代码后还会变化。因此，尽可能早地让用户接触到可运行的实际系统。”
其实，你说的这个东西应该是“概念证实原型”，的确，我们可以在初始阶段做。这个原型的目的也是验证我们做的重点需求是否符合业务用例的业务执行者（business actor）的“胃口”。另一个目的是确定10%的系统用例。
“我曾经做过两份非常详尽的用例，结果表明，除了数据流图和工作流程图外，其它数百页的用例说明简直就是垃圾。在项目开始阶段提供详尽的用例除了能导致工程延期数月外，几乎得不到任何好处。比较一下完工后的软件系统和最初的需求，会发现最初的想法早已经面目全非。”
这种情况的根本原因是初始阶段工作没有做好，导致细化阶段的需求、分析工作产生严重“偏差”。

laypeople(外行)：
“构建原型->交付、反馈、修正（里程碑）->增量构建->交付、反馈、修正（里程碑）”。你这种方法可能可行。不过如果你的“修正”由于需求、分析不正确导致“原型”彻底推翻的话，你所说的“迭代”将不会收敛。这种风险是非常大。
还有，关于大哥你说的这个例子我发表一点自己的看法。
导致这个问题的发生是因为没有充分的考虑到涉众人员的需求。90%的需求是在初始、细化阶段完成的，剩下的10%中大部分是在移交阶段完成。的确，这种需求很难捕获。但是，这种需求应该不是系统的关键需求。换句话说，如果做好了初始、细化阶段的工作，解决移交中出现的问题代价是很低的（从你的例子来看，解决起来的确不难）。但是，如果初始和细化阶段没有做好，移交的时候很可能出现“牵一发而动全身”的情况。这样导致系统的维护，运行成本极大的提高。

最后，用例不光是捕获功能性需求，同时也是up的驱动力。用例还可以做成一种规范化文档，使得后续工作能按部就班的进行。所以我才对用例这么特别的关心。
欢迎大家继续讨论。

[showerXP]

再一次申明我的观点：
在做系统用例之前其实还有一步业务用例的过程。业务用例说明的业务即使没有软件系统存在也是需要做的。做完业务用例以后，根据愿景（风险，成本，技术力量，工期什么的）来确定系统目标（边界）。做业务用例之前要和客户、涉众充分沟通，获得素材。业务用例由素材组成，但不是每一个素材都用得上。

一个业务模型引进一套软件系统，总是期望能解放生产力、提高工作效率。一套软件系统的引进能给业务模型带来什么程度的“自动化”呢？显然不可能做到解决方方面面的问题的“完美软件系统”。
业务用例的分析是一个和涉众人员（注意不是参与者）充分交流获取素材后，根据愿景，确定系统边界的过程。

[许野平]

showerXP(小阿！) :

(1)“用例不光是捕获功能性需求，同时也是up的驱动力。”

所谓用例是UP的驱动力，俺的理解是，用例必须和分析、设计等过程保持逻辑的一致性。

但是，一套正确用例的产生不仅依赖需求，同时还依赖分析、设计等阶段的工作。这就是俺在楼上讲的逻辑顺序和实践顺序的关系问题。

(2)“用例还可以做成一种规范化文档，使得后续工作能按部就班的进行。”

同样道理，用例和后续工作并不存在一个时间上的分界线。在后续工作中修改用例是根本就不能避免的事情。

当然，任何阶段的工作俺都同意做成某种程度规范化（够用即可）文档的观点。

(3)俺的一点体会：

软件工程的基本原理基本上五年级的小学生都能理解，关键在于面对不可预期的未知数如何实践。改编一句名言：

“成功的项目都是相似的，失败的项目各有各的不幸！”

[许野平]

showerXP(小阿！) :“ 这种情况的根本原因是初始阶段工作没有做好，导致细化阶段的需求、分析工作产生严重“偏差”。”

问题就出在这个地方。如果亲自实践一下就会发现，提供一个和最终程序之间偏差很小的需求说明比写程序还难。需求不是一个独立的过程，它需要综合用户要求、设计模型甚至具体编码实现等多种因素。

即便是在RUP的初始阶段，需求、分析、设计、编码、部署等工作都需要并行进行，这些任务之间在逻辑上看上去有因果关系，但是在他们的实际编制过程中却没有因果关系，而是互相参考、权衡、折衷后得到在逻辑上一致的结果。RUP循环迭代的概念，本质上讲就是这么回事。

如果我们真的认为需求可以导出分析、分析可以导出设计、设计可以导出编码等，那就陷入传统的瀑布模式。弊端就不需多讲了。

因此，不要把软件过程中逻辑上的因果顺序和实践中的过程顺序混淆。

[许野平]

showerXP(小阿！) :

（1）

其实大家大部分观点并不矛盾，有些歧义发生在对文字的理解方面。也正是文字描述容易产生歧义，我才坚持在非编程的阶段尽量少用文字描述一些规格说明，而宁愿采用原型的方法表达一些概念。

用例是否需要写，写到什么程度，完全取决于花费的代价是否合理。如果不写详细用例一样能把代码写正确，那么详细的用例就是多余的。如果编写代码用的时间小于编写用例的时间，那么编写用例是不合算的。

有位专家对我讲，一个合格的用例说明必须把界面规格用像素的精度描述出来，笑得我牙都快掉了。真不知道可视化界面开发工具是帮我们写代码的还是帮我们写用例的。

（2）

“用例必须和分析、设计等过程保持逻辑的一致性。”这句话如果我改写成“用例、分析、设计等过程必须保持逻辑的一致性。”恐怕我们就没有分歧了。在我的思维习惯里，“和”这个连词是满足交换律的，显然老兄理解成了其它意思，这也可以算是一个语言歧义的例子吧。

我这样讲是为了表明用例在思维过程中不一定是前提条件，但在最后的表述中的确是分析与设计的逻辑前提。

我自己的习惯是在与客户交流之后会首先想想系统的样子和实现方法，甚至编写DEMO程序。一切认为都OK了，才会编写需求规格说明（可能包括用例）让用户确认。最后写出的报告好像是先有了用例，然后通过严谨的推理过程导出设计方案，给人造成假象。

记得有一次用户让我去某单位参观，回来后让我们仿照人家的系统编写一个程序。后来哪个单位的人知道了这件事，认为我们剽窃了他们的成果，要打官司。结果一看，我们的程序的设计方案是他们做梦都想不到的，根本不是一个级别上的东西，这才罢了。

正因为这样，俺才一贯坚持系统需求（包括用例）是一个发现和发明的过程，而不仅仅是一个调查过程。在逻辑上需求是前提条件，在实际过程中，往往是许多因素相互影响的一个合理的结果。把需求仅仅看作用户的要求，然后由此驱动后面的一切，未免太简单化了。

--- ---

无论怎样，感谢老兄开这个话题，让大伙能有机会交流！

[laypeople]

“系统需求（包括用例）是一个发现和发明的过程，而不仅仅是一个调查过程。在逻辑上需求是前提条件，在实际过程中，往往是许多因素相互影响的一个合理的结果。”冲这个结论，俺外行人就忍不住想武断一下，嘿嘿，quicmous(快鼠)同志大概比较资深。

BTW：这个结论，又让俺狠狠同意了一把。

PS：quicmous(快鼠)同志的快。。。咳咳，仿佛是快在了打字上，真勤劳。8-O~~

[showerXP]

首先，我并没有说“在构造、移交阶段不需要需求、分析、设计等工作流”，事实上“迭代”是说明在各个阶段都有五个工作流。我在上文已经说过“ 每一个阶段都可以分五个工作流迭代开发”。我的观点是“术业有专攻”，需求、分析是初始、细化的主要工作流。同时，初始和细化应该完成90%需求和大部分的分析。我也同意在后面阶段要修改用例的事实，但是绝对不是“主流”，绝对不能是大刀阔斧的整体上修改用例。

showerXP(小阿！) :“ 这种情况的根本原因是初始阶段工作没有做好，导致细化阶段的需求、分析工作产生严重“偏差”。”

问题就出在这个地方。如果亲自实践一下就会发现，提供一个和最终程序之间偏差很小的需求说明比写程序还难。需求不是一个独立的过程，它需要综合用户要求、设计模型甚至具体编码实现等多种因素。
这个应该是初始阶段，业务用例出了问题，导致系统定义模糊。你所述和我的观点并不矛盾。相反，更能证明我的观点

“用例必须和分析、设计等过程保持逻辑的一致性。”这个我倒是和你截然相反，“分析、设计等必须和用例保持逻辑的一致性”。

真理向前一小步就是谬论。但是人类总是最求真理，不是因为怕这“一小步”而在原地“中庸”起来。

[thinkforever]

大家真有耐性码字，《软件需求》这本书讲的很清楚。

[showerXP]

"码字"我也是最近才学会，主要是提高自己表词达意的能力。

感谢quicmous(快鼠)同志的精彩解惑。即将揭帖。

[laypeople]

哈哈哈，俺PS那段可纯粹是玩笑，外行人说话就是扯皮含量大，诸位内行勿怪。

[许野平]

laypeople(外行) ,thinkforever(), showerXP(小阿！) :

呵呵，看来我是有点喜欢“码字”。在用例的问题上偶也困惑了很长时间，很多感受也是吃了亏才有的。很多问题俺还在继续探讨，有机会多交流吧！

[cnepine]

我们使用模型是用来理解系统的。

但是大型的系统的离开模型是无法理解。

[syspring]

to quicmous(快鼠)

请问能把你的qq或邮箱告知一下，有问题请教于你啊。
我的qq:340493924
email:[e-mail]

[许野平]

to syspring(和风细雨) :
俺的邮箱：[e-mail]

[ph0enix]

这一个例子叫你们辩论了这么多,可是关于楼主的一个问题仍没有解决.

能不能说点实在的?光是理论理论的,你们就没有烦的时候??

[rolt]

需求到底是如何，只有涉众才能给出答案

这个“寻找最佳击球点”的过程是需求过程里最难的。

用例只是把同源的需求用“价值”封装起来

如果该系统是firefox，“浏览页面”作为一个用例可能是合适的

另外，步骤要把交互清楚地表明出来

http://www.umlchina.net/training/umlchina_1.pdf，http://www.umlchina.net/training/umlchina_2.pdf