## 2 Background and Related Work  
A requirement has been defined as \"a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user\" [6]. Requirements are often the basis for communication between stakeholders with different backgrounds (e.g., users, developers, project managers), and so, requirements should be accessible and, whenever possible, easy to understand. There are different ways of documenting requirements. By far, the most common way is to use text, but there are also graphical notations (which end up relying on text as well). Text-based requirements are written, more often than not, using informal natural language, often ambiguous and thus, error-prone. Graphical notations introduce some formalisms, which help to reduce ambiguity, but there is still room for informality and, most of all, require stakeholders to know those notations. In some cases (e.g., for critical systems), formal methods are sometimes used, but these rely on languages and methods accessible to only a very few. Altogether, this means that, in practice, requirement specifications contain ambiguities that lead to costly errors. The estimated cost of fixing an error during the requirements phase has been estimated as up to 1500 times cheaper than fixing an error in other phases of the project life-cycle [1]. Errors in the requirements are inevitable, hence, those who are able to detect and correct them early, such that they do not propagate, have a significant competitive advantage. Besides the cost of correcting errors, the cost of changing requirements is also high (an increasing necessity nowadays in order to adapt to fast changing business needs). There are, however, not only monetary and time-related costs, but also a psychological cost on the developers and other stakeholders, leading to a resistance to change and innovation. We identify two major kinds of errors in the requirements: (1) errors when expressing or understanding requirements (we will call these verification errors); (2) errors estimating the realization value of requirements in practice (we will call these validation errors). In the literature, we also find two major kinds of approaches which propose the reduction or early detection of errors in the requirements, namely: (1) new processes, and (2) new tools. If processes were followed scrupulously, most (if not all) errors would be found. The issue, in our opinion, is that typical human beings are unable to maintain the necessary level of focus and concentration required to follow processes that are often complex, have high overhead, and lack adequate support tools. This is exacerbated by the large size of typical requirement specifications. It is impossible for a typical human being to reason on such large texts with the necessary precision. In terms of tools, and to workaround the current limitations in natural language processing, controlled natural languages (CNLs) have been proposed for writing requirements [2; 3]. A CNL should read like natural language, such that it is accessible to all or most stakeholders. However, according to a formal grammar, there is always one interpretation for a given sentence [4]. Hence, with a CNL, it is possible to remove ambiguity and, through appropriate support tools, the reduction and early detection of verification errors in the requirements. CNLs, nevertheless, are not without limitations. They require readers, and especially writers, to know the grammar and to learn to express themselves using that grammar in a way that does not impair their creativity [5]. Formal grammars can easily become complex, and the implementation of support tools demand a significant effort. Moreover, unanticipated constructions or patterns cannot be handled or have to be handled in unexpected and cumbersome ways. These limitations lead to trade-offs (e.g.,comprehensive grammar vs. support tools) which ultimately result in CNLs that are either limited in scope or not very useful.