『定義』：
　    需求評審已測試并接受了單項需求，它們被允許進入規格說明，現在需要評估規格說明是否完整。這種復查可以迭代，最好每次針對一個產品用例（PUC）的需求。

『關于需求完整性審查』:
    一種相當有效的規格說明復查方式，它是一個正式的過程： 　
    1、指派一名協調人（可能是業務分析師），負責安排審查和分發資料。
　 2、建立最容易犯的錯誤的檢查清單，你會在后續的審查中擴充這份清單。
　 3、給審查者一些時間來閱讀文檔，準備審查。
　 4、將審查限制在2小時以內，審查一天不超過2次。
　 5、審查人數為3～8人

『需求完整性復查包含以下幾個方面』：
    1、確定是否遺漏了需求  　
    2、排列需求優先級，這樣構建者能理解需求的重要性和緊急性。
    3、檢查需求之間的沖突，這會阻礙一項或多項其他需求的實現。
    4、預估構建的成本（管理層執行的任務）
    5、評估項目所面臨的風險（管理層執行的任務）

『確定是否遺漏了需求』：
    1、定義上下文范圍 　
    2、識別業務事件和‘無事件’，無事件指如果基本事件沒有發生所引起的事件。如：基本事件‘卡車處理了一條道路’，但如果卡車沒有處理那條道路，會發生什么情況？工作必須做些事情，它就是無事件（它發生是因為另一個事件沒有發生），如‘到了監控道路除冰的時間’。工作對這個無事件進行響應，將檢查道路是否按照指令進行了處理，如果沒有處理，將‘對未處理的道路進行提醒’。
    3、為BUC建模，利用你的模型展示BUC的功能，通過這些信息，你可以決定功能要用到的存儲數據。 　
    4、定義業務數據，構建正研究的工作所需要的存儲數據的模型（類圖、實體關系模型、關系模型或其他）。
    5、CRUD檢查（每個數據類都必須被創建Ｃreated并被引用Referenced），有些也被更新Update或被刪除Delete。創建一個CRUD表，以顯示是否每個類都有相應的動作。這些動作是業務用例（BUC）執行的，所以這一步能揭示遺漏的事件。 　　
 注意：如果發現了遺漏事件，你必須重新訪問利益相關者，找到關于這些事件的更多知識。如果你確定了這些事件，更新上下文范圍圖，將它們加入事件列表，更新CRUD表，繼續該過程。
    6、保管人過程檢查，分為基本過程和保管人過程 　　
        1）基本過程是指那些與系統存在的理由有聯系的過程，如：你遞上信用卡來完成支付，信用卡公司將記錄支持的金額和其他細節。
        2）保管人過程是為了維護（保管）存儲數據，這些過程對數據進行更改，原因只是為了保持數據最新，它們不屬于基本過程。如：你搬了新家、通知信用卡公司變更地址，公司相應地更新記錄。
        3）檢查保管人過程，就要查看類模型和CRUD表，確保有足夠的業務事件和相應的過程來維護工作存儲的所有數據。如果類包含可更改的屬性，那就可能有一個保管人業務事件來修改這些屬性。 　
    7、重復直到完成，將第1～6步驟做迭代（確定業務事件、對業務用例建模、加入類模型、檢查類被創建、引用、更新和刪除）。

『排列需求優先級』：
    1、影響優先級的因素
        1）實現的成本
        2）對顧客或客戶的價值
        3）實現產品所需的時間
        4）技術實現的容易程度
        5）業務或組織機構實現的容易程度
        6）對業務的好處
        7）遵守法律的要求
    2、何時確定優先級 　　       
        1）讓需求知識變得越可視，就越有機會不盲目的選擇。
        2）強烈建議在啟動會議上對每個BUC指定優先級附上顧客滿意度和不滿意度評分。
        3）編寫原子需求時，應該不斷考慮是否排列它們的優先級。原因是期望值管理，如果你一直在不斷的排列優先級，人們就能夠接受這種這種，而不會感覺被欺騙。讓利益相關者準備好接受一個事實，即你不能實現所有的需求。
    3、需求優先等級
        1）必須有Must　
        2）應該有Should
        3）可以有Could
        4）不會有Won't
    4、優先級電子表格 　
        1）把影響因子的個數限制在4個以內（如：1.對顧客的價值、2.對業務的價值、3.煎炒實現成本、4.易于實現）
        2）每個因子分配適用權重百分比
        3）累加需求的權重評分，得到該項需求的優先級評分。

『檢查需求之間的沖突』：
    1、需求沖突的情況
        1）使用相同數據的需求（按照使用的術語進行匹配查找）
        2）相同類型的需求（按照需求類型匹配查找）
        3）使用相同度量尺度的需求（查找那些驗收標準使用相同度量尺度的需求）
    2、需求分析師的沖突解決責任： 　　　
        1）在解決沖突的過程中扮演領導的角色
        2）將沖突的需求隔離出來，單獨與每個利益相關者接觸，重新對滿意度和不滿意度評分。
        3）如果作為調節人不能獲得滿意的解決方案，建議你確定現有沖突需求的成本、評估風險，召集當事人會議達成折中。

『評估項目的風險』：
    1、業務分析師在風險評估中的角色，是考慮需求是否包含某種風險，可能影響項目成功。
    2、不必進行風險分析，這項任務更有可能是由項目經理執行。
　 3、風險評估不是真正的需求問題，是項目問題。
　 4、具體要素：
        1）項目驅動
　　　  1.項目的目標
　　　  2.客戶、顧客和其他利益相關者
　　　  3.產品的用戶
        2）項目限制條件
　　　  1.強制的限制條件
　　　  2.相關事實和假定
        3）功能需求
　　　  1.工作的范圍
　　　  2.業務數據模型和數據字典
　　　  3.產品的范圍

『度量所需的工作量』：
    1、我們建議在完整性復查中包括某種規模度量活動
    2、常識告訴你，不能不清楚要構建的產品的規模以及所需的工作量就繼續開發。
    3、在需求收集過程中完成的工作，為度量過程提供了輸入信息。
    4、你的上下文模型是工作規模的權威指南，你可以簡單數一下寫下的需求數目，所有的這些都是度量，都比猜測工作量和盲目接受最后期限要強得多。