一般来说，需求是以文本形式提供的。有编写良好需求的指导方针;它们包括关于需求陈述的语法、措辞(排除、概念的表示等)和特征(具体的、可测量的、可实现的、可行的、可测试的，等等)的建议。参见(INCOSE 2011，第4.2.2.2节)和(ISO 2011)。
需求和需求集都有一些特征，用于帮助它们的开发，并验证将需求实现到解决方案中。表3列出了个别需求的特征和说明，表4则列出了一组需求的特征和说明(ISO 2011，第5.2.5和5.2.6节)。
表3。独立需求的特征。
特征 | 描述 |
必要的 | 需求定义了一个基本的能力、特征、约束和/或质量因素。如果它不包含在需求集中，就会存在能力或特性上的缺陷，无法通过实现其他需求来实现 |
适当的 | 需求的具体意图和细节量与它所引用的实体级别(抽象级别)是适当的。这包括避免对架构或设计进行不必要的约束，以帮助确保实现，尽可能独立 |
明确的 | 要求以一种只能用一种方式解释的方式陈述 |
完整的 | 需求充分描述了满足实体需求所需的能力、特征、约束或质量因素，无需其他信息即可理解需求 |
单数的 | 需求应该声明一个单一的能力、特征、约束或质量因素 |
可行的 | 需求可以在具有可接受风险的实体约束(例如，成本、进度、技术、法律、法规)内实现 |
可验证的 | 需求被结构化和表述，以便它的实现能够被证明(验证)到客户满意的层次上，需求存在的位置 |
正确的 | 需求必须是被转换的实体需求的准确表示 |
符合 | 在适用的情况下，单个需求应该符合已批准的标准模板和书写需求的样式 |
注:一些来源认为可追溯性是一种特性。然而，最近的观点是追溯性实际上是需求的一个属性;也就是说，附加在要求上的东西，而不是要求的内在特征。可追溯性特征或属性定义为:需求向上可追溯到特定的文档化的利益攸关方需求陈述、更高层次的需求，或其他来源(例如，贸易或设计研究)。需求也可以向下追溯到较低层次需求规格说明或其他系统定义工件中的特定需求。也就是说，需求的所有父子关系在跟踪中被识别，这样需求就可以追溯到它的源和实现。
表4。一组需求的特征。
特征 | 描述 |
完整的 | 需求集是独立的，因此它充分地描述了必要的能力、特征、约束和/或质量因素来满足实体的需要，而不需要其他信息。此外，该集合不包含任何to be已定义(TBD)、待指定(TBS)或待解决(TBR)条款。
|
一致的 | 需求集包含独特的、不与该集中的其他需求冲突或重叠的单个需求，并且它们使用的单位和度量系统是同构的。集合中使用的语言
|
一致的， | 例如。时，同一个词在整个集合中都被用来表示同一件事。
|
可行的 | 需求集可以在可接受的实体约束(例如，成本、进度、技术、法律、法规)内实现风险。(注:“可行”包含“负担得起”的概念)
|
可理解的 | 这组需求必须写得清楚，即实体期望什么以及它与系统的关系这是一部分。
|
可验证的 | 它必须能够被证明，需求集将在约束条件(如成本、进度、技术、法律和法规遵从性)内导致实体需求的实现。 |
需求表 | 需求可以在表格中提供，特别是为系统或系统要素指定一组参数时。提供标准表模板是一种良好的实践。对于表，适用下列约定: 调用需求集中明确指向该表的每个需求表。 用唯一的标题和表号标识每个表。 在表标题中包含“需求”一词。 在紧接前面的文本中确定表格的目的，并包括如何阅读和使用表格的解释，包括环境和单位。 对于独立-因变量的情况，组织表的方式最好适应信息的使用。 每个单元格最多应该包含一个需求。 |
