用例

    技术2 (将用例与需求连接起来)覆盖了这个项目的下一个阶段。只要业务需要被确定，这个业务构架师或者分析师就会开发用例来对它们进行说明。尤其对于大的或者复杂的项目，业务分析师经常会遇到这样两个问题：

    需求存在于文档中(除非您使用技术1)，用例位于模型中，比如 Rational Rose? Enterprise (Rose)。

    由于需求(和用例)的数量逐渐增长，拆分也变得越来越难于管理。

    业务需求与用例是如何连接起来的?用例捕获用户的视角，他们说明了用户的行为和系统的回应。但是业务需求远远超越了作为一个服务于用例的数据源。当规定了属性或者限制时，它们就变成了用例的属性(或者备用信息流)。我们应该能够记录业务需求和一个用例之间正常的连接，并用它做一些有意义的事情，比如跟踪或者分析。

    建模用例时需要大量的资料。在资源部分中的文章都是很好的起点。查看这些案例属于这篇文章以外的范围，但是我们将介绍一个应用于这个技术实现的命名习惯。

    用例的命名原则

    为什么用例的名字非常重要?回忆一下我们介绍过定义需求时主谓一致的结构。这个概念在这里得到延伸。主语由这个用例模型中的施动者来代表。我们的用例命名原则规定，用例应该以现在时态或者动词的动名词形式(ing)。在有些情况下，它有助于包括被动词修饰的宾语的名称。

    技术 2. 连接用例与需求

    现在是定义用例并把它们与需求连接起来的时候了。这个技术的目的是维持定义用例的明确性，使它们与需求保持连接(可跟踪的)，可以采用下面的步骤：

    如果您的 RequisitePro 项目不包含用例的包或者用例的需求类型，那么就创建一个。

    利用Associate Model to RequisitePro project对话框将 Rose 模型和 RequisitePro 项目联系起来。Default Requirement Type被设置为Use Case。

    现在您可以在 Rose 中创建您的模型。对于每个用例，首先根据命名原则创建一个Use Case类型的 RequisitePro 需求，如图 3所示。在Requirement Text中输入这个名字。

    在 Rose 中创建这个用例。右键点击这个用例获取 Associate Requirement to Use Case 的对话框。 选择Use Case in RequisitePro然后点击OK。这将产生 Resolve Use Case Name 对话框，这个对话框非常重要因为它利用动词连接着用例和需求，如图 4所示。

    您现在可以看到 Requirement Properties 的对话框。选择Traceability键，用例就回到了BUS需求。

    这个技术已经完成。您可以通过对 RequisitePro 中的用例命名来开始，它能够让您完全在 Rose 中进行定义、细化，并跟踪这个用例。这突出了 Rational 中的一个重大的优点：需求、建模和设计的整合。

    跟踪性

    为什么可跟踪性如此重要?可跟踪性就是对需求的生命周期从它的开始到各种转化，前前后后的跟随。随着企业的发展，也会对支持他们的系统(和他们的需求)进行跟踪。可跟踪性是联合需求的过去、现在和将来关键的连接。可跟踪性可以提供一些数据，项目的各种分析，比如成本，覆盖范围以及影响力都可以根据这些数据来执行。

    在实际中跟踪是很难做到的。主要的问题是可跟踪性被看作需求工程的一个附属的方面。这些需求被规定在文档和构建在 Rose 中的模型中。可跟踪性通常是建模工作完成之后，手工记录在电子表格中的。维护这些电子表格非常麻烦而且容易出错。但是对项目影响更大的是，电子表格本身充当了跟踪报告从而逃避了详细审查。

    我们的下一个技术解决了这个问题。这个技术的第 1 部分是，当需求被创建时归纳出跟踪需求的原则。 (我们利用用例在前面的技术中已经证明的这一点。)这个思想是在需求的整个生命周期和测试中都要维持原则。第 2 部分是生成覆盖和附属报告。这个附属报告是影响分析的第一个层次。中心思想是，这些自动生成的报告在检查中需要详细审查。

    覆盖，正如其名字所示，确保同一个层次的每个需求在下一个层次都被覆盖(或者更进一步的规定)到。例如，每个用例都必须被测试用例覆盖到。附属需求就是那些在无意中悄悄混进这一层次的需求，它们在之前一个层次中并不存在。在生命周期的早期把它们都捕获是十分重要的，因为在这个阶段的警告比系统交付后的错误报告更容易处理。使这些功能自动化操作同样十分重要。

    技术3. 跟踪覆盖和附属需求

    这个技巧显示了如何构建 Coverage and Dangler 视图来业务需求和用例之间的差距。这些视图符合标准的 RequisitePro 视图框架。采用下面的步骤。

    从业务需求包的Coverage中，选择一个新的View，这里的View Type是一个跟踪性矩阵，Row Requirement Type是 BUS，Column Requirement Type是 UC。注意如何从技术1重新利用 BUS 包。

    在View Properties框中，在行需求中创建一个名为Business Requirements CoverageQuery。现在为这个Query增加一个Traced-from属性。

    这将产生 Query Requirements 对话框。如图 5所示，选择Not Traced并选中Direct links only。

    刷新这个View。您将可以看到这个没有相关用例的业务需求。您可以省略步骤2和3创建一个完整报告View。

    Dangler视图是通过在这个技术中反向Query标准来创建的。我们以列需求类型(用例)开始，并选择Traced-toBUS 需求。这个视图显示了所有的附属用例。

    这个技术已经完成。您可以跟踪用例到最初的业务需求，并可以排除虚假的用例和不完善的业务需求。您的项目现在可以安全地进入解决方案领域了。

    总结

    在这篇文章中，您研究了需求工程的基本原理并介绍了三个管理构架需求的新技术。回顾了需求的基本原则，描述了三个管理业务需求，用例和跟踪性的技术。

    然而，我们仍然处于问题领域中。在本系列文章的第 2 部分，我我们将进入解决方案领域和解决方案开发的各个阶段(从架构的角度)，并且探索管理解决方案交付的新技术。