由于軟件系統(tǒng)的復(fù)雜性，在需求分析階段可能存在著開發(fā)方對(duì)委托方的業(yè)務(wù)需求理解不全面、不準(zhǔn)確的情況。在這種情況下，如果不通過需求評(píng)審進(jìn)行相關(guān)的質(zhì)量控制，往往造成開發(fā)結(jié)果與用戶需求不一致的情況。需求評(píng)審的目的在于描述評(píng)價(jià)目標(biāo)。需求評(píng)審可以保證軟件最大可能地滿足有關(guān)評(píng)價(jià)結(jié)果的所有需求，降低額外風(fēng)險(xiǎn)和未預(yù)料的成本。
建議依據(jù)GB/T 16260中定義的“質(zhì)量特性”的一系列質(zhì)量需求以及其中的一些子特性，結(jié)合實(shí)際系統(tǒng)，編寫需求評(píng)審規(guī)范。
需求評(píng)審建議采用測試方依據(jù)需求評(píng)審規(guī)范對(duì)需求說明書進(jìn)行審查并協(xié)調(diào)業(yè)主方完成需求說明書的評(píng)審確認(rèn)，開發(fā)方的分析人員和設(shè)計(jì)人員參會(huì)協(xié)助評(píng)審工作的工作方式。
需求分析審查針對(duì)《**系統(tǒng)需求規(guī)格說明書》，主要評(píng)審其表述的清晰性、完整性、依從性、一致性、可行性、可管理性等。評(píng)審的主要內(nèi)容有：
● 系統(tǒng)定義的目標(biāo)是否與用戶的要求一致；
● 系統(tǒng)需求分析階段提供的文檔資料是否齊全；
● 文檔中的所有描述是否完整、清晰，準(zhǔn)確地反映用戶要求；
● 與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述；
● 被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定；
● 所有圖表是否清楚，在不補(bǔ)充說明時(shí)能否理解；
● 主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明；
● 軟件的行為和它必須處理的信息、必須完成的功能是否一致；
● 設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際；
● 是否考慮了開發(fā)的技術(shù)風(fēng)險(xiǎn)；
● 是否考慮過軟件需求的其他方案；
● 是否考慮過將來可能會(huì)提出的軟件需求；
● 是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)；
● 有沒有遺漏、重復(fù)或不一致的地方；
● 用戶是否審查了初步的用戶手冊或原型；
● 項(xiàng)目開發(fā)計(jì)劃中的估算是否受到了影響。
為保證軟件需求定義的質(zhì)量，評(píng)審應(yīng)由專門指定的人員負(fù)責(zé)，并按規(guī)程嚴(yán)格進(jìn)行。評(píng)審結(jié)束，應(yīng)有評(píng)審負(fù)責(zé)人的結(jié)論意見及簽字。除開發(fā)方分析人員之外，業(yè)主方和測試方都應(yīng)當(dāng)參加評(píng)審工作。
需求說明書要經(jīng)過嚴(yán)格評(píng)測，一般，評(píng)測的結(jié)果都包括了一些修改意見，待修改完成后再經(jīng)評(píng)測，才可進(jìn)入設(shè)計(jì)階段。
在需求說明書評(píng)測結(jié)束后，測試方應(yīng)將評(píng)測意見以專題報(bào)告的形式提交業(yè)主方。