核對錶：需求（代碼大全2）

標籤：style   blog   http   color   width   資料   

Checklist: Requirement

 

針對功能需求

 是否詳細定義了系統的全部輸入,包括其來源、精度、取值範圍、出現頻率等？

 

 是否詳細定義了系統的全部輸出,包括目的地、精度、取值範圍、出現頻率、格式等？

 

 是否詳細定義了所有輸出格式（Web頁面、報表、等等）？

 

是否詳細定義了所有硬體及軟體的外部介面？

 

 是否詳細定義了全部外部通訊介面,包括握手協議、錯誤修正協議、通訊協定等？

 

是否列出了使用者想要做的全部事情？

 

 是否詳細定義了每個任務所用的資料,以及每個任務得到的資料？

 

 

針對非功能需求（品質需求）

 是否為全部必要的操作,從使用者的視角,詳細描述了期望回應時間？

 

 是否詳細描述了其他與計時有關的考慮,例如處理時間、資料轉送率、系統吞吐？

 

是否詳細定義了安全層級？

 

 是否詳細定義了可靠性,包括軟體失靈的後果、發生故障時需要保護的至關重要的資料、錯誤偵測與恢複的策略等？

 

是否詳細定義了機器記憶體和剩餘磁碟空間的最小值？

 

 是否詳細定義了系統的可維護性,包括適應特定功能的變更、作業環境的變更、與其他軟體的介面能力的變更能力？

 

 是否包含對“成功”的定義？“失敗”的定義呢？

 

 

需求的品質

需求是用使用者的語言書寫的嗎？使用者也這麼認為嗎？

 

每條需求都不與其他需求衝突嗎？

 

 是否詳細定義了相互競爭的特性之間的權衡——例如,健壯性和正確性之間的權衡。

 

是否避免在需求中規定設計（方案）？

 

需求是否在詳細程度上保持相當一致的水平？有些需求應該更詳細地描述嗎？有些需求應該更粗略地描述嗎？

 

 需求是否足夠清晰,即使交給一個獨立的小組去構建,他們也能理解嗎？開發人員也這麼想嗎？

 

每個條款都與待解決的問題及解決方案相關嗎？能從每個條款上溯到它在問題領域中對應的根源嗎？

 

 是否每條需求都是可測試的？是否可能進行獨立的測試,以及檢驗不滿足各項需求？

 

 是否詳細描述了所有可能的對需求的改動,包括各項改動的可能性？

 

 

需求的完備性

 對於開始開發之前無法獲得的資訊,是否詳細描述了資訊不完全的地區？

 

 需求的完備度是否能達到這種程度：如果產品滿足所有需求,那麼它就是可接受的？

 

你對全部需求都感到舒服嗎？你是否已經去掉了那些不可能實現的需求——那些只是為了安撫客戶和老闆的東西？