Innovative Computing Review (ICR)

: The specification of customers’ need as software requirements in natural language create ambiguities (in the requirements) and may fail the software project. Generally, customers are unable to define their needs due to the lack of domain understanding, technological constraints, and knowledge gap between the stakeholders and the requirements analysts. One of the most effective approaches to minimize these gaps and ambiguities for requirements specification and validation is the use of ontologies. However, the current approaches are mostly limited to the translation of ambiguous software requirements. This paper discussed, analyzed and compared the current usage of these ontologies and found that these approaches are time-consuming and create complexities in the overall development process. It presented a requirements specification ontology (ReqSpecOnto), bypassing the need for creating an ambiguous Software Requirement Specification (SRS). The upper software requirements ontology is defined in Ontology Web Language (OWL) which can be applied to different software scenarios. A case study of budget and planning system for a state physics lab was selected to specify its requirements as derived ontology from the upper ontology created. The results are validated through HermiT and Pellet reasoners to verify the defined relationships and constraints. Finally, SPARQL queries were used to obtain the necessary requirements.


ABSTRACT:
The specification of customers' need as software requirements in natural language create ambiguities (in the requirements) and may fail the software project.
Generally, customers are unable to define their needs due to the lack of domain understanding, technological constraints, and knowledge gap between the stakeholders and the requirements analysts.One of the most effective approaches to minimize these gaps and ambiguities for requirements specification and validation is the use of ontologies.However, the current approaches are mostly limited to the translation of ambiguous software requirements.This paper discussed, analyzed and compared the current usage of these ontologies and found that these approaches are time-consuming and create complexities in the overall development process.It presented a requirements specification ontology (ReqSpecOnto), bypassing the need for creating an ambiguous Software Requirement Specification (SRS).
The upper software requirements ontology is defined in Ontology Web Language (OWL) which can be applied to different software scenarios.A case study of budget and planning system for a state physics lab was selected to specify its requirements as derived ontology from the upper ontology created.The results are validated through HermiT and Pellet reasoners to verify the defined relationships and constraints.Finally, SPARQL queries were used to obtain the necessary requirements.

I. INTRODUCTION
In software development, requirements engineering is a complex and time-consuming process.The requirements are specified and documented in a software requirements specification (SRS) document.While the main focus in the documentation is on building a bridge between the vague concepts collected from customers and the requirements of the engineering team.Nontechnical customers are unable to explain the exact requirements to the technical, experienced analysts due to lack of proper domain knowledge.These vague concepts are documented using natural language that is ambiguous in itself.So, one cannot get a clear and concrete set of requirements for the system development.If these ambiguities are not properly identified and corrected timely, the consequences can be devastating.For instance, any misunderstanding of the exact needs of customers and stakeholders will need a lot of revision after deployment of the system.Multiple studies have shown that maintenance costs may increase up to 90% of the total development cost of the entire project because of requirement errors most of them occur due to miscommunication, ambiguities and implicit requirements [1], [2].
Identification and resolution of these problems during the maintenance phase need painstaking work which not only increases the cost of development but also results in less satisfied clients [3].
The use of modelling languages, however, within the specification document that provides semi-formal representation, does reduce some level of ambiguity.Additionally, modelling languages are still tied to natural language for labelling and this can cause e two major problems.
Firstly, naming elements with terms or labels using natural language can introduce multiple interpretations.This limits the use of models as a way of communicating knowledge among the phases of software development.Secondly, the use of natural language delivers semantics that is not machine-process-able.This can cause problems in validating or querying data in modelling tools and restrict the logical reasoning since processes cannot logically retrieve a requirement specification that is not explicitly documented.
Therefore, the requirements are validated for consistency and accuracy as a subtask within requirements engineering.In the past, the School of Systems and Technology Volume 1 Issue 2, Winter 2021 collaboration between stakeholders has long been a focus by several researchers but most of their approaches are downsided [4].
An effort has been made to reduce ambiguities in the SRS through natural language processing (NLP) tools [5].The researchers either try to find ambiguities in the requirements document or generate models from them.A study was aimed at employing the rule based NLP techniques to find quality defects from industrial based natural language requirements that are annotated by domain experts [6].Another approach refers to the application of the code smells concept to requirements engineering for identification of defects in requirements [7] but is subjective and employs multiple reviews.One of the main contributions of most NLP tools is to automate the extraction and translation of natural language specified requirements into conceptual models so they can be manually validated by analysts themselves [8], [9].This results in a lack of precision because it is still manual and dependent on humans to identify and verify errors.While these NLP tools are individual efforts to find ambiguities, they are not aimed at promoting the interoperability of knowledge in multiple phases of software requirements engineering and development.Rather they only support a representation of knowledge of requirements.
Hence, a representation for specifying software requirements that can allow machine-process-able semantics in the first place is positively required.This will reduce extra work and make it possible to resolve the ambiguities in requirements.Researchers of semantic web and linked data have been trying to produce a mechanism that can reduce the ambiguities and make requirements testable.Ontologies and their use in several domains have been effective in recent times because of their semantic and syntactic characteristics.Ontologies arrange items or concepts of data in such a way whereby meaning is created among them by using relations, restrictions between data terms, making vocabulary and taxonomies more meaningful, hence fulfilling the overall objectives.
In software engineering, its popularity has increased for two main reasons to provide machine reasoning, and to facilitate semantic interoperability [10].Contributions have been made in multiple phases of requirements engineering to resolve inconsistencies and ambiguities in the requirements specification.A detailed systematic literature review [11] identified the trend of the application of ontologies for supporting requirements specification.Most of the work on the application of ontologies in requirements specification focuses on converting or translating previously developed paper-based SRS into ontology for checking consistency and correctness of the document.These approaches are not only time consuming and complex but are also prone to introduction of ambiguities in the specified requirements.Solutions that support the process models in requirement engineering phases as inter-connected and intercommunicating are needed for better requirement specification, and can contribute to a generic framework in all projects.This can only be achieved if we rely entirely on ontologies for their specification in an attempt to shift the paradigm from trying to give semantics to ambiguous specified requirements to an approach of defining the semantics from the base that can be related to each project.In this paper, a requirements ontology has been developed for the proposed framework to generalize the concepts of requirements engineering.An instance is derived from the requirements ontology of the specific domain of the system to be developed called as domain ontology that is related to the domain of the particular software being considered.The reasoning and use of SPARQL have been applied to validate the requirements and inference check for conflicting requirements.The primary aim and contribution of this paper are to present a framework which is based on model-driven requirements engineering that is used to define, specify and validate software requirements in the form of ontologies.This will entirely replace the use of paper-based SRS with ontologies and the validated specification can be reused to support and automate other software engineering phases.We have formulated the following four research questions.
CQ-1: How software requirements can be formally specified in ontologies?CQ-2: Can software requirements be validated through ontologies?CQ-3: How can we extract the requirements to meet the needs of the software engineering team?
The rest of the paper is organized as follows: Section 2 represents literature review.Section 3 describes the methodology adopted to resolve the problem.This is further divided into sub-sections; the discussion on the collection of glossaries, taxonomies and the use of Protégé tool for developing the ontology.
The experiment, discussion of results and conclusion are described in Sections 4 and 5 respectively.

II. LITERATURE REVIEW
Requirements engineering is the process of systematically eliciting, analyzing, specifying, validating and managing requirements for a software system [12].The process of requirements elicitation involves tacit or implicit knowledge which results in ambiguous requirements.
Therefore, it involves the risk of misunderstanding [13].After the requirements have been gathered through elicitation, these are documented as a software requirements specification (SRS) document which includes requirements in the form of natural language and is represented as conceptual model [14].The SRS needs to be validated and verified to identify e conflicts and to gather agreedupon solutions to resolve them.The specification of requirements is a challenging task that must be properly managed during the process of requirement engineering.
Firstly, every detail acquired in the elicitation phase is included, and if a minor detail of the specification is missed, the development team either skips the additional functionalities or adds what was not required by the customer.In both cases, according to the Kano Model [14], the developed system will be unable to satisfy the customer.Therefore, extra costs will be spent during the maintenance phase.The requirements management also needs to be considered throughout the software development process specifically in requirements engineering due to frequent changes in the requirements.

Ontologies
were first developed by Artificial Intelligence researchers [15].They are used to provide machineprocessable semantics so that they can be shared among several other software and tools.Ontology is a formal explicit specification of a shared conceptualization [16].Ontologies have also been used in requirements engineering for  [10], [17], [18].The detailed review by [11] accounts for the work of ontologies in software engineering.Here, ontologies are divided into two basic categories; ontologies of domain and of software artefacts.The first category consists of those ontologies that attempt to conceptualize the domain knowledge of software engineering domains or subdomains.The second category consists of functionalities and characteristics of the development process or that of the functioning of the software thereby supporting its artefacts.Among these domains, ontologies are very generic like in the work of Abran and Mendes who created a 4000concept ontology on the basis of SWEBOK guide which attempts to conceptualize the whole body of knowledge of software engineering [19].Although we have also employed SWEBOK guide in our taxonomy building among other sources, but this approach is nevertheless more generic and attempts to conceptualize the entire software engineering knowledge to target multiple applications.On the contrary, our ontology differs from this approach since we are focused on requirements specification and their validation instead of encompassing knowledge of the entire software engineering domain.
An ontology for SQL was developed for the abstraction of the standard database query language [20].Similarly, an MIT project called SIMILE created an ontology for java concepts, while, a lot of work is done in ontologies used as software artefacts.According to Ruiz et al., [11]  The requirements ontology for a specific domain was created to improve the quality of SRS by converting the requirements into the ontology.Their approach develops a hierarchy of functions followed by relationships of functional requirements and their attributes[22], [23], presenting how the requirements can be analyzed using domain ontologies in order to find deviations from the requirements document.The proposed method focuses on domain ontologies where the author argues that it is essential in the process of requirements engineering.The analyst knows very little about the domain and therefore gets help from the domain experts.According to the study, domain experts can be replaced by using domain ontology so that analyst can refer to the ontology for domainspecific knowledge using inference rules.
Ismail [24] considered a semiautomated approach and created system specification ontology (SSO) to convert the previously developed SRS into ontology.Nevertheless, previous ontology learning approaches like CRCTOL, Text2Onto adopt methods that only extract concepts and their relationships.Therefore, an approach was proposed, which can learn ontology along with individuals and their concepts as a major contribution of their study.Avdeenko et al. [25]presented an approach or guideline using the Protégé tool known as DL Query to validate the correctness of an SRS.

Mahmud et al.
[26] created a language called ReSA that allows requirements specification use a domain ontology, and apply it to an automotive domain for requirements specification of a component of that domain.However, this work is different from using an upper ontology in combination with domain ontologies which would be our approach.The creation and use of an upper ontology to support requirements engineering activities have benefits over using a language to specify requirements.But, on the other hand, researchers are more interested in creating a framework for developing requirements specification directly from elicitation without the need for an intermediary ambiguous and inconsistent SRS document.A recent study conducted by [17]  documents which can involve ambiguities and complexities.A study was conducted by [18] who pointed out how it is important to have a formal specification using an ontology to support domain modelling specifically for complex domains.The proposed approach uses an ontology to extract knowledge to create models and then evaluate the result on specified requirements.They have provided an approach of generating test cases using inference rules from ontology [17].The inference rules are coded in Prolog so ontology is serialized in functional style OWL syntax to Prolog using Python code.According to Zong-yong et al.
[27], most of the studies on using ontologies in requirements elicitation focus on using a single global ontology which cannot be reused.Therefore, they presented a multiple ontologies framework based on KADS modelling with combining top-level, task, domain and application ontologies to facilitate requirements elicitation and reuse.Amarilis et al. [28] provided an ROF which is the rule based framework of ontology for automatically generating requirements.In this framework they focus on documenting standardized version of SRS in IEEE format and applied it at a university system to document teacher workload.Conformity to the ambiguous SRS standard format can again introduce inconsistencies later even after the explicit specification.
Furthermore, there has been a trend of following ontologies and semantic web in requirements engineering for representing knowledge to support a very minor product or project-specific scenarios and domains.It should be noted that ontologies are surely domain-specific that can be used to support communication among sub-domains of the same domain.The use of this approach of creating ontologies to cope with a specific problem in a project can restrict their reuse and communication among other such smaller ontologies.The concept of ontologies was to support interoperability and communication among multiple process models.According to W3C, ontologies are used to communicate knowledge within process models.According to [29] requirements engineering of Model-Driven Development (MDD) that uses model transformations to automate, the software development process lacks complete solutions to requirements models.This review also discusses that models are used not only to describe requirements in the MDD context, but also in structured or unstructured natural language.
Another recent approach [30] was to combine NLP techniques and ontologies for the purpose of bridging the gap between trained and untrained users from elicitation of requirements to the specification of those requirements.Previous efforts of NLP techniques to translate the requirements into models were made to understand and interpret natural language statements to uncover their meaning and semantics.Combination of these techniques and technologies with ontologies for the same purpose of understanding specified requirements is also the same thing with the addition of previous records being managed as a knowledge base in a way that their relationships are understood.However, these efforts can only be considered as individuals in ontologies which are only project or product-specific in terms of solving problems.Hence, we need an approach that can cater to the needs of maximum projects within a domain, reducing ambiguities in the requirements engineering process and ultimately the cost of development.

III.ONTOLOGY ENGINEERING OF REQUIREMENTS SPECIFICATION ONTOLOGY
In ontology engineering, the ontology development process is driven by scenarios that result from problems that arise in applications or existing ontologies.They also include possible solutions to those problems.According to [31], any proposal of new ontology must include these scenarios and possible solutions that describe the problem stories or scenarios, the semantic objects and relations between them.In this paper, the problem scenario arises from the requirements specification where requirements are documented in natural language in the form of SRS.These are subject to multiple interpretations and ambiguities that are neededto be specified and validated in ontologies.

A. Use Cases
The scenario is the budget and planning system of a state physics lab in the United States.The selected requirements including multiple roles and requirement types are as follows:-UC-1.End users have viewed into workflow to assess current status, bottlenecks and next steps UC-2.End user can configure its own view.UC-3.Admin can configure views of users.UC-4.Users can request resources and admin can approve those requests.UC-5.End user can add notes to workflow.UC-6.All users as per their security role can see forecasts.UC-7.End user can select reports from predefined reports.UC-8.Admin can add due dates in calendar that contains lab-level project planning activities.UC-9.Users have security roles for access to data that are configured by the main admin.UC-10.End users can drill down from hierarchical data in reports for analysis.

B. Vocabulary
A general vocabulary of software requirements to build upper requirements specification ontology was needed.We collected all terms possibly from the requirement engineering field which are used in the process of requirements specification.The first choice for collecting the terms was a glossary published by the International Requirements Engineering Board of 128 Terminologies.All them were not useful for our purpose.However, another useful source was the SWEBOK (Software Engineering Body of Knowledge).Most of the meanings and terms that were unavailable in the IREB glossary were derived from the SWEBOK.It defines the body of knowledge of the software engineering field and the practices used.The resulting 103 glossary terms have been created for our taxonomy.Table .1 shows the vocabulary of main classes and their sub-classes.

C. Taxonomy
Taxonomies have proven successful in resolving several problems in computerized systems used in different sciences.They have also been used in software requirements analysis to understand several concepts and to resolve particular problems [32].They provide basis for the implementation of ontology.For our taxonomy, several published taxonomies on requirements engineering were studied, analyzed and used.The Innovative Computing Review Volume 1 Issue 2, Winter 2021 most difficult task was the placements for NFRs (nonfunctional requirements) due to different views in software engineering by several researchers.Among the most popular or relevant was an information system requirements taxonomy [33] by Chen et al.
Afreen et al. [34]classifies NFRs in conflicted NFRs that can help understand the relations and the conflicts.In other words, it is important to establish the properties of the object at a later stage and the disjoints to define which entities are different or related to each other.Another taxonomy by Odeh et al.
[22]based on a service-oriented view of software requirements was more appropriate to our scenario, and was therefore used for the placements of the main classes of NFRs although not all of its structure was used.Therefore, we took three of the main classes as shown here: QoS, Development and Architectural (Constraints) for the classification of NFRs in our taxonomy.Another confusion was the exact number of classes because their previous standard (i.e.ISO-9126) has been replaced now with the ISO-25010 standard.And both the standards are slightly different with the removal of some classes and an addition of some new classes in the new standard.Some of the weaknesses of ISO-9126 standard for NFRs are reported in literature [35].For this purpose, we removed all the sub-classes not included in the latest standard.Similarly, we added the new subclasses to the placements where they were exactly required.Mostly, privacy and security are considered as a single entity.But according to [36]confidentiality or security is erroneously equated with privacy by some security practitioners.So, it is established that security and privacy are two different entities.Therefore, we considered security and privacy as different sub-classes of Quality of Service class in our taxonomy.

1)
Stakeholder Taxonomy: The stakeholder sub-class of person class in the ontology is divided into three sub-classes, namely, customer, user and supplier as shown in Fig. 1.The customer can be any individual or organization that requires software whereas, the supplier is the team of requirements engineers, software developers and project managers.The User sub-class has two types of users; Admin and the End User.

E. Scenario Constraints
In the scenario, view user is an end user individual.Functions of this role are defined in the system, CanDrillDownFrom Hierarchical Data, PerSecurityLevelCanSee Forecasts, has User View, has Security Role, CanSelect Reports.The restrictions are represented as negative object property assertions in Fig. 6

IV. EXPERIMENT AND RESULTS
Protégé is a tool that helps researchers build ontologies to support expert systems [37].To validate the ontologies, it provides third-party reasoners like HermiT, FaCT++ and others [38].Reasoners provide validation of the ontologies by knowledge discovery and by detecting and finding inconsistencies or contradictions.These reasoners are based on mathematical models.They provide logical deductions based on inference rules that are defined and specified in description logic.They either use forward or backward chaining to perform inference [39].We have used HermiT and Pellet reasoners in our research.HermiT is based upon hypertableau calculus and provides reasoning for OWL based ontology files.
The developed requirement specification ontology formally defines the software requirements.Inconsistencies can be detected and prevented.
Therefore, it answers our RQ-2 by defining the classes Admin, End User, Functional Requirement, Non-Functional Requirement and their individuals and then performing reasoning on them.

A. SPARQL Validation
SPARQL is a SQL like query language that is used with ontologies.For our validation, we made a few questions to retrieve different requirements in different manners.Queries are used to answer questions and received in the form of data retrieved from our ontology.The queries are written in the DL Query portion in Protégé.They can be used to extract requirements from the ontology.In the following figures, we have presented different style of software requirements elicitation according to software engineering team.In Fig. 9, information is retrieved from requirements specification ontology on all the users who should have a user view in the system.In Fig. 12, SPARQL extracts all users and their functionalities related to the Bottlenecks individual, Planner and Service Administrator CanAssess Bottlenecks.Fig. 12. Requirements related to Bottlenecks This concludes our section of SPARQL validation and proves our RQ-1 and RQ-3 defined in the beginning.Therefore, results indicated that the software requirements can be defined through ontologies and extracted from ontology through SPARQL to meet the needs of the software engineering team.

V. CONCLUSION
Software requirements specification process creates ambiguous software requirements specification document (SRS) which can result in failure of the entire project due to the ambiguous requirements.The notion that ontologies are used to specify knowledge in a machineprocessable form seems promising keeping in view its utilization in computers, medical sciences, and many other domains.This form of specification also promises to remove ambiguities that occur in natural languages.However, the current approaches of translating paper-based SRS to ontology are complex and time-consuming since they need to deal with ambiguous requirements.Our approach of semantically specifying software requirements School of Systems and Technology Volume 1 Issue 2, Winter 2021 using a generic software requirements specification upper ontology minimizes the complexities that occur in translating paper-based SRS in ontologies.It creates a validated knowledge base of semantically specified requirements that can be used to access them, conveniently.Additionally, as it is not restricted to a single domain, generic ontology can be used in many scenarios to capture a particular system's requirements to support other software engineering phases as well.The upper ontology uses a glossary of common concepts needed in specifying requirements related to the users, as well as functional and non-functional requirements and system components to create a domain ontology of a particular system as upper ontology's individuals.
In this paper, we specified ten different requirements for budget and planning system of a state physics lab, including multiple user types, functionalities and constraints.For this purpose, HermiT and Pellet reasoners were employed to verify relationships and constraints defined in the ontology.SPARQL was used to validate our competency questions.In the future, we intend to expand this ontology and apply it to multiple systems for the specification of their requirements.

Fig. 1 .
Fig. 1.Stakeholder Taxonomy 2) System Taxonomy: System sub-class consists of three subclasses namely context, requirement and resource, as shown in Fig. 2. The context subclass can be changed according to the system.The requirement is further divided into Functional and Non-functional Requirement sub-classes.The Resource can be Hardware, Software and Data.

Fig. 2 .
Fig. 2. System Taxonomy3) Functional Requirement Taxonomy:The Functional Requirement class has some of the generic sub-classes like Action, View, and Report.that can be reused in many scenarios.This

Fig. 3 .
Fig. 3. Functional Requirement Taxonomy 4) Non-functional Requirement Taxonomy: This is the largest class in our ontology consisting of all the ISO-25010 standard quality constraints or non-functional requirements divided into three sub-classes namely, Architectural, Quality of Service, and Development, shown in Fig. 4.They can be used to create object properties with other functional requirement classes in ontology to define exact system requirements.

Fig. 8 .
Fig. 8. Constraints for Power User Power User, in Figure 8, is the individual of Admin class and its functions are defined as: has Security Role, CanSelect Reports, PerSecurityLevelCanSee Forecasts, CanDrillDownFrom Hierarchical Data and has User View.On the contrary, the restrictions are: CanConfigure User View and CanConfigure Security Role.Similarly, all the roles in ontology are defined as the requirements of the system.

Fig. 9 .
Fig. 9. Users having User View Requirement SPARQL query extracts all individuals having a user view that are, View User, Planner, PowerUser and Service Administrator.Now let's consider that the software engineering team needs to extract requirements related to a particular functionality e.g.all roles that can approve the resource requests in the system.

Fig. 10
Fig. 10 shows that only one role, the Identity Domain

Fig. 10 .
Fig. 10.Extracting Users for a Particular Functionality as part of their project called, OSTAG or simply, Ontologybased Software Test Case Generation, presents a guideline for developing a requirements ontology to support other software development phases.The main focus of this work was to create an ontology from the software requirements specification Innovative Computing Review Volume 1 Issue 2, Winter 2021

TABLE 1 VOCABULARY
School of Systems and Technology Volume 1 Issue 2, Winter 2021