項目生命周期中，變更和糾正錯誤的代價在項目接近完成時通常會顯著提高。所以在項目研發過程中，需求分析師要參與到產品研發過程，與開發人員、測試人員保持緊密溝通，討論和澄清在實現過程中的需求疑問，保證產品產出和需求意圖的吻合。軟件項目中的需求變更，相信做需求的人員再熟悉不過，需求變更率的高低，也是反應需求工作好壞的一個重要KPI。對于需求變更的發生，唯有面對和解決。通常的做法：了解需變更背景、評估影響程度，考慮與各干系人的溝通（客戶、市場、研發、工程和領導），將評估結果作為變更請求，提交給項目管理團隊，獲批準后，按新計劃開展產品研發。
    下面是在項目研發過程中需求端會參與的一些活動。
    下文中提到的產品團隊通常包含這么些角色：開發經理、開發組長、測試經理、測試組長、項目經理、產品經理、需求分析師、產品策劃經理、市場經理和工程經理；研發團隊通常包含開發經理、開發組長、測試經理、測試組長和項目經理。

   （1）需求評審、版本規劃活動：
       1、需求分析師收集到市場需求后與開發、測試經理溝通，對大致方案達成一致后，開始編寫軟件需求，將編寫完成的軟件需求發給產品團隊，組織會議評審。評審要點：
          1.需求背景
          2.本期需求的總體功能要求
          3.本期需求各功能模塊要求
          4.本期需求的接口要求
          5.本期需求的性能要求
          6.需求的市場價值（本期合同驗收及回款、后期市場需求準備）
          7.需求的市場時間（在需求調研期間，需求分析是要爭取足夠的市場時間，作冗余）
          8.未來可能會開展的需求（基于市場判斷、競品分析）
          說明：
                對于較小規模的產品，產品規劃師和需求分析師通常是一個人，既負責用戶需求描述，進行外部接口、流程描述也負責將用戶需求轉換為軟件需求，進行內部模塊劃分、接口、流程的描述。   

                對于較大規模的產品，產品規劃師和需求分析師通常是兩個人，產品規劃師負責用戶需求描述，進行外部接口、流程描述，需求分析師負責將用戶需求轉換為軟件需求，進行內部模塊劃分、接口、流程的描述。
        2、需求評審完成后，將需求進行正式發布，同時，郵件說明下一階段工作計劃：
          1.請開發經理、測試經理開始需求工作量評估（含詳細設計、編碼、單元測試、集成測試、系統測試和版本發布）
          2.需求工作量評估完成時間點（結合對市場時間的把握，需求分析師要闡述期望的評估完成時間點要求）
          3.開發經理將詳細設計方案做出來后，會邀需求分析師、團隊成員做評審，以達成需求層面的共識。

        3、工作量評估輸出后，針對下面2種情況，結合個人預估和市場時間，提出建議：
          1.如評估工作量超出預期，發起討論，請研發團隊闡述超出原因，參與討論過程。
          2.如評估工作量存在不合理，發起討論，提出自己理解和建議，參與討論過程，請研發團隊重新評估。
          3.討論結束前，和研發團隊明確工作量重新評估完成時間點。
          4.工作量評估修訂并達成一致后，與開發經理、測試經理、項目經理確定版本啟動時間點。
          5.項目經理針對各方向項目的月度規劃情況，統籌安排并確定啟動時間點后，需求分析師結合啟動時間、評估工作量，發布正式版本研發計劃給給產品團隊。
          6.需求分析師進行產品版本和研發版本規劃。
          7.研發團隊按版本規劃計劃，開展開發及測試工作。

    （2）需求驗證活動：
          1.版本進入開發階段（含編碼、單元和集成測試），參與團隊成員在編碼、自測過程中的疑問和建議。
          2.版本進入測試階段（含單元和系統測試），第一輪系統測試版本關閉之前，需求分析師在系統測試環境上完成軟件需求的驗證，輸出測試過程中發現的產品問題（產品bug、與需求不吻合的地方、存在爭議的地方），組織研發團隊討論。
          3.第二輪系統測試版本關閉前完成需求驗證滿意度的問題落實。

    （3）需求變更活動：
        1、來自客戶的需求變更
           1.影響程度大的需求，與客戶溝通并直接規劃到下一輪版本。如客戶不接受，請客戶提出正式變更申請，走商務流程按合同兌現或發起合同變更流程。
           2.影響程度小的需求，結合在研版本的狀態和需求分析、開發工作量與研發團隊討論和評估。
               如版本狀態允許（如狀態為‘開發中’）且需求分析、開發工作量可以接受，提交變更申請，待項目經理批準后，追加該變更需求到在研版本。
               如版本狀態允許（如狀態為‘系統測試中’）但需求分析、開發工作量較大，與客戶溝通并直接規劃到下一輪版本。
               如版本狀態不允許（如狀態為‘系統測試中’），與客戶溝通并直接規劃到下一輪版本。
        2、來自內部的需求變更
           1.影響程度大的需求，與客戶溝通變更原因并爭取市場交付時間，如客戶接受，提交變更申請，待項目經理批準后，追加該變更需求到在研版本并順延版本計劃。如客戶不接受，內部重新討論，排列需求優先級、協調資源，滿足需求。
           2.影響程度小的需求，與客戶溝通變更原因并爭取市場交付時間，如客戶接受，提交變更申請，待項目經理批準后，追加該變更需求到在研版本并順延版本計劃。如客戶不接受，內部重新討論，排列需求優先級，滿足需求。

    （4）需求跟蹤活動：
        反饋每周的需求進展給項目管理團隊，加強與研發團隊的溝通和需求跟蹤。進展內容包括（不限于）：
          1、原始需求提出人
          2、提出日期
          3、市場接口人
          4、產品經理
          5、需求分析師
          6、版本號
          7、功能需求滿足詳細列表
          8、問題故障解決詳細列表
          9、承諾提供時間
          10、當前狀態（評審中、評審完畢、規劃中、研發中、已發布）
          11、本周進展
          12、上周進展

    （5）需求定期復盤活動：
         產品團隊定期做復盤，包括需求、進度、質量、成本、風險等?？偨Y經驗，形成過程資產。