在企業級業務架構實施階段，除了從架構規劃直接產生的項目，業務部門會提出各類業務需求。如何處理這些需求？如果還是按老辦法處理，那么新的業務需求的提出，就是企業級業務架構崩壞的開始。使用業務架構有效管理業務需求成為保證企業級架構穩定、長期有效的重要基礎性工作。

（一）架構、項目與需求的關系

業務架構是對業務的結構化表達，是一種高級的需求管理方法。業務架構定義了業務的結構，包括有哪些業務組件，以及組件和組件之間的關系。一旦業務架構規劃完成，業務架構就相對固定下來，作為一段時間內從業務到技術的“作戰地圖”，指導從業務需求到技術實現的過程。

業務需求是隨時都會存在的，是動態變化的。過去的信息化建設模式是需求驅動的，就是業務部門提出需求，科技部門提出解決方案并開發系統，結果是形成了一個又一個煙囪，導致系統割裂、數據孤島。企業級業務架構是對公司業務的整體結構化描述。在架構指導下的信息化建設模式下，需求要按照業務架構進行管理，所有業務需求都要在業務架構中找到自己的位置。

項目是對需求的實施，包括業務實施、數據實施和系統實施。在項目過程中實現了需求，同時保證了架構遵從，部分情況下也更新了架構資產。

項目實施完畢，將項目成果部署到實際業務當中。然后在業務運行又會產生新的需求，不斷往復循環。

（二）需求的三個層次

需求是分層的，不同環節處理的需求層次不同。

世界公認的軟件需求工程專家Karl Wiegers在其經典著作《軟件需求》中將需求分為業務需求，用戶需求和系統需求等三個層次。

1.業務需求（Business Requirements）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求。這份文檔有時也被稱作項目憲章（project charter）或市場需求（market requirement）文檔。

2.用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件-響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。其產出是《用戶需求說明書》和交互原型。

3.系統需求（system requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。系統需求描述的是開發人員需要實現什么，滿足哪些功能需求和非功能需求。其產出是《軟件需求規格說明書》文檔。

（三）使用業務架構管理業務需求

1.主要精力應投入到新流程、新系統的建設當中來，舊系統在保證其運行正常的前提下做最少維護。這是最基本的原則，必須遵守。不然目標和資源之間就無法匹配，有失敗的可能性。

2.要做好業務需求的入口管理，對原始需求進行篩選，明確“做不做”。要從企業級視角審視業務需求，需求有沒有業務價值，是否符合公司發展戰略，有沒有可衡量可評價的業務目標，業務邏輯是否走得通，技術上有沒有可行性，這些都需要進行考量，篩選出有價值的業務需求進入到下一環節。互聯網行業中對需求也有一個篩選標準，就是“高頻、剛需、痛點”，高頻就是使用次數很多，不斷重復，剛需就是沒有不行，痛點就是存在困擾客戶或用戶的重大問題，符合這些條件的需求是好需求，滿足了這些需求，會提高客戶/用戶滿意度，會帶來較高的業務價值。這一階段處理的需求層次是業務需求。需要建立需求池或需求存儲庫來記錄和管理所有業務需求。

3.做好企業級架構管控，對新的業務需求意向要進行統籌分析。必須按照業務架構方法進行解構，明確其所屬的業務組件。所有業務需求都應該納入到業務架構中，在業務架構中找到自己的位置。大部分業務需求可以直接在業務架構中找到明確的業務組件，少部分則需要對業務架構進行擴展設計，將其容納進來。

4.PMO分配項目任務給組件開發團隊。業務需求各就各位了，再由PMO根據業務優先級確定實施順序，匹配資源，形成項目任務。實施團隊也是按照業務組件來劃分的，包含了業務人員、需求人員和技術人員。PMO將項目任務分配給組件開發團隊，該團隊負責對同一個業務組件進行建設、維護和持續升級。

5.組件開發團隊進行需求分析，形成解決方案。組件開發團隊對同一業務組件的多個業務需求進行分析，進行需求的歸并整合，形成解決方案，納入到業務組件的模型當中來。模型本身有升級的，要沉淀到架構資產當中來。需求調研、需求分析和撰寫需求文檔的工作是由組件開發團隊完成的，這一階段處理的需求層次是用戶需求和系統需求。