编写需求时，每个字都很重要。添加副词或使用“应该”代替“必须”等简单操作都可能造成歧义，让工程师感到困惑，并使项目倒退。
更好的需求可使利益相关者之间的沟通更清晰、更有效。这将推动整个组织实现更高的透明度、更少的返工和更快的开发……而不会牺牲质量。虽然编写需求既是一门艺术也是一门科学，会因具体情况而异，但有一些最佳实践值得考虑。
遵循编写需求的这些首要注意事项，您会发现自己在整个产品开发生命周期中都有清晰且可追溯的需求。
1. 要做：使用需求模板
模板为需求提供了一致的结构。它可以是用户故事或系统工程格式，这两种格式都提供了统一的结构以支持更轻松的测试。
2. 不要：使用副词
“快速”、“轻松”和其他副词无法为测试人员提供明确的指导。相反，应关注可测试和可衡量的验收标准。
3. 要做：标准化语言
英语在日常使用中有许多含义相似的单词。选择几个来表示约定俗成的含义，例如“shall”表示具有约束力的高优先级要求。
4. 不要：含糊不清
要求往往含糊不清，因为它们太笼统，例如“设备应易于使用”。要更具体，无论是设置明确的基准还是命名特定颜色。
5. 要：使用主动语态和特定形容词
使用主动语态动词。例如，“汽车应承受……”比“汽车应增强以承受……”更清楚。还要选择特定的形容词，而不是“用户友好”和“兼容”等备用形容词。
6. 不要：将设计规范混入要求中
尽可能将设计从要求中移除，因为后者描述的是需求，而前者是对需求的回应。无设计要求为工程师提供了更多自由。
7. 要做：定期与利益相关者一起审查需求
与他人一起审查需求是确保达成共识的可靠方法。在实时平台内协作可让团队交换反馈、确保可测试性并最大限度地减少返工。
8. 不要：依赖负面需求陈述
负面陈述可能会带来歧义，因为任何系统在满足其积极需求的过程中几乎都有无数的事情“不会做”。检查负面陈述
