核對表:需求
針對功能需求
- [ ] 是否詳細定義了系統的全部輸入,包括其來源,準確度,取值範圍,出現頻率等?
- [ ] 是否詳細定義了系統的全部輸出,包括目的地,準確度,取值範圍,出現頻率,格式等?
- [ ] 是否詳細定義了所有的輸出格式(網頁,報表等等)?
- [ ] 是否詳細定義了所有硬體及軟體的外部介面?
- [ ] 是否詳細定義了全部的外部通訊介面,包括握手協定(hand-shaking),偵錯協定(error-checking),通訊協定等?
- [ ] 是否列出了使用者想要做的全部事情?
- [ ] 是否詳細定義了每項任務所使用的資料,以及每個任務會產出的資料?
針對非功能需求(品質需求)
- [ ] 從使用者的視角來看,是否已經替全部必要的操作都詳細描述了期望的回應時間(response-time)?
- [ ] 是否詳細描述了其他與計時有關的考慮,例如處理時間,資料傳輸率,系統產量(system throughput)?
- [ ] 是否詳細定義了安全等級?
- [ ] 是否詳細定義了可靠性(reliability),包括軟體失靈的後果,發生故障時需要保護的貴重資訊,錯誤檢測與恢復的策略等等?
- [ ] 是否詳細定義了機器記憶體的最小值和剩餘硬碟空間的最小值?
- [ ] 是否詳細定義了系統的可維護性(maintainability),包括適應特定功能的變更,操作環境的變更,與其他軟體的介面的變更能力?
- [ ] 是否包含了對「成功」的定義?對「失敗」的定義?
需求的品質
- [ ] 需求是用使用者的語言書寫的嗎?使用者也這麼認為嗎?
- [ ] 每條需求都不與其他需求相衝突嗎?
- [ ] 是否詳細定義了相互競爭的特性之間的權衡——例如,健全性(robustness)與正確性(correctness)之間的權衡?
- [ ] 是否避免在需求中規定設計方案
- [ ] 需求是否在詳細程度上保持相當一致的水準?有些需求應該更詳細的去描述嗎?有些需求應該更粗略地去描述嗎?
- [ ] 需求是否足夠清晰,即使轉交給一個獨立的小組去建構,他們也能理解嗎?開發者也這麼想嗎?
- [ ] 每個項目都與待解決的問題及其解決方案相關嗎?能從每個項目上回溯到他在問題領域中對應的根源嗎?
- [ ] 是否每條需求都是可測試的?是否可能進行獨立的測試,以檢驗滿不滿足各項需求?
- [ ] 是否詳細描述了所有可能的對於需求的變更,包括各項變更的可行性?
需求的完備性
- [ ] 對於在開始開發之前無法獲得的資訊,是否詳細描述了「資訊不完全」的區域?
- [ ] 需求的完備度是否達到這種程度:如果產品滿足了所有需求,那麼他就是可接受的?
- [ ] 你對全部的需求都感到很合理嗎?你是否已經去掉了那些不可能實現的需求——那些只是為了安撫顧客的東西?