# SENSE: A Flow-Down Semantics-Based Requirements Engineering Framework
## 3 SENSE Methodology
### Validity/Completeness Checks  
Finally, the framework provides necessary checks to ensure the validity and completeness of the requirements [8] and face an important challenge: to ensure that at the end we will end up with a set of requirements that are all covered by the properties, which can be enforced or verified and do not under-specify the system's behavior. For the first issue, it is necessary to identify any inconsistencies that could lead to semantic, structural, or behavioral contradictions, while for the second it is necessary to identify possible requirements that have been omitted when they should not have been. In fact, ontology, as a unit, is a static object-oriented model with constructional constraints. For example, a specific type of boilerplate can only be combined within the system with specific types of entities. The framework deals with that by running appropriate SPARQL queries. SPARQL is an ontology query language. The questions, which can be formulated in this language, can identify issues regarding the requirements, the framework of the system, and the relationships that exist or are created. The advantage of the questions is that they need to be made once, although manually, by the expert, in this case a member of the project team, and then can be reused many times. For instance, at the ATM network each client that has an account must be at least 18 years old (Table 8). Another example, related to the ATM use case, checks if a user has the role of maintainer in order to access the bank server. The query (Table 9) checks if such permission is not completely covered by the requirements. The query checks if there are requirements related to Maintainer that should have the aforementioned permission (refe \begin{table}
\begin{tabular}{l l} \hline \hline ASK & WHERE \{ \\  &?this client:age?age. \\ FILTER (?age < 18). \\ \} & \\ \hline \{ a & sp:Ask ; \\ \} & rdfscomment “must be at least 18 years old”\textgreater{}ssdstring ; \\ \multicolumn{2}{l}{sp:where (! sp:object sp\textgreater{}.age ; \\ \multicolumn{2}{l}{sp:predicate my:age ;} \\ \multicolumn{2}{l}{sp:subject spin\textgreater{}.this} \\ \multicolumn{2}{l}{[ a sp:Filter ; sp:expression} \\ \multicolumn{2}{l}{[ sp:parg1 sp\textgreater{}.age ; sp:parg2 18 ; a sp:lt ] ]} \\ \hline \hline \end{tabular}
\end{table} 
Table 8: SPARQL Query and SPIN Constraint. the M3 type (Table 3): <subject> shall [not] be able to <action>). Hence, there should exist a prefix clause of the type P3 (Table 4), for the same action, namely suspendAccount. Table 10 presents a query quite similar to the Shopy use case, related to a customer role. More specifically, it checks whether the user is a customer and, as a result, if he/she is allowed to select a product. The query checks if there are requirements related to Customer that should allow such an action (refers to main clause of the M7 type (Table 3): <entity> shall [not] allow <entity> to <action>, meaning that the system should allow the customer to act (select product). Hence, there should exist a prefix clause of the type P3 (Table 4) for the same action, namely selectProduct. Moreover, we define for each query a number of SPIN (SPARQL Inferencing Notation), a de-facto industry standard, and 19 constraints, which are SPARQL queries that are placed at appropriate classes of the ontology and, if evaluated positively, indicate a constraint violation from instances of the class. The aforementioned (ATM) query (Table 8) is transformed to the following SPIN Constraint (Table 11) while the subsequent query (Table 9) is transformed to the SPIN Constraint presented in Table 12.  
Thus, finally with the use of SPIN, the rules can draw tacit relationships, fill in gaps, and fix the ontology and requirements by categorizing its instances while checking for all possible restrictions on instances of specific classes/types. SPIN allows SENSE to carry out ontology validation checks in three categories [22; 23]:  
1. Check incompleteness requirements. 2. Check for inconsistency requirements.