|
级别: 初级
Editorial staff (dwinfo@us.ibm.com), developerWorks, IBM
2006 年 5 月 30 日
在本月的专栏中，IBM 有洞察力的专家给出了他们对 IT 架构师在目前及将来所面临的问题的观点与展望。本月，他们将考虑以下问题：“我如何将组织的业务需求转换为 IT 要求，以便在系统体系结构中满足这些需求？"
引言
注意：有关观点与展望 专栏的一般性介绍，请参阅第 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 站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
 |
在业务用例中，参与者是干系人，而系统则是业务本身。
——Bobby Woolf |
|
可以将用例用于对服务进行建模；我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。（有关服务用例的更多信息，请参阅我的 developerWorks 文章“通过服务模拟来简化 SOA 开发”。）
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。您的业务如何开展？客户希望您的业务如何开展，他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于：这些干系人如何与公司进行交互？这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程——公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司（或公司的一部分）建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。（无法实现自动化的就是需要人工完成的任务。）实现这种自动化的应用程序（实现流程和服务）是采用面向服务的体系结构的应用程序。而您现在正在进行 SOA 实践。
记录流程
 当我坐下来和客户讨论新程序或开发工作时，我会立即了解业务干系人是否出席，或是否派了代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”（即之前从没有进行过此类工作），否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率都很小。
我个人非常赞同开发业务场景来记录业务流程。业务场景允许您在整个业务问题的上下文中标识系统要求。The Open Group 提供了一本非常出色的的小册子，用于帮助了解和开发业务场景，书名为 Manager's Guide to Business Scenarios。
|
如果客户不了解业务，架构师有效定义系统要求的几率都很小。
——Andras Szakal |
|
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。您可以使用电子表格来维护此列表，但如果想要尽量保持要求的可跟踪性和根据优先级或类别管理各种要求，则这种方法就显得不合适。我极力赞同使用工具来管理要求；为了达成此目的，我建议使用 IBM Rational® RequisitePro®。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，您可以召开联合应用程序开发（Joint application development，JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过 JAD 会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。
从一开始就使用 RequisitePro
 Rational RequisitePro 是一个没有得到足够重视的 Rational 产品，该产品用于收集、记录和细化需求和其他业务概念。它允许业务用户在 Word 文档中编写声明，然后将其捕获到数据库中，并将这些声明与用户定义的其他属性相关联。这些声明可以描述需求、策略、用户角色、干系人以及与业务相关的任何其他内容。
使用迭代需求细化流程时，可以在相关声明之间建立联系。例如，需求“Portlet 显示 X、Y 和 Z 客户信息”，可以与另一项需求“角色 A、B 和 C 应接收所有必要的客户信息”联系起来。在这种情况下，第一项需求是第二项需求的细化。这样就对一般需求和详细需求之间的关系进行了建模。
|
"当更改这项业务需求时，为了与其相匹配，必须对模型或实现的哪些方面进行相应的更改？"
——Mark Linehan |
|
在我个人看来，您应该在建模阶段一开始就使用 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 功能。
|
如果我所做的只是将价格信息发布到网上，我可以到最近的小学里找个人来编写 HTML。不过，如果我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。
——Calvin Lawrence |
|
这并不能通过只使用良好的工具和方法来实现，因为每个项目都是独特的。方法和技术是指导方法，而工具则用于帮助实现这些方法的自动化。虽然很多项目都具有共同之处，但他们彼此完全一样的情况却很少。假设它们彼此相同就是假设两个完全不同的业务彼此完全相同（虽然有一定的相似性）。我过去曾和 Home Depot 及 Lowe's 进行过大量合作。尽管这两家公司相似，但他们都会告诉您各自的业务具有独特性。而他们都将这些不同之处视为他们的竞争优势。很多时候，文化、地域和地理位置对业务需求的影响决定着所建议的 IT 解决方案。政府法律法规和标准可能要求技术人员根据部署解决方案的场合对相同的业务需求采用不同的方法来设计解决方案。
捕获和交付构件的技术——用例、场景文档、Rational Unified Process (RUP)——应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要 24x7 的可用性，而只需要 8x7 的可用性即可，因为他们不希望承担 24x7 解决方案所带来的高成本，您仍然可以很好地使用这些构件。
捕获最佳实践的模式解决方案
 当我看到这个问题时，我的第一个念头是我没有资格回答这个问题，因为我不是与客户接触的架构师。不过，我通过一些咨询活动与客户接触过。我所用的技术并非基于任何正式的方法，而是基于对技术和产品的深入了解。我同意 Holt Adams 所说的“从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。”不过帮助却是唾手可得的。
我的团队和我已经开始研究一项用于将设计模式链接起来的技术，我们将这些技术称为模式解决方案。我们的目的是为了使用 Rational Software Architect 中全面的模式框架来捕获针对重复出现的问题的最佳实践。通过这个方法，我们可以采用可重复的方式更有效地将需求转换为技术。我们的目标是构建一个围绕可重复模式社区。我们希望形成一个像 Amazon.com 一样的社区，人们可以在其中对各种模式进行评论，并为他们喜欢的模式投票。请使用 Pattern Solutions discussion forum 告诉我们您对此主意及我们的实现的看法。
急需：通用技术
 我也同意 Kerrie 对原来的问题中提出的转换的真正目的的描述（我如何从业务意图转到已实现的价值或 IT 解决方案？）：其目的是通过 IT 提供支持业务意图的功能来实现业务的价值。让我们来详细地了解一下此概念。
首先，我们必须关注业务价值。IT 的目的不是使用不断发展的新技术来持续更新我们的技能，而是为业务价值作出贡献。
这句话的另一个重要方面就是 IT 不再仅是开发独立应用程序了。相反，我们提供了可组合到一起实现业务流程的各个功能。SOA 的承诺之一是，我们通过它可以在业务组织和 IT 组织（在其中通过使用服务实现业务流程）之间提供一个相互都能理解的语言机制。
最后，我们需要讨论一下 Kerrie 使用的一个有意思的术语：即业务意图。请注意，他没有使用要求、需求 或用例。业务具有意图。当然，用例或 WebSphere Business Integration Modeler 模型可以帮助了解当前的情况和清楚地说明此意图。但此类工具有一定风险，可能会过早地根据 Modeler 假定的解决方案表述问题。
|
IT 的目的不是使用不断发展的新技术来持续更新我们的技能，而是为业务价值作出贡献。
——Simon Johnston |
|
前段时间，曾进行过一次关于描述需求的连续体的 Rational 管理内部讨论，涉及的范围包括从描述业务策略的需求到人员或计算机系统在执行任务时的操作。此连续体包括远景声明、业务目标、关键性能指标 (KPI)、业务流程描述/业务用例（这两个术语可交换使用）、非功能要求，诸如此类。此讨论持续了很长时间，也非常激烈，但却并不一定是因为对此概念存在异议，而是因为存在很多术语问题——该如何称呼这些“东西”。
虽然我们在需求连续体实践中已经取得了成功，但我仍然和 Kerrie 一样认为不可能采用工具解决此问题。该连续体并不是旨在说明我们必须在需求处理方面使用单一的工具，也不是要指出可以使用唯一的方法来描述各种需求之间的转换。不过，我们的确需要一种方法，以据此对所有这些“东西”进行管理。我们需要一个全局视图，以帮助我们了解在从一个需求级别到另一个需求级别的转换期间所做的决策和假设。
另一点与数据相关，但更多地属于业务级别和 IT 级别所给出的声明间的抽象差距。例如，一个业务用户通常会声明某个特定任务的需求——它需要是“安全的”。但这对架构师意味着什么呢？我们有经验的 IT 架构师询问这是否意味着该任务必须保密地执行，还是必须具有防篡改功能或者要求强加密机制或更短暂的内容。业务用户愣了一下，然后有些结巴地说“全-全-全部”。然后，我们讨论如果支持该安全性的所有内容，以在已知且显式信任的边界内将一段简单的数据从一个服务发送到另一个服务，则所需的基础设施的成本是多少，在充分理解之后，业务用户指出他们需要的是确保没有未经授权的用户能够看到他们不应该看到的数据。因此，当我们分析业务用户的需求说明时，我们不能因为他们不懂技术而让他们强行接受某些东西。相反，我们需要获得将这些意图的声明转换为 IT 级别的具体要求的机制。
而这直接意味着我们的确需要更多地利用 RequisitePro，Mark 说从一开始就需要使用这个工具的意见是非常正确的。我们不仅需要能够在 RequisitePro 中捕获业务意图，而且必须利用 RequisitePro 和 Rational Software Architect 之间的联系来跟踪模型，以对业务意图进行反馈。不过，在此消息中存在一个断层，因为 WebSphere Business Integration Modeler 尚未与 RequisitePro 实现集成。这可以通过以下方法得到处理：在 Rational Software Architect 中打开 WebSphere Business Integration Modeler 模型，并将业务模型的 Rational Software Architect 视图与 RequisitePro 相链接。
最近，我对 Rational 业务驱动的开发技术验证进行了更改，以准确地反映以下观点：需要在该过程中尽早引入 RequisitePro，以在开发任何模型——业务模型或 IT 模型——描述解决方案之前捕获真正的意图（如果您愿意，可以将其称为问题）。Don 说明了需求和设计模型为什么经常被视为项目的障碍，而不是价值。在我看来，如果没有链接到一起，一系列需求声明和漂亮的模型仍然是二流构件——而且可能是障碍。
正是通过这个使用 RequisitePro 链接和管理的构件集，开发团队才能了解其在项目中所处的位置，并能作为整体 IT 控制流程的一部分进行项目组合管理决策。
管理不确定性和易变性
 我同意 Don Ferguson 的意见和看法，他已经进行了很好的阐述，我将不对此进行复述，而要增加一些新的东西。2005 年 11 月的 CIO 杂志中也有一篇关于将业务需求转换为 IT 要求的文章“Fixing the Requirements Mess”。我也希望能不重复这其中的内容。
本月的问题也可以表述为：“我如何从业务意图转到已实现的价值或 IT 解决方案？”
业务需求和 IT 要求有很大部分都是重合的；即，对于某些人而言业务需求 指的是“我已更改的或新的业务流程是什么样的？”而对其他人而言，则指的是“我如何借助对应的关键成功因素实现一系列业务目标？”还有些人觉得，这可能只意味着为一系列业务干系人提供功能，如新设备或新页面，或者仅是新的自动化业务规则执行而已。
|
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。
——Kerrie Holley |
|
非常重要的事实是，术语IT 要求 隐含着一个问题：业务需求和 IT 要求之间是否存在差别？这可能会引出一通长篇大论，但我的观点是，缺乏术语以及用来讨论这个问题的共同语言本身就是一个问题。
我们的挑战是业务需求和要求通常仅得到了部分理解，而且通常具有易变性。很多开发方法都在通过引入迭代开发、工具以及其他技术来适应这个不确定性和易变性。但这些方法仅解决了这个问题的一部分，因为这个不确定性和易变性仅是此问题的一部分而已。在假定特定方法是最优的方法之前，要求流程必须了解要进行的项目的类型。
项目类型因大小、范围、组织关心的重点、文化、对解决方案的认识、当前环境以及其他因素的不同而有所差异。各种项目类型要求我们对每个项目采用不同的方式来处理将组织的需求转换为 IT 要求的问题。不同的类型项目要求在开发方法、工具以及应如何管理要求方面采取不同的处理方式。
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。认为可以通过改善工具或创建新开发流程、方法或技术来完全地解决此问题的想法是错误的。
管理很多项目的需求流程需要我们具有确定应在软件中包含哪些东西不包含哪些东西的方法。此过程要求结合使用各种协作技能、辅助技能、工具、技术和方法。
经验丰富的专业人员知道将组织的业务需求转换为 IT 要求的过程中必须根据一系列因素进行调整。这些因素包括：
- 对业务需求了解多少？
- 对 IT 要求了解多少？
- 最终的解决方案的概貌如何？
这些因素在项目进行期间会不断地发生变化。
这正是采用敏捷编程、IBM Global Services (GS) 方法、Rational Unified Process (RUP) 或其他流程的技术人员不能盲目认为其采用的方法就是正确的方法的众多原因之一。没有“万能”方法；这些都是工具。有见识的专业人员必须选择何时以及如何使用正确的工具，并使这些工具与正在开发的项目类型和场景相匹配。
例如，GS 方法在帮助清楚地阐述一些要求必须适应的大环境（如系统上下文、用例、基础结构、安全）方面非常不错。此方法可帮助建立分类，以便我们在讨论 IT 要求 和业务需求 时知道各自明确的对象。
我的 IBM 同事 John Cameron 在一篇关于在启动项目时经常遇到的不确定性分类的文章中谈到了这其中的一些方面。他认为，此不确定性的程度以及我们对解决方案的认识程度在如何将组织的业务需求转换为 IT 要求方面扮演着重要的角色。John 的分析在图 1 中得到了描述，图中根据我们对需求以及项目的了解情况用一个简单的矩阵对项目进行了分类。
图 1. John Cameron 所做的不确定性分类
“Outside-in”设计
 这是个很好的问题，我希望给出而且也能给出一个很好的回答。我想，解决此问题的最重要方法就是在开发流程和开发规则的过程中保持耐心。
很多项目并不能在需要的时候获得前端需求文档与分析以及业务建模。有时候，似乎会存在不利于提高编码效率的未说明的假设。正式的一流需求处理、流程建模和构件建模可能非常费时，但同时也能确保开发过程的结果能完美地满足业务需求。需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求转换为测试用例，团队就没有理解这些需求。
开发也需要进行迭代。我们从 Eclipse 开发和其他项目了解到，我们的开发工作每四到六周就需要生产出可以使用的过渡性版本。该版本应该提供给业务干系人使用，并验证项目是否满足了业务需求。每个过渡性版本阶段均应以一组得到一致认可的并且该版本将满足的需求和用例/场景作为出发点。
|
需求文档和建模工作应定义开发工作输出的测试用例。如果团队无法将需求转换为测试用例，团队就没有理解这些需求。
——Don Ferguson |
|
最后，我们已经开始在 IBM Software Group 内试用一个称为“Outside-in-in design”的概念。在此方法中，我们依赖于以下原则：
- 进行正式的用户建模，包括角色和用户概念对象
- 为与概念对象交互的角色定义一组用例
- 提供用例/场景的低精度和高精度可视模拟（有时简单得像纸上的铅笔画一样。通过这种方式，解决方案的用户可以提供早期评估和反馈。）
- 构建过渡性版本
此过程不是瀑布型的，而是迭代过程。（此方法可帮助提供项目的持续细化，以确保其向提高业务需求和要求的满足程度方向发展。）
使用一点技巧进行迭代和增量改进
 这是大部分业务和 IT 专业人员的圣杯。多年来，各种方法、技术、工具和技巧层出不穷——最后都会通过信息技术不带偏见且不断发展的大门退出历史舞台。但我们不断的求知欲望会让我们再次尝试不同的方式，或许采用头脑风暴的方式……嗯，在尝试不同方法的时候可能会就得到给出的 P=?NP 问题的答案！
对于此问题没有完全标准的答案，以下是我对将干系人需求转换为 IT 解决方案的问题的一些看法：
缺乏用于建立共同环境的一致的术语
通常，业务管理人员所使用的语言与 IT 架构师的语言是不同的。业务分析人员/咨询人员在尝试缩小这个差距，但他们通常会加入自己的业务领越的数据和解释，从而使情况变得更为混乱。更为雪上加霜的是，由于近年来工作和角色的流动性，大多数人会将以前所担任的角色的术语环境和包袱带到新岗位来。我经常在客户会议和需求研讨会上看到术语混淆的情况。
因此，主要需求之一是为在解决方案的业务和技术上下文中使用的所有术语（名词、动词、形容词等）建立清楚、一致、连贯且简洁的（我称为 4C，即 clear、consistent、coherent 和 crisp）定义和语义。这样就为管理人员、分析人员和架构师进行有效的对话建立了基础。是的，为了对术语和模式进行标准化，的确存在跨行业部门——横向和纵向——的协作活动，但这大部分都在早期阶段进行。我对架构师的建议是这样的：不要对术语的含义想当然，要勇于举手要求澄清。
当转到最佳技术角度时的低效率（或能力缺乏）
可以直接将这个问题简单地描述为锤子-钉子综合症。即，如果您是锤子，所有事项都是钉子。此处，人力元素是一个阻碍因素——这源于我们多年的认知条件作用、我们了解的问题分析和综合模式以及我们习惯的技术领域（通常是我们最具专业知识的领域）。
例如：以数据为中心的架构师将需求集看作是由实体和关系组成的。以状态机为中心的架构师则将其可视化为一系列的状态、转换和动作。以流程为中心的架构师将需求组织成经过组合的任务和活动。以对象为中心的架构师则将其视为多态类、接口及其关系。现在，我们有以服务为中心的架构师，他们将需求集当作组合服务组成的拼板。如此等等。每个观点都有其优点和缺点，而架构师务必对每个不同的业务需求或功能应用恰当的视角，这非常重要。显然，决定哪个是“正确的”视角可以看作相当主观的问题，非常有争议。不过，应用正确的方法可以采用最有效、最典雅且最令人满意的方式实现要求。切换视角有些困难，而尝试完成此工作甚至是主题专家 (SME) 讨论的最大的话题。为每个视角配备一个 SME 可能会使得体系结构设计过程争议不断，可能会带来大的反复，并且可能出现“分析瘫痪”。
需求验证、优先排序和可跟踪性方面的问题
务必对业务需求进行评审，并与干系人一起进行分析，以合成真正的业务需求。有各种技术（用例、场景）、概念和相关工具用于捕获此工作的结果。但这个领域不是艺术，并不能靠模仿来掌握，您只能通过全心投入加以适应才能获得相关的专业知识。对每个需求进行了评审后，务必要与干系人就技术看法和一系列解决方案选择（以及成本效益分析）进行沟通。这个步骤可帮助从技术角度验证需求，也进一步使其与未声明的业务需求保持一致。在验证选项时，请通过讨论来确定各种不同需求的优先级，并在需求间建立交叉依赖关系。这些需求的依赖关系有助于创建可跟踪性，而且在出现更改请求时扮演着重要的角色。同样，这也不完全是技术问题。RequisitePro 之类的工具允许您包含一个请求管理模板（基于 RUP 或任何自定义方法），此功能可实现很多方面的自动化，如可跟踪性、需求的状态和构建之间的转换等等。
|
多年来，各种方法、技术、工具和技巧层出不穷——最后都会通过信息技术不带偏见且不断发展的大门退出历史舞台。
——Sanjay Bose |
|
还有其他几个问题，如改变业务优先级、更改操作环境、政治与文化壁垒、技能差距和很多其他问题——都可能妨碍解决方案对需求的满足。我和人合作撰写了一篇 IBM Systems Journal 文章“Impact of SOA on Enterprise Systems, Organizational Structures, and Individuals”，谈了一些对其中一些问题的看法。
最后，正如我在最近接受 IDevNews 采访所说的，将业务需求转换为 IT 系统体系结构的一种不错的方法就是采用迭代增量的方式进行（借用了数学上的渐近法）。
所有需求并非全部同样重要
 成熟的组织了解所有需求并非都同样重要。大多数需求本身对体系结构并没有影响；相反，它们与实现有关。某些需求要比其他需求重要很多，只要了解了这个区别，您就能作出更好的决定，以分配资源满足高优先级的需求。直到系统部署完成之后，需求收集才结束。可执行系统的出现会改变干系人看待问题的方式。
这些评论的一个非常重要的隐含意义——正如 Don Ferguson 所指出的——就是成熟的组织会执行迭代增量的流程，这些流程的主要构件都是可执行的。这样就强行让开发团队有规律地开展工作，新需求可以在开发过程中不断地发现，旧需求会重新确定优先级（有时会将其丢弃），而最重要的，每个需求都会针对实际情况而不是文档进行度量。
了解真正的需求
 我观察到的一点就是，业务部门在了解自己的需求方面并不在行，而 IT 部门如果假设业务部门能够很好地了解自己的需求，则犯了一个很大的错误。就像病人去看医生，要求得到科学的治疗一样，业务部门通常以所需的解决方案来表述自己的需求，而不是他们希望实现的业务成果。在我实际遇到的客户中，业务团队会说“我们需要新的保险索赔系统。”不过，他们真正需要的却是将他们在处理索赔方面的效率提高 X% 或降低成本 Y% ，或者其他类似的说法。新的索赔系统可能提供也可能不提供这个改进，但如果实际需求未知，则几乎可以肯定不会提供这种改进。
|
就像病人去看医生，要求得到科学的治疗一样，业务部门通常以所需的解决方案来表述自己的需求，而不是他们希望实现的业务成果。
——Kurt Bittner |
|
由于不清楚真正的需求，需要将更多的精力放在帮助由业务人员和 IT 人员组成的扩大团队了解真正的需求。通常需要专家级辅助人员来帮助指导讨论并消除争议。我完全同意 Kerrie 所说的，最大的挑战是“人员问题”，这个问题是由业务和 IT 之间的价值认识不一致及目标不同、不同文化和组织间执行不同目标的奖励结构不同而引起的。即使世界上最好的工具也不能克服这个问题，而且，实际上还有可能会使得情况更糟。强大的工具放在不能胜任的工匠手中只会导致材料报废的速度更快。
有时候，回避人为因素，而尝试使用技术解决问题会更为简单一些。人员和组织不喜欢变化，而大部分改进都要求进行大幅度更改，如果不能满足这个要求，通常会导致组织无法缓和所遭遇的文化/价值隔阂问题。
使用表述良好的需求武装业务分析人员
 可以对业务需求进行捕获、解释并转换为将为业务提供支持的功能和非功能 IT 要求。
业务需求是通过对业务流程、业务目标、业务实体类型和决策过程的业务模型的分析捕获的。业务需求应或可以通过一组关键性能指标进行度量，以便提供有关实现要求和满足业务需求方面的成功程度的反馈。
它们是通过一个对变化进行划分、分解、细化、映射和分析的过程（面向变化的分析和设计）解释的。划分是将业务域分解为域组成类型或功能区域。这表示结构划分。业务的分解是对如何将流程分解为子流程和用例的解释。分解过程将创建一个分层结构，而细化过程则将这个分层结构细化为一组可操作的面向目标的交互序列。
|
（业务）流程建模对了解业务如何工作非常重要。有些人更喜欢采取用例建模或业务用例的方式。就最终目的而言，此过程就是记录面向目标的业务活动的动态或流方面的特征。
——Ali Arsanjani |
|
将业务需求映射为 IT 要求的过程需要能证明给定业务要求是可跟踪的，而且受到一组互补的 IT 功能的支持（这些 IT 功能由非功能方面提供支持）。此映射通常通过目标-服务建模完成。我们将逐个研究各个变化，并表示流程、域/功能领域和规则间的共同之处。
将需求转换为 IT 服务的过程可以通过组合使用以下互补的技术来完成：
- 域分解（包括流程分解、功能区域分析和面向变化的分析）
- 目标-服务建模
- 分析现有资产（包括现有系统、打包的应用程序和任何我们可以利用的资产，如标准、框架、各个领域的专用语言等等）
此过程的关键在于在给定时间框架内标识难点和业务相关的驱动因素，更改将存在于此框架外，因而需要应用面向变化的分析。我们将随后以这些重要的出发点为基础，将我们的理解细化为可操作的 IT 要求，可以通过组合功能和非功能要求来满足这些 IT 要求。
简单项目的需求管理在范围和深度方面与一系列业务或企业与价值链都有所不同。我们曾说过，业务需求通常是一个时间点的剪影，可能会发生彻底的变化。业务功能的区分通常不会随着时间而发生彻底变化，而会更加细化。基本功能最后将成为最终解决方案的一部分，但任何情况下都应由 IT 系统加以支持。
每个领域也都在其中嵌入了可以用于表述该领域的问题的语言。了解这个基础语义对于了解需求背后的意图（从而提供满足这些意图的需求）十分关键。
对于 SOA 或基于组件的方法，我建议使用面向服务的建模方法，这个方法在我的 developerWorks 文章“基于服务的建模和架构”有介绍。
（业务）流程建模对了解业务如何工作非常重要。有些人更喜欢采取用例建模或业务用例的方式。就最终目的而言，此过程就是记录面向目标的业务活动的动态或流方面的特征。
业务需求的实现是通过实现一系列基础 IT 功能和非功能要求而达成的。能以声明的方式表达这些要求——使用业务域提供的服务的语法和语义——非常重要。通过这个功能，业务分析人员可以参与到软件开发生命周期中来。
没有捷径，立即动手，不要等待
 IT 架构师在项目的生命周期的初始阶段扮演的主要角色之一是捕获关于干系人的需求的信息。IT 架构师必须听取客户和干系人的看法，理解他们的业务需求，并系统地以增量方式形成 IT 解决方案的结构更为详细的结构。这个过程通常不仅是靠通过经验积累就能完成的，而且必须为一种有所控制的方法。
生活中的两个事实也可应用到 IT 解决方案的开发中：
几乎没有真正的捷径。
最好现在就动手，而不要等待。
我和客户一起工作时，我常常发现在构建 IT 解决方案中为软件开发项目记录的需求级别非常少。这种定义缺乏的原因是由于将业务需求细化为可操作的 IT 要求是一项很困难的工作，需要经验丰富的人员（这就是为什么 IT 架构师是极其宝贵的资源的一个原因）。将业务需求细化为 IT 要求是一项艰巨的任务，需要将精力放在细节上，而且是一个迭代的过程。
此处要指出的是，您必须花大量的时间来详细说明您的解决方案的需求。统计数据表明，在前期花的时间越多，在开发过程的后期阶段花的时间就越少，从而可以缩短开发周期。如果无法足够详细（以便能通过技术加以实现）而清晰地将干系人的需求用书面形式表述出来，您就没有完成捕获项目要求的任务。
有很多方法可用于将业务需求细化为较高抽象级要求，然后再将此类要求细化为技术 IT 要求。建模是从干系人捕获初始功能要求集的一个主要方法。通过创建用例、建模过程流和形成统一建模语言（Unified Modeling Language，UML）交互关系图，您可以开始将业务要求细化为更为详细的定义，系统必须支持或启用所定义的这些功能。在复杂环境中会使用包括以下内容的更为复杂的方法：
这些方法可以确保 IT 要求与业务目标一致，从而让公司能够真正实现 SOA 的价值主张。
|
如果无法足够详细（以便能通过技术加以实现）而清晰地将干系人的需求用书面形式表述出来，则您就没有完成捕获项目要求的任务。
——Holt Adams |
|
从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。架构师从过去项目中获得的经验将影响这些决策，但架构师还必须忠实地对每个要求（对满足需求极为重要的 IT 功能）进行评估。确定了 IT 功能后，架构师可以将这些功能映射为体系结构组件（然后映射到技术和产品），从而以增量的方式向他们的解决方案结构添加更为详细的定义。在开发解决方案的体系结构时，架构师应该利用工具的功能类捕获和管理要求，对业务组织、需求和流程进行建模，细化并将要求映射到 IT 功能，并标识体系结构组件和技术/产品。
|