## 2 Background and Related Work
Besides removing ambiguity, another major benefit of using a CNL is that relevant artifacts can be predictably generated. This enables, in particular, code generation, automated verification, early validation, and in the end, reduced time-to-market. A requirements specification written in a CNL can be compiled into a formal model that can be verified to prove that there are no contradictions, that invariants are not violated, and more [2; 3; 7; 8; 9; 10]. Similarly, a requirements specification can be compiled into prototypes or mockups, or ideally, into runtime or production code, which can be delivered to QA as well as to end-users, enabling the realization of the requirements to be tested and validated in practice as soon as possible. In the literature, we find that Osmosian [11], Logical English [12; 13], reqs [14; 15], and Gherkin [16], are the CNLs that most closely resemble REX. First, Osmosian is accompanied by compiler, desktop, editor, etc., all of them written in \"plain english\". This project seems to have been developed to prove the point that \"plain english programming\" is feasible (we believe that requirements can be regarded as just another programming language, yet one with a very high-level of abstraction and all-powerful), and thus, resorts almost completely in \"plain english\", which for practical purposes is not always appropriate. For practical purposes, there should be a balance between natural and technical modes of expression. Second, reqs, like REX, has also been developed for runtime code generation, but from very limited use case specifications. Third, Cucumber is focused on acceptance tests specifications, which some may regard as a requirements specification; however, so far, it has not been sufficient for runtime code generation (as opposed to test code generation). Lastly, Logical English, developed in Prolog, with a complex and imposing grammar has also not been developed for runtime code generation. In the literature, many other CNLs can be found, of which we highlight: (1) the CNLs presented by [PERSON] et al. [17], which impose a strict and thus, limiting grammar; (2) SBVR [18], or SBVR-SE, to be more specific, and RuleSpeak [19] (supported by RuleXpress [20]) for managing business rules; and (3) ACE [4] and PENG [21] for knowledge representation using first-order logic. In the end, the CNLs that are found in the literature have at least one of the following limitations: not suitable or very limited for requirements specifications, no runtime code generation support, or no balance between natural and technical modes of expression. In this article, we present REX, a CNL which distinguishes itself by having a small but comprehensive set of rules, and thus, a grammar that is simple, easy to understand, and easy to support. In this way, and as explained in the following sections, the limitations above do not apply to REX. Looking back through a CNL for requirement specification, the two major kinds of requirement errors identified above are addressed as follows:  
* Verification errors: ambiguity is removed (through a formal grammar), and automated verification is added (through code generation);
* Validation errors: the time/effort required to measure the realization value of requirements in practice is reduced (through code generation). Altogether, some of the error-prone parts of requirements engineering can be automated (e.g., verification) and accelerated (e.g., validation), leading to reduced time-to-market, and enabling stakeholders to focus more of their time, energy, and motivation on producing value.