摘要：《需求規格說明書》是軟體工程需求階段的成果性文件，其質量的好壞直接關係到軟體開發專案的成敗，監理方作為專案質量的監控方，有責任和義務對《需求規格說明書》進行審核把關，本文就審核的重點和需要把握的要點進行闡述，最後給出監理審核報告模板，以供監理同行**和改進。
君欲食堅果 必先破其殼
需求範圍控制是需求階段控制的難點，如果處理不好，會導致業主方與承建方的糾紛，甚至專案沒完沒了，不能驗收。因為在專案驗收時往往以招標檔案、投標檔案、開發合同、需求成果文件為依據來確定專案是否達到了範圍的要求，往往是招投標檔案對使用者需求範圍規定不細，合同沒有規定，如果需求成果文件再寫的很草，專案到了上線試執行時，業主方會認為所要的功能沒有實現，承建方認為使用者開始沒有提出需求，後來不斷改變和新增需求，專案不可控，永遠沒法驗收。為解決這一難題監理方應從中起到重要作用。建議的做法是：
一是控制好軟體開發方法利於需求獲取：根據專案複雜度、業主方資訊化基本情況，選好開發方法，如果複雜度高業主方資訊化基礎弱可能選用原型法，如果時間緊、承建方經驗豐富可選用敏捷法。
二是巧妙引導使用《使用者需求說明書》，協調、建議業主方和承建方，需求調研時彙總「需求調研表」形成《使用者需求說明書》對開發的範圍和效能目標需求進行界定，並建議業主方業務部門對其業務需求簽字確認，同時約定更的範圍比如10%—15%為合理變更範圍，如果在這個範圍內，承建方應開發和調整不增加費用，如果超出這個範圍或對系統架構有較大的變更，業主方要增加費用。形成會議紀要或備忘錄各方遵守。
三是以《使用者需求說明書》為依據對《需求規格說明書》的開發範圍進行檢查和審核。
金玉其外 秀慧其中
要求《需求規格說明書》形式與內容並重，本節主要闡述形式要求和內容的完整性，只有形式與內容都達到要求才認為是合格的《需求規格說明書》。
一是形式完美：包括封皮完美、版本控制資訊清晰、章節分部合理、文字簡練、準確、專業、無冗餘、**並茂等
二是內容完整：包括引言（包括目的、範圍、閱讀物件、參考資料、縮寫詞、略語、相關法律法規等）；功能需求；非功能需求（包括可靠性、安全性、易用性、可用性、可擴充套件性、可維護性、可移植性等）；介面需求、約束條件等文件結構合理，其中要求執行環境、操作方式、故障處理、備份需求、反應速度、流量、頻度等一應俱全，把握乙個原則是：不能缺項。
慧眼點睛 更上層樓
重點一：把握《需求規格說明書》的三要素是審核的第一關鍵，首先要了解軟體開發中採用結構化方法、物件導向的方法、soa架構對《需求規格說明書》的影響。《需求規格說明書》除了與使用者溝通要使用者理解、監理人員作為控制專案的依據、測試人員作為測試依據之外，也是開發設計人員的依據和工作指南，如果開發方法用的是結構化方法，那麼《需求規格說明書》中「業務流」、「資料流」、「資料字典」成為其不可缺少的三要素，缺一不可，並且是環環相扣，相互對應，下面分別述之。
一是業務流程圖：要與使用者實際業務一致，要以使用者容易理解的、標準的圖形清晰表述，如果較複雜就用子圖分層的方法表述，以簡易和容易理解業務為原則。
二是資料流程圖：先是與業務流程圖一一對應，再是涉及的輸入或輸出表應明確畫出，表劃分合理、無冗餘。注意處理好分層時的表達。
三是資料字典：實際上是資料流程圖中輸入、輸出表中對應的資料項，需要說明的是要標出資料項要求的型別或字長等屬性。
如果是物件導向的方法，由於其迭代和無間隙的特點，需求和設計沒有明顯的界限，所以在審核《需求規格說明書》時至少要有用例圖、順序圖、類圖等，所要表述的要把握基本與結構化方法三要素相對等的資訊，如果情況複雜時還要有狀態圖，以下簡述之：
用例圖：能清晰反映出角色和用例，可以對應業務流中的主要功能項，通常用例將轉化為程式選單，主要用於審核檢查業務範圍。
順序圖：審核檢查順序圖的粒度，基本上能對應業務流程和資料流程就行了，它是以時間順序描述流程的，也可以空間順序的協作圖來代替其描述流程。
類圖：類圖主要是描述資料項，可以將其對應為結構化方法的資料字典，但其更貼近自然，更能適應變化。
重點二：把握介面和安全尤為重要，介面和安全是軟體開發的重點和難點，處理不好，會給專案埋下定時炸彈，即使迴避一時，但矛盾很快會暴露，根據專案實際情況對這兩個方向的把握也是監理審核的重點。
囉囉嗦嗦 終要定格 寫了這麼多最終還是建議完成「關於對《需求規格說明書》的審核」監理報告，以下丟擲一磚來，希望引來金鳳凰。
關於對《需求規格規格說明書》的審核
審核報告
專案名稱
***x資訊管理系統建設專案
業 主 方
業主方全稱
監 理 方
監理方全稱
承 建 方
承建方全稱
xx監理公司於***x年x月x日對承建方提交的《需求規格說明書》（包括：《oa系統需求規格說明書》、《**需求規格說明書》、《業務系統需求規格說明書》）進行審核，意見或建議如下：(如果不特指三個系統的某乙個，就表示對三個系統共同的評審結果)
一、需求目標：《oa系統需求規格說明書》中「需求目標」部分，對系統的效能有較充分的描述，系統的功能描述少，具體要「做什麼」在目標中沒有很明白的描述。《**需求規格說明書》中「需求目標」對功能和效能都有描述。《業務系統需求規格說明書》中「需求目標」較為明確。
二、內容完整性方面：(1)需求分析結構內容方面：包括了「編制目的」、「適用範圍」、「術語說明」、「參考資料」、「系統目標」、「執行環境」、「需求描述」、「功能模組詳細需求」、「資料庫效能要求」、「應用平台效能要求」等文件結構上較完整，文件結構沒有大的遺漏項，但某些要素不詳細或不完整，具體見下面的內容。(2)需求業務內容方面：以業主方意見（《使用者需求說明書》）為準。
三、系統的功能需求：(1)各業務模組都有業務流程描述，但沒有業務流程的細節和可選流程及處理；(2)資料流程的描述不是很清晰；(3)頁面需求描述清晰到位；(4)資料項的描述較為詳細；符合要求；(5)對許可權的描述較為簡單，有些不清晰；(6)部分功能的描述過於簡單，如：《oa系統需求規格說明書》中8.1.2 功能概述中的描述：「包括資訊瀏覽、發布、修改、刪除的功能。」就沒有說明「資訊」指的是什麼。(7)對組合查詢中，沒有對「查詢條件」進行描述。
四、系統的效能需求：效能需求描述的較為清晰，包括：「執行環境」、「硬體要求」、「軟體要求」等，但對安全性和內、外網的需求方面的需求描述較少。
五、系統的資料需求：《oa系統需求規格說明書》中功能方面在各子項需求中描述的較為清晰，效能的需求方面也有專門的章節描述，但對資料保密性和備份方面描述較少。《**需求規格說明書》中功能方面資料沒有描述，效能的需求方面也有專門的章節描述。《業務系統需求規格說明書》中功能方面在各子項需求中描述的較為清晰，效能的需求方面也有專門的章節描述，但對資料保密性和備份方面描述較少。
六、系統的介面需求：《oa系統需求規格說明書》中有介面的說明部分，但各模組之間的介面關係描述的較弱。《**需求規格說明書》中有介面的說明部分，但各模組之間的介面關係描述的較弱。《業務系統需求規格說明書》中有介面的說明部分，但各模組之間的介面關係描述的較弱。
八、系統的設計約束：《oa系統需求規格說明書》中設計約束方面表現較弱。《**需求規格說明書》中有該方面的描述，但表現較弱。《業務系統需求規格說明書》中有該方面的描述，但表現較弱。
結論：《需求規格說明書》的文件結構基本符合規範，但某些要素需要進一步細化、完善。
***x監理公司
需求規格說明書
團隊專案之需求規格說明書 任務描述 根據需求分析階段性成果物 編制完整的需求規格說明書 任務目的 一方面鍛鍊需求分析文件編寫能力，另一方面通過對內容評價，掌握需求分析方法 引言部分及階段報告 葉鴻 主要 其他成員參與討論 專案概述部分 張瑞源 主要 其他成員參與討論 功能需求部分 童子銘 主要 其他...
python需求分析說明書 需求規格說明書
1 概述 summary 1.1 專案的目的與目標 purpose and aim of project 學員體能成績管理系統需求說明書是為了讓系統的涉眾就該系統的需求達成一致認可，明確該系統的需求，為後續的開發工作提供依據。通常，該需求規格說明可以作為產品設計的主要依據，並作為程式設計師編碼時了解...
軟體需求規格說明書
在整理完與使用者的談話稿，交付使用者審閱後，下一步是制定軟體需求規格說明書了，貌似和客戶簽約需要依據這份規格說明書，一旦確定，雙方達成協議簽字後，使用者如需更改增加功能是需要再付費的。主要內容有 1.簡介 1.1 目的 1.2 應用範圍 1.3 術語及縮寫定義 2.全面描述 2.1 系統用例圖 2....