在本专栏中，IBM有洞察力的专家给出了他们对IT架构师在目前及将来所面临的问题的观点与展望。本月，他们将考虑以下问题：“我如何将组织的业务需求转换为IT要求，以便在系统体系结构中满足这些需求？”

　　引言

　　注意：有关观点与展望专栏的一般性介绍，请参阅第1部分。

　　作为IT架构师，您可能经常会发现自己处于进退维谷的境地，前有您的业务目标，后有您的IT系统。这两方面都具有规模大、不易改变和灵活性差的特点。制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。似乎是这样，业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。

　　而这就是我们为了实现高效率而需要着手处理的问题：理解这两种语言并执行必要的转换，以便IT能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与IT的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。

　　由于这部分工作可能会非常困难而棘手，因此，我们向IBM体系结构专家队伍寻求指导。本月我们邀请这些专家分享他们用来将业务需求表述为明晰简洁的技术要求的方法，以便IT团队能成功地实现。

　　我们在此提供的内容谈不上全面。本文的全部内容都是在讨论如何将业务需求转换为技术要求，但关于这个主题还有很多可说。每位IT架构师对此问题的答案的关注点都或多或少有自己的特别之处，没有任何答案能满足所有人的愿望。不过，我们的专家将为您指明有用的方向，以抛砖引玉，我们相信这可以帮助您找到本月的问题的最恰当答案。

　　再次感谢我们的供稿编辑Holt Adams，您将在下面读到他对本月讨论的问题的看法。

　　欢迎每月阅读developerWorks IT体系结构方面的精彩内容：如何将业务需求转换为IT要求这一主题是本月要讨论的话题。

　　我们也欢迎您就本专栏未来的发展方向给出您的意见和建议。您有需要我们的专家团队回答的问题吗？请将您的问题发布到我们的IT体系结构讨论论坛。或者，通过以下邮件地址与我联系：pdreyfus@us.ibm.com。

　　另：为了显得没有偏袒，让讨论自然地展开，我们本月按照姓名的字母降序对供稿人的回答进行排列。（仔细阅读过第一期专栏的读者会发现该期的供稿人是按照从A到Z的顺序排列的。）

　　一个词：用例（哦，两个字）

　　用电影毕业生 (The Graduate) 中的方式来说，我只想对你说一个词：用例。（哦，那是两个字。）很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构(SOA)中，我们也使用这个概念来对业务进行建模。

　　在Alistair Cockburn的Writing Effective Use Cases一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。

　　例如，股票交易Web站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。

　　可以将用例用于对服务进行建模；我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。

　　还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。您的业务如何开展？客户希望您的业务如何开展，他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于：这些干系人如何与公司进行交互？这些都是业务用例。

　　获得了业务用例后，则可以随后将其链接起来，以形成业务流程——公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。

　　通过用例将公司（或公司的一部分）建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。（无法实现自动化的就是需要人工完成的任务。）实现这种自动化的应用程序（实现流程和服务）是采用面向服务的体系结构的应用程序。而您现在正在进行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)——应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要24×7的可用性，而只需要8×7的可用性即可，因为他们不希望承担24×7解决方案所带来的高成本，您仍然可以很好地使用这些构件。

　　捕获最佳实践的模式解决方案

　　当我看到这个问题时，我的第一个念头是我没有资格回答这个问题，因为我不是与客户接触的架构师。不过，我通过一些咨询活动与客户接触过。我所用的技术并非基于任何正式的方法，而是基于对技术和产品的深入了解。我同意Holt Adams所说的“从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。”不过帮助却是唾手可得的。

　　我的团队和我已经开始研究一项用于将设计模式链接起来的技术，我们将这些技术称为模式解决方案。我们的目的是为了使用Rational Software Architect中全面的模式框架来捕获针对重复出现的问题的最佳实践。通过这个方法，我们可以采用可重复的方式更有效地将需求转换为技术。我们的目标是构建一个围绕可重复模式社区。我们希望形成一个像Amazon.com一样的社区，人们可以在其中对各种模式进行评论，并为他们喜欢的模式投票。请使用Pattern Solutions discussion forum告诉我们您对此主意及我们的实现的看法。

　　急需：通用技术

　　我也同意Kerrie对原来的问题中提出的转换的真正目的的描述（我如何从业务意图转到已实现的价值或IT解决方案？）：其目的是通过IT提供支持业务意图的功能来实现业务的价值。让我们来详细地了解一下此概念。

　　首先，我们必须关注业务价值。IT的目的不是使用不断发展的新技术来持续更新我们的技能，而是为业务价值作出贡献。

　　这句话的另一个重要方面就是IT不再仅是开发独立应用程序了。相反，我们提供了可组合到一起实现业务流程的各个功能。SOA的承诺之一是，我们通过它可以在业务组织和IT组织（在其中通过使用服务实现业务流程）之间提供一个相互都能理解的语言机制。

　　最后，我们需要讨论一下Kerrie使用的一个有意思的术语：即业务意图。请注意，他没有使用要求、需求 或用例。业务具有意图。当然，用例或WebSphere Business Integration Modeler模型可以帮助了解当前的情况和清楚地说明此意图。但此类工具有一定风险，可能会过早地根据Modeler假定的解决方案表述问题。