軟件需求評審會規(guī)范

1、XXXXXX網(wǎng)絡技術（北京）有限公司軟件需求評審會規(guī)范（軟件需求評審會規(guī)范）規(guī)定軟件需求評審會規(guī)范XXXXXX網(wǎng)絡技術（北京）有限公司版本丨1期說明編寫者審核者備注AB本文件的初稿C最終版本D第一次修改軟件需求分析評審會記錄編制規(guī)定目的:對“軟件需求規(guī)格說明”進行分析評審。適用范圍：適用于軟件開發(fā)項目組和客戶對用戶需求分析的評審。規(guī)程：3.1該評審會是軟件開發(fā)項目組及客戶共同進行的對軟件需求分析工作總結和評價。主要針對“軟件需求規(guī)格說明”。3.2軟件需求分析評審會至少要涉及以下主要內容：3.2.1內容評審：“軟件需求規(guī)格說明”的內容是否完備、格式是否符合要求、采集的數(shù)據(jù)是否全面、建立的系統(tǒng)模型

2、的準確性、建立的概念模型能否準確地表達系統(tǒng)模型等。322可行性評審：用戶提出的需求是否足以支持系統(tǒng)目標的實現(xiàn)、系統(tǒng)開發(fā)的限制條件對系統(tǒng)目標的影響。3.3評審時應參考“軟件需求調查記錄”。3.4項目組長總結并填寫“軟件需求分析評審會記錄”。相關文件相關記錄5.1軟件需求調查記錄5.2軟件需求規(guī)格說明5.3軟件需求分析評審會記錄附錄A軟件需求分析評審會記錄文檔登記號：項目名：主持人：會議時間：參加人：列席人：對原始需求進行評審，如果不通過要求重新整理原始需求，如果通過，則進入相應的原始需求數(shù)據(jù)庫，作為下一步開發(fā)設計和計劃的基礎。對原始需求的評審參照以下評審列表:階段原始需求評審項目組項目編號項目名

3、標準執(zhí)行時間復審文檔發(fā)布編號復審文檔時間核對表標準參考核對項標準(Y/N/E)改進意見R-1理解性：（1）是否每一個需求只有一種解釋（2）功能性需求是否可以按模塊方式描述？是否明確地標識出了其功能（3）是否有術語定義一覽表（4）是否使用了形式化或半形式化的語言（5）語言是否有歧義性（6）需求定義是否足夠清楚和明確，使其能夠作為開發(fā)設計規(guī)范和功能性測試的基礎R-2一致性：（1）各個需求之間是否一致？是否有沖突和矛盾？（2）所規(guī)定的模型、算法和數(shù)值方法是否相容（3）是否使用了標準的術語和定義形式（4）需求是否與其軟硬件操作環(huán)境兼容（5）是否說明了軟件對其系統(tǒng)和環(huán)境的影（6）是否說明了環(huán)境對軟件的影

4、響（7）所采用的技術是否與用戶的要求一致R-3可實現(xiàn)性：（1）需求定義是否使系統(tǒng)設計、實現(xiàn)、操作和維護可行（2）所規(guī)定的模型、數(shù)值方法和算法是否對待解決問題適合？是否能夠在相應的限制條件下實現(xiàn)（3）是否能夠達到關于質量的要求R-4可追溯性：（1）是否可以從上階段的文檔中找到需求定義中的相應內容（2）需求定義是否明確地表明前階段中提出的有關需求和設計限制都己被覆蓋（3）需求定義是否便于向后繼開發(fā)階段查找信息R-5設計無關性：（1）是否需求只描述了做什么，沒有描述怎么做（2）需求描述是否是適當程度的抽象/詳細R-6清晰性：（1）所有定義、實現(xiàn)方法是否清楚地表達了用戶的原要求；（2）是否有不能理解或

5、造成誤解的描述；（3）在功能實現(xiàn)過程、方法和技術要求的描述上，是否背離了功能的實際要求。R-7正確性：（1）需求定義是否滿足標準的要求；（2）算法和規(guī)則是否由科技文獻或其它文獻做基礎；（3）是否定義了對在錯誤、風險分析中所標識出的各種故障模式和錯誤類型所需的反應（4）是否參照了有關的標準（5）是否對每個需求都給出了理由？理由是否充分（6）對設計和限制是否都有論證只有軟件工程過程組（SEPG）有權限改變核對項.鍵入N如果標準/方法沒有被執(zhí)行（出于嚴重錯誤而否決工作產(chǎn)品,錯誤改正后必須再次復審）,“Y”如果確認標準/方法被執(zhí)行（工作產(chǎn)品可以不經(jīng)修改而被接受人”E如果可以暫時接受工作產(chǎn)品（發(fā)現(xiàn)必須改正的微小錯誤，但是不再需要進一步復審）.項目