从 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 产品来建模或者开发，可是我怎样才能将它们与需求联系起来呢？"
"我们已经拥有了 XYZ 工具并有可比较的特性，这里所说的有什么更好的特性呢？" 
        IT 专家喜欢清晰地陈述他们的技术需求，以便他们能够开始编码。项目经理和消费者们并不清楚像 Rational RequisitePro® 这类工具的好处，也不清楚它们与 Rational Portfolio Manager，诸如此类项目管理工具的适应性。（有些项目使用了整个 Rational 工具集，除了 RequisitePro！）在这篇文章中还回答了一些有效的问题。

        像 Rational 这样的工具，如果我们适当地运用，就具有重要的意义。有些项目经理把工具（比如 RequisitePro）作为需求的智囊库，也就是说，这些需求被输入了这个工具，然后报告就从这个工具中发布。于是项目经理就对他们为什么看不见切实的利益而感到奇怪。

        这篇文章的目的就是填补产品文档与方法文档之间的空白。这个 Rational 工具文档很好地描述了它的特性和能力，方法文档中含有大量的方法和最佳实践。然而，IT 构架师仍然面对着如何将这个工具的利益最大化的问题。在这篇文章中，您将学到业务需求、用例，以及基本的跟踪能力，并附有系统级别的需求、组件，以及测试过程中的跟踪性。

Empire Systems Corporation

        为了论证如何最佳使用构架需求技术，这个系列的文章将会涉及到来自 Empire Systems Corporation (ESC) 的特殊的，假定的例子，个人计算机、膝上电脑、电脑组件以及相关硬件，比如 Web 照相机和麦克风的虚构的制造商和供应商。ESC 已经有一个 Web 应用，并且已经启用了许多它的应用软件。现在公司的领导者想通过流线的过程把公司转型到下一个级别，使业务能力自动化，采用一个企业构架，最终，提高税收和利益率。

业务需求

        成功的 IT 项目都是以良好的业务需求开始的。技术文档含有需求工程的方法、技术和最佳实践。然而，对于需求的讨论，尤其是业务需求通常非常模糊、散漫，并且一般而言都比较难于理解。由于缺乏清晰的需求表达会影响到业务需求的传递，随后会影响映射到技术需求。让我们重新回顾一下一些基本的需求工程的原则。

重视业务 
        业务需求应该重视实际的业务需求，并要与其它的业务概念有明显特性（比如远景、任务、目标或者结果）。通常的一个错误将业务的目标（例如，“达到缩减20％成本的目标”）陈述为一个业务的需求。
尽可能简洁 
        需求必须是具体的、可测量的、 可控的、 可现实的以及限时的。这比看起来更有挑战性。可是，通过寻问以下的问题就能够很容易地完成：
为什么要用这种方式来处理？
您将获得什么样的结果，或者如果这个问题被解决您将能够做什么？
明确地说，什么过程将会受到这个障碍的影响？
通过补偿这个过程将会得到什么利益（尽可能是可计算的）？
做什么来改变事情？
这通常很难回答，涉众们往往回到问题的陈述上来。需求工程可以以一些如果……怎么样 的建议来获取一些可能性。尽管如此，还是要在涉众们回到正轨时立即撤回。

        关于时间框架，对于背景和业务环境什么时候可以完成？ 
        这并不是特意为项目交付而设的点，而是推理业务背景的起点。例如，一个上网卡的商人想要以节日为目标开张他的新 Web 站点。

确定并阐明范围
什么是进什么是出？ 什么被执行了或者被交付了，什么时间？
确定“主语”和“谓语”
这是经常最容易被忽略的，也是范围频繁变化的主要原因。如果这不仅仅是一个动词，可以将它规定为独特的需求。这提高了明确性并促进涉众们之间更好的理解。
关注需求本身，而不是如何实现
业务需求通常陈述完成了什么 ，并且应该避免任何关于怎样完成的提示。例如，一个企业想要主观的、综合的观点融合到他们的业务数据中。重点应该是他们想要做什么，而不是他们需要得到什么（例如，数据库）。
需求样例

        ESC 有几个基于 Web 的应用软件。因为每个应用软件都是独立开发的，消费者面临着像需要分别在每个应用软件上注册以及对于每个业务功能需要不同的窗口的问题，引起了他们的抱怨。为了解决这些抱怨，ESC 业务小组制定了下面的需求：

BR264： 消费者应该能够通过一个兼容的界面访问所有的 ESC 应用软件，并且只需要注册一次。ESCWeb（主要的商业 Web 网站）对于所有的消费者应该有相同的外观和感觉。这将减少用户差错并提高用户的体验。ESCWeb 最终也将支持移动的和远程的客户。
很显然，这个需求能够被改善。通过运用这些原则，我们能够对它进行如下的重述。

BR264：在 ESC5.0 版本中，消费者想要注册一次就可以应用所有的 ES C应用软件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。

BR265：在 ESC5.0 版本中，所有的 ESC 应用软件将执行 ESC Web Standard 273-1 和 273-2，这将再减少10％的用户差错。