需求規格正式審核會議

前言

一個好的需求規格，必須是完整、正確、清楚、可行、必要、且可加以驗證測試的，而要確保此一品質要求最重要的步驟，便是需求規格的正式審核會議。通常在此過程中多花一分力氣找出潛在的需求錯誤，往往便可省下後面開發階段裡近百倍的成本。因此本文的目的，便是說明如何成功地召開並完成需求規格的正式審核會議。

邱奕南，2001/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. 需求是否真的是需求，而非實作的解決方案，或是問題的描述？

三、會議過程

  1. 由解釋員逐一唸出並解釋各個需求規格條文中的語意。
  2. 審核人員比對自己的理解方向是否和解釋員有所出入。
  3. 審核人員討論並提出對於該需求規格的疑惑之處。
  4. 需求分析人員回答審核人員提出的疑問。
  5. 審核人員討論需求分析人員的回答，並加以決議。
  6. 主持人裁示該需求規格是否通過審核。
  7. 記錄員記錄各未通過之需求規格的問題與錯誤。
  8. 記錄員將記錄的內容一一唸出，供審核人員確認。
  9. 審核人員最後討論決議需求規格書的審核結果：通過、些微修正後直接通過、退回修正重審。

在會議過程中，主持人必須特別注意控制下列事項：

  1. 對事不對人。審核的是需求規格書，而不是需求分析人員。
  2. 討論的內容必須符合議程與主題，避免愈扯愈遠。
  3. 限制爭論與辯駁，將有爭議的問題記錄下來，會後另行討論。
  4. 提出的問題不必討論出解決方案，可留到會議之後再進一步討論。

四、會議之後

如果需求規格通過審核，且有必要定出各需求實作時的優先次序時，可再加開需求評價會議，訂出各需求的優先次序。其步驟為：

  1. 將需求分成一定要做的核心需求，和可有可無的一般需求。將核心需求都列為第一優先順位。
  2. 針對一般需求，利用成本效益評價法，定出其價值，然後依價值高低依次排序需求。

成本效益評價法，是由審核人員對各需求的下列四項因素進行評價（各項分數０～９）：

  1. 加入該需求所會產生的利益。
  2. 捨棄該需求所會導致的損失。
  3. 完成該需求所需的成本。
  4. 無法完成該需求可能的風險。

各項因素取平均值後，再依照下列公式計算出該需求的評價值：

(利益 + 損失) / (成本 + 風險)

會議全部結束後，記錄員應整理出會議報告，提供給各審核人員觀閱確認，然後再交由需求分析人員修正需求規格。

參考文獻

  1. 軟體工程實務專家作法，第四版，Roger S. Pressman原著，金子葳等人譯，儒林，1998
  2. 微軟如何滿足客戶的需求，Karl E. Wiegers原著，許惠丹編譯，華彩，2000