项目生命周期中，变更和纠正错误的代价在项目接近完成时通常会显著提高。所以在项目研发过程中，需求分析师要参与到产品研发过程，与开发人员、测试人员保持紧密沟通，讨论和澄清在实现过程中的需求疑问，保证产品产出和需求意图的吻合。软件项目中的需求变更，相信做需求的人员再熟悉不过，需求变更率的高低，也是反应需求工作好坏的一个重要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）需求定期复盘活动：
         产品团队定期做复盘，包括需求、进度、质量、成本、风险等。总结经验，形成过程资产。