| UML软件工程组织 | |||
| |
|||
|
|||
使用 Rational RequisitePro 进行需求管理的新技术
作者：Kumar Mani 出处：IBM
从 Kumar Mani 的这个系列中发现捕获，管理和跟踪构架需求的新方法。这种方法是建立在构架理论基础上的，且适用于所有的 IT 项目。如果您是一位在公司或者综合项目中面临复杂请求的IT构架师或者经理，您就可以利用这些方法来管理这个项目，并有助于保证及时交付的时间。这篇文章探究了利用 IBM® Rational® 工具集的实现，但是它能够被复制，就像使用其它产品一样简单。 介绍这篇文章描述了一个构架方法和一个着重强调 需求项目、获取需求的科学、分析以及项目整个生命周期的管理需求的技术。尽管这篇文章是利用 Rational 工具集来阐述这些技术的，但是并不是特意为这些产品来做指导的。你们的目的是利用基本的构架技术并将它们运用到您的项目中。IT 构架师对 Rational 都比较熟悉，当然也应该能够很容易地在他们的项目中复制这些技术。 需求非常重要是因为它们是来自开发架构的中心的。 图 1显示了 Open Group Architecture Framework Architecture Development Method (TOGAF ADM) 和它的八个阶段。 图1. TOGAF Architecture Development Method 
需求作为一种需要、机会或者缺乏的表现，贯穿整个开发过程驱动着其他的阶段。然而需求管理在项目中由于许多不同的原因通常被忽略或者并没有被充分地处理。IT 构架师通常会问：
像 Rational 这样的工具，如果我们适当地运用，就具有重要的意义。有些项目经理把工具（比如 RequisitePro）作为需求的智囊库，也就是说，这些需求被输入了这个工具，然后报告就从这个工具中发布。于是项目经理就对他们为什么看不见切实的利益而感到奇怪。 这篇文章的目的就是填补产品文档与方法文档之间的空白。这个 Rational 工具文档很好地描述了它的特性和能力，方法文档中含有大量的方法和最佳实践。然而，IT 构架师仍然面对着如何将这个工具的利益最大化的问题。在这篇文章中，您将学到业务需求、用例，以及基本的跟踪能力，并附有系统级别的需求、组件，以及测试过程中的跟踪性。 为了论证如何最佳使用构架需求技术，这个系列的文章将会涉及到来自 Empire Systems Corporation (ESC) 的特殊的，假定的例子，个人计算机、膝上电脑、电脑组件以及相关硬件，比如 Web 照相机和麦克风的虚构的制造商和供应商。ESC 已经有一个 Web 应用，并且已经启用了许多它的应用软件。现在公司的领导者想通过流线的过程把公司转型到下一个级别，使业务能力自动化，采用一个企业构架，最终，提高税收和利益率。 业务需求成功的 IT 项目都是以良好的业务需求开始的。技术文档含有需求工程的方法、技术和最佳实践。然而，对于需求的讨论，尤其是业务需求通常非常模糊、散漫，并且一般而言都比较难于理解。由于缺乏清晰的需求表达会影响到业务需求的传递，随后会影响映射到技术需求。让我们重新回顾一下一些基本的需求工程的原则。
ESC 有几个基于 Web 的应用软件。因为每个应用软件都是独立开发的，消费者面临着像需要分别在每个应用软件上注册以及对于每个业务功能需要不同的窗口的问题，引起了他们的抱怨。为了解决这些抱怨，ESC 业务小组制定了下面的需求： BR264： 消费者应该能够通过一个兼容的界面访问所有的 ESC 应用软件，并且只需要注册一次。ESCWeb（主要的商业 Web 网站）对于所有的消费者应该有相同的外观和感觉。这将减少用户差错并提高用户的体验。ESCWeb 最终也将支持移动的和远程的客户。 很显然，这个需求能够被改善。通过运用这些原则，我们能够对它进行如下的重述。 BR264：在 ESC5.0 版本中，消费者想要注册一次就可以应用所有的 ES C应用软件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。 技术1. 确定 RequisitePro 中的业务需求在这个记录将需求记录在 RequisitePro 的技术中，关键是保持获取和澄清这个需求的原则。这个技术包括三个步骤：
技术1现在已经完成。您已经获取了一个清晰而且简洁的业务需求，并准备好转向下一个阶段。 图 2 显示了这个技术。 图 2. 利用技术1获取业务需求
用例技术2 (将用例与需求连接起来)覆盖了这个项目的下一个阶段。只要业务需要被确定，这个业务构架师或者分析师就会开发用例来对它们进行说明。尤其对于大的或者复杂的项目，业务分析师经常会遇到这样两个问题：
业务需求与用例是如何连接起来的？用例捕获用户的视角，他们说明了用户的行为和系统的回应。但是业务需求远远超越了作为一个服务于用例的数据源。当规定了属性或者限制时，它们就变成了用例的属性（或者备用信息流）。我们应该能够记录业务需求和一个用例之间正常的连接，并用它做一些有意义的事情，比如跟踪或者分析。 建模用例时需要大量的资料。在 资源部分中的文章都是很好的起点。查看这些案例属于这篇文章以外的范围，但是我们将介绍一个应用于这个技术实现的命名习惯。 为什么用例的名字非常重要？回忆一下我们介绍过定义需求时主谓一致的结构。这个概念在这里得到延伸。主语由这个用例模型中的施动者来代表。我们的用例命名原则规定，用例应该以现在时态或者动词的动名词形式(ing)。在有些情况下，它有助于包括被动词修饰的宾语的名称。 技术 2. 连接用例与需求现在是定义用例并把它们与需求连接起来的时候了。这个技术的目的是维持定义用例的明确性，使它们与需求保持连接（可跟踪的），可以采用下面的步骤：
这个技术已经完成。您可以通过对 RequisitePro 中的用例命名 来开始，它能够让您完全在 Rose 中进行定义、细化，并跟踪这个用例。这突出了 Rational 中的一个重大的优点：需求、建模和设计的整合。 跟踪性为什么可跟踪性如此重要？ 可跟踪性就是对需求的生命周期从它的开始到各种转化，前前后后的跟随。随着企业的发展，也会对支持他们的系统（和他们的需求）进行跟踪。可跟踪性是联合需求的过去、现在和将来关键的连接。可跟踪性可以提供一些数据，项目的各种分析，比如成本，覆盖范围以及影响力都可以根据这些数据来执行。 在实际中跟踪是很难做到的。主要的问题是可跟踪性被看作需求工程的一个附属的方面。这些需求被规定在文档和构建在 Rose 中的模型中。可跟踪性通常是建模工作完成之后，手工记录在电子表格中的。维护这些电子表格非常麻烦而且容易出错。但是对项目影响更大的是，电子表格本身充当了跟踪报告从而逃避了详细审查。 我们的下一个技术解决了这个问题。这个技术的第 1 部分是，当需求被创建时归纳出跟踪需求的原则。 （我们利用用例在前面的技术中已经证明的这一点。）这个思想是在需求的整个生命周期和测试中都要维持原则。第 2 部分是生成覆盖和附属 报告。这个附属报告是影响分析的第一个层次。中心思想是，这些自动生成的报告在检查中需要详细审查。 覆盖，正如其名字所示，确保同一个层次的每个需求在下一个层次都被覆盖（或者更进一步的规定）到。例如，每个用例都必须被测试用例覆盖到。附属需求就是那些在无意中悄悄混进这一层次的需求，它们在之前一个层次中并不存在。在生命周期的早期把它们都捕获是十分重要的，因为在这个阶段的警告比系统交付后的错误报告更容易处理。使这些功能自动化操作同样十分重要。 技术3. 跟踪覆盖和附属需求这个技巧显示了如何构建 Coverage and Dangler 视图来业务需求和用例之间的差距。这些视图符合标准的 RequisitePro 视图框架。采用下面的步骤。
这个技术已经完成。您可以跟踪用例到最初的业务需求，并可以排除虚假的用例和不完善的业务需求。您的项目现在可以安全地进入解决方案领域了。 总结在这篇文章中，您研究了需求工程的基本原理并介绍了三个管理构架需求的新技术。回顾了需求的基本原则，描述了三个管理业务需求，用例和跟踪性的技术。 然而，我们仍然处于问题领域中。在本系列文章的第 2 部分，我我们将进入解决方案领域和解决方案开发的各个阶段（从架构的角度），并且探索管理解决方案交付的新技术。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
