很多企业在进行新产品开发时，产品需求的确定，仿佛只是产品经理和市场人员的事，他们确定产品该做成什么样子，写成产品规格说明书或者需求文档，然后给研发的系统工程师评审，确定在技术上是可行的，就可以启动一个项目，投入资源进行开发了。然而在这个过程中，很容易出现需求描述不清晰、不详细，导致开发人员开发出不符合客户真正需要的产品。为了解决这个问题，企业会要求产品经理和客户进行前期的需求确认，要求他们将需求文档写得更加详细，要求开发人员参与评审，确保客户、产品、研发三方对需求达成一致的理解。
在这个过程中，测试很少参与。有几方面原因：一是测试不负责产品的实现过程，因此在可实现性上没有发言机会；二是企业招聘测试工程师的时候只强调用例设计能力，不要求他们具有对需求的评审技能。企业普遍认为需求阶段没有测试啥事儿，但结果往往是产品开发出来了，测试才发现有需求上的问题，才发现有些功能需要另外开发一些辅助接口才能对其验证，妨碍了项目按期完成。少数正规化做得比较好的企业，会让测试人员参与到需求评审中来，就可测试性需求提出意见。可即使我们这样去做了，效果却不见得好，为什么？
在确定产品需求这件事上，产品经理、系统工程师和测试工程师的着眼点是不一样的：产品经理会着力于将产品的卖点描述清楚，至于产品的这些卖点在技术上是不是可行的，一般就交给研发系统工程师来确定了；系统工程师会更多地考虑如何将产品做出来，而这些考虑，一般会体现在设计文档中，对于需求文档，他们只会提出和设计相矛盾的地方；测试工程师按照流程要求，会检查需求描述中是否存在前后矛盾的地方，会考虑自己怎么去测试这些需求，顺带提出新的可测试性需求。
在需求评审的这个过程中，你会发现，并没有人对需求文档的完成标准负责：是不是将产品方方面面都描述清楚，使得这些需求在逻辑上顺理成章了？
这样的需求会使开发在实现产品、测试在验证产品时出现很多需要脑补的环节。这些脑补的内容是没有经过评审的，很容易出现问题。也有人问过这个问题，“只做黑盒测试可以保证产品测试充分吗？”针对这个问题，有一个看似完美的假设--只要需求写得很充分、很详细，没有未描述的空白地带，测试只要按照需求说明一一验证到位了，就不会有漏测。然而事实却是，哪怕这个假设成立，在实际中也是不可行的，因为这对产品经理要求太高了，极少有产品经理能够写出如前所述般“完美”的需求说明。
为了解决需求不够详细这个问题，企业会将需求分阶段表现，先用市场需求（MRD）描述产品的卖点和市场空间之类的信息，信息传到产品部的时候用产品需求（PRD）描述更接近研发理解的产品各个功能和性能需求点，最后研发再用产品详细规格（SyRS）描述各个功能点需要满足的要求，一步一步地细化，最终让需求变得足够详细。这样做是可以达到目的的，只要研发能够投入资源去做产品详细规格书，一般能满足“需求足够详细”这个要求。但你会发现，这中间还是没有测试啥事情。
实际上，测试工程师是整个团队中最擅长将需求变得足够详细的人，因为他的工作需要将产品实际运行的每一个细节都表述清楚。执行测试的时候，不将每个细节都检查一遍是不可能的。但是，我们招聘测试工程师的时候，是不要求他具有写需求的能力的，在实际工作中，也不要求他们写需求，因此，他们也很乐意将需求文档这一最决定他们工作质量的交付物的完成情况交给别人去负责。
在敏捷项目中，每次客户更新需求的时候，测试都得参与，第一时间构思这些需求该怎么验证，虽然没有形成什么文档，但完善需求这个过程是切切实实地在测试工程师的脑海中跑了一遍的。因此，测试是有能力做这个事情的，只是需要锻炼而已。
在项目结束之前，需要完善用户文档，并对用户文档进行验证。前者是文档工程师的工作，后者则是由测试工程师负责的。在人员配备没有这么“豪华”的企业，没有文档工程师，开发人员会被指定去写用户手册，有些企业也会让测试工程师去写。相较而言，测试工程师去做这件事情会更合理，因为他们是从客户的角度出发来对产品进行验证的，测试工程师更能够写出符合客户思维习惯和使用习惯的使用手册。
当测试工程师能够承担起撰写用户手册这个任务之后，就可以承担需求文档完善的工作了。需求文档和用户手册的要求不一样，卖点、特性等这些关键信息的描述不能出现任何偏差，这些可以让产品经理按照原有要求出需求文档，测试在此基础上进行完善，使需求文档满足详细、完备、逻辑顺畅的要求。
这种做法在需求阶段增加了工作量，并且同一个交付物由不同角色的人员合作完成，可能会带来职责不清的问题，这是缺点；但测试人员参与完善需求的工作，保证了他们在需求阶段就充分投入去了解产品应该做成什么样子，为后续的用例设计打下良好的基础，同时，可测试性需求这些内容会自然而然地体现在需求里面，减少后续需求更改的次数。这些好处是能够弥补前面所提到的缺点所带来的代价的。
