CN112925506A - Method for detecting conflict between software requirements and computer readable storage medium - Google Patents

Method for detecting conflict between software requirements and computer readable storage medium Download PDF

Info

Publication number
CN112925506A
CN112925506A CN202011360683.3A CN202011360683A CN112925506A CN 112925506 A CN112925506 A CN 112925506A CN 202011360683 A CN202011360683 A CN 202011360683A CN 112925506 A CN112925506 A CN 112925506A
Authority
CN
China
Prior art keywords
requirement
relationship
action
items
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011360683.3A
Other languages
Chinese (zh)
Inventor
连小利
樊志强
张航
张莉
李华莹
郭维泽
赵子岩
牛婵
刘必欣
李敏
张捷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
CETC 15 Research Institute
Research Institute of War of PLA Academy of Military Science
Original Assignee
Beihang University
CETC 15 Research Institute
Research Institute of War of PLA Academy of Military Science
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University, CETC 15 Research Institute, Research Institute of War of PLA Academy of Military Science filed Critical Beihang University
Priority to CN202011360683.3A priority Critical patent/CN112925506A/en
Publication of CN112925506A publication Critical patent/CN112925506A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/10Requirements analysis; Specification techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3608Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Machine Translation (AREA)

Abstract

The invention discloses a method for detecting conflict between software requirements and a computer readable storage medium, which perfects the type of the requirement conflict and expands the range of the requirement conflict, so that the invention is not limited to the conflict between a pair of requirements, but also comprises the conflict under the combined action of a plurality of requirements.

Description

Method for detecting conflict between software requirements and computer readable storage medium
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method for detecting conflicts between software requirements and a computer-readable storage medium.
Background
With the explosive development of the information technology industry and the explosive growth of software scale, software development faces more and more serious challenges. Among them, the conflict of software requirements is always a common problem and a fatal problem in the software requirements. In a broad sense, the conflict of software requirements refers to the mutual interference and dependence between requirements, which can bring negative influence and unexpected problems to the operation of the whole system. In addition, the conflict of software requirements can cause the ambiguity of software development tasks, seriously delay the progress of software development, and is one of the roots of unstable and incomplete software functions. The requirement conflict is identified in the early stage of software development, so that the rework phenomenon in the development process can be greatly reduced, and the development cost is saved. However, software requirements conflict types are various, and it is difficult to detect a covert or indirect conflict by manual walkthrough. Moreover, the rapid increase in software size also presents a significant challenge to manually check for conflicting needs. How to utilize a computer to perform automatic detection of demand conflicts becomes a key problem to be solved urgently in the field of software development.
Disclosure of Invention
The invention provides a method for detecting conflicts among software requirements and a computer readable storage medium, which are used for solving the problems that the existing requirement conflict types are imperfect and the requirement conflicts can not be detected comprehensively.
In a first aspect, the present invention provides a method for detecting a conflict between software requirements, which is characterized by comprising: processing an input requirement item described by a natural language to obtain a part-of-speech tagging result and a dependency analysis result of the requirement item; and converting the requirement items described by the natural language into an octave form meeting the requirement meta-model based on the analysis result, and detecting conflicts among the requirement items through the requirement meta-model.
Optionally, the processing the input requirement entry described in the natural language to obtain a part-of-speech tagging result and a dependency analysis result of the requirement entry includes: and analyzing the requirement entry by using a natural language processing tool CoreNLP to obtain a part-of-speech tagging result and a dependency analysis result of the requirement entry.
Optionally, the octave comprises: the label id, group number, trigger event, executor agent, action operation, input, output, and constraint.
Optionally, the label id is a unique identifier of the requirement entry, the group number is a flag of each requirement entry group, the trigger event is an execution timing or trigger condition of the requirement entry, the executor agent is an executor of the action, the action operation is a core action executed by the requirement entry, the input is data that the executor needs to use when executing the action and already exists before the action is executed, the output is an object that is created, destroyed, and changed after executing the action, and the constraint is a relevant constraint for executing the action.
Optionally, the converting, based on the analysis result, the requirement item described in the natural language into an octave form conforming to a requirement meta-model includes:
identifying actions and group numbers in the requirement items, executors of the requirement items, triggering events of the requirement items and input-output constraints of the identification items based on the analysis results.
Optionally, the detecting conflicts between requirement entries through the requirement meta-model includes:
and detecting the inclusion relation, the inconsistent relation and the interlocking relation among the requirements among the requirement items through the requirement meta-model.
Optionally, the inter-requirement inclusion relationship includes: a behavior containing relationship and a condition containing relationship;
the inconsistent relationship between the demands is divided into: behavior inconsistency relation, constraint inconsistency relation and condition inconsistency relation;
the inter-demand interlocking relationship is divided into: conditional action interlocking relationships and input-output interlocking relationships.
Optionally, detecting an inter-requirement inclusion relationship, an inter-requirement inconsistency relationship, and an inter-requirement interlocking relationship between requirement items through the requirement meta-model includes:
traversing all the required items, and detecting the input-output interlocking relationship;
traversing all the requirement entries, and combining the requirement entries with the same triggering event and executor into a group;
traversing any two requirement item pairs belonging to the same group, and detecting whether a behavior containing relationship, a behavior inconsistency relationship and a constraint inconsistency relationship exist in the requirement item pairs;
traversing all two requirement entries which are not in the same group, and detecting whether a condition containing relationship and a condition inconsistent relationship exist in the two requirement entries;
and detecting whether a conditional action interlocking relationship exists among a plurality of requirement items of each group by taking each requirement group as a basic unit.
Optionally, before traversing all the requirement entries and detecting the input-output interlocking relationship, the method further includes: all the requirement entries are traversed to ensure that all the requirement entries are in the form of octaves.
In a second aspect, the present invention provides a computer-readable storage medium storing a signal-mapped computer program, which when executed by at least one processor, implements any of the above-described methods for detecting conflicts between software requirements.
The invention has the following beneficial effects: the invention perfects the type of the demand conflict and expands the range of the demand conflict, thereby not only limiting the invention to the conflict between a pair of demands, but also including the conflict of the combined action of a plurality of demands.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a flowchart illustrating a method for detecting conflicts between software requirements according to a first embodiment of the present invention;
FIG. 2 is a flowchart illustrating a method for identifying a requirement entry octave according to a first embodiment of the present invention;
FIG. 3 is a flowchart illustrating another method for detecting conflicts between software requirements according to the first embodiment of the present invention;
FIG. 4 is a diagram of a demand interlock provided by the first embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
Aiming at the problems that the existing requirement input in a special form is not suitable for the requirements of the current widely-used natural language writing, the requirement conflict type is incomplete, and some more key requirement conflicts can not be detected, such as the interlocking conflicts among a plurality of requirements and the like, the embodiment of the invention provides a method for detecting the conflicts among the software requirements, and the automation degree and the detection accuracy of the conflict detection among the existing software requirements can be improved. The present invention will be described in further detail below with reference to the drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the invention.
A first embodiment of the present invention provides a method for detecting conflicts between software requirements, and referring to fig. 1 and 3, the method includes:
s101, processing an input natural language described requirement item to obtain a part-of-speech tagging result and a dependency analysis result of the requirement item;
specifically, the embodiment of the invention uses a natural language processing tool CoreNLP to analyze the requirement entry, so as to obtain a part-of-speech tagging result and a dependency analysis result of the requirement entry.
S102, converting the requirement items described by the natural language into octave forms conforming to the requirement meta-model based on the analysis result;
the octave group in the embodiment of the invention comprises: the label id, the group number, the trigger event, the executor agent, the action operation, the input, the output and the constraint, however, in the specific implementation, those skilled in the art may set other types of arrays according to the actual requirement, and the present invention is not limited to this.
It should be noted that, in the embodiment of the present invention, the reference id is a unique identifier of a requirement entry, the group number is a flag of each requirement entry group, the trigger event is an execution timing or a trigger condition of the requirement entry, the executor agent is an executor of an action, the action operation is a core action executed by the requirement entry, the input is data that the executor needs to use when executing the action and already exists before the action is executed, the output is an object that is created after executing the action, destroyed and changed, and the constraint is a relevant constraint for executing the action.
In specific implementation, the converting the requirement item described in the natural language into an octave form conforming to the requirement meta-model based on the analysis result in the embodiment of the present invention includes: identifying actions and group numbers in the requirement items, executors of the requirement items, triggering events of the requirement items and input-output constraints of the identification items based on the analysis results.
S103, detecting conflicts among the requirement items through the requirement meta-model.
Specifically, the embodiment of the invention detects the inclusion relationship, the inconsistent relationship and the interlocking relationship among the requirements among the requirement items through the requirement meta-model.
Generally speaking, the embodiment of the invention uses a natural language processing tool CoreNLP to analyze the requirement items to obtain part-of-speech tagging results and dependency analysis results, provides a requirement meta-model in an eight-tuple form, provides a set of algorithms to automatically identify each tuple of the requirement items, and further provides a set of requirement conflict detection algorithms to automatically detect various conflicts among the requirement items.
The present invention defines the requirement meta-model as an octave, i.e. (label, group number, trigger event, actor, action, input, output, constraint). The specific definition is as follows:
(1) reference number (id): the unique identifier of the requirement item is usually composed of numbers and/or letters. The label of each requirement item is unique.
(2) Group number (group): the group number of the requirement item is a natural number and is a mark of each requirement item group. The requirement items with the same group number are in the same group, and the trigger event and the executor are the same.
(3) Triggering event (event): the execution timing or trigger condition of the demand entry. When the trigger event is satisfied, the executor must perform the corresponding action. Defining an event quintuple as: (executor, action, input, output, constraint), namely (agent, operation, input, output, restriction). If the same requirement item has a plurality of events, the five tuples of each event are connected through an 'AND' OR 'OR' connecting word to form the trigger event of the whole requirement item.
(4) Performer (agent): the performer of the action, requires the true subject of the clause.
(5) Action (operation): the core action executed by the requirement item, the predicate of the main sentence of the requirement item. An action is usually a verb, sometimes also containing other complementary parts.
(6) Input (input): the performer needs the data used when performing the action and already exists before the action is performed.
(7) Output (output): objects created, destroyed, changed after performing the action.
(8) Constraint (restriction): the relevant constraints on the actions to be performed include order, frequency, number, etc.
Further, as shown in fig. 2, the embodiment of the present invention converts the requirement entry described in the natural language into the requirement model in the form of an octave by the following method:
traversing all the requirement entries to ensure that all the requirement entries are in the form of octaves;
traversing all the required items, and detecting the input-output interlocking relationship;
traversing all the requirement entries, and combining the requirement entries with the same triggering event and executor into a group;
traversing any two requirement item pairs belonging to the same group, and detecting whether a behavior containing relationship, a behavior inconsistency relationship and a constraint inconsistency relationship exist in the requirement item pairs;
traversing all two requirement entries which are not in the same group, and detecting whether a condition containing relationship and a condition inconsistent relationship exist in the two requirement entries;
and detecting whether a conditional action interlocking relationship exists among a plurality of requirement items of each group by taking each requirement group as a basic unit.
Generally speaking, the embodiment of the invention perfects the type of the requirement conflict, expands the scope of the requirement conflict, is not limited to the conflict between a pair of requirements, and also comprises the conflict of the combined action of a plurality of requirements, such as the interlocking relationship between the requirements; in addition, the invention provides a set of inter-demand conflict detection algorithm, can perform conflict detection on the demands described by the natural language, has lower time complexity, is performed in a fully automatic way, and does not need any other auxiliary data.
In another aspect, the present invention provides a system for detecting a conflict between software requirements, the system comprising:
the natural language processing module is used for processing the input natural language described demand items to obtain part-of-speech tagging results and dependency analysis results of the demand items;
the requirement structuralization module is used for converting the requirement items described by the natural language into octave forms meeting the requirement model and using the analysis result of the natural language processing module;
and the requirement conflict detection module is used for detecting various types of conflicts among the requirement items and outputting the conflicts according to a format given by a user.
The method according to embodiments of the invention is explained and illustrated in detail below with reference to the drawings in which:
in the requirement octave model, the labels of requirements are directly obtained from the input requirement text, and the method for identifying the other seven tuples is as follows:
identification of action and group number:
the predicate verbs in the main sentence of the requirement entry should be computed as actions;
if the requirement items contain a plurality of predicate verbs, the requirement items are firstly split into a plurality of requirement items in the same group, and each requirement item only contains a single predicate verb and is then identified respectively;
the actions are divided into 3 forms, which are respectively: ABLE do, NOT do, and do (unable to execute, i.e., force execution). The specific identification rules are as follows:
if the sentence contains the words which can be equal, the action form is ABLE do;
otherwise, if the sentence contains negative words such as unable, impossible and the like, the action form is NOT do;
otherwise, the action form is do.
If there is an indeterminate structure directly related to the predicate verb of the requirement item main sentence, the action is calculated;
if the requirement item is a judgment sentence pattern, the whole judgment structure is counted as an action.
Identification of performers:
if the requirement item is in an active morpheme, calculating a noun having an nsubj dependent relation (CoreNLP semantic dependent analysis result) with a predicate verb of a main sentence of the requirement item as an executor;
if the required item is passive, calculating the real executor of the action, namely the actual subject as the executor;
if the executor is not found yet, the executor is regarded as an owner and recorded as ALL.
Identification of a triggering event:
searching a condition clause with the beginning of 'current' or 'if' in the requirement item, and processing the condition clause in a processing mode similar to the requirement item to obtain an event five-tuple;
when the requirement item has a plurality of conditional clauses, decomposing the requirement item into a plurality of conditional clauses only containing a single predicate, and sequentially processing the conditional clauses;
if the demand entry does not have a trigger event, it is marked as ALL, which means that it should be executed in any case.
Identification of inputs and outputs:
direct objects (dobj dependency, CoreNLP semantic dependency analysis result) of predicate verbs of the requirement item main sentence are calculated as input and output;
if the required item is passive, calculating the form subject as input and output;
calculating nouns and noun phrases in the concierge structure and the shape language components in the sentence as input;
and processing the object clauses of the requirement items in a manner similar to the requirement items to obtain the octaves. The input of the original requirement item is the whole object clause, and the output is an empty set;
if the input or output of the requirement entry is an empty set, it is recorded as VOID.
And (3) identifying the constraint:
calculating adverbs with an advmod dependency relationship (CoreNLP semantic dependency analysis result) in the requirement item as constraints;
if the requirement item contains semantic constraints such as time, place, execution mode and the like, the requirement item is calculated as a constraint;
if the constraint of the requirement entry is an empty set, it is recorded as VOID.
At the same time, some unimportant components in the requirement entry will be ignored and not counted as components of any tuple, including:
(1) example components, i.e., "such as," like, "and words such as" are listed below. The examples are given solely for the purpose of illustration and are not essential to the claimed subject matter, nor are they intended to be within the scope of the claims hereof;
(2) description of action execution target. The goal is simply a result of the execution of the action and should not be counted among the actions.
By the method, the requirement items described by the natural language can be well converted into the requirement model of the octave, the accuracy rate reaches 94.93%, and the identification accuracy rate of an executor is 100%. While structured related errors are mainly focused on the recognition of "inputs", which has a limited impact on inter-demand collision detection.
For the seven types of demand conflicts described above, the detection rules are as follows:
1. the demand room includes
Two different requirements are concentrated for the demand: and if the semantics of some tuples of the requirement a comprise the semantics of some tuples corresponding to the requirement b, and other tuples are the same, the requirement a and the requirement b are called to have a relation contained between the requirements. This relationship means that: requirement b is essentially a redundant requirement, and deleting requirement b does not change the essential meaning of the requirement set.
(1) Behavior containment relationships
If and only if both demand a and demand b are satisfied:
(a) the triggering event and the executor of the requirement a and the requirement b are the same;
(b) the semantics of the action of the requirement a comprise the semantics of the action of the requirement b;
(c) the input of requirement a comprises the input of requirement b, and the output of requirement a also comprises the output of requirement b;
(d) the constraint set of the requirement a comprises the constraint set of the requirement b;
then a behavior-inclusive relationship is said to exist between requirement a and requirement b, which is an anti-symmetric relationship.
(2) Conditional containment relationships
If and only if both demand a and demand b are satisfied:
(a) if the trigger event of demand a is satisfied, the trigger event of demand b must also be satisfied;
(b) the executors, actions, inputs, outputs and constraints of the requirements are all the same;
then a condition-inclusive relationship is said to exist between requirement a and requirement b, which is an anti-symmetric relationship.
2. Inconsistency between demands
Two different requirements are concentrated for the demand: and if the semantics of the requirement a and the semantics of the requirement b cannot be met at the same time, the requirement a and the requirement b are called to have an inconsistent relationship between the requirements.
(1) Behavioral inconsistency relationships
If and only if demand a and demand 2 are satisfied:
(a) the triggering event and the executor of the requirement a and the requirement b are the same;
(b) the meaning of the demand a action conflicts with the meaning of the demand b action;
(c) the input of the requirement a comprises the input of the requirement b or the input of the requirement b comprises the input of the requirement a;
(d) the output of demand a comprises the input of demand b or the input of demand b comprises the output of demand 1;
then a behavioral inconsistency relationship between requirement a and requirement b is said to exist, which is a symmetric relationship.
(2) Constraint inconsistency relation
If and only if the requirements a and b are fulfilled:
(a) the trigger event, the executor and the action of the requirement a and the requirement b are the same;
(b) the input of the requirement a comprises the input of the requirement b or the input of the requirement b comprises the input of the requirement a;
(c) the output of demand a comprises the input of demand b or the input of demand b comprises the output of demand a;
(d) the constraint of demand a is not the same as the constraint of demand b;
then a constraint inconsistent relationship between requirement a and requirement b is said to exist, which is a symmetric relationship.
(3) Conditional inconsistency
If and only if the triggering event of demand a and demand b are met: when the behavior of the requirement b is executed, the triggering event of the requirement a is not necessarily satisfied, that is, the behavior of the requirement b conflicts with the behavior of the triggering event of the requirement a, and a relationship with inconsistent conditions exists between the requirement a and the requirement b.
3. Inter-demand interlock
As shown in FIG. 4, the demand interlock graph is a directed graph, and each demand in the demand set is a node in the graph. If two requirements in the requirement set satisfy a certain association condition, a directed edge exists between the two requirements in the interlocking graph. If a loop exists in the interlocking graph (such as the red part in the graph), the requirements are called to have an interlocking relationship among the requirements. In this case, the presence of loops can undermine the stability and reliability of the required execution.
(1) Conditional action interlocking relationship
If demand a and demand b satisfy the condition: the action of executing the requirement a can directly meet the trigger event of the requirement b, namely, the action containing relationship exists between the trigger event of the requirement a and the trigger event of the requirement b, the requirement a and the requirement b meet the association condition of conditional action interlocking, and a directed edge from the requirement a to the requirement b exists in the conditional action interlocking graph.
In the conditional action interlock diagram, if a loop exists, it is said that all the requirements in the loop have a relationship of conditional action interlock. The requirement of the conditional action interlock may result in the triggering event of the requirement being satisfied forever during execution, and thus the intention of the requirement may be violated.
(2) Input-output interlocking relationship
If demand a and demand b satisfy the condition: and if the certain entity in the output of the requirement a comprises the certain entity in the input of the requirement b, and the input of the requirement b is not null, the requirement a and the requirement b meet the association condition of input-output interlocking, and a directed edge from the requirement a to the requirement b exists in the input-output interlocking graph.
In the input/output interlock diagram, if a loop exists, it is said that all the requirements in the loop have the input/output interlock relationship. The input and output interlock requirements are continuously changed in the process of executing the requirements, and the requirements cannot be stably executed.
The method can identify 83.33% of conflicts among 236 requirements, wherein all conflict types are included, and the algorithm of the invention is proved to be effective.
A second embodiment of the present invention provides a computer-readable storage medium storing a signal-mapped computer program, which when executed by at least one processor, implements the method for detecting conflicts between software requirements as set forth in any of the first embodiments of the present invention.
The relevant content of the embodiments of the present invention can be understood by referring to the first embodiment of the present invention, and will not be discussed in detail herein.
Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, and the scope of the invention should not be limited to the embodiments described above.

Claims (10)

1. A method for detecting conflicts between software requirements, comprising:
processing an input requirement item described by a natural language to obtain a part-of-speech tagging result and a dependency analysis result of the requirement item;
and converting the requirement items described by the natural language into an octave form meeting the requirement meta-model based on the analysis result, and detecting conflicts among the requirement items through the requirement meta-model.
2. The method according to claim 1, wherein the processing the input requirement entry described in the natural language to obtain a part-of-speech tagging result and a dependency analysis result of the requirement entry comprises:
and analyzing the requirement entry by using a natural language processing tool CoreNLP to obtain a part-of-speech tagging result and a dependency analysis result of the requirement entry.
3. The method of claim 1,
the octave includes: the label id, group number, trigger event, executor agent, action operation, input, output, and constraint.
4. The method of claim 3,
the label id is a unique identifier of the requirement item, the group number is a mark of each requirement item group, the trigger event is an execution time or a trigger condition of the requirement item, the executor agent is an executor of the action, the action operation is a core action executed by the requirement item, the input is data required to be used by the executor when executing the action and exists before the action is executed, the output is an object which is created, destroyed and changed after the action is executed, and the constraint is a relevant constraint for executing the action.
5. The method of claim 3, wherein transforming the requirement items described in the natural language into octave forms conforming to a requirement meta-model based on the analysis results comprises:
identifying actions and group numbers in the requirement items, executors of the requirement items, triggering events of the requirement items and input-output constraints of the identification items based on the analysis results.
6. The method of claim 3, wherein detecting conflicts between requirement entries via the requirement meta-model comprises:
and detecting the inclusion relation, the inconsistent relation and the interlocking relation among the requirements among the requirement items through the requirement meta-model.
7. The method of claim 6,
the inter-demand inclusion relationship includes: a behavior containing relationship and a condition containing relationship;
the inconsistent relationship between the demands is divided into: behavior inconsistency relation, constraint inconsistency relation and condition inconsistency relation;
the inter-demand interlocking relationship is divided into: conditional action interlocking relationships and input-output interlocking relationships.
8. The method of claim 7, wherein detecting inter-demand containment, inter-demand inconsistency, and inter-demand interlocking relationships between demand items via the demand meta-model comprises:
traversing all the required items, and detecting the input-output interlocking relationship;
traversing all the requirement entries, and combining the requirement entries with the same triggering event and executor into a group;
traversing any two requirement item pairs belonging to the same group, and detecting whether a behavior containing relationship, a behavior inconsistency relationship and a constraint inconsistency relationship exist in the requirement item pairs;
traversing all two requirement entries which are not in the same group, and detecting whether a condition containing relationship and a condition inconsistent relationship exist in the two requirement entries;
and detecting whether a conditional action interlocking relationship exists among a plurality of requirement items of each group by taking each requirement group as a basic unit.
9. The method of claim 8, wherein before traversing all requirement entries and detecting an input-output interlock relationship, the method further comprises:
all the requirement entries are traversed to ensure that all the requirement entries are in the form of octaves.
10. A computer-readable storage medium, in which a signal-mapped computer program is stored, which, when executed by at least one processor, implements the method of detecting conflicts between software requirements of any of claims 1-9.
CN202011360683.3A 2020-11-27 2020-11-27 Method for detecting conflict between software requirements and computer readable storage medium Pending CN112925506A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011360683.3A CN112925506A (en) 2020-11-27 2020-11-27 Method for detecting conflict between software requirements and computer readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011360683.3A CN112925506A (en) 2020-11-27 2020-11-27 Method for detecting conflict between software requirements and computer readable storage medium

Publications (1)

Publication Number Publication Date
CN112925506A true CN112925506A (en) 2021-06-08

Family

ID=76162615

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011360683.3A Pending CN112925506A (en) 2020-11-27 2020-11-27 Method for detecting conflict between software requirements and computer readable storage medium

Country Status (1)

Country Link
CN (1) CN112925506A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050203913A1 (en) * 2004-03-15 2005-09-15 Ramco Systems Limited Software life cycle availability over the internet
CN103049700A (en) * 2013-01-28 2013-04-17 北京航空航天大学 Conflict detection system and method for computer network defense (CND) policy
CN104267971A (en) * 2014-10-20 2015-01-07 张璇 Aspect-oriented trusted software process modeling method
CN109446513A (en) * 2018-09-18 2019-03-08 中国电子科技集团公司第二十八研究所 The abstracting method of event in a kind of text based on natural language understanding
CN111309871A (en) * 2020-03-26 2020-06-19 普华讯光(北京)科技有限公司 Method for matching degree between requirement and output result based on text semantic analysis

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050203913A1 (en) * 2004-03-15 2005-09-15 Ramco Systems Limited Software life cycle availability over the internet
CN103049700A (en) * 2013-01-28 2013-04-17 北京航空航天大学 Conflict detection system and method for computer network defense (CND) policy
CN104267971A (en) * 2014-10-20 2015-01-07 张璇 Aspect-oriented trusted software process modeling method
CN109446513A (en) * 2018-09-18 2019-03-08 中国电子科技集团公司第二十八研究所 The abstracting method of event in a kind of text based on natural language understanding
CN111309871A (en) * 2020-03-26 2020-06-19 普华讯光(北京)科技有限公司 Method for matching degree between requirement and output result based on text semantic analysis

Similar Documents

Publication Publication Date Title
US12050874B2 (en) System for knowledge acquisition
Sawyer et al. Shallow knowledge as an aid to deep understanding in early phase requirements engineering
US20180260474A1 (en) Methods for extracting and assessing information from literature documents
KR101306667B1 (en) Apparatus and method for knowledge graph stabilization
US7231388B2 (en) Similar document retrieving method and system
US20090222395A1 (en) Systems, methods, and software for entity extraction and resolution coupled with event and relationship extraction
US9208139B2 (en) System and method for identifying organizational elements in argumentative or persuasive discourse
CN112199512B (en) Scientific and technological service-oriented case map construction method, device, equipment and storage medium
Iftene et al. Hypothesis transformation and semantic variability rules used in recognizing textual entailment
Boujelben et al. A hybrid method for extracting relations between Arabic named entities
CN107562919A (en) A kind of more indexes based on information retrieval integrate software component retrieval method and system
CN113609838A (en) Document information extraction and mapping method and system
CN112733517B (en) Method for checking requirement template conformity, electronic equipment and storage medium
Kimelfeld Database principles in information extraction
CN112925506A (en) Method for detecting conflict between software requirements and computer readable storage medium
CN112099764B (en) Formal conversion rule-based avionics field requirement standardization method
JPH02254566A (en) Automatic excerpt generating device
Ferilli et al. Towards a Process Mining Approach to Grammar Induction for Digital Libraries: Syntax Checking and Style Analysis
Kuropiatnyk et al. Automation of template formation to identify the structure of natural language documents
Emebo et al. An automated tool support for managing implicit requirements using Analogy-based Reasoning
Mohbey et al. Preprocessing and morphological analysis in text mining
Lomotey et al. Terms analytics service for CouchDB: a document-based NoSQL
CN117829140B (en) Automatic comparison method and system for regulations and regulations
Allahyari-Abhari et al. Requirement phrasing assistance using automatic quality assessment
Gribermane et al. Text Processing Techniques in Approaches for Automated Composition of Domain Models.

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20210608

RJ01 Rejection of invention patent application after publication