要：《需求規格說明書》是軟件工程需求階段的成果性文檔，其質量的好壞直接關系到軟件開發項目的成敗，監理方作為項目質量的監控方，有責任和義務對《需求規格說明書》進行審核把關，本文就審核的重點和需要把握的要點進行闡述，最后給出監理審核報告模板，以供監理同行探討和改進。
????君欲食堅果 必先破其殼??
????需求范圍控制是需求階段控制的難點，如果處理不好，會導致業主方與承建方的糾紛，甚至項目沒完沒了，不能驗收。因為在項目驗收時往往以招標文件、投標文件、開發合同、需求成果文檔為依據來確定項目是否達到了范圍的要求，往往是招投標文件對用戶需求范圍規定不細，合同沒有規定，如果需求成果文檔再寫的很草，項目到了上線試運行時，業主方會認為所要的功能沒有實現，承建方認為用戶開始沒有提出需求，后來不斷改變和新增需求，項目不可控，永遠沒法驗收。為解決這一難題監理方應從中起到重要作用。建議的做法是：
????一是控制好軟件開發方法利于需求獲取：根據項目復雜度、業主方信息化基本情況，選好開發方法，如果復雜度高業主方信息化基礎弱可能選用原型法，如果時間緊、承建方經驗豐富可選用敏捷法。
????二是巧妙引導使用《用戶需求說明書》，協調、建議業主方和承建方，需求調研時匯總“需求調研表”形成《用戶需求說明書》對開發的范圍和性能目標需求進行界定，并建議業主方業務部門對其業務需求簽字確認，同時約定更的范圍比如10%—15%為合理變更范圍，如果在這個范圍內，承建方應開發和調整不增加費用，如果超出這個范圍或對系統架構有較大的變更，業主方要增加費用。形成會議紀要或備忘錄各方遵守。
????三是以《用戶需求說明書》為依據對《需求規格說明書》的開發范圍進行檢查和審核。
????金玉其外 秀慧其中??
????要求《需求規格說明書》形式與內容并重，本節主要闡述形式要求和內容的完整性，只有形式與內容都達到要求才認為是合格的《需求規格說明書》。
????一是形式完美：包括封皮完美、版本控制信息清晰、章節分部合理、文字簡練、準確、專業、無冗余、圖文并茂等
????二是內容完整：包括引言（包括目的、范圍、閱讀對象、參考資料、縮寫詞、略語、相關法律法規等）；功能需求；非功能需求（包括可靠性、安全性、易用性、可用性、可擴展性、可維護性、可移植性等）；接口需求、約束條件等文檔結構合理，其中要求運行環境、操作方式、故障處理、備份需求、反應速度、流量、頻度等一應俱全，把握一個原則是：不能缺項。
????慧眼點睛 更上層樓??
????重點一：把握《需求規格說明書》的三要素是審核的第一關鍵，首先要了解軟件開發中采用結構化方法、面向對象的方法、SOA架構對《需求規格說明書》的影響。《需求規格說明書》除了與用戶溝通要用戶理解、監理人員作為控制項目的依據、測試人員作為測試依據之外，也是開發設計人員的依據和工作指南，如果開發方法用的是結構化方法，那么《需求規格說明書》中“業務流”、“數據流”、“數據字典”成為其不可缺少的三要素，缺一不可，并且是環環相扣，相互對應，下面分別述之。
????一是業務流程圖：要與用戶實際業務一致，要以用戶容易理解的、標準的圖形清晰表述，如果較復雜就用子圖分層的方法表述，以簡易和容易理解業務為原則。
????二是數據流程圖：先是與業務流程圖一一對應，再是涉及的輸入或輸出表應明確畫出，表劃分合理、無冗余。注意處理好分層時的表達。
????三是數據字典：實際上是數據流程圖中輸入、輸出表中對應的數據項，需要說明的是要標出數據項要求的類型或字長等屬性。
如果是面向對象的方法，由于其迭代和無間隙的特點，需求和設計沒有明顯的界限，所以在審核《需求規格說明書》時至少要有用例圖、順序圖、類圖等，所要表述的要把握基本與結構化方法三要素相對等的信息，如果情況復雜時還要有狀態圖，以下簡述之：
用例圖：能清晰反映出角色和用例，可以對應業務流中的主要功能項，通常用例將轉化為程序菜單，主要用于審核檢查業務范圍。
順序圖：審核檢查順序圖的粒度，基本上能對應業務流程和數據流程就行了，它是以時間順序描述流程的，也可以空間順序的協作圖來代替其描述流程。
????類圖：類圖主要是描述數據項，可以將其對應為結構化方法的數據字典，但其更貼近自然，更能適應變化。
????重點二：把握接口和安全尤為重要，接口和安全是軟件開發的重點和難點，處理不好，會給項目埋下定時炸彈，即使回避一時，但矛盾很快會暴露，根據項目實際情況對這兩個方向的把握也是監理審核的重點。
????啰啰嗦嗦 終要定格? 寫了這么多最終還是建議完成“關于對《需求規格說明書》的審核”監理報告，以下拋出一磚來，希望引來金鳳凰。

關于對《需求規格規格說明書》的審核
審核報告

項目名稱	XXXX信息管理系統建設項目
業 主 方	業主方全稱
監 理 方	監理方全稱
承 建 方	承建方全稱
XX監理公司于XXXX年X月X日對承建方提交的《需求規格說明書》（包括：《OA系統需求規格說明書》、《網站需求規格說明書》、《業務系統需求規格說明書》）進行審核，意見或建議如下：(如果不特指三個系統的某一個，就表示對三個系統共同的評審結果) 一、需求目標：《OA系統需求規格說明書》中“需求目標”部分，對系統的性能有較充分的描述，系統的功能描述少，具體要“做什么”在目標中沒有很明白的描述。《網站需求規格說明書》中“需求目標”對功能和性能都有描述。《業務系統需求規格說明書》中“需求目標”較為明確。 二、內容完整性方面：(1)需求分析結構內容方面：包括了“編制目的”、“適用范圍”、“術語說明”、“參考資料”、“系統目標”、“運行環境”、“需求描述”、“功能模塊詳細需求”、“數據庫性能要求”、“應用平臺性能要求”等文檔結構上較完整，文檔結構沒有大的遺漏項，但某些要素不詳細或不完整，具體見下面的內容。(2)需求業務內容方面：以業主方意見（《用戶需求說明書》）為準。 三、系統的功能需求：(1)各業務模塊都有業務流程描述，但沒有業務流程的細節和可選流程及處理；(2)數據流程的描述不是很清晰；(3)頁面需求描述清晰到位；(4)數據項的描述較為詳細；符合要求；(5)對權限的描述較為簡單，有些不清晰；(6)部分功能的描述過于簡單，如：《OA系統需求規格說明書》中8.1.2 功能概述中的描述：“包括信息瀏覽、發布、修改、刪除的功能。”就沒有說明“信息”指的是什么。(7)對組合查詢中，沒有對“查詢條件”進行描述。 四、系統的性能需求：性能需求描述的較為清晰，包括：“運行環境”、“硬件要求”、“軟件要求”等，但對安全性和內、外網的需求方面的需求描述較少。 五、系統的數據需求：《OA系統需求規格說明書》中功能方面在各子項需求中描述的較為清晰，性能的需求方面也有專門的章節描述，但對數據保密性和備份方面描述較少。《網站需求規格說明書》中功能方面數據沒有描述，性能的需求方面也有專門的章節描述。《業務系統需求規格說明書》中功能方面在各子項需求中描述的較為清晰，性能的需求方面也有專門的章節描述，但對數據保密性和備份方面描述較少。 六、系統的接口需求：《OA系統需求規格說明書》中有接口的說明部分，但各模塊之間的接口關系描述的較弱。《網站需求規格說明書》中有接口的說明部分，但各模塊之間的接口關系描述的較弱。《業務系統需求規格說明書》中有接口的說明部分，但各模塊之間的接口關系描述的較弱。 八、系統的設計約束：《OA系統需求規格說明書》中設計約束方面表現較弱。《網站需求規格說明書》中有該方面的描述，但表現較弱。《業務系統需求規格說明書》中有該方面的描述，但表現較弱。 結論：《需求規格說明書》的文檔結構基本符合規范，但某些要素需要進一步細化、完善。 XXXX監理公司

總結

以上是生活随笔為你收集整理的需求规格说明书评审的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。