引言
注意：有关观点与展望 专栏的一般性介绍，请参阅第 1 部分。
作为 IT 架构师，您可能经常会发现自己处于进退维谷的境地，前有您的业务目标，后有您的 IT 系统。这两方面都具有规模大、不易改变和灵活性差的特点。制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。似乎是这样，业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。
而这就是我们为了实现高效率而需要着手处理的问题：理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。
由于这部分工作可能会非常困难而棘手，因此，我们向 IBM 体系结构专家队伍寻求指导。本月我们邀请这些专家分享他们用来将业务需求表述为明晰简洁的技术要求的方法，以便 IT 团队能成功地实现。
我们在此提供的内容谈不上全面。本文的全部内容都是在讨论如何将业务需求转换为技术要求，但关于这个主题还有很多可说。每位 IT 架构师对此问题的答案的关注点都或多或少有自己的特别之处，没有任何答案能满足所有人的愿望。不过，我们的专家将为您指明有用的方向，以抛砖引玉，我们相信这可以帮助您找到本月的问题的最恰当答案。
再次感谢我们的供稿编辑 Holt Adams，您将在下面读到他对本月讨论的问题的看法。
欢迎每月阅读 developerWorks IT 体系结构方面的精彩内容：如何将业务需求转换为 IT 要求这一主题是本月要讨论的话题。
我们也欢迎您就本专栏未来的发展方向给出您的意见和建议。您有需要我们的专家团队回答的问题吗？请将您的问题发布到我们的 IT 体系结构讨论论坛。或者，通过以下邮件地址与我联系：pdreyfus@us.ibm.com。
Paul Dreyfus，编辑
developerWorks SOA and Web services
pdreyfus@us.ibm.com
另：为了显得没有偏袒，让讨论自然地展开，我们本月按照姓名的字母降序对供稿人的回答进行排列。（仔细阅读过第一期专栏的读者会发现该期的供稿人是按照从 A 到 Z 的顺序排列的。）
一个词：用例（哦，两个字）
用电影毕业生 (The Graduate) 中的方式来说，我只想对你说一个词：用例。（哦，那是两个字。）很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。
在 Alistair Cockburn 的 Writing Effective Use Cases 一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。
例如，股票交易 Web 站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
 |
|
可以将用例用于对服务进行建模；我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。（有关服务用例的更多信息，请参阅我的 developerWorks 文章“通过服务模拟来简化 SOA 开发”。）
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。您的业务如何开展？客户希望您的业务如何开展，他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于：这些干系人如何与公司进行交互？这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程——公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司（或公司的一部分）建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。（无法实现自动化的就是需要人工完成的任务。）实现这种自动化的应用程序（实现流程和服务）是采用面向服务的体系结构的应用程序。而您现在正在进行 SOA 实践。
记录流程
当我坐下来和客户讨论新程序或开发工作时，我会立即了解业务干系人是否出席，或是否派了代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”（即之前从没有进行过此类工作），否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率都很小。
我个人非常赞同开发业务场景来记录业务流程。业务场景允许您在整个业务问题的上下文中标识系统要求。The Open Group 提供了一本非常出色的的小册子，用于帮助了解和开发业务场景，书名为 Manager's Guide to Business Scenarios。
|
|
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。您可以使用电子表格来维护此列表，但如果想要尽量保持要求的可跟踪性和根据优先级或类别管理各种要求，则这种方法就显得不合适。我极力赞同使用工具来管理要求；为了达成此目的，我建议使用 IBM Rational® RequisitePro®。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，您可以召开联合应用程序开发（Joint application development，JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过 JAD 会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。
从一开始就使用 RequisitePro
Rational RequisitePro 是一个没有得到足够重视的 Rational 产品，该产品用于收集、记录和细化需求和其他业务概念。它允许业务用户在 Word 文档中编写声明，然后将其捕获到数据库中，并将这些声明与用户定义的其他属性相关联。这些声明可以描述需求、策略、用户角色、干系人以及与业务相关的任何其他内容。
使用迭代需求细化流程时，可以在相关声明之间建立联系。例如，需求“Portlet 显示 X、Y 和 Z 客户信息”，可以与另一项需求“角色 A、B 和 C 应接收所有必要的客户信息”联系起来。在这种情况下，第一项需求是第二项需求的细化。这样就对一般需求和详细需求之间的关系进行了建模。
|
|
在我个人看来，您应该在建模阶段一开始就使用 RequisitePro。RequisitePro 中管理的声明可成为建模工具（如 IBM WebSphere® Business Integration Modeler、Rational Sofware Architect (RSA) 或 Rational Software Modeler (RSM)） 的输入。事实上，Rational Sofware Architect 和 Rational Software Modeler 都提供了将 RequisitePro 需求显式地链接到用例和其他建模元素的功能。您还可以将需求链接到 Java™ Java 2 Platform Enterprise Edition (J2EE) 和其他类似的实现构件。通过此功能，您可以获得各种问题的答案，如“当更改此项业务需求时，为了与其相匹配，必须对模型或实现的哪些方面进行相应的更改？”
最后，在读过了 Simon Johnston 所提出的观点后，我希望补充一些内容：
我最近组织了一次理解“策略”概念的工作，了解什么是策略，以及它应该如何适应 IBM 的系列工具。通过这项工作，得出了以下定义：
- 策略 是在一定业务领域内以实现特定业务目标为目的的声明。此定义与说明和其他相关材料中强调的业务意图是一致的。
- 声明 是以某种人类语言表述的语句。因此策略与 RequisitePro 的适应性非常好；就某种意义而言，策略就是一种需求。
策略是通过一个细化流程制定的，该流程以高级策略声明为基础进行，而这些高级策略声明通常不能直接实现；这些高级声明将通过迭代方式细化为更为详细的策略。然后，可以通过使用我前面描述的 RequisitePro 功能将完全细化的策略与实现工作联系起来。Simon 所说的“连续体”与策略生命周期这个观点是一致的。
Calvin Powers 完成了一个基于 Web 的相对不错的演示文档，演示了可以如何将 RequisitePro 用于捕获和细化业务策略。请访问 IBM Business and Technology Solutions Resource Library，并在 Demos 部分查找“Policy Provisioning using IBM Rational RequisitePro and IBM Workplace Business Controls and Reporting”。
正确功能的正确解决方案
我很喜欢 Kerrie Holley 对本月问题的重新表述：“我如何从业务意图转到已实现的价值或 IT 解决方案？”开发和设计解决方案的体系结构时需要考虑的最重要的事项之一就是所需的对应功能和容量级别。如果我所做的只是将价格信息发布到网上，我可以到最近的小学里找个人来编写 HTML。不过，如果我是 Wal-Mart，而我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。
经验丰富的专业人员可以帮助客户将业务需求转换为业务意图。业务意图更为模糊，但更与“基本需求”和“投资回报”一致。确定了业务意图之后，就可以通过创新且可重复的 IT 解决方案获得实现的价值。
和 Kerrie 一样，我相信业务需求和 IT 功能存在重叠。正是由于这个模糊不清的界线使得体系结构设计成为了一个困难而费时的过程。不管是采用瀑布式还是迭代方法（我们喜欢后者），规划和需求分析阶段始终都很单调乏味。客户很少知道他们需要什么（尽管很多人知道他们希望得到什么）。经验丰富的专业人员有责任帮助客户将业务需求转换为 IT 功能。
|
|
这并不能通过只使用良好的工具和方法来实现，因为每个项目都是独特的。方法和技术是指导方法，而工具则用于帮助实现这些方法的自动化。虽然很多项目都具有共同之处，但他们彼此完全一样的情况却很少。假设它们彼此相同就是假设两个完全不同的业务彼此完全相同（虽然有一定的相似性）。我过去曾和 Home Depot 及 Lowe's 进行过大量合作。尽管这两家公司相似，但他们都会告诉您各自的业务具有独特性。而他们都将这些不同之处视为他们的竞争优势。很多时候，文化、地域和地理位置对业务需求的影响决定着所建议的 IT 解决方案。政府法律法规和标准可能要求技术人员根据部署解决方案的场合对相同的业务需求采用不同的方法来设计解决方案。
捕获和交付构件的技术——用例、场景文档、Rational Unified Process (RUP)——应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要 24x7 的可用性，而只需要 8x7 的可用性即可，因为他们不希望承担 24x7 解决方案所带来的高成本，您仍然可以很好地使用这些构件。