流程：
預審：產品提前2小時發出通知和初稿（不需要完善細節，可以只是原型），召集主管或負責人預審。未必需要開會，只要每個人能確認需求沒大問題就好。
跟運營有關的需求，應該在全體評審前由運營先審核完畢。
產品經理根據問題修改完畢後，逐個找負責人確認。都通過後，發出通知
專案經理收集工作量評估進行排期，並在各方確認後發出立項郵件
要求：全體評審不能在上個版本未上線的時候進行，要給參會人足夠的時間精力做好評審
如果問題太多，應該再舉行一次需求評審
核心作用就是向開發打招呼，知道要做什麼，好安排人力資源。所以產品文件不需要很完善，但一定要交代清楚目標和核心的功能點。
召集開發測試的主管或負責人簡單過一遍即可，主要是評審可行性。
不需要預審的條件：
開發工作量小於5個工作日
改ui為主，沒有難度
所有人都要評的：
目標是否清晰；針對目標，需求的設計是否合理
針對需求：不完善的地方、影響範圍、使用者體驗。盡量在寫**前發現需求問題
工作量時間安排。限時上線的就砍需求，不限時就由大家來決定發布時間
風險點：所有導致評估不准和專案延期的可能性
特別地，
測試要評估測試資源的充足性（例如測試裝置）、自動化測試可行性
運維要評估伺服器資源的充足性
後期才發現非業務性質的需求疏漏的話，技術與產品同責。
按照每個需求來評，各個職能都評。以0.5人天為最小單位。具體方法請參考《團隊開發如何評估工作量》。
《需求評審的關注點》
《團隊開發如何評估工作量》
本系列文章的目錄：
專案後期的工作量估算（兼談後期需求控制）
通常乙個專案都會有某個里程碑代表專案告一段落，可能是商務到款 初驗 上線 專家評審會 等等。然而在這個節點之後，還有多少工作量呢？有些專案可能一點工作量都沒有，有些專案的工作量可能極大，應該如何界定和估算專案後期的工作量呢？關鍵在於評估當前版本對使用者需求的滿足程度，假設有若干個 使用者 接觸 過這...
專案管理中需求分析工作六守則
守則 永遠不要顯得比客戶更聰明 第一條 了解需求，而不是去批評客戶 第二條 客戶比你更熟悉業務的環境 第三條 客戶總是知道問題在哪兒，你的工作就是要讓他們自己願意說出來 守則 尊重使用者的現實選擇 第一條 客戶永遠是對的 第二條 提供最合適的解決方案，而非最好或最貴的方案 第三條 不要把客戶當傻瓜 ...
如何採用模擬法和類推法估算軟體專案工作量
用於軟體專案工作量估算的方法有以 估 為主的專家法和類推法，以 算 為主的模擬法和方程法。在軟體估算的實踐中，模擬法和類推法也是普遍使用的估算方法，但很多人搞不清二者的應用範圍和估算步驟，現在筆者就對這兩種估算方法做一下詳細介紹。1 模擬法 模擬法是指將本專案的部分屬性與類似的一組基準資料進行比對，...