让我们回顾一下需求分析的历史，然后讨论SOA中如何来进行面向服务的分析和建模吧。
软件工程方法中，需求分析的方法跟问题域的复杂度和类型紧密相关。在早期，计算需求主要来自科学计算，其抽象手段主要是“数据结构+算法”。在沟通需求的时候，技术人员跟业务人员以自然语言为基础来沟通，然后以过程和/或函数以及数据结构为主要抽象手段，来建立分析模型。分析结果包含过程/函数、流程图、数据流图，复杂一些的，引入模块和子系统来分割。然后，用自然语言描述为主的文档来作为沟通的手段。如果我们还记得关于GOTO的讨论，我们了解，这个计算时代经过多年的发展，推动了结构化编程的发展和成熟。
伴随着商业计算逐渐成为主流，商业计算从早期类似于科学计算的财务等，转向更为广泛的领域，其计算的复杂度和类型，发生了很大的变化，这中间各种数据库技术曾经领衔主演了一段时间，我们按下不表。这期间，在“软件危机”的推动下，对象成为基本的抽象手段，将其高度内耦合的数据、状态和行为结合在一起，不仅提高了抽象度，也自然地反映人们认识和描述这个世界的方式。经过多年的实践、争吵和合作，人们总结出了很多关于对象分析和建模的方式，组件、接口、各种分析和设计模式，逐渐地被认识和流行，UML建立了图例和文档规范，以便沟通。这是软件界的一个巨大进步。在这种软件工程方法中，技术人员通常用自然语言同业务人员沟通，然后用“Use Case”（用例）来建立各种角色所看到的系统边界，再辅助以用户交互（UI）等必要的其他模型，建立一个系统的分析视图，然后，以对象（和组件）为基本手段，建立系统的分析模型，最后，用UML和一些过程如RUP提供的文档模板为基础，提供需求分析结果。这种分析方法，今天非常流行，也很有效。
但是，商业计算的情况再次发生巨大的变化——“整合”和“灵活性”成为主要的需求。经过几十年的发展，商业计算已经不再是过去白手起家的时刻，我们已经有了很多的“历史”，那就是我们已经建立起来的这么多的系统：每个企业都有IT系统，少到几个、几十个，多到几千甚至上万。人类花了这么多钱、这么多时间在这些系统上，没有了这些系统，核心业务会崩溃。但这些系统也给我们带来了巨大的麻烦——它们能够满足不同业务部门（Line of Business，LoB）的垂直需求，可是相互不往来、也不能或者很难相互往来，难以满足跨业务部门的水平需求，更不要说在今天这个平的世界里，如何将合作伙伴、客户连接起来，建立一个动态的商业价值网络。但是，全球化的经济结构和运作模式，互联网作为全球化的IT基础设施，从商业和技术两个角度，透过竞争，既给富有创新和执行能力的企业带来了一个前所未有的商业机会，又迫使跟随的企业不得不起而迎战——将业务模式调整到以客户为中心，将自己内部的业务系统连接起来，水平整合业务活动成为端到端的业务流程，透过这些流程，让整个公司的员工可以自由地得到业务活动需要的信息，轻松地相互协作，从而将整个企业的运作模式转化为一个扁平的结构，打破业务部门的边界，极大地提高企业的效率，得到更好的客户满意度。即便如此，用户需求、市场情况、商业环境的快速变化作为这个时代的特点，要求企业能够快速调整自己的商业模型，因此，在整合的基础上，还要加上快速应变的灵活性要求。这就涉及到了软件的两个魔鬼：复杂度和演变。全面整合（整个企业，客户，合作伙伴）的系统，其复杂度再次提升，而灵活应变能力，在一个整合的世界里，大家都变，自己也没办法以不变应万变，究竟如何因变？所以，我们需要发展软件系统的构造方法，它既可以帮助我们将问题域进行良好的分割，分解映射为分布世界里的独立单元，又可以
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
