业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。而这就是我们为了实现高效率而需要着手处理的问题:理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。
一个词:用例
在业务用例中，参与者是干系人，而系统则是业务本身。
用电影《毕业生》中的方式，我只想对你说一个词:用例。很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。
在Alistair Cockburn的《Writing Effective Use Cases》一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。
例如，股票交易Web站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
可以将用例用于对服务进行建模;我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。业务如何开展？客户希望业务如何开展？他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于，这些干系人如何与公司进行交互，这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程—公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司或公司的一部分建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。实现这种自动化的应用程序是采用面向服务的体系结构的应用程序，而现在正在进行 SOA 实践。
记录流程
如果客户不了解业务，架构师有效定义系统要求的几率都很小。
笔者在与客户讨论新程序或开发工作时，会立即了解业务干系人是否出席或派代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”，否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率就很小。
笔者个人非常赞同开发业务场景来记录业务流程，业务场景允许在整个业务问题的上下文中标识系统要求。
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。我极力赞同使用工具来管理要求;为了达成此目的，我建议使用 IBM Rational RequisitePro。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，可以召开联合应用程序开发（JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过JAD会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。
正确功能的正确解决方案
如果我所做的只是将价格信息发布到网上，我可以到最近的小学里找个人来编写HTML。如果我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。
开发和设计解决方案的体系结构时需要考虑的最重要的事项之一就是所需的对应功能和容量级别。
经验丰富的专业人员可以帮助客户将业务需求转换为业务意图。业务意图更为模糊，但更与“基本需求”和“投资回报”一致。
笔者相信业务需求和IT 功能存在重叠。正是由于这个模糊不清的界线使得体系结构设计成为了一个困难而费时的过程。不管是采用瀑布式还是迭代方法，规划和需求分析阶段始终都很单调乏味。客户很少知道他们需要什么，经验丰富的专业人员有责任帮助客户将业务需求转换为IT功能。
这并不能通过只使用良好的工具和方法来实现，因为每个项目都是独特的。尽管两家公司相似，但他们都会告诉你各自的业务具有独特性，并将这些不同之处视为他们的竞争优势。很多时候，文化、地域和地理位置对业务需求的影响决定着IT解决方案。政府法律法规和标准可能要求技术人员根据部署解决方案的场合对相同的业务需求采用不同的方法来设计。
捕获和交付构件的技术，包括用例、场景文档、Rational Unified Process (RUP)—应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要24x7的可用性，而只需要8x7的可用性即可，因为他们不希望承担24x7解决方案所带来的高成本，仍然可以很好地使用这些构件。
管理不确定性和易变性
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。
业务需求和IT要求有很大部分都是重合的;即对于某些人而言业务需求指的是“我已更改的或新的业务流程是什么样的？”而对其他人而言，则指的是“我如何借助对应的关键成功因素实现一系列业务目标？”还有些人觉得，这可能只意味着为一系列业务干系人提供功能，如新设备或新页面，或者仅是新的自动化业务规则执行而已。
重要的事实是:业务需求和IT要求之间是否存在差别？这可能会引出一通长篇大论，但我的观点是，缺乏术语以及用来讨论这个问题的共同语言本身就是一个问题。
我们的挑战是业务需求和要求通常仅得到了部分理解，而且通常具有易变性。很多开发方法都在通过引入迭代开发、工具以及其他技术来适应这个不确定性和易变性。但这些方法仅解决了这个问题的一部分，因为这个不确定性和易变性仅是此问题的一部分而已。在假定特定方法是最优的方法之前，要求流程必须了解要进行的项目的类型。
项目类型因大小、范围、组织关心的重点、文化、对解决方案的认识、当前环境以及其他因素的不同而有所差异。各种项目类型要求我们对每个项目采用不同的方式来处理将组织的需求转换为 IT 要求的问题。不同的类型项目要求在开发方法、工具以及应如何管理要求方面采取不同的处理方式。
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。认为可以通过改善工具或创建新开发流程、方法或技术来完全解决此问题的想法是错误的。
经验丰富的专业人员知道将组织的业务需求转换为 IT 要求的过程中必须根据一系列因素进行调整。这些因素包括:对业务需求了解多少？对IT要求了解多少？最终的解决方案的概貌如何？
这些因素在项目进行期间会不断地发生变化。这正是采用敏捷编程、IBM Global Services 方法、RUP或其他流程的技术人员不能盲目认为其采用的方法就是正确的方法的众多原因之一。
没有捷径，立即动手，不要等待
如果无法足够详细而清晰地将干系人的需求用书面形式表述出来，则您就没有完成捕获项目要求的任务。
IT架构师在项目的生命周期的初始阶段扮演的主要角色之一是捕获关于干系人的需求的信息。IT架构师必须听取客户和干系人的看法，理解他们的业务需求，并系统地以增量方式形成IT解决方案的结构更为详细的结构。这个过程通常不仅是靠通过经验积累就能完成的，而且必须为一种有所控制的方法。
生活中的两个事实也可应用到 IT 解决方案的开发中: 几乎没有真正的捷径;最好现在就动手，而不要等待。
笔者和客户一起工作时，我常常发现在构建 IT 解决方案中为软件开发项目记录的需求级别非常少。这种定义缺乏的原因是由于将业务需求细化为可操作的 IT 要求是一项很困难的工作，需要经验丰富的人员（这就是为什么 IT 架构师是极其宝贵的资源的一个原因），将业务需求细化为 IT 要求是一项艰巨的任务，需要将精力放在细节上，而且是一个迭代的过程。
此处要指出的是，必须花大量的时间来详细说明解决方案的需求。统计数据表明，在前期花的时间越多，在开发过程的后期阶段花的时间就越少，从而可以缩短开发周期。
有很多方法可用于将业务需求细化为较高抽象级要求，然后再将此类要求细化为技术 IT 要求。建模是从干系人捕获初始功能要求集的一个主要方法。通过创建用例、建模过程流和形成统一建模语言（Unified Modeling Language，UML）交互关系图，您可以开始将业务要求细化为更为详细的定义，系统必须支持或启用所定义的这些功能。在复杂环境中会使用包括以下内容的更为复杂的方法:组件业务建模或者面向服务的模型体系结构。
这些方法可以确保 IT 要求与业务目标一致，从而让公司能够真正实现 SOA 的价值主张。
从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。架构师从过去项目中获得的经验将影响这些决策，但架构师还必须忠实地对每个要求（对满足需求极为重要的 IT 功能）进行评估。确定了 IT 功能后，架构师可以将这些功能映射为体系结构组件（然后映射到技术和产品），从而以增量的方式向他们的解决方案结构添加更为详细的定义。
文章来源于领测软件测试网 https://www.ltesting.net/
