# SENSE: A Flow-Down Semantics-Based Requirements Engineering Framework
## 3 SENSE Methodology
### Form and Language Standardization  
In order to address the ambiguity found in the natural-language written requirements, SENSE proceeds with systematizing the specification of the requirements by developing and establishing complete sets of standard expressions (boilerplates), using an appropriate artificial language. This language looks natural while allowing the combination of different boilerplates through a well-defined syntax and precisely defined semantics using reasoning procedures. In this context, natural language processing (NLP) techniques, such as the phrasal semantic parsing, are used both for better defining the boilerplates and for properly receiving the information embedded in them. Practically, boilerplates allow the requirements to be recorded consistently, reducing, among other aspects, misspellings, poor grammar, and ambiguity, making it easier to  
Figure 4: (**a**) Part of requirements of an ATM network regarding accounts; (**b**) part of the ATM ER diagram. understand, categorize, and identify the requirements. In addition, boilerplates act as an input mechanism to record not only the requirements but also the semantics that these requirements imply, e.g., who those involved are, or what the capabilities of the system should be [10; 20]. Boilerplates are semi-complete and customizable in order to facilitate the user and to be able to suit the needs of different systems. The mechanism of boilerplates is, in essence, a fixed dictionary of concepts from a knowledge base, relevant to the field of hardware or software being developed, and a set of predefined structures. The basic building block of a boilerplate is a clause which expresses some aspect of the requirement. Each of such terms has a type, e.g., capacity, function, etc., which indicates the type of requirement being expressed. In addition, each term may have a type of target, indicating the general objective pursued, e.g., minimizing something, maximizing something, or exceeding a certain value, which is useful when we think about what exactly it is that we want to express. The clauses can be combined and put together to produce complete boilerplates, which will express multiple aspects of a specific requirement. The semantics of the boilerplates language are matched with an appropriate ontology [21], such as those presented above, which is a particularly important aspect of the approach as it is the one that allows words to be drawn about the entities and their properties involved in the relationship described by the boilerplates. In any case, the ontology should focus on the concepts needed to define the requirements. Thus, the content of the boilerplates can, through reasoning, be examined for inconsistencies, omissions, etc. Practically, each boilerplate is defined as a sequence of attributes and fixed syntax elements, which facilitate the construction of a requirement. An example boilerplate could be: _IF <state>_, _<subject> shall <action>_. Obviously, the terms IF and shall are fixed components while the rest, enclosed in brackets, are properties that can take any value. This example consists of a prefix, _IF <state>_, which defines a condition, and a main clause, _<subject> shall <action>_, which defines a capability. For instance, requirement R19.2: \"If user approves data insertion, the system updated DB\" can be expressed using the aforementioned boilerplate as follows: _If <state> user approves data insertion </state>_, _<subject> the system </subject> shall <action> updates DB </action>_. In fact, the language of boilerplates is a means of avoiding ambiguity in writing the requirements, in contrast, that is, to free writing, which exists in natural language. In such a language, certain requirements may be expressed through a number of alternatives, considering different provisions and combinations of clauses. Thus, the grammar (Tables 1 and 2) is context-free, containing both necessary and optional clauses, in the sense that some information types must always be written while the others are optional.