需求质量把控-风险和问题前置方案简述

需求质量把控-风险和问题前置方案简述

前言：为了更好的把控需求的质量和测试过程，列出一写可行性的建议方案。

背景：测试过程中发现一些问题，比如：需求文档文字表述不清晰；测试发现某些功能不正确或者实现错误；产品验收时候，总会验收出想不到的一些问题，等。

1.需求文档评审需要严格把控结果：需求评审遗留的问题或者不通过的疑问点，如有存在，代表此需求不通过。目前有此现象，但需求还是通过，产品后续在补充完整。建议不通过，后续补充完整后，由测试开发把关需求最终是否通过。

目的：这样会督促产品在写需求文档时，考虑好整个场景，前置调研需求的可实现性，防止到测试阶段由测试人员发现问题，在改需求。

2.需求评审会议后，1.测试需要把控需求的不合理点及其风险点。2.确定开发是否能需求所有的功能可以实现。

目的：1.需求问题前置，提早发现问题，防止开发做完后，测试阶段频繁的在做改动。2.开发过程如实现不了需求所要求的，由开发在开发阶段抛出此问题，不能在测试阶段由测试抛出此类问题。

3.需求评审完，建议加入业务串讲环节（重要的项目），产品，开发，测试会议。

 目的：测试可提前明白开发实现的逻辑，测试用例方向和测试方法提前知晓，产品可在此同步一致需求的意思，防止需求各自有各自的理解，开发可提前梳理梳理实现的方案。这样整个项目，进度质量在这一阶段整体提高。

4.测试阶段，产品修改需求，必须由测试把控修改需求的范围，是否合理，如改动大的相应的增加测试的测试时间。

    目的：防止项目的时间压倒测试这里，压缩测试时间。

5.1.测试范围100%按照需求文档来执行，如修改的，必须同步在需求文档内，不许口头说明。2.需求文档没写到的业务场景可以选择不测，比如需求写的很简单，测试的时候才发现需要测试的场景范围很多。

  目的：1.防止后面各方扯皮，可隐性提高初稿需求文档的质量。2.产品比开发和测试更能了解整个业务场景，提高产品需求文档方面，业务方面的考虑周全，风险前置到产品，提高整个项目的质量。

备注：此些建议，运用的场景不一样，且推动实施可能较难。

表达出此类的思想，实现可灵活实现。