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

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

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

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

項目是對需求的實施，包括業(yè)務實施、數(shù)據(jù)實施和系統(tǒng)實施。在項目過程中實現(xiàn)了需求，同時保證了架構遵從，部分情況下也更新了架構資產。

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

（二）需求的三個層次

需求是分層的，不同環(huán)節(jié)處理的需求層次不同。

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

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

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

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

（三）使用業(yè)務架構管理業(yè)務需求

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

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

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

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

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