1．定義
需求工程，是指采用工程化的方法和標準，收集、記錄和分析客戶對信息化的需求，並最終確定系統需要實現的功能以及功能的相關特征和約束。需求工程包含三個主要的部分：需求調研、需求分析、需求管理。
註：關於需求管理
需求管理是需求工程中非常重要的內容，包含對需求的跟蹤、控制、變更、版本管理等內容，它是保證系統的內容、質量、進度的重要手段，需求管理的內容更加偏重於軟件的過程管理。
2．作用
需求工程的作用歸集為壹句話就是：收集客戶想要做什麽，最終確定實際做什麽。
對於壹個應用軟件的開發來說，需求工程成果的質量極大地影響著這個軟件的設計結果，是決定成敗的主要環節，從客戶那裏完整地獲取、記錄、分析與確認需求，並正確地傳遞給後續的工程是壹個需求分析師的必備能力。需求工程的分析成果形成的需求規格說明書不但是後續設計與開發的依據，同時也是客戶對完成系統評估、驗收的依據。
另外壹方面，需求工程的內容也極大地影響著軟件開發的成本、技術、周期、資源、質量以及最終客戶的滿意度等諸多方面。需求工程的成果不但會影響客戶最後獲得的效果，也會影響到軟件開發者的最終利益。
需求工程的核心工作是需求調研和需求分析，最終的主要交付物有兩個。
1）需求調研成果（需求調研資料匯總）
從客戶現場通過面對面的調研收集到的第壹手需求資料，包括用圖形、文字和表格等方式記錄的原始資料，形成需求調研資料匯總。
2）需求分析成果（需求規格說明書）
基於前述的調研資料進行分析，識別出最終需要進行開發的全部內容，並且通過客戶確認，最終形成需求規格說明書，這是後續設計、開發過程的依據。
1．需求的收集與確認
從客戶不清晰的原始需求到可以進行編碼開發的過程中，對收斂貢獻最大的部分是②需求工程，而比較容易進行規範化、標準化作業的是③～⑤的部分。②將①的復雜內容梳理並形成了清晰的需求說明規格書。③將②的成果再進壹步抽提、轉換成為架構、功能和數據的設計成果。④將③的成果再進壹步抽提、轉換為組件、機制的構成方式。⑤將④的成果用編碼的形式開發成為最終的軟件。
從圖形的推進變化上可以看出，需求工程②擔負著將原始需求①的內容理出頭緒並形成壹份清晰明了、可以確認的需求規格說明書的任務；而③～⑤的壹系列工作，越靠後的部分就越單純，復雜度降的越低，要做的事就越收斂。②需求工程是開拓者，它擔負了最為雜、亂、累的工作，從客戶原始需求到編碼的5個步驟中對收斂起的作用最大。②部分圖形的收斂越大（梯形的坡度大），③以後的設計開發的圖形就越接近於正矩形，工作就越順利，否則②～⑤都是大坡度的梯形時就說明需求工程做的不到位，在後續的設計和開發中會不斷地發現前期的需求有問題而造成返工。
註：關於“收斂”的含義
收斂，指的是將復雜的原始需求，歸集成為可以進行標準化作業的過程。標準化的作業內容是不受需求影響的，不論需求是否復雜其內容都是固定的。
2．需求，並非都是來自於客戶調研
構建信息系統的需求是否都是從客戶那裏獲得的呢？這個問題反映出了完成的系統中有多少內容是經過軟件工程師（包括咨詢、需求、設計、開發、實施等）提案的，這些提案往往包含更多的高級需求、更多的附加價值，需求的來源有多個。
1）基本需求
基本需求來自於對客戶進行的“調研”，這類需求以功能需求為主，基本上按客戶意願進行設計和開發，內容大部分在需求調研、需求分析階段內確定。
2）中級需求
中級需求不是客戶直接提出來的功能需求，而是在需求分析階段、業務設計階段通過對客戶提出來的業務需求進行轉換、優化、補缺、提升的過程中產生的需求，也就是為完善業務而產生的需求。
3）高級需求
高級需求主要來自於軟件工程師根據本次客戶的目標需求、新的設計理念、新技術等而提出，也就是說，高級需求是軟件工程師設計出來的需求，例如，“事找人流程設計（架構）”“按照任務設計組件（功能）”“數據的復用（數據）”等。“設計需求”需要軟件工程師有足夠的知識和能力。
上述三個需求來源的獲取難度順序為高級需求＞中級需求＞基本需求。
軟件工程師要認識到，需求工程（調研與分析）完成了，並非是需求獲取的工作全部完成了，只是由客戶直接提出來的需求完成了，而通過設計工程的需求發掘尚未開始。
註：高級需求會影響開發成本這裏只考慮如何發掘有價值需求的方法，不考慮新需求帶來的開發成本問題。
需求通常分為兩大類，即功能性需求和非功能性需求。
功能性需求是系統必須要提供的業務處理功能，也是軟件需求的主體。通常所說的需求前面沒有形容詞時指的都是功能性需求。
獲取的需求可以分為三類，它們之間存在著轉換關系，按照轉換的順序分為： 目標需求、業務需求以及功能需求。
目標需求：客戶提出的信息化的目標、理念、希望、價值。
業務需求：客戶提出的系統要對應業務的內容、過程、規則等。
功能需求：確定系統必須提供的處理業務需求的功能及功能的具體描述。
非功能性需求是指建立壹些指標性的條件來判斷系統運行情況，而不是針對某個業務處理的具體功能需求，它們被用來判斷運行的系統是否可以滿足以下的條件：安全性、可靠性、互操作性、健壯性、易使用性、可維護性、可移植性、可重用性、可擴充性等。
售前咨詢的結果中包含著很多對需求分析、業務設計而言非常重要的輸入，特別是很多的“目標需求”來源於此，目標需求對後續信息系統整體規劃、頂層設計有著非常重要的影響
1．售前咨詢的內容
在進入到設計工程之前的階段，與客戶的所有交流和溝通的目的都是在獲取需求，特別是對大型項目來說，簽訂合同之前通常會有壹個售前咨詢階段，在這個階段壹般軟件商會派出經驗比較豐富的咨詢師（如專家型咨詢師）來與客戶進行交流，探討根據客戶的需求可以提供什麽樣的解決方案，這個階段的咨詢具有以下幾個特點。
● 合同尚未簽訂，具體信息系統做什麽內容尚未確定，能否簽約取決於咨詢的結果。
● 此時客戶方面的參與者多為企業高層，如經營者、高級管理者以及信息化主管等。
● 客戶的需求多為目標需求、業務需求甚至是難度痛點等內容，較少談及功能需求。
● 需求會涉及企業的發展戰略、現存的主要問題及公司對信息化的期待等內容。
● 交流中談到的內容可能會比較抽象，需求也多為隱性需求，是否能夠成為真實需求需要咨詢師去引導、判別、確認等。售前咨詢通常談到的都是相對高端的需求，它們是後續需求分析中“目標需求”的主要來源，是企業經營管理者對信息系統的價值期望（盡管可能是用隱性方式提出的），在後續所謂的“需求調研”階段中，往往可能就沒有機會再去直接聽取企業高管的需求了，所以這個部分的內容要作為非常重要的需求記錄下來，作為後續需求分析的重要參考素材。
2．售前咨詢與需求工程
售前咨詢的方式非常依賴於咨詢師個人的能力和魅力，它並沒有特別規範和標準的交付物以及模板，因此沒有將咨詢工作明確地列入到需求工程中（軟件商不同可能劃分方法不壹樣），這兩者的重點不同。
（1）售前咨詢：重點是通過售前咨詢活動，提出解決方案，協助銷售部門簽下合同。
（2）需求工程：重點是進入客戶現場，對已經確定的合同內容進行詳細的調研。雖然咨詢的主要目的是促成簽訂合同，但是咨詢階段收集到的信息是非常重要的需求工程分析對象，尤其是“目標需求”。
3．咨詢師的作用
（1）咨詢師，代表的是軟件企業的最高專業水準，他應該是軟件商的名片。
（2）咨詢師是全面闡釋軟件商的理念與主張的傳道士。
（3）咨詢師建立的起點高，則整個項目的起點高，總價值也會高（對軟件商與客戶雙方）。
（4）咨詢師要能夠利用儲備的知識和經驗，為客戶的決策者充當顧問、參謀。
（5）咨詢師的工作重點是要與客戶項目的決策人進行溝通，獲取客戶的目的、期望等目標需求。
4．咨詢師的能力要求
對於從事售前咨詢的專家型咨詢師來說，對他的要求就比較高了，主要體現在以下幾個方面（不限於此）。
1）溝通能力溝通的對象有客戶的決策層，生產、財務等中間管理層，對能力的要求較高，例如，
● 理解：是否能夠理解高層的談話要旨、隱含的需求？
● 展示：能否充分地展示出軟件企業的服務能力、產品能力？
● 說服：能否說服客戶，例如，導入系統後要在組織或管理制度上做相應的改變？等等。
2）專業能力對咨詢師而言，對他的專業能力要求是綜合的。
● 是否掌握行業咨詢的基本知識？
● 是否熟悉客戶的主營業務和輔營業務知識？
● 是否基本清楚軟件行業的最新技術、匹配的案例、解決方案等。
需求工程的工程分解分為兩個階段，即需求調研階段和需求分析階段
需求調研階段的主要工作有兩個：需求調研，資料匯總。
（1）需求調研：利用問卷、現狀構成圖、訪談記錄、既存表單的方式收集客戶的需求。
（2）資料匯總：將調研過程中收集到的資料進行匯總，形成需求調研資料匯總，作為需求分析階段的分析依據。
需求分析階段的主要工作有兩個：需求分析，資料匯總。
（1）需求分析：基於需求調研資料分析客戶的需求，最終確認系統需要實現的功能。
（2）資料匯總：將分析成果資料進行匯總，形成需求規格說明書，作為後續的各個設計階段的輸入。
1．需求調研
目的主要是收集、記錄客戶對信息化的需求，重點是對內容的“記錄”，而不是“分析”或是“設計”，避免因為分析與設計融入了需求分析師個人的見解，需求調研階段的資料壹定要保持其“原始性”（使用需求模板是為了使記錄內容標準化、格式化）。
2．需求分析
在對需求調研資料的理解基礎之上，進行了抽提、歸類、梳理，同時根據分析補全了調研時的斷點，並且采用比較規範的方式進行了表述，重要的是：需求分析師通過對目標需求、業務需求等高端需求的分析加入了個人的理解，以及對企業信息化提升有價值的意見，所以需求分析的結果與原始記錄之間會發生不同，需求分析師的理解代表了軟件開發團隊的理解，並以此為基礎向客戶進行確認，最終稿就形成了向下壹個設計環節的輸入資料。
所以說，需求分析師的能力會最終影響到信息系統的內容、技術、成本和周期等。
3．二者的關系
兩者都采用非技術設計用語描述，需求調研采用“客戶用語”進行記錄，需求分析采用“業務設計用語”表達分析的結果。在工作目的上兩者有所不同，例如：需求分析做的業務流程圖必須具有業務的完整性，且符合業務流程的標準表達方式；而需求調研收集到的業務流程圖可能是片段的、不連續的流水賬。需求分析對需求實體的內容進行了抽提、分類，建立了需求體系表；需求調研階段不要求這個梳理，只進行原始的收集和記錄即可（要保留原始狀態）。需求分析成果的作用有兩個：向前端的客戶確認，向後端輸出設計依據；需求調研的成果僅僅是向需求分析提供資料。兩者最大的區別如下。
（1）需求調研：著眼於對原始需求的收集、記錄。
（2）需求分析：著眼於從整體上理解、歸集、確認，需求分析不是對需求調研的重復。
需求工程階段完成的資料對後續的各個設計階段的影響
（1）需求調研：收集、梳理客戶的原始需求。
（2）需求分析：調研資料只提供給需求分析，不能被設計所直接引用（可以參考）。
（3）概要設計：要完整地對需求分析的結果全面覆蓋，給出規劃。
（4）詳細設計：原則上是針對概要設計的成果進行細節設計。
（5）應用設計：對需求分析中關於應用方面的要求給出系統實現的方法。
（6）技術設計：對需求分析成果中的非功能性需求、技術需求做出響應。
（7）、（8）開發～測試：不能將需求分析的成果作為開發與測試的依據（可以參考）。
（X）系統驗收：客戶對系統的最終驗收是依據需求規格說明書進行的。?
需求調研並不是按照工作的順序或是調研內容之間的關系去進行的，因此不存在嚴格意義上的工作分解，它是按照需求表達形態的不同進行劃分的，需求表達的形態分為三個類型。
（1）圖形類：包括表達客戶業務現狀的圖形、用界面表達的需求等。
（2）文字類：通過問卷、訪談記錄形式收集的用文字表達的需求。
（3）表單類：客戶提供的實際報表、單據形式的需求。
這三種類型的資料相互之間沒有必然的關聯關系或是順序，可以同時進行收集。
需求調研的結果經過梳理，將非功能性需求分離後剩下的都是功能性需求，可以按照功能性需求的定義將它們分為：目標需求、業務需求和功能需求，這三者存在著目標需求→業務需求→功能需求的轉換關系。嚴格地講，它們不是三種類型的需求而是需求的三個層次，最終只有成為第三層的功能需求才能在系統中實現。分析階段的工作分解就是按照這個順序確定的。
（1）第壹層工作：對目標需求的分析、向業務需求的轉換。
（2）第二層工作：對業務需求的分析、向功能需求的轉換。
（3）第三層工作：對功能需求的分析和確定。
建立相應的需求體系，沒有這個需求體系，就是用個人的經驗來解決客戶的問題，有了這個體系，就可以做到用集體的經驗和智慧來解決客戶的問題。這裏需求體系主要指的是建立“業務需求”。
建立了需求體系可以帶來很多的價值，試舉幾例如下。
1．體系化的知識積累
（1）研究與實踐的成果可以有條理地進行積累，包括：理念、方法、標準、規範等。
（2）客戶價值的積累，包括：不同業務領域、行業、板塊、系統、模塊、功能等。
2．商業規模化的需要
（1）提升軟件企業的價值，可以為客戶提供體系化的解決方案。
（2）抽提、規劃、建立新的商業模式，對客戶的需求進行快速響應。
3．降低成本提高效率
（1）積累的知識可以得到有效的復用、***享，降低成本。
（2）可以大幅度地縮短開發周期，同時可以幫助減少“需求失真”現象。
4．規避風險的首要措施
（1）規避風險的最佳方式是讓每個人事先知道該如何做，有了體系支持就可以做到。
（2）人的能力不足、調研分析時間短的問題，可以用知識庫幫助解決。
5．快速培養人才的捷徑作為需求分析師，被要求具有很多的能力，例如“業務能力”“溝通能力”“抽象能力”“表現能力”等，但這太抽象，難以理解，而且非壹日之功。建立壹個可以提供大多數人直接參考和***享的知識庫，可以讓需要者“有序可循”，它像壹個“業務平臺”，可以讓大家提供經驗、分享知識，並由大家***同維護。
需求工程可以說對每個從事軟件行業的人員來說都是基礎知識。因為它的核心內容是：
（1）如何與他人交流，如何快速地理解他人的想法，如何向他人傳遞想法等？
（2）對壹個復雜的、不熟悉的研究對象如何快速找到切入點？
（3）如何將壹個不清晰的對象，用簡單的語言、圖形或是表格的方式表達出來？
（4）如何將客戶用語（知識、經驗）表達的需求轉換為業務設計用語的表達方式？等等。
? 管理信息系統的需求數量多少、需求的附加價值高低，取決於客戶對信息化的目的和需求分析師的能力，需求分析師的位置通常是夾在前面的“咨詢師”和後面的“業務設計師”之間，當軟件企業具有這兩個崗位或是該項目配置有這兩個崗位時，需求分析師自身能力對項目的影響可以在某種程度上得到控制，如果軟件企業沒有其他兩個崗位或是本項目沒有配置這兩個崗位，那麽需求分析師就決定了這個項目的最高水平（企業管理型項目的最高水平通常是由業務設計師決定的），因此他就必須要掌握壹定的咨詢和業務設計知識。
需求工程，以設計輸入為要求標準
需求工程不但是壹門“知識”，同時也是壹門可以定性定量執行的“技術”，它有模板、有流程、有標準，更重要的是它與後續的設計有著嚴格的傳遞與繼承關系，由於有了設計的範圍、內容、格式等作為需求工程的產出標準，所以需求工程要做的內容就非常具體、規範，作為壹門“技術”的需求工程的可操作性大為提升。建立以設計輸入為需求工程標準的方法，可以提升設計質量、產品質量以及工作效率。