实际如何编写用例

每个开发组都应该形成并制定了一套工作习惯。下面将介绍一种我比较欣赏的工作方式一分工合作过程，它是我最推崇的工作方式。AndyKraus，当时在IBM工作，非常清晰地描述了他的开发组与大量不同的用户组协同工作的经验。相信你能从这份报告中得到一些有用的启示。

分工合作过程
开发组与个人相比，有两个优点:第一，便于集中讨论;第二，便于对研究的问题达成共识。然而分开工作却能编写更多文件。基于这个原因，我比较喜欢的过程是:当需要集中研讨或对问题形成共识时，让开发人员以整个组的方式工作，其余时间则一个或两个人一起工作。下面是整个过程，首先是大纲，然后是详细说明。
1.制定一份粗略系统功能图:

• 对系统采用叙述达成共识(开发组);
• 对应用领域达成共识，并集中讨论系统主执行者和系统目标(开发组);
• 编写系统描述(个人);
• 收集各种系统描述(开发组)。

2.制定详细的用例视图:

• 集中研讨用例编写(开发组);
• 对用例编写格式达成共识(开发组);
• 编写用例(个人);
• 审核用例(个人);
• 审核用例(开发组)。

第1阶段:制定粗略的系统功能图第1阶段分4个步骤完成。
第1步 对系统采用的叙述达成共识(开发组)

整个开发组聚在一起弄清楚系统应该描述什么及怎样对系统进行描述。首先，每个人写一份系统叙述，内容可能相同，也可能不同。然后，开发组阅读并讨论这些系统描述，对应该描述什么、怎样描述及其长度，以及哪些细节应包含、哪些细节不需要包括等达成一致。这可能需要花数小时。最后，整个开发组对要构造的系统有一个清晰认识。
第2步 对应用领域达成共识，并集中讨论系统主执行者和系统目标(开发组)
开发组应花费足够的时间找出系统总体目标、范围、主执行者。然后，建立一个直观的描述，一个输入输出列表，一个设计范围图，一个主执行者及项目相关人员列表以及一个最重要的初始用户目标集列表。这些条目都互相关联，因此讨论某项时，可能会牵扯到对其他各项的理解。采用这种方式，可以在同一时间建立起所有条目。如果开发组认为他们已经弄清楚了所要建立的系统，那么这可能会花几个小时到一天时间;如果他们还不知道，则可能需要数天来完成这项工作。最后，要对讨论域的范围、建立什么系统及关键执行者达成共识。

第3步 编写系统描述(个人)
开发组分散工作，分别对系统所需求功能写出使用描述。开发人员单独编写系统描述，然后和一个同伴进行交换，或在一个几个人的小组内传阅，最后把结果送到整个开发组。
第4步 收集各种系统描述(开发组)
开发组共同讨论描述的内容。回答“这是我们想要建立的系统吗?”这个问题，可能会对系统描述进行多次讨论，甚至重新编写系统描述，直到开发组成员都认为系统叙述正好描述了他们想要的系统。
到此为止，第1阶段工作完成，团队应向每个投资方发送一份系统叙述，它显示新系统草图(低精度)，应该包括如下各项:

• 系统构想陈述
• 列出哪些在领域中和哪些不在领域中(包括功能和设计范围)
• 在执行环境中的系统草图
• 关键的主执行者列表
• 项目相关人员及其相关利益列表
• 最重要用户目标列表
• 系统描述集(至少半页)

第2阶段:制定详细用例视图
第2阶段分五个步骤完成。
第1步 集中研讨用例编写(开发组)
首先提出一份需要编写的用例详细列表。然后，列出在系统生命周期中可能遇到的主执行者，以及所有能够想到的针对主执行者的用户目标。由开发组采用适当技术对其审核、集中讨论。当然也可以分组进行这步工作。
处理庞大的、不同种类开发组的一个有用技术是将它分成3到4人的工作小组。通常，系统有几个领域或兴趣组，每个组都需要用到相关知识，因此，工作小组应至少从每个领域组中抽取一人，使得每个工作小组都包含讨论所需的各方面知识，也便于小组成员相互了解。小组比大组行动迅速。同时这种分组方法使得工作小组的讨论能同时覆盖系统多个领域。
如果要采用分组的方法构造所有主执行者和用户目标列表，那么还需要把各小组组织起来同时把各组的结果也汇集起来，作为整体重新对该列表是否能完成和是否能接受，进行评审。最后，开发组将得到一份临时的、所有需要编写的用户目标用例集。当然，随着时间推移，还会发现新的用户目标。
开发组公布主执行者及用户目标列表。与此同时，还可能对用例开发优先级、复杂度评估及开发时间等做一些附加讨论。

第2步 对用例编写格式达成共识(开发组)
这一步中，整个开发组首先一起编写用例样本(或者每个人先编写，然后把每个版本放在一起综合)。开发组讨论用例编写层次和风格、用例模板、项目相关人员及其的利益、最小保证等。到这步结束时，应该形成一个初步的用例编写标准。

第3步 编写用例(个人)
在这个阶段，整个开发组按专业重新分成小组，每个小组由2到4人组成，并为每个专业小组选择用例。
花费几天或数周时间，各小组独自或成对编写用例(我没有发现更大的分组有利于用例的编写工作)。然后在小组内传阅，不断改进草稿直到编写正确。然后编写概要用例。在用例编写过程中，小组成员肯定需要对某些用例分解，创建子功能用例，增加一些主执行者和新的目标等。
在这步工作中，对每个用例指定两个联系人，甚至可以将其中一人指定为主要编写者，这是非常有用的。在编写过程中，会出现很多关于业务规则的问题，这其实是系统真正需求与原来约定之间矛盾造成的。这种工作方式便于一个人回答相关人员对业务规则的询问，同时，另一位人员还能对即将开始的用户界面，以及用户目标是否在正确的层次进行复检。

第4步审核用例(个人)
用例编写人员可以通过电子方式，或直接通过纸面方式，传阅用例草稿。有趣的是，使用纸面方式有特别的好处。因为纸上保留了每个员工的评论，编写者可能只需对用例做一遍编辑，便可集众家之长。一个开发组说，他们曾试图采用在线建议的方法，但是由于用例要进行反复修改，根据一个人的建议修改后，还需要查看这些修改是否满足其他人的建议，因此他们放弃了这种方式。但无论在任何情况下，传阅用例草稿的双方都应该对用例编写层次和业务规则进行检查。编写者把用例发送给系统开发人员和系统应用专家进行审核。技术人员确定用例是否包含实现所需要的各种细节(数据描述和用户界面设计除外)，应用专家应确定系统需求是否确实如此，以及业务过程是否真正以这种方式工作。
第5步 审核用例(开发组)
最后对用例应该有一个开发组对用例进行审核，软件设计人员、业务专家、应用专家、用户界面设计人员都参加审核。用例编写完成后，开发组根据项目以及项目的审核政策和审核机制建立一个他们认为最好的用例草稿。编写者应确保每一步都是可理解的、正确的，并且足够详细便于实现。所有这些工作可以通过正式审核、非正式审核、用户审核及开发人员审核来进行。
一旦系统用例草稿通过了用户和技术专家详细检查，用例就达到了第一个正式的基本要求，然后开始系统设计。此后对用例的修改应只限于修复错误，而不应该改变用例的表达形式。
很快就会看到编写用例草稿和完成用例之间的差别，在完成用例编写时，编者应该:

• 指定所有扩展条件
• 仔细考虑业务策略与失败处理的联系
• 验证对项目相关人员利益的保护
• 验证用例是否仅描述了实际需要的所有需求
• 确保每个用例对用户和应用专家是可读的，以及开发人员清楚地知道所要实现的系统。