需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤，它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发，梳理端到端的跨系统 业务流程；基于业务流程，依据科学的方法论进行服务鉴别；由服务列表出发，梳理服务的消费和提供关系；然后根据 SOA 的最佳实践，定义服务的接口，包括服务的 Schema 描述，字段的类型，编码的规则；依据服务的消费－提供关系，梳理 ESB 中的服务映射和转换规则和策略。
概括而言，我们需要从功能性和非功能性两个方面来进行 ESB 的需求分析。
针对 ESB 的功能性需求，我们要侧重了解以下方面的问题：
1. 梳理出要被集成的系统的名称，个数。
2. 针对每个系统而言，要了解：
  • 该系统的对外接口是向外调用 (OutBound)，被别人调用 (Inbound)，还是二者都有；
  • 接口的实时性要求，是实时的还是批量的，还是二者皆有？
  • 接口的调用方式，是同步的还是异步的，还是二者皆有？
  • 应用系统所运行的操作系统平台。
  • 应用系统本身的编程语言？C/C++, Java…..
  • 这些系统现有接口的情况，是否已经可以提供对外接口，接口的方式是什么，包括接口的通讯协议是什么，HTTP/MQ/Socket/ 其它？接口的数据格式是什么，XML/ 自定义格式 / 其他行业标准格式？接口的编程语言是什么，Java/C/C++？如果本身不能提供接口，那么要做接口开发时有什么要求或限制条件？
  • 这些应用后台数据库的情况，数据库能否直接访问？
  • 每个应用跟其他应用交换数据时，源数据格式和目的数据格式，比如从文本格式转换为 XML 格式？
  • 交易特征：哪些处理要采用两阶段提交；是否需要多个消息组成一个交易；是否要保证消息之间的处理顺序；
  • 适配器的情况：对于一些特殊系统，是否已经具备现成的适配器；适配器是单向的还是双向的；
  • 消息通信的模式：是 Send and Forget、Request/Reply 还是 Pub/Sub?
针对 ESB 的非功能性需求，我们要确认：
1. ESB 平台的扩展性和高可用性需求，包括 HA 和集群等；
2. ESB 平台的性能需求，主要包括系统间数据交换的频率，要交换的数据的大小 ( 消息大小将直接对效率造成影响 )；峰值时候对 ESB 数据吞吐量、响应时间的要求等；
3. 哪些交易要保证数据传输的高可靠性；
4. ESB 平台的可管理性需求，如服务的生命周期管理，ESB 平台的维护和管理；如果企业已经设立了 SOA 管控方面的规范，那么要遵从规范的制约，比如要考虑是否有规定的命名规则，企业是否有企业级的数据规范和底层通讯协议的规范等；
5. 安全性方面的要求：是否采用 SSL 传输加密，是否对消息进行加密/解密处理等；
6. 错误处理和日志以及平台本身的运行监控等方面的要求等。