監理方如何審核《需求規格說明書》

君欲食堅果 必先破其殼需求範圍控制是需求階段控制的難點，如果處理不好，會導致業主方與承建方的糾紛，甚至項目沒完沒了，不能驗收。因為在項目驗收時往往以招標文件、投標文件、開發合同、需求成果文檔為依據來確定項目是否達到了範圍的要求，往往是招投標文件對用戶需求範圍規定不細，合同沒有規定，如果需求成果文檔再寫的很草，項目到了上線試運行時，業主方會認為所要的功能沒有實現，承建方認為用戶開始沒有提出需求，後來不斷改變和新增需求，項目不可控，永遠沒法驗收。為解決這壹難題監理方應從中起到重要作用。建議的做法是：壹是控制好軟件開發方法利於需求獲取：根據項目復雜度、業主方信息化基本情況，選好開發方法，如果復雜度高業主方信息化基礎弱可能選用原型法，如果時間緊、承建方經驗豐富可選用敏捷法。二是巧妙引導使用《用戶需求說明書》，協調、建議業主方和承建方，需求調研時匯總“需求調研表”形成《用戶需求說明書》對開發的範圍和性能目標需求進行界定，並建議業主方業務部門對其業務需求簽字確認，同時約定更的範圍比如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監理公司