大多數從事軟體開發的人士都有這樣的體會，需求分析是乙個軟體成功與否的關鍵。在當今軟體工程領域出現的許多問題，都源於需求的不清晰。
正因為如此，我們現在面臨的客戶，我們的專案經理自身，以及我們的管理層已經開始嚴控需求。我們不僅定製了需求提交的流程，還定製了需求說明的格式。但在實際操作過程中，通常是大家先做了乙份使用者需求，然後花費大量時間寫軟體需求，以滿足認證和立項的需要。但到頭來軟體需求根本沒人看，開發過程全憑專案經理和團隊的理解進行。大家都只是應付，「軟體成功與否的關鍵」成了擺設，我們很多時候沒理解需求就匆忙入手，導致「需求變更乃萬惡之源」。
在這裡我不是講怎麼進行需求調研，也不是講怎麼去寫需求文件，而是從我們的實際出發，闡述一下召開技術部內部的需求評審會。
1.概述
技術部內部需求評審會是在需求基本確定的情況，從技術實施的角度來評審專案需求，找出不確定的、不清晰、有歧義的需求。其目的是幫助專案組真正理解專案需求，理解專案目標，輔助專案設計，從而制定合理的專案計畫。
參加人員成員包括公司專案管理團隊，專案開發團隊，產品線專家，技術專家，將採用頭腦風暴法來評審需求，提出對需求的見解。
技術部內部需求評審會是在需求基本確定的情況下召開的，針對「客戶原始需求記錄」、「需求說明書」進行分析評審。
2、需求評審過程
2.1 客戶原始需求介紹
需求評審會的第一步就是針對客戶原始需求的介紹，由市場人員或者售前工程師講解使用者的原始需求，可能就是幾句話，如「需要對指令碼自動製作」等。通過客戶原始需求的了解，參加會議的人員就可以了解專案的初步目標是什麼。
2.2 需求說明介紹
2.3 頭腦風暴
對於需求說明書，展開頭腦風暴式的**。誰都可以提問，提出自己認為有問題或者不解的地方。如果需求調研人員無法解釋清楚，如果乙個描述可能導致幾種理解，就說明在這個點上是個風險點，需要再跟客戶確認。
同時，我們可以根據需求說明來**設計方案，**對於某個功能怎麼設計合理；**某個模組是不是在別的專案組實施過，可以復用；**專案中的技術難點；**專案中的風險點；**實施計畫的初步模型；**專案組的組建；......
3 評審結果
需求評審會評審的結果不是對需求調研的成功打分，主要是找到需求說明書中的風險點，幫助專案經理去把握需求，指導和輔助需求設計。
同時實現各個專案中間的經驗共享，模組最大化重用，減少實施的風險和代價。
如何開需求評審會
參考自 要讓相關人員詳細了解需求 知道自己處於什麼位置，要做什麼 評估需求的難度和時長，進行分解和計畫安排 最好是所有干係人 如果不能都到會，也要所有干係負責人到會 如果負責人本人不能到會，需要該負責人的backup到會 前提是開發計畫已經被排期，進入確認階段 在開發計畫開始前3 5天進行評審 分為...
如何開測試評審會
一.測試 評審會背景 目前，開發有需求說明會 設計評審會 複審會等各種會議，但多是站在開發的角度，從需求和 層面進行複審和風險規避。在測試環節和測試階段缺少以測試為主體的評審機制和溝通機制，容易造成以下幾方面的問題 1.由於文件的質量良莠不齊，以及書面語言的侷限性，僅從文件獲取資訊，可能會造成資訊不...
需求評審會議如何召開
需求評審會議如何召開 需求評審會的目的，是為了讓相關人員，對產品的需求方案達成共識，讓boss提前知道完成專案所需的資源投入等等 由於相關人員較多，需要討論的問題也較多，所以會前對會議的全面準備，反覆預演練，是乙個產品對於每個需求評審會，都一定要做到的 1.評審會前 會前較為必要的是複雜問題或容易有...