介绍
这篇文章描述了一个构架方法和一个着重强调需求项目、获取需求的科学、分析以及项目整个生命周期的管理需求的技术。尽管这篇文章是利用 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%成本的目标”)陈述为一个业务的需求。
尽可能简洁
文章来源于领测软件测试网 https://www.ltesting.net/
