需求評審會議分析

第一部分：失敗案例

案例一

某領域專家A先生就某企業的成本管理系統作用戶需求報告的評審工做，在評審會開始時間不長，就被在場的企業的一位副總B先生打斷，認爲A先生提出的方案不適合本企業，A先生提出的管理改進方案在企業中沒法實施。該副廠長提完意見後，與會的用戶方人員紛紛跟隨B先生的提出了他們的反對意見，導致評審會沒法再進行下去，最終該報告被用戶否決。

案例二

某軟件公司內部舉行產品的需求評審會，主要是公司內部的領域專家參加，在評審會開始後不久，某領域專家就對需求報告中的某個具體問題提出了本身的不一樣意見，因而，與會人員紛紛就該問題發表本身的意見，你們爭執不下，結果，導致會議出現了混亂情況，主持人沒法控制局面，會議大大超出了計劃評審時間。

案例三

某軟件公司爲某公司A作業務流程管理系統的需求評審會，當項目組人員在會議上宣讀多達上百頁的需求報告時，用戶明確提出聽不懂，導致會議不得不改日進行。

案例四

某軟件公司在用戶處開完物資管理系統的需求評審會後，與會人員離開會議室時，紛紛搖頭，認爲本次會議沒有多少實際效 果，徹底是在走過場。

案例五

某軟件公司在公司內部舉行產品的需求評審會時，需求報告的執筆人與產品策劃主要策劃人員的想法差異很大，導致需求評審會沒有必要繼續進行下去。

---

第二部分：需求評審中常見的問題

◇ 需求報告很長，短期內評審者根本就不能把需求報告讀懂，想清楚；

◇ 沒有做好前期準備工做，需求評審的效率很低；

◇ 需求評審的節奏沒法控制；

◇ 找不到合格的評審員，與會的評審員沒法提出深刻的問題；

 

---

第三部分：如何作好需求評審

建議一：分層次評審

目標性需求：定義了整個系統須要達到的目標；

功能性需求：定義了整個系統必須完成的任務；

操做性需求：定義了完成每一個任務的具體的人機交互；

 

目標性需求是企業的高層管理人員所關注的，

功能性需求是企業的中層管理人員所關注的，

操做性需求是企業的具體操做人員所關注的。

 

建議二：正式評審與非正式評審結合

建議三：分階段評審

分階段評審能夠將本來須要進行的大規模評審拆分紅各個小規模的評審，下降了需求返工的風險，提升了評審的質量。

建議四：精心挑選評審員

需求評審可能涉及的人員包括：需方的高層管理人員、中層管理人員、具體操做人員、IT主管、採購主管；供方的市場人員、需求分析人員、設計人員、測試人員、質量保證人員、實施人員、項目經理以及第三方的領域專家

首先要保證使不一樣類型的人員的都要參與進來，不然極可能會漏掉了很重要的需求。

其次在不一樣類型的人員中要選擇那些真正和系統相關的，對系統有足夠了解的人員參與進來

建議五：對評審員進行培訓

對於主持評審的管理者也須要進行培訓，以便於參與評審的人員可以牢牢圍繞評審的目標來進行，可以控制評審活動的節奏，提升評審效率

建議六：充分利用需求評審檢查單

需求形式的檢查單和需求內容的檢查單。需求形式的檢查能夠由QA人員負責，主要是針對需求文擋的格式是否符合質量標準來提出的，需求內容的檢查是由評審員負責的，主要是檢查需求內容是否達到了系統目標、是否有遺漏、是否有錯誤等等，這是需求評審的重點

建議七：創建標準的評審流程

建議八：作好評審後的跟蹤工做

在需求評審後，須要根據評審人員提出的問題進行評價，要造成書面的需求變動的申請，進入需求變動的管理流程，並確保變動的執行，在變動完成後，要進行復審。

建議九：充分準備評審

評審質量的好壞很大程度上取決於在評審會議前的準備活動。常出現的問題是，需求文檔在評審會議前並無提早下發給參與評審會議的人員，沒有留出更多更充分的時間讓參與評審的人員閱讀需求文檔。

 

---

摩兜公司-IT賦能中心-需求評審標準

前提：主持者明確本次評審內容及評審的級別、參會者名單確立、文件無低級錯誤（文字、頁面）

目標：會議中對下一階段作的內容中功能性、操做性需求進行討論

1：評審內容須要有清單（思惟導圖）

2：評審清單內要求對評審內容作文字性或流程圖或思惟導圖或原型圖的描述（建議用流程圖、原型圖）

3：評審前至少半個小時將評審內容分發給參會人員（將準備好的文件打包）

4：會議內容：介紹需求，頭腦風暴對內容進行補充（作好記錄），主持者進行引導，將全部的建議進行斷定並做出決定（記錄）。

5：會後整理文檔，繪製成project、思惟導圖、禪道需求記錄等進行管理，並整理會議紀要，經過郵件進行確認。