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