如何编写优质的软件测试需求文档
编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。
从较高的层次来看，书写需求文档的目的是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：
● 工程师可以根据系统所说进行实现
● 测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。
● 终产生的成果满足终端用户的要求。
黑盒测试 书写优质的需求文档：
基本的原则是：需求文档应当尽量简洁，用易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。
列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤：
1、定义系统的边界。这也是黑盒系统所必要的。
2、定义输入和输出。这也应当是你看待内部系统的方式。
3、用易懂的方式描述系统的预期行为
4、除了输入和输出之外，你的需求是不是还涉及了系统的其他部分？如果是，那么你的需求设计过度了。重构需求，让它变得精简。
5、你的需求是不是过于模棱两可？加入更多的限定规范。注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么没关系。你不需要（也不应该）把系统的行为限制得过头。
6、你的需求是否可测试？（这里指的是黑盒测试）如果不是，你好返回到第4步。如果这种返工发生很多次，那说明你的黑盒无法正确描述系统，或者你的测试工具不够。无论是哪种情况，不可测试的需求文档几乎是一文不值的。
7、你的需求文档通俗易懂么？如果你的需求文档非常难以读懂，那说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第3步。
8、你是不是真的做到了第4步？你确认么？再检查一下。
例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个LED闪烁。
显然，我们已经完成了步骤2和步骤3了！
● 输入：从弯曲传感器读取数据。
● 输出：LED。
但是我们跳过了步骤1：
● 在这个例子里，我们将把黑盒画到设备的微处理器上。
让我们继续往下进行，
第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界？
● 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量ADC脚的电压而已。
● LED仅由数字输出脚控制。
下面，让我们来修正这个问题：
第0版本的需求：
1、该设备应当根据ADC脚的不同频率的电压，来切换数字输出端的状态。
