# SENSE: A Flow-Down Semantics-Based Requirements Engineering Framework
## 3 SENSE Methodology
### Ontologies  
Given the importance of the ontologies, the first step of the proposed approach is to develop or adapt proper ontologies covering the system requirement specifications. Although SENSE is generic and can be used in a variety of cases, a proper domain ontology should be used each time in order to gasp the semantics and provide the necessary guidelines for a specific system. Officially, an ontology is a formal naming and definition of the concepts, their characteristics, and the relationships between them that exist in a particular domain. For example, a skyscraper (concept) is a kind of (relationship) building (concept) with floors (characteristic). Common components of ontologies include individuals, instances, classes, attributes, relations, functions, restrictions, rules, and axioms as well as events. Therefore, in this context, we have developed two ontologies, the first refers to an eshop software system called Shopy ontology, while the other refers to an ATM system, along with the necessary general (upper) ontology for the abstract description of the system. Discussing in detail the development of the ontologies is beyond the scope of this paper, yet they are briefly presented below.  
Figure 2: Abstract architecture of SENSE system.  
The Shopy ontology (Figure 3a-c) covers the requirements of an eshop, including company policies, stakeholders, and product management while it supports, among other aspects, sales and marketing. This system is able to handle the users, orders, and products of the company. The system users, staff, and clients can log in to the system and as soon as they are authenticated; they can, e.g., confirm a purchase or enter the payment information. For instance, Figure 3b depicts some of the core actions that such a system should support; it should allow users to create a profile (see Appendix A R1.6) and let them log in to the system (R1.7--\"load permissions\" in Figure) or select a product (R1.1). For the purposes of better understanding, the Appendix A presents part of the functionality and security requirements of the Shopy system.  
For implementation purposes, the TopBraid Composer, an editor (free edition) for the Resource Description Framework (RDF) Schema and OWL models, was used. This editor is fully compliant with the W3C standards, and it is considered appropriate for the ontologies  
Figure 3: (**a**) Part of the Shopy ontology in RDF/XML; (**b**) part of functional requirements of Shopy system regarding a new client; (**c**) part of the Shopy ER diagram.  
and semantic applications. Furthermore, it supports, among others, the SPARQL Inference Notation (SPIN), which is used later in the SENSE framework.  
The second ontology refers to an automated teller machine network, a scenario case used multiple times in academic courses [19]. The developed ATM ontology (Figure 4a,b) covers the requirements of an ATM network that supports server maintenance for the bank accounts as well as processing the transactions against them.  
The system includes both the clients and the staff (maintainers) that, among others, are the only ones allowed to connect a new ATM to the network. The system accepts cards, authenticates the client (who can use any ATM in the network) and carry out the transaction if it is allowed. For instance, Figure 4a depicts the need of the ATM core system to support multiple ATM devices while each user is able to use any of these ATMs. Furthermore, each user may have more than one account. Hence, the bank server should handle all the users, regardless of which ATM they use, allowing them to log in if their credentials are proper (R1.3 Appendix A), while only one client may be served each time (R2.1). Part of the above functionality is presented in the Appendix A.