由于信息ERP應用系統(tǒng)建設針對的行業(yè)廣泛，因此在需求分析階段可能存在著承建單位對業(yè)主單位的業(yè)務需求理解不全面不準確的情況，常發(fā)生承建單位認為某一個業(yè)務功能的實現(xiàn)非常簡單，而實際上業(yè)主單位業(yè)務標準的要求很復雜的情況。在這種情況下，如果不在監(jiān)理單位的協(xié)調(diào)下進行業(yè)主單位與承建單位充分的溝通，往往造成承建單位按照自己的理解進行開發(fā)的情況，如果在測試階段沒有發(fā)現(xiàn)此類問題則給系統(tǒng)造成重大隱患，如果發(fā)現(xiàn)問題則造成工程建設返工與延期。
　　因此，在此階段監(jiān)理單位的工作重點是監(jiān)督承建單位的分析人員、設計人員和測試人員對需求說明書的審查，并協(xié)調(diào)業(yè)主單位與承建單位需求說明書的評審確認。需求分析階段工作落實的情況，直接決定了后續(xù)開發(fā)工作的質(zhì)量、進度、投資與變更的情況，因此必須在監(jiān)理過程中給予足夠的重視。
需求說明書評審監(jiān)理
　　一、需求說明書評審原則
　　原則1：功能與實現(xiàn)分離，即描述要“做什么”而不是“怎樣實現(xiàn)”
  　原則2：要求使用面向處理的規(guī)格說明語言，討論來自環(huán)境的各種刺激可能導致系統(tǒng)做出什么樣的功能性反應，來定義一個行為模型，從而得到“做什么”的規(guī)格說明。
　　原則3：如果目標軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。描述該目標軟件與系統(tǒng)的其它系統(tǒng)元素交互的方式。
　　原則4：規(guī)格說明必須包括系統(tǒng)運行的環(huán)境。
　　原則5：系統(tǒng)規(guī)格說明必須是一個認識的模型，而不是設計或?qū)崿F(xiàn)的模型。
　　原則6：規(guī)格說明必須是可操作的。規(guī)格說明必須是充分完全和形式的，以便能夠利用它決定對于任意給定的測試用例，已提出的實現(xiàn)方案是否都能滿足規(guī)格說明。
　　原則7：規(guī)格說明必須容許不完備性并允許擴充。
　　原則8：規(guī)格說明必須局部化和松散的耦合。它所包括的信息必須局部化，這樣當信息被修改時，只要修改某個單個的段落（理想情況）。同時，規(guī)格說明應被松散地構造（即耦合），以便能夠很容易地加入和刪去一些段落。
　　這是由Balzer和Goldman提出的8條原則，主要用于基于形式化規(guī)格說明語言之上的需求定義的完備性，但這些原則對于其它各種形式的規(guī)格說明都適用。當然要結合實際來應用上述的原則。
　　二、需求說明書評審框架
　　需求說明書是分析任務的最終產(chǎn)物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。軟件需求說明書的框架：
　　Ⅰ. 引言 A.系統(tǒng)參考文獻   B.整體描述   C.軟件項目約束
　　Ⅱ. 信息描述 A.信息內(nèi)容表示   B.信息流表示 C數(shù)據(jù)流 D控制流
　?、? 功能描述 A.功能劃分 B.功能描述 C處理說明 D限制∕局限 E 性能需求
  ?、?設計約束
　?、?支撐圖  
　?、? 行為描述 A.系統(tǒng)狀態(tài)   B.事件和響應   C.控制描述
　?、? 檢驗標準 A.性能范圍   B.測試種類   C.期望的軟件響應   D.特殊的考慮
　?、? 參考書目
　?、? 附錄
　　三、需求說明書評審內(nèi)容
　　作為需求分析階段工作的復查手段，在需求分析的最后一步，應該對功能的正確性、完整性和清晰性，以及其它需求給予評價。評審的主要內(nèi)容是：
　　 系統(tǒng)定義的目標是否與用戶的要求一致；
　　 系統(tǒng)需求分析階段提供的文檔資料是否齊全；
　　 文檔中的所有描述是否完整、清晰、準確反映用戶要求；
　　 與所有其它系統(tǒng)成分的重要接口是否都已經(jīng)描述；
　　 被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠，確定；
　　 所有圖表是否清楚，在不補充說明時能否理解；
　　 主要功能是否已包括在規(guī)定的軟件范

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html