采用用例，第1部分: 理解用例类型和工件
作者：Wayne 文章来源：天极
在此 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 回答道。
“根据‘系统应...’格式叙述的传统需求表示方法的关键问题是这些叙述不直接转化为验收测试；这要求一个额外的思考过程。用例通过连接跨越此间隙。“ 他强调说。他继续解释，用例的事件流描述了主角的请求和系统的动作（例如显示处理结果或修改一个系统状态），工作在测试过程中时，这对明确描述测试步骤和验证点是有用的。在早期阶段使用系统验收标准作为抽取和记录需求的一个基础，会给团队成员大量的控制。
文章来源于领测软件测试网 https://www.ltesting.net/
