核對清單: 軟體需求規格
本核對清單有助於確認軟體需求規格是否正確且完整。
關係
主要說明

參照:[IE830]



檢查項目
在實作上所應顧及的功能、外部介面、效能、屬性及設計限制
功能:軟體有何用處?
 
外部介面:軟體與人、系統硬體及其他軟硬體如何互動?
 
效能:各項軟體功能的速度、可用性、回應時間及復原時間等表現如何?
 
屬性:是否考量到可攜性、正確性、維護性及安全性等方面?
 
實作上的設計限制:有無任何現行的必要標準、實作語言、資料庫整合性原則、資源限制或作業環境等?
有無任何 SRS 以外的指定需求
這表示 SRS:
  • 應正確定義所有的軟體需求;
  • 不應說明任何設計或實作細節;
  • 不應對軟體加諸其他限制。
SRS 是否在未限定任何設計的同時,適當限制有效設計範圍
SRS 是否展現出基本特性
正確:SRS 中是否聲明軟體所應符合的各項需求?明確
每項需求是否獨具唯一一種解釋?是否採用客戶所使用的語言?是否利用圖表來輔助自然語言說明?
完整
SRS 是否涵蓋功能、效能、設計限制、屬性及外部介面等相關方面的所有重要需求?  是否界定 所有可能情況下的期望輸入值範圍? 是否針對有效或無效的輸入值設定回應? 所有的圖形、表格及圖表,是否含括各項條件與測量基準值單位的完整標籤、參照及定義? 是否已解決所有的 TBD?
一致
SRS 與願景文件、使用案例模型及增補規格是否一致?是否與任何其他更高階的規格一致?內部是否一致,不含造成衝突的零星個別需求?
需求評等能力
每項需求有無標示 ID 以指出特定需求的重要性或穩定性?是否界定其他重要屬性以資判定適當的優先順序?
可驗證
SRS 中陳述的每項需求是否均可驗證?有無合乎成本效益的管制流程,可供人員或儀器檢查軟體產品 是否符合需求?
可修改
SRS 的結構及樣式能否在變更需求時兼顧輕易、徹底及一致性,同時仍維持原有的結構及樣式?是否針對 冗餘性進行界定、最小化及交互參照?
可追蹤
各項需求是否附有明確的 ID?各項需求來源是否明確?能否藉由明確參照先前構件進行逆向追蹤?能否 在合理的數量範圍內正向追蹤 SRS 所繁衍的構件?