前段时间，曾进行过一次关于描述需求的连续体的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要求 隐含着一个问题：业务需求和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开发和其他项目了解到，我们的开发工作每四到六周就需要生产出可以使用的过渡性版本。该版本应该提供给业务干系人使用，并验证项目是否满足了业务需求。每个过渡性版本阶段均应以一组得到一致认可的并且该版本将满足的需求和用例/场景作为出发点。

　　最后，我们已经开始在IBM Software Group内试用一个称为“Outside-in-in design”的概念。在此方法中，我们依赖于以下原则：

　　·进行正式的用户建模，包括角色和用户概念对象
　　·为与概念对象交互的角色定义一组用例
　　·提供用例/场景的低精度和高精度可视模拟（有时简单得像纸上的铅笔画一样。通过这种方式，解决方案的用户可以提供早期评估和反馈。）
　　·构建过渡性版本

　　此过程不是瀑布型的，而是迭代过程。（此方法可帮助提供项目的持续细化，以确保其向提高业务需求和要求的满足程度方向发展。）

　　使用一点技巧进行迭代和增量改进

　　这是大部分业务和IT专业人员的圣杯。多年来，各种方法、技术、工具和技巧层出不穷——最后都会通过信息技术不带偏见且不断发展的大门退出历史舞台。但我们不断的求知欲望会让我们再次尝试不同的方式，或许采用头脑风暴的方式……嗯，在尝试不同方法的时候可能会就得到给出的P=？NP问题的答案！

　　对于此问题没有完全标准的答案，以下是我对将干系人需求转换为IT解决方案的问题的一些看法：

　　缺乏用于建立共同环境的一致的术语

　　通常，业务管理人员所使用的语言与IT架构师的语言是不同的。业务分析人员/咨询人员在尝试缩小这个差距，但他们通常会加入自己的业务领越的数据和解释，从而使情况变得更为混乱。更为雪上加霜的是，由于近年来工作和角色的流动性，大多数人会将以前所担任的角色的术语环境和包袱带到新岗位来。我经常在客户会议和需求研讨会上看到术语混淆的情况。

　　因此，主要需求之一是为在解决方案的业务和技术上下文中使用的所有术语（名词、动词、形容词等）建立清楚、一致、连贯且简洁的（我称为4C，即clear、consistent、coherent和crisp）定义和语义。这样就为管理人员、分析人员和架构师进行有效的对话建立了基础。是的，为了对术语和模式进行标准化，的确存在跨行业部门——横向和纵向——的协作活动，但这大部分都在早期阶段进行。我对架构师的建议是这样的：不要对术语的含义想当然，要勇于举手要求澄清。

　　当转到最佳技术角度时的低效率（或能力缺乏）

　　可以直接将这个问题简单地描述为锤子-钉子综合症。即，如果您是锤子，所有事项都是钉子。此处，人力元素是一个阻碍因素——这源于我们多年的认知条件作用、我们了解的问题分析和综合模式以及我们习惯的技术领域（通常是我们最具专业知识的领域）。

　　例如：以数据为中心的架构师将需求集看作是由实体和关系组成的。以状态机为中心的架构师则将其可视化为一系列的状态、转换和动作。以流程为中心的架构师将需求组织成经过组合的任务和活动。以对象为中心的架构师则将其视为多态类、接口及其关系。现在，我们有以服务为中心的架构师，他们将需求集当作组合服务组成的拼板。如此等等。每个观点都有其优点和缺点，而架构师务必对每个不同的业务需求或功能应用恰当的视角，这非常重要。显然，决定哪个是“正确的”视角可以看作相当主观的问题，非常有争议。不过，应用正确的方法可以采用最有效、最典雅且最令人满意的方式实现要求。切换视角有些困难，而尝试完成此工作甚至是主题专家(SME)讨论的最大的话题。为每个视角配备一个SME可能会使得体系结构设计过程争议不断，可能会带来大的反复，并且可能出现“分析瘫痪”。

　　需求验证、优先排序和可跟踪性方面的问题

　　务必对业务需求进行评审，并与干系人一起进行分析，以合成真正的业务需求。有各种技术（用例、场景）、概念和相关工具用于捕获此工作的结果。但这个领域不是艺术，并不能靠模仿来掌握，您只能通过全心投入加以适应才能获得相关的专业知识。对每个需求进行了评审后，务必要与干系人就技术看法和一系列解决方案选择（以及成本效益分析）进行沟通。这个步骤可帮助从技术角度验证需求，也进一步使其与未声明的业务需求保持一致。在验证选项时，请通过讨论来确定各种不同需求的优先级，并在需求间建立交叉依赖关系。这些需求的依赖关系有助于创建可跟踪性，而且在出现更改请求时扮演着重要的角色。同样，这也不完全是技术问题。RequisitePro之类的工具允许您包含一个请求管理模板（基于RUP或任何自定义方法），此功能可实现很多方面的自动化，如可跟踪性、需求的状态和构建之间的转换等等。

　　还有其他几个问题，如改变业务优先级、更改操作环境、政治与文化壁垒、技能差距和很多其他问题——都可能妨碍解决方案对需求的满足。我和人合作撰写了一篇IBM Systems Journal文章“Impact of SOA on Enterprise Systems， Organizational Structures， and Individuals”，谈了一些对其中一些问题的看法。

　　最后，正如我在最近接受IDevNews采访所说的，将业务需求转换为IT系统体系结构的一种不错的方法就是采用迭代增量的方式进行（借用了数学上的渐近法）。

　　所有需求并非全部同样重要

　　成熟的组织了解所有需求并非都同样重要。大多数需求本身对体系结构并没有影响；相反，它们与实现有关。某些需求要比其他需求重要很多，只要了解了这个区别，您就能作出更好的决定，以分配资源满足高优先级的需求。直到系统部署完成之后，需求收集才结束。可执行系统的出现会改变干系人看待问题的方式。

　　这些评论的一个非常重要的隐含意义——正如Don Ferguson所指出的——就是成熟的组织会执行迭代增量的流程，这些流程的主要构件都是可执行的。这样就强行让开发团队有规律地开展工作，新需求可以在开发过程中不断地发现，旧需求会重新确定优先级（有时会将其丢弃），而最重要的，每个需求都会针对实际情况而不是文档进行度量。

　　了解真正的需求

　　我观察到的一点就是，业务部门在了解自己的需求方面并不在行，而IT部门如果假设业务部门能够很好地了解自己的需求，则犯了一个很大的错误。就像病人去看医生，要求得到科学的治疗一样，业务部门通常以所需的解决方案来表述自己的需求，而不是他们希望实现的业务成果。在我实际遇到的客户中，业务团队会说“我们需要新的保险索赔系统。”不过，他们真正需要的却是将他们在处理索赔方面的效率提高X%或降低成本Y% ，或者其他类似的说法。新的索赔系统可能提供也可能不提供这个改进，但如果实际需求未知，则几乎可以肯定不会提供这种改进。

　　由于不清楚真正的需求，需要将更多的精力放在帮助由业务人员和IT人员组成的扩大团队了解真正的需求。通常需要专家级辅助人员来帮助指导讨论并消除争议。我完全同意Kerrie所说的，最大的挑战是“人员问题”，这个问题是由业务和IT之间的价值认识不一致及目标不同、不同文化和组织间执行不同目标的奖励结构不同而引起的。即使世界上最好的工具也不能克服这个问题，而且，实际上还有可能会使得情况更糟。强大的工具放在不能胜任的工匠手中只会导致材料报废的速度更快。

　　有时候，回避人为因素，而尝试使用技术解决问题会更为简单一些。人员和组织不喜欢变化，而大部分改进都要求进行大幅度更改，如果不能满足这个要求，通常会导致组织无法缓和所遭遇的文化/价值隔阂问题。

　　使用表述良好的需求武装业务分析人员

　　可以对业务需求进行捕获、解释并转换为将为业务提供支持的功能和非功能IT要求。

　　业务需求是通过对业务流程、业务目标、业务实体类型和决策过程的业务模型的分析捕获的。业务需求应或可以通过一组关键性能指标进行度量，以便提供有关实现要求和满足业务需求方面的成功程度的反馈。

　　它们是通过一个对变化进行划分、分解、细化、映射和分析的过程（面向变化的分析和设计）解释的。划分是将业务域分解为域组成类型或功能区域。这表示结构划分。业务的分解是对如何将流程分解为子流程和用例的解释。分解过程将创建一个分层结构，而细化过程则将这个分层结构细化为一组可操作的面向目标的交互序列。

　　将业务需求映射为IT要求的过程需要能证明给定业务要求是可跟踪的，而且受到一组互补的IT功能的支持（这些IT功能由非功能方面提供支持）。此映射通常通过目标-服务建模完成。我们将逐个研究各个变化，并表示流程、域/功能领域和规则间的共同之处。

　　将需求转换为IT服务的过程可以通过组合使用以下互补的技术来完成：

　　·域分解（包括流程分解、功能区域分析和面向变化的分析）
　　·目标-服务建模
　　·分析现有资产（包括现有系统、打包的应用程序和任何我们可以利用的资产，如标准、框架、各个领域的专用语言等等）

　　此过程的关键在于在给定时间框架内标识难点和业务相关的驱动因素，更改将存在于此框架外，因而需要应用面向变化的分析。我们将随后以这些重要的出发点为基础，将我们的理解细化为可操作的IT要求，可以通过组合功能和非功能要求来满足这些IT要求。

　　简单项目的需求管理在范围和深度方面与一系列业务或企业与价值链都有所不同。我们曾说过，业务需求通常是一个时间点的剪影，可能会发生彻底的变化。业务功能的区分通常不会随着时间而发生彻底变化，而会更加细化。基本功能最后将成为最终解决方案的一部分，但任何情况下都应由IT系统加以支持。

　　每个领域也都在其中嵌入了可以用于表述该领域的问题的语言。了解这个基础语义对于了解需求背后的意图（从而提供满足这些意图的需求）十分关键。

　　对于SOA或基于组件的方法，我建议使用面向服务的建模方法，这个方法在我的developerWorks文章“基于服务的建模和架构”有介绍。

　　（业务）流程建模对了解业务如何工作非常重要。有些人更喜欢采取用例建模或业务用例的方式。就最终目的而言，此过程就是记录面向目标的业务活动的动态或流方面的特征。
　
　　业务需求的实现是通过实现一系列基础IT功能和非功能要求而达成的。能以声明的方式表达这些要求——使用业务域提供的服务的语法和语义——非常重要。通过这个功能，业务分析人员可以参与到软件开发生命周期中来。

　　没有捷径，立即动手，不要等待

　　IT架构师在项目的生命周期的初始阶段扮演的主要角色之一是捕获关于干系人的需求的信息。IT架构师必须听取客户和干系人的看法，理解他们的业务需求，并系统地以增量方式形成IT解决方案的结构更为详细的结构。这个过程通常不仅是靠通过经验积累就能完成的，而且必须为一种有所控制的方法。

　　生活中的两个事实也可应用到IT解决方案的开发中：

　　·几乎没有真正的捷径。
　　·最好现在就动手，而不要等待。

　　我和客户一起工作时，我常常发现在构建IT解决方案中为软件开发项目记录的需求级别非常少。这种定义缺乏的原因是由于将业务需求细化为可操作的IT要求是一项很困难的工作，需要经验丰富的人员（这就是为什么IT架构师是极其宝贵的资源的一个原因）。将业务需求细化为IT要求是一项艰巨的任务，需要将精力放在细节上，而且是一个迭代的过程。

　　此处要指出的是，您必须花大量的时间来详细说明您的解决方案的需求。统计数据表明，在前期花的时间越多，在开发过程的后期阶段花的时间就越少，从而可以缩短开发周期。如果无法足够详细（以便能通过技术加以实现）而清晰地将干系人的需求用书面形式表述出来，您就没有完成捕获项目要求的任务。

　　有很多方法可用于将业务需求细化为较高抽象级要求，然后再将此类要求细化为技术IT要求。建模是从干系人捕获初始功能要求集的一个主要方法。通过创建用例、建模过程流和形成统一建模语言（Unified Modeling Language，UML）交互关系图，您可以开始将业务要求细化为更为详细的定义，系统必须支持或启用所定义的这些功能。在复杂环境中会使用包括以下内容的更为复杂的方法：

　　·组件业务建模 (Component Business Modeling)
　　·面向服务的模型体系结构

　　这些方法可以确保IT要求与业务目标一致，从而让公司能够真正实现SOA的价值主张。

　　从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。架构师从过去项目中获得的经验将影响这些决策，但架构师还必须忠实地对每个要求（对满足需求极为重要的IT功能）进行评估。确定了IT功能后，架构师可以将这些功能映射为体系结构组件（然后映射到技术和产品），从而以增量的方式向他们的解决方案结构添加更为详细的定义。在开发解决方案的体系结构时，架构师应该利用工具的功能类捕获和管理要求，对业务组织、需求和流程进行建模，细化并将要求映射到IT功能，并标识体系结构组件和技术/产品。