筆者在諮詢實踐中總結了針對軟體需求工程的12條最佳實踐，羅列如下。所謂最佳並非嚴密的邏輯證明，而是經過大量的實踐與觀察依據經驗確定的，智者見智，仁者見仁，有爭議在所難免，僅供參考，能夠對大家有所啟發，足矣。
1 成立甲乙雙方參與的需求控制組
專案的成功不單是乙方的成功，而是甲乙雙方的成功，甲乙雙方緊密配合，互相理解，互相合作才能成功，需要避免一方獨大，一方具有絕對控制權的現象，所以成立甲乙雙方參與的需求控制組是避免需求蔓延的有效手段。該組織具有對需求的決策權，對於每項需求的增刪改都要平衡了進度、質量、投入後才能確定，該組織不能是乙個流於形式的組織，應切實地參與到需求的獲取、描述、分析、確認、變更等活動中。
2 識別合適的需求提供者，尤其不要遺漏了終端使用者
在獲取需求時應該首先識別誰可能有需求，首先識別出來合適的需求提供者，需求的提供者中包括了客戶、終端使用者、間接使用者。客戶是掏錢買軟體的人，終端使用者是使用軟體的人，間接使用者是對軟體有影響力，但是他可能不使用該軟體，也不掏錢買該軟體，三種型別的角色有可能有重合，三者都決定了軟體的需求，可能不同的角色對需求的作用不同，不要忽略了任何一種型別的需求提供者。在很多專案中往往忽略了終端使用者的需求，而導致操作層的需求捕獲不全，系統在上線時返工很大。
3 定義需求調研問題單
在需求調研的準備階段，需要準備好需要關注的問題，事先的準備可以保證需求調研活動的完備性、高效性。在調研問題單中尤其不要遺忘如下的問題：
異常是如何處理的？
峰值是如何處理的？
非功能性的需求有哪些？
未來可能的變化有哪些？
最重要的需求是什麼？
對照問題單進行調研進行及時的記錄後，調研記錄可以請客戶確認是否完備正確。
4 在專案初期教育客戶如何實施乙個軟體專案
客戶教育是乙個大問題，尤其是對乙個沒有it經驗的客戶，如果客戶缺乏正確的實施乙個it專案的觀點，那麼他就不知道如何去提需求，如何控制需求的範圍，如何管理乙個it專案。客戶的需求是乙個專案的輸入，如果需求不明確、需求有遺漏、需求總是變化、需求不切實際、需求沒有劃分優先順序，則對整個專案的成敗影響重大。因此需要在專案的初期對客戶實施教育，告訴客戶專案成敗的關鍵因子是什麼，在整個專案進展過程中客戶需要注意什麼。
5 引導使用者劃分需求的優先順序
使用者往往不關注需求的優先順序，認為所有的需求都重要，需求工程師需要引導使用者劃分需求的優先順序，而不是單刀直入的讓使用者劃分需求的優先順序。可以通過如下的啟發式問題引導客戶劃分需求的優先順序：
在談到的上述的需求中，最重要的3項需求是什麼？
這個需求比另外乙個需求更重要嗎？
對於這個需求是否可以考慮採用其他的解決方案，而不通過系統來實現？或簡單實現？
如果推遲或不實現這個需求，是否對專案的目標有影響？
如果推遲或不實現這個需求，會對哪些業務，哪些人員有影響？
6 採用使用者故事+驗收準則描述使用者需求
使用者故事是敏捷開發方法中描述使用者需求的方法，該方法採用三段論的方式描述需求：
角色功能目的
如：作為乙個家庭主婦，我需要乙個30平公尺的餐廳，以便於我招待10個朋友進餐。
作為乙個系統管理員，我希望系統能夠自動備份重要的資料，以便於在發生災難時可以自動恢復。
通過這個描述方式可以幫助我們確定每個需求的重要性，同時也提供了乙個伸縮的彈性，即這個需求的細節特性可能有比較大的協商空間，可以方便我們進行需求、質量、進度、投入的平衡。
僅僅描述了使用者故事還不足以讓開發人員準確了解需求，還需要描述每個故事的驗收標準，通過驗收標準來細化需求，在開發與使用者之間達成對需求的一致理解。比如：
餐廳要燈光明亮；
餐廳要靠近廚房；
餐廳要5公尺*6公尺
；等等。
不僅僅是在敏捷方法中需要描述每個需求的驗收準則，在傳統的需求描述中也需要明確描述需求的驗收標準，但是很多需求工程師恰恰忽略了這一點，很多專案的驗收準則描述為參考需求規格說明書進行驗收。客戶在驗收時檢查的特性實際上比需求規格說明書中描述的特性要少的多，驗收標準代表了客戶的最低要求，通過編寫驗收標準可以發現需求中不明確的地方，凡是不能寫出驗收標準的需求，通常都是模糊的需求，通過編寫驗收標準可以起到對需求補充完善的作用，驗證需求的作用。
7 需求描述中至少包括：業務流程圖、用例、介面原型、非功能性需求、需求優先順序
業務流程圖描述客戶的業務處理的流程，對於理解需求提供了乙個很好的背景資訊，可以從業務流程圖中提取出功能需求與非功能性需求。
用例描述了人機互動的流程，劃分了人與系統的職責，清晰刻畫了正常與異常的事件流，無論是與客戶還是與技術人員都很容易溝通，是描述功能需求的一種有效方式。
介面原型將軟體的功能直觀地展示出來，一圖勝千言，便於引導客戶提出更細緻、更準確的需求，也便於與技術人員的溝通。在需求獲取與分析時應該盡早構造出介面原型。並非需要針對所有的需求都要構造原型，核心的、難以理解的需求需要構造原型。
非功能性需求是使用者容易忽略的需求，需求分析人員需要引導客戶提出非功能性需求，如果客戶不能提出來，需求分析人員需要根據歷史的經驗定義出非功能性需求並和客戶確認，非功能性需求一定要描述出來，不能想當然的認為應該如何如何而沒有文件化。非功能性需求能量化則量化，不能量化則採用原型描述。
需求的優先順序一般最多劃分為3級，優先順序最高的最先實現。需求的優先順序為採用迭代方法提供了乙個基礎，也為平衡進度、質量、需求、投入提供了決策依據。
在描述系統需求時不僅僅限於上述的5個方面，還有專案的目標、涉及的使用者角色、系統的執行環境、處理的資料等等，但是上面的5個方面往往是最容易出問題的地方。
8 測試人員參與需求評審，確保需求的可測試性
需求的描述要詳細到可測試的程度，所謂可測試即測試人員閱讀了需求以後可以編寫出測試用例，能夠識別出輸入、操作流程、處理邏輯及預期的輸出。測試人員參與需求的評審關注的就是需求的可測試性，如果乙個需求不可測試，則說明該需求描述的不夠明確。
9 採用功能點方法度量軟體規模，確保需求描述的明確性
功能點方法不僅僅是一種規模度量的方法，還是一種需求驗證的方法，如果存在兩個人功能點分析師對同一需求計算出的功能點不一致，往往是由於需求的描述不夠明確而導致的。在需求階段，通過度量軟體的規模可以促進對需求的溝通、理解從而發現需求中模糊、有爭議的地方。
10 通過給客戶講解需求及演示介面原型的方式讓客戶確認需求
需求每經過乙個傳遞，就會發生一次誤傳，要麼資訊有遺漏，要麼資訊有錯誤，通過需求的確認可以及時發現這些錯誤，及時糾正這些錯誤。開發人員給客戶講解對需求的理解、給客戶演示介面原型以及在開發過程中階段性的演示半成品都是需求確認的方式。人們只有在看到實際的軟體時才能提出更多的需求，這是客觀的現實，因此應該多採用原型法來確認需求，這也是敏捷方法中頻繁交付這條實踐的**。
對客戶的需求可以確認多次，比如首先是初步的需求訪談記錄確認，然後是介面原型的確認，再進行高保真的介面原型確認，在專案開發過程中，可以不斷的對半成品的軟體進行確認，直至最後的驗收確認。
11 無論大小需求的變更都應納入變更控制的流程
需求總是漸變的，對於大變更、小變更都納入需求變更的流程，很多專案往往忽略了對小變更的控制，積少成多，最終導致需求、設計、**的不一致。需求的變更可以分級控制，明確劃分不同級別的需求變更，級別不同審批的流程與許可權可以不同。
12 針對非功能性需求執行qfd（質量功能部署）
針對非功能性需求執行qfd，即建立非功能性需求與設計方案之間的對映關係，非功能性需求與測試用例之間的對映關係。在實際中專案組往往只會關注功能性需求的實現與測試，而忽略了非功能性需求的實現與測試，通過該實踐可以規避對非功能性需求的實現風險。
軟體需求最佳實踐
需求實踐所面臨的問題 需求分析的核心線索 在 原有的需求分析方法中，我們往往過多的關注how，而沒有關注what，或者關注了what而沒有關注what背後的需求場景和背後的問題why。這都導 致我們沒有進行很好的需求挖掘。需求分為業務需求，使用者需求和軟體需求三個層面。而我們在平時的需求分析中往往很...
軟體需求最佳實踐
需求實踐所面臨的問題 需求分析的核心線索 在 原有的需求分析方法中，我們往往過多的關注how，而沒有關注what，或者關注了what而沒有關注what背後的需求場景和背後的問題why。這都導 致我們沒有進行很好的需求挖掘。需求分為業務需求，使用者需求和軟體需求三個層面。而我們在平時的需求分析中往往很...
《軟體需求最佳實踐》閱讀筆記06
第7章 需求描述最佳實踐 在描述需求時，我們首先確定以什麼風格來表述，另外還應該選擇與專案 團隊特點相符合的風格模板。常見的描述風格與選用標準 在描述需求時，最常見的描述風格個可以分成自然語言 圖形化模型和形式化規格描述3種 自然語言，也就是使用結構合理的自然語言來描述需求，這種形式不管對於寫的人還...