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