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