The paper presents an approach to organizing the detection of conflicts between requirements based on an ontological model and a system of production rules. Requirements in the form of plain text are converted to instances of OWL ontologies for analysis. There are three basic elements “subject”, “action” and “object” in the requirements. These elements become classes of the ontology. The object properties between instances of the same classes are defined in the ontology. In the system of rules it is determined that one of four types of relations can be established between a pair of the requirements: isConflict, isDuplicate, isInterconnect, isNotInterconnect. We develop the software product in the Python language for building and applying production rules system for classes and property objects of the ontology. Protégé 5.2 is used to work with the ontology. Also Python library PySwip and development environment SWI-Prolog 7.6.4 are used in the work. The paper also considers the issues of extracting requirements ontology instances from the automated processing results of textual requirements. The UDPipe with Russian language model is used for text processing
Essential precondition for successful implementation of the software products is the preliminary
development of high-quality software requirements specification (SRS). The latter task is solved
during requirements engineering (RE) process, in which inaccurate and incomplete ideas about what
services should the software product provide in order to solve the potential users’ problems are
converted into a formal SRS. Moreover, it is necessary to take into account the limitations under
which the software product should be implemented and work. According to SEBoK (version1.9.1) a
set of requirements must satisfy the following characteristics: complete, consistent, feasible,
comprehensible and able to be validated.Тhe completeness means that the set of requirements need not
be further refined. The consistency criterion assumes that the requirement set does not contain
conflicting requirements, the requirements are not duplicated, and the same term is used for the same
element in the whole set of requirements. The feasibility criterion means that a solution can be
developed for a set of requirements that meets the requirements taking into account the limitations of
the project (for example, cost) with an acceptable level of risk. The comprehensibility criterion implies
that a set of requirements has to be formulated so that to give a clear idea of what is expected of the
software product, and in what way it relates to the whole system. The validability criterion implies that
it should be possible to prove that the set of requirements will lead to the user needs satisfaction under
existing constraints of the project [
For the agile software development approach, the requirements specification is usually not a single document, but logical structure filled with requirements to the software product. The creation of such specifications is usually preceded by the development of a document called «Vision and scope», which gives an overview of the developed software product in terms of the key needs and constraints under which the project will be implemented. Then, the work begins on the creation of the product backlog containing prioritized list of requirements. The major feature of an agile approach is permanent readiness to change the requirements, therefore only those elements of the product backlog that have the highest priorities are worked out in detail at the current time. The requirements with low priorities remain in the product backlog, where they can be added, removed, or changed at any time. Under conditions of variability of the requirements their coordination becomes one of the most difficult problems in the requirements engineering.
Requirements negotiation involves detection and resolution of conflicts. Therefore, it seems that at
the stage of collecting the product backlog elements, the most important of the above quality
characteristics is to ensure the consistency of the set of product backlog elements. In this paper we will
consider the main component of this quality characteristic, namely, conflict-free set of requirements.
The proposed approach can be used as part of the intellectual support of the engineering process based
on ontological models. The ontology data of requirements can be processed together with the data of
other ontologies in the field of requirements engineering described by us in works [
The paper is organized as follows. Section 2 provides an overview of publications on the research theme. In section 3 we propose an approach to converting text requirements into the ontology. In section 4, we describe the developed software based on production model to search for conflicts between the requirements represented by instances of the ontology. Section 5 concludes on the prospects of the proposed approach.
The paper [
The authors of [
The paper [
The paper [
The paper [
In [
The paper [14] proposes an approach to the automatic building the ontology out of a set of user stories. SpaCy library is used for processing texts in natural English language that allows to make parsing sentences based on the dependency tree, searching named groups, extracting registered entities, as well as permitting coreference. The problem of extracting knowledge in a natural language for further reflection in the ontology of a subject area is reflected in [15].
Thus, the conducted analysis of publications on the topic of the study allows us to conclude that one of the promising areas in search for conflicts between the requirements are approaches involving presentation of text requirements in the form of ontology instances. This can be done manually and semi-automatically. Automatic construction of ontologies from the texts of requirements is currently extremely relevant and still not well covered topic. The considered papers on the construction of ontologies from the texts of requirements does not directly affect the problem of conflict determination, but the ideas used in them can be used as a basis for extracting from the results of automatic text processing of requirements of instances of ontology, structured for the task of finding conflicts between requirements.
In a sentence that expresses a requirement, regardless of the requirements recording technique used (for example, requirements can be written in the IEEE 830 or user stories style), three main parts can be distinguished: the subject, the action, and the object on which the action is directed. Each requirement must be represented in the ontology as a set of instances of these three classes. The object properties between pairs of instances for each class must be determined. For each requirement it is necessary to create an instance of the class “Requirement”, which will be associated with corresponding instances of the classes “subject” (“actor”), “action” and “object”. It is also necessary to determine the possible relations between instances of classes. It should be noted that a class, the elements of which grammatically correspond to the subjects of sentences with requirements, in an ontology may be called differently, for example, “actor” or “functional user role”. In the example below which illustrates the proposed approach the term “actor” will be used to designate the subject.
First, in the Protégé 5.2 environment, the structure of classes was implemented and the object properties between them were set. Figure 1 shows the object properties of ontology, their domains and ranges.
The object properties between instances of the same class “Actor” are grouped into the object properties class “relationActor”. Also, the relations between the instances of the classes “Action” and “Object” are grouped into object properties classes “relationAction” and “relationObject”.
The object properties of the “sameAsActor”, “sameAsAction”, “sameAsObject” are set up between instances of the corresponding classes if one name is used for the elements of two requirements or the full name is in one and an abbreviation in the second. These properties are symmetric. For example, instances of the class “Actor” with the values “senior manager” (“sr. manager”) and “senior manager” will be connected by the object property “sameAsActor”. Also, each of them will be connected with itself by this property. It is necessary for comparing two requirements without including duplicates of the same instances of the class “Actor” in the ontology (see Figure 2).
The object properties “isaActor”, “isaAction” and “isaObject” are used to setting hierarchical relations. For example, the “senior manager” is a “manager”.
The object properties “synonymsActor”, “synonymsAction” and “synonymsObject” are set if the values of the corresponding requirements elements have a synonymous value. For example, the action “to view” records is synonymous with the action “to list” records.
The object properties “antonymsAction” and “antonymsObject” are set between instances of the corresponding classes if they have the opposite meaning. For example, the object “my comment” and the object “someone else's comment”.
The object properties “partOfAction” and “partOfObject” are set between instances of the respective classes if one is part of the other. For example, the “product” object is part of the object “shopping basket”. Or, for example, the “delete” action is part of the “edit” action.
In all other cases, it is considered that the corresponding elements of the requirements are bound by the object properties “no-relationActor”, “no-relationAction” and “no-relationObject”. In other words, the relation between them is not revealed.
Figure 3 shows an example of requirement elements transformed into ontology instances. Requirements: User story 01: Как менеджер, Я могу удалить только добавленные мною описания товаров…
As a manager, I can only delete the product descriptions I added ...
User story 02: Как менеджер, Я могу редактировать описания всех товаров из каталога….
As a manager, I can edit descriptions for all products from the catalog ....
It should be noted that the conversion of textual requirements into ontology instances can be carried out in semi-automatic mode using automatic text processing tools. The UDPipe with the Russian language model can be used for processing of textual requirements in Russian. The UDPipe parses the proposal and provides the results in the format CoNLL-U.
The following fields are used to describe the annotation of text token (word, punctuation mark, or special character) of a sentence in the CoNLL-U format: 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 specific language extension, 7) HEAD: number of the parent token or zero for the root token, 8) DEPREL: universal dependency relation to parent token (set to “root” if HEAD = 0), 9) DEPS: list of secondary dependencies 10) MISC: additional information.
Figure 4 illustrates the presentation in the CoNLL-U format of the sentence “Как менеджер, Я хочу удалять товар из каталога” (“As a manager, I want to remove product from the catalog”).
A subject (actor), an action and an object can be automatically extracted from the results of a sentence analysis, provided that the sentence with the requirement is formulated simply enough, that is does not contain a lot of speech turns (see Figure 5).
The setting of object properties between instances of requirements elements can also be performed in semi-automatic mode. For example, using regular expressions, modal verbs and negatives can be searched. The linguistic ontologies like WordNet can be used to search for synonyms. It should be said that the search for antonyms with the help of linguistic ontologies for verbs can lead to undesirable results, since, for example, the actions “add” and “delete” can be viewed as antonyms, however, the verb phrases “can remove” and “cannot remove” will have an antonymous meaning .
Production rules can be applied for processing the parser results of sentences. For example: If X is an animated noun (UPOSTAG = NOUN and FEATS: Animacy = Anim), then this is a subject (actor). Next, it is necessary to check whether the noun has a definitive in order to extract the whole name of the subject. For example, if the actor “senior manager” is used instead of the actor “manager” then the actor is described as an animated noun (ID = 3, UPOSTAG = NOUN, FEATS: Animacy = Anim) and definitive “senior” (ID = 2, UPOSTAG = ADJ, DEPREL = amod, HEAD = 3). The universal dependence relation “amod” indicates that the adjective “senior” serves as a definitive for the noun “manager”. In the case of user story, the case of actor search is simplified due to a certain position of the actor in the sentence, so the actor can be extracted even without the use of special tools.
To extract the «action», it is necessary to analyze the tokens that are defined as verbs (UPOSTAG = VERB). At the same time, attention should be paid to the morphological features of the token in order to separate the verbs from the participles (FEATS: VerbForm = Part) and the adverbial participles (FEATS: VerbForm = Conv). In the example in Figure 5, the words «“want” (UPOSTAG = VERB, FEATS: VerbForm = Fin) and “delete” (UPOSTAG = VERB, FEATS: VerbForm = Inf) are the verbs. The phrase “I want” in the user Story is predefined, therefore, we extract the word “delete” as an action.
The object will be a noun associated with the word-action. In this example, this is the word “description” (ID = 11, UPOSTAG = NOUN, DEPREL = obj, HEAD = 6). The universal dependence relation “obj” indicates that the noun “description” plays the role of a direct object for the verb “delete”. Next, it is need to check whether the word “description” has attribute relations with other words of a sentence in order to extract the whole object.
Determining object properties between the instances of the requirements elements can also be performed in semi-automatic mode. For example, modal verbs and negatives can be searched using regular expressions. Besides, the linguistic ontologies like WordNet can be used to search for synonyms. It should be noted that the search for antonyms of verbs with the help of linguistic ontologies can lead to undesirable results. For example, the actions “add” and “delete” can be viewed as antonyms, however, the verb phrases “can delete” and “cannot delete” will have an antonymous meaning in terms of the problem to be solved.
To determine the type of relationship between the requirements, a system of production rules of the following form can be generated:
For the ontology with the properties of objects presented in figure 1, 144 rules were formed with the proposed approach. Below we give some examples of conflict detection rules:
AND isaObject (Object1, Object2) THEN isConflict (Requirement1, Requirement2)
AND partOfObject (Object1, Object2) THEN isConflict (Requirement1, Requirement2)
AND antonymsObject (Object1, Object2) THEN isConflict (Requirement1, Requirement2) Depending on the used rule, one of the following four relations between the requirements are detected: “conflicting requirements”, “requirements are duplicates”, “requirements are related” or “connection is not detected”.
To implement the proposed approach, an application with a graphical interface in Python was developed. The application provides the following functions:
• building a system of production rules to process relations between instances of ontology classes and saving them as a model into XML file; • editing the system of production rules previously saved as a model; • application of the model rules to the requirements, presented in the form of class instances of OWL ontology.
To implement the first function, a constructor was created that helps the user to build a system of rules for analyzing the relations between the requirements elements in a few «clicks». The constructor allows you to select a file with OWL ontology for which the model was built. In the next steps of working with the designer, you can define which ontology classes correspond to the elements «actor», «action» and «object», as well as select the properties of objects that will be used for analysis. This allows the end user to create their own rules for processing the data they have. At the last step of working with the application, the generated combinations of antecedents for the production rules are issued. The user needs to define rule consequents by selecting the type of relation between the requirements for each rule. Semi-automatic rule generation does not allow the user to skip any rule because it covers all possible combinations for rule antecedents. Figure 6 shows the last step in building the model.
Further we consider two examples for rules obtained from the ontology described above. The first example analyzes the requirements in the form of user stories; the second example analyzes the requirements in the form of simple statements.
IF sameAsActor(Actor1, Actor2) AND partOfObject(Action1, Action2)
Substitution of data into the rule: IF sameAsActor(«менеджер», «менеджер») AND partOfAction(«удалить», «редактировать») AND isaObject(«добавленное менеджером описание товара», «описание товара в каталоге») THEN isConflict(Requirement1, Requirement2)
IF sameAsActor(Actor1, Actor2) AND antonymsAction(Action1, Action2) AND sameAsObject(Object1, Object2) THEN isConflict(Requirement1, Requirement2)
R1: Пользователь может удалять комментарии.
The user can delete comments R2: Пользователь может только просматривать комментарии.
The user can only view comments.
Substitution of data into the rule: IF sameAsActor(«пользователь», «пользователь») AND antonymsAction(«может удалять», «может только просматривать») AND sameAsObject(«комментарии», «комментарии») THEN isConflict (Requirement1, Requirement2)
In the first example, the Manager on the one hand can edit the descriptions of any goods (regardless of whether he added them or not), and on the other hand he has a ban on editing the descriptions of goods added not by him. In the second example, we see a contradiction in the actions of the user on one object “comments”, which also requires clarification and correction, because it is not clear what kind of comments we mean: only the comments created by the user himself, or all the comments to the objects created by the user in the system. And at first glance, “understandable flaws” can lead to the implementation of functionality that does not correspond to the original idea.
In the course of requirements analysis, data in the form of classes’ instances and relationships between them are imported into the database of facts in Prolog language, the generated production rules are imported into Prolog Rules. Then the Prolog Inference Engine is used to detect conflicts between the requirements. The results of the requirements analysis are saved into a text file. Python library PySwip and SWI-Prolog 7.6.4 development environment were used to implement this functionality.
The paper proposed an approach to detection of conflicts in the set of requirements based on an ontological model and a production rules system. To organize the processing of textual requirements, it was proposed to extract from the textual requirements the subject (actor), the action and the object on which the action is directed and save them in the form of ontology instances. It was also proposed to establish relations between instances of classes belonging to a pair of requirements that are defined in the ontology as object properties. The production rules system for determining the type of relation between a pair of requirements is based on these object properties. The developed toolkit to be able to facilitate the process of detection conflicting requirements since it performs the matching of requirements in a semi-automatic mode, which contributes to the detection of seemingly minor inaccuracies in the requirements formulation. It should be noted that the application of this approach requires the recording of textual requirements in the form of simple sentences that can be partially processed automatically, since it is quite labor-intensive to completely manually convert textual requirements into ontology instances.
The reported study was funded by Russian Ministry of Education and Science, according to the research project No. 2.2327.2017/4.6.