這張需求覈對表包含了一系列的問題——問問自己項目的需求工作做得如何。本書並不會告訴你如何做出好的需求分析，所以列表裏面也不會有這樣的問題。在開始構建之前，用這份列表做一次“心智健全”檢查，看看你的地基到底有多堅固——用“需求里氏震級”來衡量。
並不是覈對表中所有的問題都適用於你的項目。如果你做的是一個非正式項目，那麼你會發現有些東西根本就不需要考慮。你還會發現一些問題你需要考慮，但不需要做出正式的回答。如果你在做一個大型的、正式的項目，你也許就要逐條考慮了。
針對功能需求
q 是否詳細定義了系統的全部輸入，包括其來源、精度、取值範圍、出現頻率等？
q 是否詳細定義了系統的全部輸出，包括目的地、精度、取值範圍、出現頻率、格式等？
q 是否詳細定義了所有輸出格式（Web頁面、報表，等等）？
q 是否詳細定義了所有硬件及軟件的外部接口？
q 是否詳細定義了全部外部通信接口，包括握手協議、糾錯協議、通信協議等？
q 是否列出了用戶想要做的全部事情？
q 是否詳細定義了每個任務所用的數據，以及每個任務得到的數據？
針對非功能需求（質量需求）
q 是否爲全部必要的操作，從用戶的視角，詳細描述了期望響應時間？
q 是否詳細描述了其他與計時有關的考慮，例如處理時間、數據傳輸率、系統吞吐量？
q 是否詳細定義了安全級別？
q 是否詳細定義了可靠性，包括軟件失靈的後果、發生故障時需要保護的至關重要的信息、錯誤檢測與恢復的策略等？
q 是否詳細定義了機器內存和剩餘磁盤空間的最小值？
q 是否詳細定義了系統的可維護性，包括適應特定功能的變更、操作環境的變更、與其他軟件的接口的變更能力？
q 是否包含對“成功”的定義？“失敗”的定義呢？
需求的質量
q 需求是用用戶的語言書寫的嗎？用戶也這麼認爲嗎？
q 每條需求都不與其他需求衝突嗎？
q 是否詳細定義了相互競爭的特性之間的權衡——例如，健壯性與正確性之間的權衡？
q 是否避免在需求中規定設計（方案）？
q 需求是否在詳細程度上保持相當一致的水平？有些需求應該更詳細地描述嗎？有些需求應該更粗略地描述嗎？
q 需求是否足夠清晰，即使轉交給一個獨立的小組去構建，他們也能理解嗎？開發者也這麼想嗎？
q 每個條款都與待解決的問題及其解決方案相關嗎？能從每個條款上溯到它在問題域中對應的根源嗎？
q 是否每條需求都是可測試的？是否可能進行獨立的測試，以檢驗滿不滿足各項需求？
q 是否詳細描述了所有可能的對需求的改動，包括各項改動的可能性？
需求的完備性
q 對於在開始開發之前無法獲得的信息，是否詳細描述了信息不完全的區域？
q 需求的完備度是否能達到這種程度：如果產品滿足所有需求，那麼它就是可接受的？
q 你對全部需求都感到很舒服嗎？你是否已經去掉了那些不可能實現的需求——那些只是爲了安撫客戶和老闆的東西？
