编写需求文档时的8个注意事项
编写需求时，每一个词汇的选用都至关重要。简单地添加一个副词或将“必须”改为“应该”都可能产生模糊含义，这可能使工程师感到困惑并导致项目延误。
更好的需求能使各方利益相关者之间的交流更为清晰有效。这将整个组织推向更大的透明度，减少重新工作的需要，同时加快开发速度，且不会牺牲质量。虽然编写需求是一项结合艺术和科学的工作，会根据上下文环境而变化，但仍有一些最佳实践需要考虑。
遵循以下关于编写需求的主要注意事项，你将会发现在整个产品开发周期中，需求既清晰又可以追溯。
1.应该：使用需求模板
模板能为需求提供一致的结构。可以使用用户故事或系统工程格式，两者都能为更容易的测试提供统一的结构。
2.不应该：使用副词
“快速”、“轻松”等副词无法为测试人员提供清晰的指导。你应专注于可测试和可衡量的验收准则。
3.应该：标准化你的语言
中文、英语中包含许多在日常用法中含义相似的词汇。你需要确定一些词汇来表示被大家接受的含义，例如用“shall”表示具有约束性的高优先级需求。
4.不应该：模糊不清
需求常常因为过于泛泛而引起歧义，例如，“设备应易于使用”。应当更具体，无论是设定一个明确的标准，还是指定一个特定的颜色。
5.应该：使用主动语态和特定的形容词
使用主动语态的动词。例如，“汽车应该承受…”比“汽车应该被加强以承受…”更清晰。也要选择具体的形容词，而不是常用的像“用户友好”和“兼容”等词汇。
6.不应该：在需求中混入设计规格
尽可能从需求中去除设计，因为需求描述的是需求，而设计则是对需求的响应。不含设计的需求可以给工程师更多的自由度。
7.应该：定期与利益相关者审查需求
与其他人审查你的需求是确保大家对需求有共同理解的可靠方法。在实时平台上协作可以让团队交换反馈，保证可测试性，并且最小化返工。
8.不应该：依赖于负面的需求声明
负面声明可能引入歧义，因为在实现其积极需求的过程中，任何系统都有几乎无穷无尽的“不做”的事情。你需要审查负面声明。
以上就是编写需求时的一些重要原则。遵循这些原则，能帮助你编写出更清晰、更易于理解和执行的需求，从而使项目更有效地推进。
需求管理指南：
需求管理： 需求管理主要内容 | 需求管理的重要性 | 采用敏捷方法进行需求管理 | 如何克服需求管理的 5 大挑战 | 更多
需求编写： 功能需求的示例和模板 | 采用 EARS 方法来改进需求工程 | 如何编写一份优秀的产品需求文档（PRD） | 功能性需求与非功能性需求的区别 | 有效需求的特征 | 更多
需求收集和管理流程： 需求工程概述 | 产品团队的需求分析指南 | 敏捷产品团队的 11 种需求收集技巧 | 定义和实施需求基线 | 更多 需求的可追溯性： 什么是需求可追溯性 | 可追溯性在现代产品和系统开发中的关键作用 | 如何创建和使用需求追溯矩阵 | 更多
需求确认和验证： 产品团队的需求验证和确认 | 更多
需求管理领域文章：
做好需求分析的4大关键认知 | 盘点国内9款热门需求管理系统 | 构建产品路线图的方法与工具 | 做好需求优先级判断的7种主流模型 | 采用敏捷方法进行需求管理 | 更多