需求規格正式審核會議
前言
一個好的需求規格，必須是完整、正確、清楚、可行、必要、且可加以驗證測試的，而要確保此一品質要求最重要的步驟，便是需求規格的正式審核會議。通常在此過程中多花一分力氣找出潛在的需求錯誤，往往便可省下後面開發階段裡近百倍的成本。因此本文的目的，便是說明如何成功地召開並完成需求規格的正式審核會議。
邱奕南，2000/5/9
一、決定與會人員及角色
1.客戶代表：只有客戶才有權決定需求規格的必要性，因此審核人員中，最重要的便是客戶代表。如果客戶族群有多種，應從最具代表性的幾個客戶族群中，各挑一個客戶代表參與會議。如果是套裝類軟體，客戶代表則可由產品經理、行銷人員、業務人員、或現行客戶擔任。客戶代表的主要工作，便是審核需求是否完整、正確且必要。
2.專案經理或產品經理：以整體規劃的角度來審核需求是否完整、正確、清楚。
3.系統分析師：審核需求是否清楚，並由理論與邏輯的角度來審核需求是否可行。
4.系統設計師：審核需求是否清楚，並由理論與應用技術的角度來審核需求是否可行。
5.資深程式設計師：審核需求是否清楚，並由應用技術與程式撰寫的角度來審核需求是否可行。
6.測試人員：審核需求是否清楚、並可加以驗證測試。
7.品質保證人員：監督正式審核會議是否合乎既定流程，並審核需求規格中是否有可能違反品保規章、或影響其他相關品質的部份。
8.需求分析人員：不參與審核，主要聆聽審核人員的討論，思考並回答審核人員的疑問。
上述各類人員至少均應派一位代表參與審核（可兼任），但審核人員（不含需求分析人員）最多不要超過7人，如果超過時可改成分組討論的方式來進行審核，避免人多口雜，延緩了會議的效率。而在與會人員中，還必須指派會議中的三個角色（需求分析人員均不可擔任）：
1.主持人：通常由專案經理或產品經理擔任，負責與需求分析人員共同規劃、決定與會人員，同時協調並控制整個會議的議程順利進行。
2.解釋員：負責逐一解釋各個需求規格中的語意。
3.記錄員：負責記錄會議中所發現的需求問題與錯誤。
二、會前準備
1.決定與會人員並發出審核會議通知書，明訂出各與會人員的職責，以及會議的議程。整個會議的時間以不超過兩小時為宜，若有需要可分成多次會議進行。
2.將需求分析結果寫成正式的需求規格文件。
3.先進行數次非正式的複審，以降低需求規格可能出錯的機率。其過程和正式審核會議有些類似，但比較不嚴謹，通常每次找一到兩位同事（最好是非參與正式審核會議的人員），針對需求規格書中每個需求，逐條說出他們所了解的程度，以及他們的看法。非正式複審往往可事先找出絕大多數描述不清楚的需求。
4.對即將交付審核的需求規格書，進行校閱的工作，避免有任何的錯漏字。
5.會議幾天前（至少要三天以上）即將需求規格書送交審核人員進行預審。審核人員可先行反應需求規格書中明顯的問題與錯誤，需求分析人員在修正需求規格書後，應將新的需求規格書重新送交審核人員，並將修正之處附於文件之後供做參考。需求分析人員應持續追蹤所有審核人員是否均已進行過預審。
審核人員預審時，可依下列問題進行思考（但非絕對）：
1.所有需求彼此之間的牽動關係是否正確？
2.所有需求描述的詳細程度是否適當？
3.是否已納入了所有客戶曾告知的需求？
4.需求中是否漏了任何必要的資訊或重要限制？
5.是否有重複或相互衝突的需求？
6.所有需求是否都描述得清楚明確？
7.所有需求是否都在專案範圍以內？
8.需求描述內容是否有拼字或文法錯誤？
9.所有需求是否能透過某種方式來加以驗證？
10.所有需求是否都能指出它的來源？
11.品質需求是否都採用適當的數據加以表達？
12.是否有安全性的考量？
13.需求是否真的是需求，而非實作的解決方案，或是問題的描述？
