为什么要参与需求分析？
1，吃透被测对象详细需求——是后期测试活动的依据。
2，指出需求歧义——避免需求流失。
3，对需求不合理提出改进建议——把可能的缺陷关闭在需求分析阶段。
需求：凡是被测事物就是需求。（不限于：系统，文档，脚本，算法）
实际工作中，当测试接入时，项目处于什么阶段是不确定的。不同阶段的项目，测试展开工作的重点不同。需要通过历史需求和当前需求分析，明确被测对象现状与风险，作为后期展开工作活动的重要依据。
项目根据阶段分三类：新项目 ， 中期项目 ， 维护项目。
新项目：项目立项刚结束，承接到规划的需求，开发和测试新接入此项目。
此类项目往往迭代一规划的开发任务已经初步给出，但产品最终成型还是停留在规划上，这个时候测试人员也要依据自己的经验，专业，结合原始需求与开发一起参与需求分析整个过程。并提出建议和意见。通常开发人员更多的会从代码实现可行性，难度，实现方式等方面考虑。测试则应从用户体验，界面交互，性能，甚至是维护和推广的角度来考虑。
中期项目：项目已完成几个迭代，处于开发中期。
此类项目迭代已稳定进行几个周期，开发处于中期。这时候接入测试，测试人员需要先熟悉已完成的需求，产品规划等，再结合新需求进行需求分析。一方面做新需求分析，一方面要考虑新需求对老版本的关联和影响。或采用新需求兼容老版本的方式，或者老版本做更改和扩展，适应新需求。根据项目实际情况决定。
维护项目：项目开发结束，上线，处于维护阶段。
此类项目基本已经开发完成，开发人员通常只留有部分人员。测试此时接入，需要较多时间来熟悉已有功能。根据项目资料文档尽快熟悉产品的情况。后期维护，承接新需求时重点考虑的是新需求对老版本的影响。通常也是采用新需求兼容老版本的方面。不会再对老版本做大的变动。
测试需求的依据有哪些
1）待测软件相关的各种文档资料。
2）与客户或系统分析员的沟通。
3）业务背景资料。如待测软件业务领域的知识等。
4） 用户体验方面。
5）同类成熟产品参考。
需求分析步骤
step1：承接需求时，需要需求方给出原始需求文档；并由需求方主讲进行首次需求澄清。
step2：开发团队进行需求分析（包括需求的可实施性，关键风险，实现效果，开发周期，交付结果，验收标准等）后，开发主讲进行需求反澄清。形成完善的需求规格说明书文档。
