尽量保持简单（keep it simple, stupid，KISS）。对于任何希望使用该服务的人而言，实际使用该服务的过程是否足够简单？此需求既是业务需求，也是技术需求，必须认真加以分析。尽可能少地对服务的任何潜在使用者的业务和技术成熟度进行假设。服务应该方便调用，能正常工作，具有良好的错误报告能力，且通常能够与其他服务进行集成。成熟度较低的企业应该能够使用您的服务，而且不需要在技术方面进行大量资金投入，也不需要对其业务流程进行较大的更改。
全面“考虑”。需考虑可用性、可伸缩性、可靠性等等。这些如何从业务角度影响您的 SOA？确保业务和技术团队保持同步。
全球化。是否需要针对国际用户对您的服务进行本地化？这会对性能、可用性、容量等造成何种影响？
一般来说，捕获这些基本类别中的需求是一个很不错的起点。当然，每一步都包含很多细节，需要投入大量的精力进行计划和协调，还需要很好地对项目进行管理。不过，这些有关需要捕获的信息类型的指导方针可帮助您定义自己的需求流程。
您的企业 SOA 的技术需求
当从技术角度看待企业 SOA 时，需要仔细考虑总体的体系结构。对服务平台的可用性、可伸缩性、性能、可靠性等等的要求要比在非 SOA 环境中更为重要。如果基础设施无法满足这些需求（您没有办法确切预测这些需求或针对这些需求制定相应的计划），则会极大地增大丢失业务的风险。因此一定要谨慎：要事先进行计划，并保持沟通渠道的畅通。应主动了解相关业务趋势以及如何使用您的 SOA 中的服务、正在构建哪些新服务、服务使用者趋势等等。遵循流程，积极进行容量规划、管理和监视，并主动进行故障排除工作。
从软件体系结构的角度而言，需要确保随时关注不断变化的 SOA 技术、标准和框架。您服务的使用者可能会使用各种可用技术，因此需要持续地关注技术趋势，并尽可能多地针对新兴技术对服务进行测试。针对互操作性制定相应计划——或者从技术选择的角度预测互操作性挑战。
需求流程回顾
无论使用正式的工具（如 IBM® Rational® RequisitePro®、CaliberRM 或 iRise Application Simulator），还是使用非正式工具（如 Microsoft® Office Word 或 Visio），所有典型的需求流程都适用于 SOA 项目。制定两个流程来为您的企业 SOA 收集需求：一个用于收集各个服务的需求（如本系列第二篇文章中所述），另一个用于收集关于服务如何适应现有 SOA 的需求（如本文中所述）。
创建自己的用例模板或需求文档或任何用于捕获需求的工具，但要确保具有映射到这两个流程的两个不同部分。可以继续使用前一篇文章中所示的用例模板，或对其进行扩展，以捕获企业 SOA 服务的其他相关部分。