Denice Surjan | 2018年3月19日
正如卡尔·威格斯（Karl Wiegers）在其论文中准确地写出更好的要求时所说的那样，“质量在读者眼中……无论作者认为要求有多精细，最终的仲裁者都是那些必须根据这些要求来开展自己的工作的人。”
编写需求时，避免歧义对于构建您要构建的产品至关重要。 在我们最近的文章“五种模棱两可的语言会破坏您的需求”中，我们分享了需求编写中模棱两可的示例，并提供了有助于澄清的专家提示。
这是另外四个含糊不清的来源，另外还有其他最佳实践可以节省您的需求以及您的产品。
负面要求
负要求或逆要求会造成很多不必要的歧义。 主动语态中的积极要求更容易理解。 这是从消极到积极时提高清晰度的前后示例。
缩写ie和例如
一些读者可能会误认为ie的使用， 例如缩写ie代表拉丁语短语id est ，表示“即”。缩写例如代表拉丁语短语exempli gratia ，表示“例如”。
这两个缩写很容易混淆（无论是作者还是读者），以至于最好完全避免使用它们，而要明确地说出您的意思。
A / B结构
一些需求编写者使用A / B构造，例如“数据应该记录在审计/历史表中。”这种构造很少用在正式的写作中，因为它含糊不清，可以用多种方式解释。 一些示例包括：
- A与B相同。在这种情况下，它们是同义词，您应始终坚持一个术语。
- A和B。在这种情况下，请使用显式连词“和”。
- A或B。在这种情况下，请使用显式连词“或”。
副词
以-ly结尾的单词通常是模棱两可的。 它们可能描述了产品的某些理想特性，但是确切的要求留给每个读者的解释。 这里有一些例子：
- “允许用户编辑他的兴趣以及可能的搜索结果……”用户是否应该能够编辑搜索结果？
- “优化上传和下载以快速执行。”五秒钟是否算是快速？
- “提供明显更好的下载时间。”确切说明要好多少，或给出一个确切的下载时间范围。
- “正在更改内容选择的订户（ 实际上是当前已订阅订户的子集）……”他们是否是子集？
- “ 适当地公开信息……”什么被认为适当？
在描述预期产品的特性时要特别具体，以便所有读者在完成预期结果时拥有共同的愿景。
阅读Karl Wiegers的论文“ 编写高质量的需求 ”，以了解制定成功的需求还有哪些其他内容。
Denice Surjan | 2018年3月19日
