编写需求文档，在嵌入式开辟范畴是很是普遍的。需求文档被用来定义开辟任务，协调年夜范围的研发打算。对最终的产品，需求文档饰演着开辟者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以阐扬巨年夜的作用。然而，如果你在嵌入式开辟范畴工作的时间足够长，你就会很快发现，这个范畴里不合格的需求文档实在是太多了。当你测验测验对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。

从较高的条理来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：

• 工程师可以按照系统所说进行实现。

• 测试人员，在不与开辟人员沟通的前提下，可以操纵满足硬件要求的设备验证需求。

• 最终产生的功能满足终端用户的要求。

黑盒测试书写优质的需求文档：

最根基的原则是：需求文档应当尽可能精练，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。

枚举一下更详细的法则，通常会更有帮忙。下面是书写优质需求文档需要遵循的步调：

1. 定义系统的鸿沟。这也是黑盒系统所需要的。

2. 定义输入和输出。这也应当是你对待内部系统的唯一体例。

3. 用最易懂的体例描述系统的预期行为。

4. 除输入和输出之外，你的需求是不是还涉及了系统的其他部分？如果是，那么你的需求就设计过度了。重构需求，让它变得精简。

5. 你的需求是不是过于模棱两可？插手更多的限定规范。注意：有些模棱两可的描述其实不是坏事，假定描述所包含的所有情况都可被接管，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要（也不该该）把系统的行为限制得过甚。

6. 你的需求是否可测试？（这里指的是黑盒测试）如果不是，你最好返回到第4步。如果这种返工产生很多次，那就说明你的黑盒无法正确描述系统，或你的测试东西不敷优秀。无论是哪种情况，不成测试的需求文档几近就是一文不值的。

7. 你的需求文档通俗易懂么？如果你的需求文档很是难以读懂，那就说明你写得欠好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第3步。

8. 你是不是真的做到了第4步？你确认么？再查抄一下。

例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并按照不合的频率值让一个LED闪烁。

显然，我们已经完成了步调2和步调3了！

• 输入：从弯曲传感器读取数据。

• 输出：LED。

可是我们跳过了步调1：

• 在这个例子里，我们将把黑盒画到设备的微措置器上。

让我们继续往下进行，

第四步：除输入和输出以外，我们是否还涉及了其他的系统鸿沟？

• 微措置器其实不关心从弯曲传感器读取什么样的数据，从措置器的角度来看，仅需要做的是丈量ADC脚的电压罢了。

• LED仅由数字输出脚节制。

下面，让我们来修正这个问题：

第0版本的需求：

1. 该设备应当按照ADC脚的不合频率的电压，来切换数字输出真个状态。

第五步：需求写模棱两可么？

恩，我们的描述太模棱两可了。输出端切换的速度要多快？ 跟电压的关系如何？ 输入电压的范围是多少？ 让我们加一些更细节的描述吧：

版本0.1

1. 输出端应当由一个自由勾当的按时器进行节制

2. 自由运行按时器的频率最高不得高于每秒10次，不得低于每秒1次。

3. 自由运行按时器的触发频率应当在最高和最低值之间呈线性转变，并与ADC真个输入电压成正比。

4. ADC真个输入电压应当每100毫秒读取一次

5. 当ADC真个输入电压端被读入时，节制自由运行按时器周期时间的注册值也应当被更新。