The paper presents an approach to organizing the requirements analysis based on the ontological model consisting of three OWL ontologies. The distinguishing features of the proposed approach are the combination of the ontological model with the rules formulated in the predicate form, as well as the focus on the support of the currently most demanded agile approach to software engineering. To take these aspects into account the proposed theoretical apparatus includes such important peculiarities as building and re ning the Product backlog, tracing the requirements, identifying con icting requirements and eliminating duplicate requirements. The latter functions are provided by applying logical inference to the system of axioms in the Prolog language obtained by combining the ontology of requirements, the ontology of the application domain and the formulated production rules. The rules are used for analysis of the relations between the requirements. In the current version, we determine four types of relations between a pair of the requirements that can be determined: isCon ict, isDuplicate, isInterconnect, isNotInterconnect.
Software development is a knowledge-intensive work in which team discussion of the current stage results in terms of their compliance with the requirements formulated in the requirements engineering stage is the key to success. In the process of requirements engineering inaccurate and incomplete ideas about a software product are transformed into a formal requirements speci cation . In agile environment, the backlog concept is used is part of an approach to working with the requirements. Backlog is a log of the remaining work that a team needs to perform. There is a product backlog and a sprint backlog [Dar2016]. Before planning a sprint, elements of the product backlog should be divided into small user stories, basic behavior scenarios should be written to them, implementation e orts should be assessed, and priorities should be determined. This work is done by the product owner together with the development team in preparation for the product backlog grooming. To work e ciently with requirements, this approach requires automated tools to support the requirements engineering process.
Numerous studies have proven the e ectiveness of using ontologies to support the requirements engineering process (see, for example, the surveys [Als2019] and [Der2014]). However, in various studies, ontological modeling is applied to di erent aspects of the multilateral and complicated process of requirements engineering. In the early 2000s, it was proposed to consider the process of developing ontologies as a subprocess of the requirements engineering process [Bre2003], whereas in [Zhu2005] the domain ontology is e ciently used as an infrastructure for specifying software requirements. An approach to automating the process of validation and measurement of knowledge about the requirements was proposed in [Sieg2014].
Later, the ontological approach began to be applied not only to the software engineering with a classic waterfall cycle, but also to the iterative development process. In [Tham2016] ontological approach is applied to improving the requirements engineering process in the Agile environment. The ontology is designed to work with user story templates. Ontology enables to identify synonymous concepts, hyperonymic and hyponymic relations between the concepts. The latter enables the requirements engineering process to de ne user stories that must be performed for user roles of applications that include other roles. In [Sitt2016] an approach to developing a recommender system that supports the evolution of the Agile requirements is presented. It is proposed to use the following four ontologies: "Environmental Context Ontology", "Problem Domain Ontology", "Requirements Ontology" and "Agile Requirements Ontology".
Issues of requirements traceability are addressed in the [Avd2015] devoted to the development of frame ontology which enables to create a consistent model of requirements types for a speci c software development project.
In [Bha2015] two types of ontologies are distinguished which can be used to represent knowledge of the software domain being developed: the application domain ontology and the application domain feature model ontology. In [Mur2015] the requirements are considered as a specialized subset of a set of knowledge about the domain while the domain ontology is used as a "background source" in the process of extracting requirements for a software product from natural language texts.
The paper [Egy2004] addresses the issues of de ning cooperation and con icts between the requirements. Requirements con ict if they contain contradictory statements about common software attributes and are in a state of cooperation if they mutually supplement statements about attributes.
In [Rob2016] an approach to the automatic construction of an ontology from a set of user stories is proposed. For text processing in natural english language, the spaCy library is used, which allows for parsing sentences based on a dependency tree, searching for named groups.
Ontologies are used to formally represent the knowledge about the types of requirements, the structure of the requirements speci cation, as well as the subject area of the software product [Cas2010]. The trends of recent studies in the eld of improving the requirements engineering process are the methods of working with requirements as with the facts from the application domain model. The relevance of the developed approach to extraction, automation and analysis of the requirements in natural language is determined by the variability of the requirements and the need for a quick comparison of the requirements texts.
Thus, summarizing the above, the following areas can be distinguished in the existing studies of the possibilities for using the ontologies in the eld of requirements engineering: (1) development of the ontologies for the representation of knowledge about the requirements engineering process taking into account peculiarities of certain techniques, requirements types and characteristics of their quality, (2) development of ontologies for representing knowledge of the application domain which describe domain concepts, relationships between different users roles, actions of users in the system, components of the software product, (3) development of the requirements ontologies for identifying con icts, duplicates and cooperation between the requirements. It is worth noting that if the rst two areas are given quite a lot of attention in the literature, the third question is raised very super cially.
It is worth noting that while the rst two areas are given quite a lot of attention in the literature, the third issue, which is very important from the point of view of obtaining really useful practical results, is touched on very super cially. This is explained by the complexity of the problem of formalizing knowledge and implementing the mechanism of knowledge inference. But the ontological approach gives maximum bene t only when the model described in terms of formal logic starts using the inference mechanism, which will make it possible in our case to identify con icting requirements, to reveal the incompleteness or redundancy of the knowledge contained in the combined model of the requirements and the application domain.
We propose an approach to agile requirements engineering based on combination of the OWL ontology with production rules followed by the system which allows you to apply full-scale inference to a system of logical axioms, uploaded to the Prolog inference system. The proposed ontology system includes three ontologies. The rst ontology is necessary to represent knowledge of the engineering requirements process taking into account the peculiarities of the agile development. The second ontology is necessary to represent knowledge of the application domain. The third ontology is needed to identify the relations between requirements.
The rest of paper is organized as follows. Section 2 describes the OWL ontology system. Section 3 proposes an approach to converting textual requirements into the ontology. Section 4 describes the approach to analyzing the relationship between requirements. Section 6 summarizes the work. 2 2.1
An ontology to support the requirements engineering process in Agile consists of classes that correspond to events, roles and agile artefacts. The ontology classes are instances of project requirements and their artefacts, as well as information about the development team and requirements sources . Figure 1 shows the taxonomy of the top-level classes and the object properties. A description of the top-level classes is given in Table 1.
Description describes the attributes of user stories such as priority, risk level, etc. includes subclasses describing the project's backlogs includes subclasses such as qualitative scales used in assessing priorities, risks, etc. contains subclasses corresponding to the concept "software product" instances of this class are the features being developed contains subclasses corresponding to the concept "requirement" contains subclasses corresponding to the concept "requirements artefact" includes subclasses describing the classi cation of requirement types includes subclasses describing the classi cation of risks contains subclasses corresponding to the concept "stakeholder" includes subclasses describing the classi cation of requirements statuses includes subclasses describing the structural elements of requirements includes instances which are tasks a development team works on includes subclasses describing roles in a team includes subclasses describing the classi cation of test types includes subclasses describing the types of constraints for non-functional requirements
The object properties re ect the relations that can be established between instances of the ontology classes. For example, to specify the relation "the requirement re nes another requirement", the object property "re nes" is used. This object property, in turn, includes sub-properties that can be established between di erent classes of requirements artefacts which by their nature are also requirements (for example, the behavior scenario). It is proposed to use ontology for representing knowledge of traceability. Ontology includes two types of relations implemented through object properties: traceFrom and traceTo. The rst relation includes subrelations which enables bottom-up tracing, the second top-down tracing. For the object property "traceFrom" and the subproperties included in it, the inverse properties are set - "Inverse Of". The object property "con icts" is specifed that requirements con ict with each other. This can be done directly in this ontology or transferred from the ontology for analyzing of relations between the requirements. 2.2
In this paper, it appears that the application domain ontology must include a set of facts about the subject area, a users role model, a features tree model. Terminology description of the application domain includes the domain concepts and words that make up the domain concepts. In this work, it is proposed to present a set of facts about the subject area taking into account some object properties and classes characteristic of lexical ontologies. This will allow later when analyzing data to compare data ontologies of the application domain ontology with data from external lexical ontologies. Words include nouns, verbs, auxiliary verbs and de nitions combined with nouns. The hierarchical structure of the classes "DomainConcept" and "Word" is presented in Figure 2. Object and data properties are also presented in Figure2.The description of these classes is given in Table 2. In the class "DomainConcept", there are two main subclasses that are needed to describe and verify the validity of requirements: "Entity" and "RelationAction". The class "Entity" in turn is divided into classes "Actor" and "Object". Actor is an entity with some behavior. An actor can be a user or a software system (subsystem). An object is an entity to which actions performed by an actor are directed. The actor and the object are interconnected by actions. Relations-actions, in turn, should include the semantic verb, and can also include the auxiliary verb and the not particle. For example: "can not delete." The verb "delete" in this phrase is semantic. Semantic verbs of the subject area will be allocated in a separate class "OperationAction".
The class "User" is a subclass of the class "Actor". To build a role model, it is necessary to distinguish user classes that are typical for the subject area, the object properties between class instances, and their data properties. Let us consider the approach to building in ontology of the users role model for the company's web-site designed to work with company consumers of the products or services (clients). The following classes of users can be distinguished here: internal users of the system (employees) and external users (clients). All internal users of the system must be registered users, and consumers of products or services produced by an enterprise may be registered users who work with the web system through a personal account. External users can be registered and unregistered. On the other hand, the user of the web system can be: (1) a registered user who works through a personal account (logged in user) and (2) a user unregistered in the system who works with the publicly accessible part of the web system.
A user registered in the system but not logged into the personal account at a given time and who works with the public part of the web system (an unauthorized user).
In turn, an unregistered user can be a user who has an active account in the system (a user who has logged o in the system) and a user who does not have an account. For any non-logged-on user of the web system, features is available corresponding to the publicly accessible part of the system intended for the client. Class name DomainConcept Entity Actor System User Object OperationAction RelationAction NegativeRelationAction Word AmodWord Adjective Participle AmodUserDet AmodUserPost Negation NounWord VerbWord AuxiliaryVerbWord Description class whose elements are domain concepts class whose elements are entities class whose elements are actors class whose elements are actors-systems class whose members are actors-users class whose elements are objects used by actors class whose elements are semantic verbs class whose elements are actions class whose elements are negative actions class whose elements are words class whose elements are words de ning nouns class whose elements are adjectives class whose elements are participles class whose elements are words that de ne the ownership of an object to a user class whose elements are words de ning the level of the user's position class containing the particle "NOT" class whose elements are nouns class whose elements are verbs class whose elements are auxiliary verbs
Based on this, a class structure was designed to describe the users role model. The hierarchical structure of the class "User" is presented in Figure 3. Object and data properties are also presented in Figure 3. The description of data and object properties for the class "User" is given respectively in Tables 3 and 4.
The class "ProductFeatures" is used to build a feature tree. Feature can be mandatory or optional. The description of feature variability is incorrect if optional feature has mandatory child features. On the Figure 4 shows the axioms for evaluation of feature variability. Object and data properties of class "ProductFeatures" are also presented in Figure 4 . 2.3
To determine the relations between sentences with requirements, it is necessary to transform them into ontology instances and establish relations between individual elements of sentences, such as an actor, an action, and an object. Figure 5 shows the object properties between instances of ontology classes, their domains and ranges.
Object properties between instances of the same class "Actor" are grouped into a object property class "relationActor". They are also grouped into object property classes "relationAction", "relationObject" and "relationrequirement" relations between the classe instances "Action", "Object" and "Requirement", respectively.
Object properties "sameAsActor", "sameAsAction", "sameAsObject" are set between instances of the corresponding classes "Actor", "Action" and "Object" if one name is used for elements of two requirements or, for
The conversion of textual requirements into ontology instances can be carried out in manual and semi-automatic mode using automatic text processing tools. The UDPipe parser with the Russian language model can be used for text processing of requirements in Russian. This tools parses the sentence and gives the results in the format CoNLL-U. The following elds are used to describe the annotation of text token (word, punctuation mark, or special character) of a sentence: 1) ID: token index 2) FORM: word form or punctuation symbol 3) LEMMA: lemma of word form 4) UPOSTAG: universal part of speech tag 5) XPOSTAG: language tag of a part of speech (if not, a dash is indicated) 6) FEATS: list of morphological features from the universal feature inventory or from a speci c language extension
Actor, action and object can be automatically extracted from the results of the analysis of the proposal. At the same time, the sentence with the requirement should be formulated simply enough. In other words, sentence must not contain a lot of speech turns. Figure 6 illustrates the dependency tree of the sentence: "As a manager, I can only delete the product descriptions I added".
Production rules can be applied to process the results of parsing sentences. To extract "Entity" , it is necessary to analyze tokens that are de ned as nouns (UPOSTAG = NOUN). For example, the main word in the name of an entity can be de ned by the rule:
IF X is a noun AND X is related by an dependency relation RXZ with the verb Z THEN X is the main word in the name of the entity.
Next, it is determined whether the given noun has a de nition in order to extract the name of the entity as a whole. Further, to determine the composite names of entities, the rules for analyzing dependencies are applied, taking into account dependencies between tokens, their parts of speech and their morphological characteristics in the russian model Russian-syntagrus-ud-2.4-190531.udpipe. Entities, in turn, are divided into actor and objects. The main word in the name of an entity that is a user is an animated noun (UPOSTAG = NOUN and FEATS: Animacy = Anim).
To extract the "action", it is necessary to analyze the tokens that are de ned as verbs (UPOSTAG = VERB). To de ne an operation-action (a semantic verb for a relationship-action), the following rule applies: IF Y is a verb AND Y is not an auxiliary verb THEN Y is an operation-action.
Next, it is necessary to determine if this operation-action has a particle "NOT" and form an instance of class "Action". 4
Requirements are converted from textual requirements to an ontology for analyzing of relations between the requirements. If necessary, data on previously veri ed requirements from the main ontology of the project are transferred to the same ontology. Further, relations between instances of classes "Actor", "Action" and "Object" are established. Production rules are then applied to determine the relations between requirements. All statements are converted to rules and facts in the SWI-Prolog language. Software modules for processing OWL les, building a production model and transferring facts and rules to the Prolog system are implemented in Python. The general scheme for organizing requirements analysis is shown in Figure 7.
The following scheme for generating production rules of the form is used to determine the type of relation between requirements:
IF ObjectProperty between class instances actor (Actor1, Actor2) AND ObjectProperty between class instances action (Action1, Action2) AND ObjectProperty between class instances object (Object1, Object2) THEN ObjectProperty between class instances requirement (Requirement1, Requirement2) Depending on the used rule one of the following four relations between the requirements are set: isCon ict, isDuplicate, isInterconnect, isNotInterconnect.
Consider an example of comparing two requirements on the following sentences: User story 01: Как менеджер, Я могу удалить только добавленные мною описания товаров
User story 02: Как менеджер, Я могу редактировать описания всех товаров из каталога
IF sameAsActor("менеджер" , "менеджер") AND partOfAction ("удалить" , "редактировать") AND isaObject("добавленное менеджером (только мною) описание товара" , "описание товара в каталоге") THEN isConflict (Requirement1, Requirement2).
These requirements con ict as the product descriptions added by a separated manager are a subset of all product descriptions. The operation "edit" includes the operation "delete". Therefore, according to the rst statement, the manager can delete any elements of the set "product description" and, according to the second, only some of them. 5
The paper proposed an approach to analyzing requirements based on ontological and production models of knowledge representation. The ontology structure was designed for storing knowledge of the progress of work with requirements with an agile approach. Designed ontologies are designed to solve typical problems for requirements engineering in agile software development. These include re ning the Product backlog, tracing requirements, identifying con icting requirements, eliminating duplicate requirements. It was proposed to extract from the textual requirements of the actor the action and the object, and to save them in the form of appropriate ontology instances. An approach to the formation of production rules for the analysis of relations between instances of ontology classes is de ned. For the successful automatic extraction of instances of ontology classes "Actor", "Action" and "Object" from textual requirements, it is required to record the requirements in the form of simple sentences.
The reported study was funded by Russian Ministry of Education and Science, according to the research project No. 2.2327.2017/4.6.