盡量保持簡單（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 服務的其他相關部分。