今天進行了傳說中的需求評審。開始以為是一群大boss坐在那裡挑我們的毛病，沒想到是乙個極度輕鬆和open的過程。總結下一哈：
首先，需求評審的參與者是pd，pm，需求方和專案小組全體成員。目的是對需求方提出的需求進行確認和補充。大致的流程是：需求方給出乙個大概的輪廓，開發團隊提出自己的想法，然後諮詢需求方這樣是否滿足了需求。在這個過程中，可以順帶解決兩個問題：一是統一了專案組內部的想法，二是使需求盡量詳細，避免以後因為需求問題導致的變更。
在對prd文件進行提問的時候，作為乙個有經驗的開發人員，要問一些有「技術含量」的問題：
1.未雨綢繆，考慮產品上線之後會產生的問題。如產品對併發的要求，以後是否會有擴充套件，是否需要公升級服務，需要長期維護？
2.**遠矚，考慮全面。如劃定系統的涉眾，具體實施過程，必須要遵守的規則（高壓線），最後的期望產出物。
3.向直接使用者提問。在他們那裡可以改善一些很「蹩腳」的需求提案。而且可以詢問一些以前類似系統的使用情況，對即將做的產品有更直觀的了解。
4.做任何決定都要有書面記錄。比如需求評審開會時一定要指定兩個書記員，記錄需求的更改細節。需求評審結束之後要對本次評審進行總結，並整理乙份完整的需求文件出來，給今天與會的人員每人乙份。而且此需求一旦制定，以後最好不要再去修改。
5.充分考慮到專案風險。在評審會議上，要收集和公布所有的風險和應對措施。這樣以後出現風險時不會太慌張。
軟體需求評審 過程階段評審
過程階段評審，無評審，不過關！還記得在我們還是學生的年代，每次考試交卷前都會檢查好幾遍，生怕錯漏了什麼，實際上就是開展了一次評審活動，評審的人是你，評審的物件是那份卷子，評審的目的是為了發現問題並修改。在軟體生產過程中，涉及到一道道環節，軟體生命週期從專案啟動到需求，緊跟著設計，然後開發，之後測試，...
需求評審與需求測試
在軟體開發過程中，需求分析是最開始的工作，需求分析如果做得不夠詳細或者是偏離使用者需求的話，往往會給專案帶來滅絕性的災難。因此如何保證需求分析的正確性，不偏離使用者的需求就成了決定軟體專案成敗的關鍵。需求工程師取得使用者的顯性需求後，要仔細的分析使用者到底要求軟體實現什麼功能，使用者的表達和需求工程...
專案管理 需求評審6大靈魂拷問
當需求來臨時，不能來者不拒，一定要思考下面六大問題，可有效避免做無用功。需求描述 為什麼要做 是否真的必要 期望的目標 怎麼做做什麼 透視最根本目的 自查，減少浪費 設定可量化的指標 系統設計和詳細設計 以建設公司內部知識社群為例 1.需求描述 建立乙個內部知識分享社群。2.為什麼要做？可以形成業務...