需求必须遵循一些规则和结构：

（一）独特的

需求是其本身的实体，不能是两个或多个需求的组合。

（二）明确的

需求的所有读者应该对需求的内容有相同的理解，只能有一种解释。

（三）可验证的

如果不能正确验证需求，那么工程师将如何确定他们已满足需求呢？通常，你将进行内部验证，测试工程师会进行测量，以检查硬件是否正常运行并符合其设计规格和要求。

然后进行设计验证，在该测试中，将对产品的外壳，不同温度和湿度条件下进行更严格的测试，该验证阶段还包括EMC测试。最后，该产品将在实际操作条件下进行现场测试，或者将其集成到更大的系统中，或者使其与其他设备进行交互。

（四）属性

应该给需求赋予属性以支持前面提到的规则要求：

​ 标题：需求的描述性标题；

​ ID：不能重复的唯一标识；

​ 与安全相关：在某些安全性很重要的产品中，将需求分类为与安全相关是一种良好做法；

​ 优先级：在某些情况下，无法实现所有需求，因为它们会相互冲突。分配优先级可为设计人员提供信息，选择最相关的需求；

​ 来源：这是指需求的来源，是客户、承包商还是外部的；

​ 理由/目的：对需求及其存在原因的简短描述；

​ 验证方法：该需求将如何验证、测试和分析；

​ 跟踪信息：需求必须是可追溯的。

通常情况下，在产品需求完成之前可能会修改原产品需求的50％以上的内容。例如，可能会突然出现需要结合新技术或者新法规的情况，这会迫使你更改设计。

需求变更需要由需求工程师，系统工程师或项目经理解决和管理。一般情况下，工程师可以使用工具或软件来寻求帮助。需求工具可以自动化并保留可追溯性和历史更改的记录，同时支持需求验证结果的记录。

管理新出现的需求也很重要，这些需求仅在系统组合在一起时出现，很难预见，必须在其他需求的基础背景下分配它们，避免孤立需求。

（五）电子产品的需求文档

电子产品的需求文档没有单一的格式，每个设备都有自己的规格和特殊性。当然，大多数电子产品可以遵循以下需求类别：

​ 产品说明：产品的一般高级描述，最好附有系统级框图；

​ 设计要求：产品在组件和设计方面需要具备的功能；

​ 功能要求：产品要执行的功能；

​ 环境和功能性环境要求：与对环境的影响及其在何处执行功能有关；

​ 机械要求：外壳相关要求；

​ 使用寿命要求：工作时间和工作温度；

​ 测试要求：产品需要通过的相关测试。