在此 Rational Edge 文章系列的第1部分，作者分析了不同的用例和工件类型，并简要地讨论了如何将用例技术引入到一个不熟悉它们的团队。

　用例技术是一种越来越流行的捕获需求和驱动系统开发的方法。这种技术的新采用者面临的挑战是如何将此技术引入到一个组织，以及如何确定用例何时完成。通常，他们必须在实际的项目压力之下面对这些挑战。本文的目标就是概述这些原理，帮助他们战胜这些挑战。在第1部分，我们将分析不同的用例和工件类型，并简要讨论如何将用例技术引入到一个不熟悉它们的团队。

在本系列中，我们将通过一个假定的案例研究来进行我们的具体讨论，在这个案例中，一个积极热心的分析师和她的CATLYST项目团队的其他成员使用用例开始了一段新的旅程。你们中那些读过 Rational Edge 的 2003 年 1 月期中“一个新的RUP经理的真实故事”的人，将会认出我们的虚拟团队的扮演者。第2部分将会跟踪这个项目的执行，并突出这些原理是如何应用的。

Smith，是一个经验丰富的项目经理，他刚刚成功地交付了项目REALITY-J，正坐在他的小卧室中，这时，一名高级团队成员，Harriet，轻轻地敲了敲他门口的钢门。Harriet已经被分到另一个项目作分析师，并且在收集项目需求方面需要得到帮助，特别是在使用用例方面。了解到Smith有使用用例的实践经验，她想到找他寻求建议。

“我们正打算开始一个叫CATALYST的新项目。”她解释道。“它的目标为一个国际连锁酒店提供增值服务，并解决他们的记账问题。我们的团队在用例技术方面参差不齐。你能给我一些有关如何进行的提示吗？”

需求领导能力是关键的
“你的团队有一个主设计师吗？”Smith问。

你说的主设计师是指的什么呢？“Harriet 回答道。

”如果你的团队成员在有关如何引导需求管理过程上有不同的想法，并且有不同的文档化和组织需求的方式，那么谁来进行最后的发言呢？“Smith问道。

”我不知道，我认为我不是一个主分析师。我在REALITY-J的时侯，我只是看到了所应用的用例，但是你写了大多数用例。我只是你的用例的一个用户。目前在我们的团队中，我们已经有了三个工作成员：Roland，Helen和我自己。我们在项目开始时都承担了分析师角色，然后接下来是团队领导角色。Roland说他有一些使用用例的经验。Helen没有使用用例的经验，但她正在积极地阅读这个主题，我也是这样。Simon是我们的项目经理。我想，如果我们之中要有一些差异的话，他将是做决定的一个人。” Harriet回答道。

“Simon要积极地参与到需求采集－－确定用例，概述它们，等等－－中吗？” Smith问道。

“我认为不是这样。他可能会非常忙于项目的其它方面，并且对用例也相当陌生。我们大概要做这些需求，并且他可能是提出项目进度表的人，等等。” Harriet说道。

“那么，Simon不会有时间做一个主分析师的工作，” Smith说道。 “这是一个问题。如果你的团队没有一个主分析师，每个人都处于风险中。你的团队必须做的第一件事就是确定一个主分析师。” Smith 告诫说。他指出IBM Rational统一过程，? 或 RUP，?在涉及到需求采集过程的两个角色之间进行了一个明确的区分，并且给Harriet展示了RUP中的以下描述：

• 系统分析师。系统分析师角色通过概述系统功能和给系统划定界限，领导和协调需求抽取和用例建模；例如，设置存在哪些角色和用例，以及他们如何进行交互。
• 需求说明者。需求说明者角色通过描述需求的一个或若干个用例以及其它支持性软件需求，来详细说明系统功能的一部分规格说明。需求说明者可能也要负责一个用例包，并维护这个包的完整性。

”简而言之，系统分析师拥有大的景象，而需求说明者工作在详细内容上。“ Smith 解释道，指出 Harriet 的项目既没有一个系统分析师（如RUP所定义的），也没有一个主设计师（如他所定义的）。她的团队需要一个负责人，不仅要协调团队，而且要通过明确描述需求指南来确保一致性。否则，一个需求说明者可能错误地认为另一个人正在编写一个特定区域的需求文档，至关重要的需求区域就可能从缝隙中漏掉。Smith强调的主分析师，在连接隔阂和确保需求完整性方面扮演了一个关键性的角色。

“用户代表也需要一个负责人。否则，你将发现自己处于无休止的争论之中，并迟延将耽搁需求收集过程的决策。”他继续道。“告诉最终用户团队在你们开始工作之前确定这样一个人。一个成功的项目要求在项目一方和最终用户一方都要有强有力的领导能力。”

　需求是一种达到目的的方式
　Smith向Helen笑了笑，Helen已经进到了他的小房间，从旁听到了这个讨论。

Smith知道Harriet是一个完美主义者，喜欢事情都清楚地说到最小的细节，他想帮助她在开始管理需求时采用一种平衡的观点。“她必须避免为了自己的兴趣而集中于文档上，相反，要坚持聚焦在理解问题和获得有关如何解决问题的多数人意见上。”他自己这样认为。因此下一步，他画出了三个重叠椭圆，并标记出一些区域，表示顾客需要什么，哪些将被捕获为需求，以及将最终被交付的系统（参见图1）。

图1：有效捕获需求

　"这三个椭圆表示了你需要跟踪项目进度的框架。"Smith 说道，并在下面继续解释了每一个椭圆。

涉众需求和目标。 系统被构建以满足一定的涉众需求或目标；这些定义了系统要做什么。
描述需求。 在需求采集期间，涉众需求和目标被提取为需求。
系统构建。 系统遵从规定需求进行构建，并验证涉众需求和目标。这样就关闭了椭圆。
“决不要忽略看到这个事实，即需求不只是到结束的一个手段。最终目标是要有一个满足涉众的需求和目标的有益的运转系统。” Smith告诉Harriet道。 然后他增加了一些字母到需求椭圆中的每个区域，如图1所示。

“好吧，让我们试一些小测验。在这些标记字母部分的哪一块发生了活动？”Smith问道。

"很明确，是A部分。"Harriet 回复道。

“是的，A是被识别的涉众需求集，需求是根据它们进行编写的，并且它们表示了已经被构建和验证的系统部分。” Smith 赞同道。

“我认为行动在D部分也发生了。” Helen 提出。

“正是！如果一个系统满足了涉众目标，你是否已经写下了需求就无关紧要了。在一些非常少见的实例中，当每个人都对项目目标有一个非常强的理解时，就已经不需要描述需求了－－或者需求规格说明可以是最小程度的。”

这实际上是让Harriet思考。“你是说，在某些实例中，我们可以忘掉需求？”

"当然不是！但是记住我说需求是到达目标的方法，这是一个有用的系统。" Smith 说道。“需求的主要目的是连接涉众和我们的想法之间的差距，特别是在我们不理解或不同意的区域。”

“我还不确定我是否了解了。这意味着我们应当有更多的会议和更少的文档吗？” Harriet 问道。

“你应当保持会议以取得一致意见，并使用文档来明了已经同意了什么以及还有哪些未解决。” Smith 回答道。

选择合适的技术和工件
　“那么需求的整体思想是保持涉众和我们之间的连续的一致。用例技术如何在这里得到应用呢？” Helen 问道。

“确定业务角色，业务工作人员以及业务用例，还有系统角色和用例，有助于我们阐明系统的目标和范围，以及其满足业务目标的任务。用例规格说明帮助我们阐明角色和系统之间的交互关系。”Smith 回答道。

“根据‘系统应...’格式叙述的传统需求表示方法的关键问题是这些叙述不直接转化为验收测试；这要求一个额外的思考过程。用例通过连接跨越此间隙。“ 他强调说。他继续解释，用例的事件流描述了主角的请求和系统的动作（例如显示处理结果或修改一个系统状态），工作在测试过程中时，这对明确描述测试步骤和验证点是有用的。在早期阶段使用系统验收标准作为抽取和记录需求的一个基础，会给团队成员大量的控制。

需求工件
　”我们的系统有不同种类的需求：用户界面，业务过程，基础结构需求，数据需求，以及接口需求。我们如何在用例中捕捉这些需求呢？”

Smith进行了回答，描述了捕捉除了用例之外的各种不同种类需求的许多关键工件2，如图2所示。

图2： 需求工件概要

• 
• 业务用例模型。 所期望系统的目标经常是要解决业务问题或通过提供增值服务开拓商业机会。业务用例将用例的概念扩展为描述业务过程。业务用例模型（与业务用例规格说明一起）提供了一种评价所期望系统范围的方式－－有些部分可以自动化，有些部分不能，有些部分可以通过更改业务过程来进行。这就允许我们从一种业务观点来评价用例模型的完整性，因为每个系统用例必须支持一个或更多的业务用例。
• 业务实体和领域模型。 大多数系统需要操作和展现业务信息。一个业务实体将一组相关信息字段表示为类。业务实体通过一个业务过程（例如业务用例）被处理和操作，它们接着通过系统用例被自动化。所有业务用例及它们关系的总和组成了领域模型，领域模型描述了问题域。每个系统用例将操作一些实体，并且实体通常被包括在多个系统用例中。
  业务规则。 今天，系统的复杂性通常是由系统必须符合的业务规则的复杂性所导致的结果。业务规则将被业务用例和系统用例来表示，并且可以是各种形式，决策表，计算规则，决策树，时间图（描述哪些事件必须发生在其它事件之前或之后，以及从中产生的过程），运算法则，等等。在用例流中描述业务规则通常会把用例规格弄得混乱。因此，它们通常是在单独的工件中被捕获，或者是作为用例规格的附加物。
• 用户体验模型和情节串连图板 用户体验建模是捕获用户界面需求而不借助于画出屏幕布局的一种便利方式，画出屏幕布局的方式可能要花费巨大的工作量，并且非常可能发生变更。用户体验建模将实际的用户界面屏幕抽象为一个UML类，其原型是?screen?。属性确定了用户在一个屏幕上可以看到什么；操作确定了用户在每个屏幕上可以做什么；并且关联关系确定了航行路线。用户体验情节串连图板是用户体验模型的子集，用于描述与系统用例有关的屏幕。
• 补充规格说明。 补充规格说明描述了影响多个用例的需求。例如，所有用例都服从权限控制，审计跟踪，个性化，等等。补充需求实际上通常是技术方面的，并且可以是关联于功能、可用性、可靠性、性能以及可支持性。它们通常被表示为“系统应做 ...”形式的陈述语句。

　用例类型

　“我如何知道我应当使用这些工件的哪一个？”Harriet问道。

“好，像毛主席所说的：‘不管黑猫或白猫－－只要抓到老鼠就没有差别。’只要这种技术能做这件事情，它就是好的。” Smith 回答道。

“我理解你的意思是什么，尽管我认为这是后来的邓小平所说的话。” Harriet 说。“但是我仍然需要一些一般的指南。”

“让我们通过看一下用例的不同类型来开始吧。” Smith 回答道，并且继续列出了如表1所示的用例类型。

表1：用例类型

　“这是真正有用的。” Harriet说道。“我需要不同的用例规格说明模版来创建不同的工件吗？"

“你可以对所有的工件使用相同的基本用例规格说明模版，如果你用适当的附加描述本来补充它的话。” Smith 回答道。“例如，你可以附加相应的用户体验情节串连图板，参与实体的类图，相关业务规则等等，作为你的用例规格的附加描述。这不意味着每个用例规格说明都需要一个完全的附加描述集；只包括那些会促进理解的附加描述。”

“那么，对你的列表中的用例类型要求哪些工件呢？” Harriet 问道。

“我真的想忍住不作推荐－－以免你们把它们视为上帝的永恒之语。” Smith 说道。“这实际上取决于项目环境。然而，还是有一些明显的。例如，数据维护用例可以很好地通过领域建模来描述，还可能有用户体验建模。我发现领域建模适合于数据分析用例。因为它们是以数据为中心的。请求批准用例可以用业务用例规格来补充，如果它们不是琐细的话。在许多情况下，支付用例需要相当多的业务规则。忠实用例是令人感兴趣的，因为它们将自己插入到了已有用例中。”

“我不能完全回答你的问题。” Smith 继续道。“用例类型更像是用例模式－－设计模式－－但是是在用例级别。你将在你的项目中碰到不同的用例种类，因此尽早地从每个种类中选出一个代表性的用例，用它进行工作。这会帮助你决定需要什么样的书写风格和什么样的附加信息。如果你喜欢的话，我可以帮助你确定在项目开始时的用例模式。”

评价完整性和细节
　“我如何知道我何时已经完成了我的用例？” Harriet问道。

“你必须应用一些参考框架来评价用例模型，例如业务要求，业务领域，等等。然而，直到项目完全结束之后，你的用例才会真正完成，因为你对系统的理解－－以及你的最终用户的理解会随着时间的过去而被改进和发展。这就是为什么你必须增量地和迭代地进行工作。” Smith 回答道。“起先，你会想要集中在每个用例对于要进行的开发是否足够详细。”

“是的，但是我如何知道我已经有了足够的细节？” Harriet 问道。

Smith 通过列出一些标准进行了回答：

• 用例规格说明。基本流和可选流对于开发和测试团队是清晰的和可以理解的，并且已经收到了最终用户的正式批准。
• 业务用例规格说明。 当用例在业务过程中被激活时，规格说明是非常清晰的。团队也已经验证，结果是对业务过程中的步骤有价值的。换句话说，团队已经验证了相对于业务过程的用例中的事件流。
• 业务实体。 所有的将通过已经被细化的用例操作的业务实体，以及它们的属性和子分类已经被定义。子类常常被用于评价事件流的完
• 性和业务规则。例如，预订将是用于预订一个酒店房间的一个实体，但是有三种不同的预订类型：预付款，直接预订，优先预订，等等。这些不同的类型应当按照可选流来对待，并且业务规则也必须考虑它们，例如，通过计算不同预订类型的房间费用。
• 业务规则。要求支持用例的业务规则是清晰的。例如，如果有一个用例是进行一个房间预订，也必须有一个计算规则来确定房间费用。
  用户体验情节串连图板。由用例定义的用户界面所需要的屏幕被识别出来，包括字段和导航路径。
• 补充规格说明。 清楚补充规格说明如何影响用例事件流的。例如，如果用例需要用户身份标识，就必须清楚何时 要求身份标识以及要求什么许可。
  
  “喔！看起来有很多工作！” Harriet 喊道。

“我没有说详细说明需求是容易的，但是就像我先前所说的，需求是到目标－－一个有用的和工作的系统－－的一种方式。” Smith说道。“使用一个表（参见表2）来决定哪个工件对你的项目最有意义。然后，决定你需要用例的多少细节，并使用相同的表来跟踪在采集你所需要信息方面的进度。在表中的每一个单元，指出你是否已经收集了工件的内容和已与用户进行了验证。”

表2：跟踪需求采集过程

　迭代地引入用例技术
　“这要学习那么多东西！” Helen 喊道。

“我同意。我的团队和用户代表不熟悉用例，挑选和选择技术将不太容易。” Harriet 接着说。“我认为我们在培训上也要用大量时间。”

“你们说得对，这是一件复杂的事情。让我看一下你们可以如何应对。” Smith 说。他建议采用如图3所示的三阶段的方法，并继续解释每个阶段。

阶段1：技术研讨会
　阶段2：使用范例和指南进行微小迭代
　阶段3：使用高级技术

　图3：将需求技术引入到一个项目

　技术研讨会
　大多数项目团队在使用需求技术，特别是在用例方面有具有不同程度经验的成员，因此主导一个研讨会来建立你计划使用的需求技术的共同理解是明智的。分析师和最终用户代表都应当参与，因为他们都将参与到文档化需求的编写和评审中。

主持人可以是来自团队内的或是团队外的，只要他或她是知识渊博的人，其专业技能是大家都知道的，并且受人尊重的。主持人在当前项目的环境中讨论需求技术是重要的；否则，讨论将过于抽象。预先提供一些项目信息，即使他或她不是团队的一名成员。

进行微小迭代
　在按照技术研讨会之后，项目团队应对挑选不同的用例类型（参见表1），然后在一个微小迭代中细化、实现和测试它们，这个迭代要努力解决风险。当项目的大多数成员都对用例没有什么经验时，这是非常重要的。通过走过这个微小迭代，项目团队将获得重要技能的第一手经验：

编写有效的用例

• 决定补充用例所需要的额外工件。
• 理解用例如何驱动开发（设计和测试）。
• 微小迭代的目标是快速地按比例增加团队的能力。如果有些团队成员在获得这些技能方面有困难，就有必要延长主持人的涉入或重新调整团队角色结构。

因为目标是培训技能和帮助团队从一个瀑布模型转换到一个迭代模型，因此微小迭代的场景应当简单，以使团队可以快速地从需求移到设计，然后进行编码和测试。这个小规模试验项目将帮助团队立即如何执行一个迭代和使用合适的工件。

必要时使用高级技术
　研讨会和微小迭代应当覆盖各种用例类型：数据集中，工作流集中，数据维护，报告，等等。这将帮助团队成员试验不同的编写风格和需求模式。在微小迭代结束时，团队应当回顾需求是如何被组织和文档化的，并识别要改进的区域。这可能要求引入更高级的技术，通过用例符号： ?include? 和 ?extend? 来结构化需求，等等。

没有经验的团队可能想在项目开始时避免使用高级技术，因为这些技术会激起方法论辩论，并将团队从他们的采集和捕获需求的主要目标转移开。最好是在需求改进需求之前，首先将需求记录在纸上。

在微小迭代的最后，团队将获得使用用例的动手经验，并且他们也将会对项目需求有一个好的理解。高级技术将帮助他们按照一种最大化用例可理解性的方式来结构化他们的需求，并在用例编写方面减少重复。主持人应当推荐要使用哪种技术，并提供有关如何进行的必要指导。