{"id":27093,"date":"2018-03-19T09:21:28","date_gmt":"2018-03-19T16:21:28","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=26351"},"modified":"2023-01-12T16:53:13","modified_gmt":"2023-01-13T00:53:13","slug":"how-to-avoid-ambiguity-and-save-your-requirements","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2018\/03\/19\/how-to-avoid-ambiguity-and-save-your-requirements\/","title":{"rendered":"How to Avoid Ambiguity and Save Your Requirements"},"content":{"rendered":"

\"\"<\/p>\n

As Karl Wiegers accurately states in his paper on writing better requirements<\/a>, \u201cquality is in the eye of the reader \u2026 No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.\u201d<\/p>\n

Avoiding ambiguity when writing requirements is essential to building the product you want built. In our recent post, “Five Ways Ambiguous Language Will Ruin Your Requirements<\/a>,” we shared examples of ambiguity in requirements writing and gave expert tips to help clarify.<\/p>\n

Here are four more sources of ambiguity, plus additional best practices to save your requirements \u2014 and your product.<\/p>\n

Negative Requirements<\/strong><\/h3>\n

Negative or inverse requirements create a lot of unnecessary ambiguity. Positive requirements in active voice are much easier to understand. Here are some before and after examples of increased clarity when moving from negative to positive.<\/p>\n

\"Negative<\/p>\n

Abbreviations i.e. and e.g.<\/strong><\/h3>\n

Some readers might misconstrue the use of i.e.<\/em> and e.g.<\/em> The abbreviation i.e.<\/em> stands for the Latin phrase id est<\/em>, which means \u201cthat is.\u201d The abbreviation e.g.<\/em> stands for the Latin phrase exempli gratia<\/em>, which means \u201cfor example.\u201d<\/p>\n

These two abbreviations are so commonly confused \u2014 either on the part of the writer or the reader \u2014 that they are best avoided altogether in favor of explicitly saying what you mean.<\/p>\n

A\/B Construct<\/strong><\/h3>\n

Some requirements writers use the A\/B construct, as in, \u201cdata should be recorded in an audit\/history table.\u201d This construct is rarely used in formal writing because it is so vague it could be interpreted in a variety of ways. Some examples include:<\/p>\n