测试是根据用户需求文档来设计测试计划，编写测试用例的。不仅是测试，编码也需要根据用户需求文档来设计。写用户需求文档的应该就是我们所说的系统工程师或者结构工程师了，他们的成果分别是《系统需求说明说》和《结构需求说明书》。

作为测试的一部分，对说明书的静态测试也是十分必要和重要的，对于需求文档的测试，包括比如系统实现的逻辑是否合理，措辞是否严谨，需求的可测性等等，这些发现的问题都应该作为需求说明书的bug，需要让SE来更改。这里当然不是说我们很牛，要找SE的问题，但是我们至少要从测试和客户的角度来看待，让说明书符合一定的规范。

问题举例：1. 理论算法一大堆，但是没有可测性，让测试无法下手，这时应该给出一些实例。2.需求描述含糊，例如用：所有、凡是、一切等等的字样都需要更改，应该给出具体实例，以得出比较具体的测试范围。3.需求描述不清楚，有重复等等。

根据软件理论，在需求文档期间发现的问题能使整个项目的成本大大节俭，包括时间，人力和金钱。所以，我们还是要认真对待的,不要把SE看成神圣不犯错误的。 不过，当然还是很崇拜SE，对系统结构了解的是那么清楚，哪个部件需要有更改都能估计到。