编写需求文档时的8个注意事项

编写需求时，每一个词汇的选用都至关重要。简单地添加一个副词或将“必须”改为“应该”都可能产生模糊含义，这可能使工程师感到困惑并导致项目延误。

更好的需求能使各方利益相关者之间的交流更为清晰有效。这将整个组织推向更大的透明度，减少重新工作的需要，同时加快开发速度，且不会牺牲质量。虽然编写需求是一项结合艺术和科学的工作，会根据上下文环境而变化，但仍有一些最佳实践需要考虑。

遵循以下关于编写需求的主要注意事项，你将会发现在整个产品开发周期中，需求既清晰又可以追溯。

1.应该：使用需求模板

模板能为需求提供一致的结构。可以使用用户故事或系统工程格式，两者都能为更容易的测试提供统一的结构。

2.不应该：使用副词

“快速”、“轻松”等副词无法为测试人员提供清晰的指导。你应专注于可测试和可衡量的验收准则。

3.应该：标准化你的语言

中文、英语中包含许多在日常用法中含义相似的词汇。你需要确定一些词汇来表示被大家接受的含义，例如用“shall”表示具有约束性的高优先级需求。

4.不应该：模糊不清

需求常常因为过于泛泛而引起歧义，例如，“设备应易于使用”。应当更具体，无论是设定一个明确的标准，还是指定一个特定的颜色。

5.应该：使用主动语态和特定的形容词

使用主动语态的动词。例如，“汽车应该承受…”比“汽车应该被加强以承受…”更清晰。也要选择具体的形容词，而不是常用的像“用户友好”和“兼容”等词汇。

6.不应该：在需求中混入设计规格

尽可能从需求中去除设计，因为需求描述的是需求，而设计则是对需求的响应。不含设计的需求可以给工程师更多的自由度。

7.应该：定期与利益相关者审查需求

与其他人审查你的需求是确保大家对需求有共同理解的可靠方法。在实时平台上协作可以让团队交换反馈，保证可测试性，并且最小化返工。

8.不应该：依赖于负面的需求声明

负面声明可能引入歧义，因为在实现其积极需求的过程中，任何系统都有几乎无穷无尽的“不做”的事情。你需要审查负面声明。

以上就是编写需求时的一些重要原则。遵循这些原则，能帮助你编写出更清晰、更易于理解和执行的需求，从而使项目更有效地推进。

 需求管理指南： 

需求管理： 需求管理主要内容  |  需求管理的重要性  |  采用敏捷方法进行需求管理  |  如何克服需求管理的 5 大挑战  |  更多 

需求编写： 功能需求的示例和模板  |  采用 EARS 方法来改进需求工程  |  如何编写一份优秀的产品需求文档（PRD） |  功能性需求与非功能性需求的区别  |  有效需求的特征  |  更多 

需求收集和管理流程： 需求工程概述  |  产品团队的需求分析指南  |  敏捷产品团队的 11 种需求收集技巧  |  定义和实施需求基线  |  更多  需求的可追溯性： 什么是需求可追溯性  |  可追溯性在现代产品和系统开发中的关键作用  |  如何创建和使用需求追溯矩阵  |  更多 

需求确认和验证： 产品团队的需求验证和确认  |  更多 

需求管理领域文章：

 做好需求分析的4大关键认知  |  盘点国内9款热门需求管理系统  |  构建产品路线图的方法与工具  |  做好需求优先级判断的7种主流模型  |  采用敏捷方法进行需求管理  | 更多