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

（一）架構(gòu)、項目與需求的關(guān)系

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

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

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

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

（二）需求的三個層次

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

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

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

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

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

（三）使用業(yè)務(wù)架構(gòu)管理業(yè)務(wù)需求

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

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

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

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

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