•正確性:對照原始需求檢查SRS
•必要性:不能回溯到出處的需求項可能是多余的
•優先級:恰當劃分并標識
•明確性:不使用含糊的詞匯
•可測性:每項需求都必須是可驗證的
•完整性:不能遺漏必要和必需的信息
•一致性:與原始需求一致、內部前后一致
•可修改性:良好的組織結構使需求易于修改
注意,其實現在很多公司做的所謂需求規格說明書評審并不是真正的需求評審,他們更多的是關注有沒有需求,需求打算如何實現,而沒有把精力放在評價上面的幾個“性”上。
SRS測試步驟
•第一步:獲取最新版本的SRS,同時盡量取得用戶原始需求文檔
•第二步:閱讀和嘗試理解SRS描述的所有需求項
•第三步:對照SRS Review Checklist進行檢查并記錄
•第四步:針對檢查結果進行討論、修訂SRS后回到第一步,直到Checklist的所有項通過
軟件需求規格說明書評審檢查單模板
項目編號 |
| |||
檢查人 |
| |||
檢查日期 |
| |||
序號 |
檢查項 |
檢查結果 |
說明 | |
1 |
是否所有需求都體現了 |
是[ ] 否[ ] NA[ ] |
| |
2 |
用語是否清晰無歧義(查找諸如也許、可能、大概、大約等關鍵字) |
是[ ] 否[ ] NA[ ] |
| |
3 |
是否清楚描述軟件要做什么及不做什么? |
是[ ] 否[ ] NA[ ] |
| |
4 |
是否描述了軟件使用的目標環境,指明并簡短描述了目標環境中其它相關軟件產品/子系統/模塊 |
是[ ] 否[ ] NA[ ] |
| |
5 |
是否每一個具體需求都有唯一的編號 |
是[ ] 否[ ] NA[ ] |
| |
6 |
每一個需求是否切實可行、可測試、前后一致、彼此不沖突 |
是[ ] 否[ ] NA[ ] |
| |
7 |
是否說明了對每個輸入的驗證措施,并描述了每個輸入的屬性,如:度量單位、邊界值、時序要求等 |
是[ ] 否[ ] NA[ ] |
| |
8 |
是否說明了對每個輸入的處理 |
是[ ] 否[ ] NA[ ] |
| |
9 |
是否說明了對每個輸出項是如何輸出的,并且描述了每個輸出的屬性,如:度量單位、邊界值、時序要求等 |
是[ ] 否[ ] NA[ ] |
| |
10 |
是否描述了性能需求 |
是[ ] 否[ ] NA[ ] |
| |
11 |
所描述的性能需求是否能通過測試來進行驗證 |
是[ ] 否[ ] NA[ ] |
| |
12 |
是否說明了所有對系統可能的約束 |
是[ ] 否[ ] NA[ ] |
| |
13 |
質量屬性是否以可測量或可驗證的術語進行描述 |
是[ ] 否[ ] NA[ ] |
| |
14 |
是否清楚描述了系統中與其它子系統、模塊或硬件設備的相關接口 |
是[ ] 否[ ] NA[ ] |
|
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/