Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The software requirement extraction method, the software requirement extraction device, the computer equipment and the readable storage medium aim at solving the technical problem that in the traditional technology, in the software development process, the quality of the developed unmanned aerial vehicle flight control system software is poor due to the fact that the accuracy of software requirement extraction of the unmanned aerial vehicle flight control system software to be developed is poor. The following describes in detail the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems by embodiments and with reference to the drawings. The following specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
It should be noted that, in the software requirement extraction method provided in the embodiment of the present application, an execution main body may be a software requirement extraction device, and the software requirement extraction device may be implemented as part or all of a computer device by software, hardware, or a combination of software and hardware. In the following method embodiments, the execution subject is a computer device, and the computer device may be an unmanned aerial vehicle flight controller.
Please refer to fig. 1, which illustrates a flowchart of a software requirement extraction method according to an embodiment of the present application. The embodiment relates to a specific implementation process for requirement extraction of unmanned aerial vehicle flight control system software to be developed by constructing an application requirement model based on historical defect prior data. As shown in fig. 1, the software requirement extraction method of this embodiment may include the following steps:
and S100, determining function requirement information corresponding to the unmanned aerial vehicle flight control system software to be developed.
The unmanned aerial vehicle flight control system software is a core part of the unmanned aerial vehicle flight control system. The unmanned aerial vehicle flight control system is used for controlling the whole flight process of the unmanned aerial vehicle from running, takeoff, air flight to approach landing, and specifically can be realized through an unmanned aerial vehicle flight controller in the unmanned aerial vehicle flight control system. Drone flight control system software may be deployed in the drone flight controller. In this embodiment, the function demand information may be a function that the unmanned aerial vehicle flight control system software developed and proposed by the demand side needs to realize.
And step S200, acquiring non-function requirement information corresponding to the function requirement information according to the function requirement information.
Wherein the non-functional requirement information comprises historical defect prior data.
Software requirement extraction is taken as basic work of requirement engineering, is a key ring for obtaining high-quality software, and is related to success or failure of the whole software development project. Taking the development of the flight control system software of the unmanned aerial vehicle as an example, due to the characteristic of high safety requirement of the flight control system software of the unmanned aerial vehicle, if the knowledge acquired in the software requirement extraction process is incomplete, a serious safety problem can be caused.
In this embodiment, the computer device obtains, according to the functional demand information, non-functional demand information corresponding to the functional demand information, where the non-functional demand information includes historical defect prior data, such as a security demand corresponding to the unmanned aerial vehicle flight control system software. As an embodiment, a SREP (software requirements error pattern) library may be set in the computer device, and the SREP library is used to store historical defect prior data, where the historical defect prior data may be empirical data collected in a historical application scenario or empirical data obtained in a software test.
For example, in a historical application scenario, the unmanned aerial vehicle completes a "pre-destruction" action in a remote control state, the acquired prior data is "before the pre-destruction, it is ensured that the flight safety protection switch has been triggered", and the computer device stores the prior data as historical defect prior data included in the non-functional requirement information in the historical application scenario. In this embodiment, if the computer device determines that the function demand information corresponding to the to-be-developed unmanned aerial vehicle flight control system software is to realize that the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state, the computer device ensures that the flight safety protection switch is triggered before acquiring the historical defect prior data "pre-destruction" included in the non-function demand information corresponding to the demand scene, that is, the scene in which the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state.
And step S300, constructing an application demand model based on the historical defect prior data.
The application demand model is used for demand extraction of unmanned aerial vehicle flight control system software to be developed; the application requirement model comprises a functional logic use case which is used for expressing the implementation logic of the function corresponding to the functional requirement information. As one embodiment, the application requirements model may also include non-functional logic use cases.
The computer equipment constructs an application demand model based on the historical defect prior data, wherein the application demand model comprises a functional logic use case, and the functional logic use case is used for expressing the implementation logic of the function corresponding to the functional demand information.
As an implementation manner, continuing the above example, the function requirement information is that the unmanned aerial vehicle completes a "pre-destruction" action in a remote control state, the historical defect prior data is "before pre-destruction, it is ensured that the flight safety protection switch has been triggered", and the corresponding use case including the historical defect prior data is as follows:
namely, the historical defect prior data is fused into the functional logic use case corresponding to the functional requirement information. The method comprises the steps of extracting the requirement of unmanned aerial vehicle flight control system software to be developed based on the application requirement model, specifically generating a specification document of the application software requirement in a natural language by using a functional logic case in the application requirement model, and providing the specification document for developers to refer to during software development. According to the embodiment, the historical defect prior data is fused into the application requirement model, so that the knowledge completeness of the application requirement model is improved. It is understood that in other embodiments, the expression form of the functional logic use case is not limited to the above exemplary manner, and other expression forms may exist, which are not specifically limited herein.
The method comprises the steps of determining function requirement information corresponding to unmanned aerial vehicle flight control system software to be developed; acquiring non-functional demand information corresponding to the functional demand information according to the functional demand information, wherein the non-functional demand information comprises historical defect prior data; constructing an application demand model based on historical defect prior data; the application demand model is used for demand extraction of unmanned aerial vehicle flight control system software to be developed; the application requirement model comprises a functional logic use case which is used for expressing the realization logic of the function corresponding to the functional requirement information; therefore, the prior information of the application demand model is enhanced by integrating the historical defect prior data into the application demand model, so that the knowledge of the application demand model is more complete; and then, the requirement extraction of the unmanned aerial vehicle flight control system software to be developed is carried out based on the application requirement model, so that the error avoiding effect of historical defect prior data can be fully exerted in the requirement extraction process, and the quality and the reliability of the developed unmanned aerial vehicle flight control system software are improved. The accuracy of software demand extraction has been promoted to this embodiment to the quality of the unmanned aerial vehicle flight control system software of development has been promoted.
Fig. 2 is a flowchart illustrating a software requirement extraction method according to an embodiment. On the basis of the embodiment shown in fig. 1, as shown in fig. 2, in the software requirement extraction method of this embodiment, the step S300 specifically includes a step S310 and a step S320, specifically:
and S310, constructing a required knowledge body of the unmanned aerial vehicle flight control system by adopting a body tool based on a Knowledge Aided Design System (KADS).
The unmanned aerial vehicle flight control system demand knowledge body comprises an unmanned aerial vehicle flight control system generalization body, a task body, a field body and an application body; the unmanned aerial vehicle flight control system generalization body, the task body, the field body and the application body comprise corresponding concepts and incidence relations among the concepts.
In this embodiment, as an implementation manner, an Ontology tool prot g is used to establish a requirement Knowledge Multi-Ontology Framework (RKMOF), that is, an unmanned aerial vehicle flight control system requirement Knowledge Ontology, so as to obtain a quadruple representation of the RKMOF: RKMOF ═ UAV FCS GO, DO, TO, AO >. The UAV FCSGO (Unmanned Aerial Vehicle Flight Control System Generalized Ontology) is an Unmanned Aerial Vehicle Flight Control System generalization Ontology, the DO (Domain Ontology) is a field Ontology, the TO (task Ontology) is a task Ontology, and the AO (application Ontology) is an application Ontology.
As an implementation mode, the computer device firstly detects whether a built and reusable unmanned aerial vehicle flight control system generalization body exists, and if no built and reusable unmanned aerial vehicle flight control system generalization body exists, firstly, the unmanned aerial vehicle flight control system generalization body is built; if there is unmanned aerial vehicle flight control system generalization body, then multiplexing existing unmanned aerial vehicle flight control system generalization body. Further, the computer device may also cut and expand the generalized body of the flight control system of the unmanned aerial vehicle, for example, remove duplicates, delete, add new, and so on. After establishing an unmanned aerial vehicle flight control system generalization body, the computer equipment detects whether a constructed and reusable task body exists, and if no constructed and reusable task body exists, the computer equipment establishes the task body; if the task body exists, the existing task body is reused. After the task body is established, whether a constructed and reusable field body exists is detected, and if no constructed and reusable field body exists, the field body is established; if the existing domain ontology exists, the existing domain ontology is reused. Further, after the domain ontology is established, whether a constructed and reusable task ontology exists is detected, and if no constructed and reusable task ontology exists, the task ontology is established; if the existing task body exists, the existing task body is reused. Further, the computer device can also cut and expand the task ontology, the domain ontology and the task ontology, such as removing duplication, deleting deletion, adding and the like. Therefore, the existing ontology is multiplexed by detecting whether the reusable ontology exists or not, and the sharing of ontology resources is realized.
It should be noted that, in the above ontology construction process, the computer device may all use an ontology tool prot g to implement, and a graphical user interface may be provided for a user to check, browse, encode, and modify an ontology according to the definition of concept hierarchy, concept attributes, rules, and constraints. Specifically, the computer device adopts ontology tool prot g e software to construct, reason and retrieve an ontology, and can express and organize ontology concepts, relationships, attributes and the like based on web ontology Language-Description (OWL-DL); the ontology file is mainly stored in a form of an owl by using four concepts of class (Classes), "instance (instances)," Object properties (objects), "and data properties (data properties)" in the ontology construction process; and reasoning the ontology file through inference engine plug-ins pellet, Hermit and the like of the prot g é software, providing a user interface for a user to inquire, and the like. The unmanned aerial vehicle flight control system generalization ontology comprises a plurality of generalization concepts of the unmanned aerial vehicle flight control system and incidence relations among the generalization concepts, the task ontology comprises a plurality of task concepts of the unmanned aerial vehicle flight control system and incidence relations among the task concepts, the field ontology comprises a plurality of field concepts and incidence relations among the field concepts, and the application ontology comprises a plurality of application concepts and incidence relations among the application concepts.
And S320, constructing an application demand model according to the demand knowledge body and the historical defect prior data of the unmanned aerial vehicle flight control system.
In this embodiment, the computer device may be provided with an SREP library. Specifically, after the SREP types in the summary field are collected by the testers and the field experts with reference to the test records and the problem report sheet according to the development and test experiences, the computer device obtains the empirical data collected in the historical application scene or the empirical data obtained in the software test to form an SREP library storing the historical defect prior data, and the historical defect prior data is expressed in an ontology form. The computer equipment constructs an application demand model according to the demand knowledge body of the unmanned aerial vehicle flight control system and the historical defect prior data, the application demand model comprises a functional logic use case, and the functional logic use case is used for expressing the implementation logic of the corresponding function of the functional demand information, namely, the historical defect prior data is fused into the functional logic use case corresponding to the functional demand information. And performing demand extraction of unmanned aerial vehicle flight control system software to be developed based on the application demand model.
Therefore, in the embodiment, KADS is used as a modeling framework basis of the unmanned aerial vehicle flight control system requirement knowledge body, the defects that powerful links are lacked among knowledge of each layer (UAV FCS GO, DO, TO and AO) in the unmanned aerial vehicle flight control system requirement knowledge body, the knowledge contained in the domain knowledge body is not complete enough and the like are overcome, the constructed unmanned aerial vehicle flight control system requirement knowledge body can integrate relatively independent knowledge layers together TO form a knowledge system, and the positive effect is played in knowledge sharing and reusing.
On the basis of the embodiment shown in fig. 2, referring to fig. 3, fig. 3 is a schematic diagram of a step S310 in a software requirement extraction method according to another embodiment. As shown in fig. 3, in the software requirement extraction method of this embodiment, step S310 specifically includes step S311, step S312, step S313 and step S314, and specifically:
and S311, based on KADS, establishing ontology representation for a plurality of generalization concepts of the unmanned aerial vehicle flight control system and the incidence relation among the generalization concepts by adopting an ontology tool to obtain a generalization ontology of the unmanned aerial vehicle flight control system.
In this embodiment, the computer device, based on the KADS, first establishes an unmanned aerial vehicle flight control system generalization ontology in an unmanned aerial vehicle flight control system requirement knowledge ontology by using an ontology tool prot g. Specifically, the computer device obtains a plurality of generalized concepts of the flight control system of the unmanned aerial vehicle and an association relationship between the generalized concepts, which may be determined according to the understanding and experience of the domain expert and many requirements of the demander. Then, the computer device describes the generalized concept terms and attributes, the hierarchical structure and the association relationship by using an ontology tool prot g, namely, multiple generalized concepts of the unmanned aerial vehicle flight control system and the association relationship among the generalized concepts are represented in a standardized manner, and a generalized ontology of the unmanned aerial vehicle flight control system is obtained. As an implementation manner, for the established generalized body of the flight control system of the unmanned aerial vehicle, a graphical user interface can be provided for a user to check, browse or modify the generalized body of the flight control system of the unmanned aerial vehicle.
And S312, extracting tasks corresponding to the unmanned aerial vehicle flight control system software by adopting a body tool according to the generalized body of the unmanned aerial vehicle flight control system and a preset concept mapping relation to construct a task body.
The task body is used for representing the execution process of the execution requirement extraction task.
After the unmanned aerial vehicle flight control system generalization body is established, the computer equipment establishes a task body in the unmanned aerial vehicle flight control system requirement knowledge body. In this embodiment, specifically, the requirement extraction task may be described by using a plurality of task concepts and an association relationship between the task concepts, and a problem solution process for executing the requirement extraction task is depicted, and the plurality of task concepts and the association relationship between the task concepts may be obtained by identifying the task concepts and the association relationship therein by a domain expert according to a requirement item of a demand side, and supplementing and optimizing the task concepts and the association relationship by referring to an existing document, an industry standard, and an existing software system.
Then, the computer device obtains a plurality of task concepts of the supplemented and optimized unmanned aerial vehicle flight control system and the association relationship among the task concepts. Further, the computer device uses the generalized ontology of the flight control system of the unmanned aerial vehicle as a top-level knowledge ontology according to the generalized ontology of the flight control system of the unmanned aerial vehicle and a preset concept mapping relationship, and uses the ontology to edit the prot g e to describe a plurality of task concepts and the association relationship among the task concepts according to a target and input/output to be realized by a PSM (Problem solution method) so as to realize a reasoning step required by a task target and obtain the task ontology. The task ontology reflects a task flow, for example, each action such as climbing, hovering, returning and descending of the unmanned aerial vehicle can be a task concept, and the context between each action can be an association relationship between each task concept.
And step S313, establishing ontology representation for a plurality of domain concepts of the domain and the incidence relation among the domain concepts by adopting an ontology tool according to the domain corresponding to the task ontology to obtain the domain ontology.
And the domain ontology is used for representing the knowledge characteristics of the domain corresponding to the task ontology.
The computer equipment establishes ontology representation for a plurality of domain concepts and the incidence relation among the domain concepts by adopting an ontology tool prot g according to the task domain corresponding to the task ontology to obtain the domain ontology.
Specifically, the computer device constructs a domain ontology according to domain knowledge required for completing a task in the task ontology, and performs normalized description on a plurality of domain concepts in the domain corresponding to the obtained task ontology and association relations among the domain concepts through an ontology tool prot g to obtain the domain ontology. The field that the task body corresponds is like unmanned aerial vehicle flight control field.
And S314, constructing an application body by adopting a body tool according to the generalization body, the task body and the field body of the unmanned aerial vehicle flight control system.
The computer equipment adopts the body tool to construct the application body according to the generalization body, the task body and the field body of the unmanned aerial vehicle flight control system. Specifically, the computer device obtains the application domain related concepts and associations, and obtains the application ontology by performing normalized description on the terms and attributes of the application concepts, the hierarchical structure and the association relationship through an ontology tool prot g according to the mapping relationship of the concepts.
Therefore, in the requirement extraction process of introducing the ontology concept into the unmanned aerial vehicle flight control system software, the generalization ontology, the task ontology, the field ontology and the application ontology of the unmanned aerial vehicle flight control system are adopted to carry out conceptualized standard description on the related concepts and the association relation, the completeness of knowledge in software requirements is improved, and the quality of the developed unmanned aerial vehicle flight control system software is improved.
Fig. 4 is a flowchart illustrating a software requirement extraction method according to an embodiment. On the basis of the embodiment shown in fig. 2, as shown in fig. 4, in the software requirement extraction method of this embodiment, step S320 includes step S321 and step S322, specifically:
and S321, constructing a field demand model according to the field ontology and the task ontology.
And step S322, constructing an application demand model according to the field demand model, the application body and the historical defect prior data.
In this embodiment, the computer device specifically combines the contents of the domain ontology and the task ontology according to the domain ontology and the task ontology to obtain a domain demand model with richer knowledge.
In this embodiment, the historical defect prior data includes at least one set of software requirement historical defect data, and each set of software requirement historical defect data includes at least defect scene information and defect solution information.
As an implementation manner, referring to fig. 5, fig. 5 is a schematic diagram of a refinement step of step S322 in this embodiment. As shown in fig. 5, step S322 of the present embodiment includes step S322a and step S322 b:
step S322a, generating at least one transection use case according to the defect scenario information and the defect solution information included in the at least one set of software requirement historical defect data.
The crosscutting use case comprises implementation logic used for representing non-functional requirements corresponding to the non-functional requirement information; the non-functional requirements include safety requirements corresponding to the unmanned aerial vehicle flight control system software.
In this embodiment, the focus points corresponding to the software requirements of the flight control system software of the unmanned aerial vehicle are divided into general focus points and transverse focus points, wherein the general focus points correspond to the functional requirements, and the transverse focus points correspond to the safety requirements in the non-functional requirements.
After the computer equipment acquires the function requirement information corresponding to the unmanned aerial vehicle flight control system software to be developed, determining the crosscut attention points corresponding to the general attention points of the unmanned aerial vehicle flight control system software requirements, namely the safety requirements in the non-function requirements corresponding to the function requirements.
For example, the function requirement information includes that the unmanned aerial vehicle completes a "pre-destruction" action in the remote control state, and the unmanned aerial vehicle completes a "just-to-destroy" action in the remote control state, that is, a general focus of a function requirement 1 (that the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state) included in the function requirement information is "pre-destruction", and a general focus of a function requirement 2 (that the unmanned aerial vehicle completes the "just-to-destroy" action in the remote control state) included in the function requirement information is "just-to-destroy". The computer device searches preset transverse cutting concern points respectively corresponding to 'pre-destruction' and 'instant destruction' to obtain two groups of software requirement historical defect data, wherein one group of software requirement historical defect data ensures that the flight safety protection switch is triggered before the defect scene information 'pre-destruction' and the defect solution information 'pre-destruction, and the other group of software requirement historical defect data ensures that the flight safety protection switch is triggered before the defect scene information' instant destruction 'and the defect solution information' instant destruction, namely the transverse cutting concern points corresponding to the 'pre-destruction' and the 'instant destruction' are both 'pre-destruction/instant destruction', and the flight safety protection switch is ensured to be triggered.
In this embodiment, the computer device describes a use case through an application scenario of a UML (Unified Modeling Language) Modeling tool Rational Rose, where the use case includes a precondition, a postcondition, a domain condition restriction, and a step. Specifically, the computer device constructs a transverse cutting scene by using the Rational Rose according to the historical defect data of the software requirement, and obtains a transverse cutting case. The use case describes the activities necessary to complete the task, including the various changes, i.e., the various scenarios, and thus, the safety requirements necessary to complete the task, i.e., pre-crash/pre-crash, are traversed to ensure that the flight safety protection switch has been triggered. It can be understood that, if there are a plurality of traverse points corresponding to each general point of interest, a plurality of traverse use cases are obtained, and a traverse use case set is formed.
Step S322b, generating a function logic case corresponding to the function requirement information according to the field requirement model, the application body and the crosscut case to obtain the application requirement model.
And the computer equipment generates a functional logic case corresponding to the functional demand information according to the field demand model, the application body and the transverse cutting case to obtain the application demand model. The domain requirement model and the application ontology are used for providing concepts and incidence relations of function use cases corresponding to the generated function requirements, and the transverse use cases are used for supplementing implementation logics of non-function requirements corresponding to the function requirements. And the computer equipment integrates the transverse cutting use cases of the transverse cutting concern points corresponding to the general concern points into use case development of the function requirement information to obtain a final function logic use case, so that an application requirement model is obtained.
Continuing to use the function requirement information including that the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state, and the unmanned aerial vehicle completes the "instant destruction" action in the remote control state, that is, the general focus point of the function requirement 1 (that the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state) included in the function requirement information is "pre-destruction", and the general focus point of the function requirement 2 (that the unmanned aerial vehicle completes the "instant destruction" action in the remote control state) is "instant destruction", and the cross-cut focus points corresponding to the general focus point "pre-destruction" and "instant destruction" are both "before pre-destruction/instant destruction", ensuring that the flight safety protection switch has been triggered ", for example, see fig. 6, and fig. 6 is a flow chart of the function logic case corresponding to the function requirement information generated by the computer device. As shown in fig. 6, the functional requirement information includes that the unmanned aerial vehicle completes the "pre-destruction" action in the remote control state, and the unmanned aerial vehicle completes the "instant destruction" action in the remote control state, and the computer device generates the functional logic use case corresponding to the functional requirement information by combining the non-functional requirement information, specifically, the security requirement:
therefore, the problem of incomplete knowledge in requirement extraction of unmanned aerial vehicle flight control system software is solved, historical defect prior data is used as a transverse cutting case to be fused into a case development process of functional requirement information, prior information of an application requirement model is enhanced, and the knowledge is complete. Based on this application demand model, further carry out the software demand extraction activity of unmanned aerial vehicle flight control system software, full play the mistake avoidance effect of historical defect priori data, play positive effect to the quality and the reliability that promote unmanned aerial vehicle flight control system software.
Fig. 7 is a flowchart illustrating a software requirement extraction method according to an embodiment. On the basis of the embodiment shown in fig. 1, as shown in fig. 7, the software requirement extraction method of this embodiment further includes step S410 and step S420, specifically:
step S410, acquiring multiple sets of software requirement historical defect data.
In this embodiment, an SREP (Software requirements fault pattern) library is provided in the computer device, and the SREP library is used to store historical defect prior data, where the historical defect prior data may include multiple sets of Software requirements historical defect data. Each group of software requirement historical defect data comprises corresponding defect scene information, defect expression information and defect solution information.
The software of the unmanned aerial vehicle flight control system is mostly real-time embedded software and has the following characteristics: 1) the method has extremely strong processing requirements of special external equipment and is closely related to hardware; 2) strong real-time is often required; 3) generally run in an environment that is specific or has special conditions, associated with the interaction environment; 4) the safety requirement is high.
Based on the above characteristics, the historical defect prior data in the SREP library is classified, see fig. 8, and fig. 8 is a classification schematic diagram of the historical defect prior data.
As shown in fig. 8, the first category is: direct action on hardware by unpredictable changes in operating conditions eventually leads to failure of the drone flight control system. Unforeseen operating condition changes directly act on hardware components of the unmanned aerial vehicle flight control system, the hardware components gradually permeate into internal units of the components along with time accumulation, and then the characteristics of components or circuits are influenced, and generated abnormal electric signals serve as software input and act on the unmanned aerial vehicle flight control system software through a software-hardware interface, so that the unmanned aerial vehicle flight control system software is abnormal in operation, and then the abnormal electric signals act on the components or the unmanned aerial vehicle flight control system in a reverse mode, and further global or local faults of the unmanned aerial vehicle flight control system are caused.
The first type of historical defect prior data may be expressed as:
scenario of incomplete demand:
scene 1:
the domain constraint k belongs to a domain constraint set;
and (3) defect expression: safety issues;
the solution is as follows: and giving a complete set of predefined operating conditions and a complete set of domain constraints to construct a complete domain ontology.
As shown in fig. 8, the second category is: direct action on hardware by unforeseen environmental changes eventually leads to failure of the drone flight control system. The above-mentioned change direct action is in unmanned aerial vehicle flight control system's hardware component, accumulates along with time, progressively permeates to the inside unit of part, and then influences components and parts or circuit characteristic, and the unusual signal of telecommunication that produces will act on unmanned aerial vehicle flight control system software through soft-hardware interface as software input to lead to unmanned aerial vehicle flight control system software to operate unusually, the reaction is in parts or unmanned aerial vehicle flight control system again, and then causes unmanned aerial vehicle flight control system's global or local trouble.
The second type of historical defect prior data can be expressed as:
scenario of incomplete demand:
scene 2:
the domain constraint k belongs to a domain constraint set;
sub-scene 2-1:
sub-scene 2-2:
sub-scenes 2-3:
sub-scenes 2-4:
sub-scenes 2-5:
sub-scenes 2-6:
sub-scenes 2-7:
sub-scenes 2-8:
and (3) defect expression: safety issues;
the solution is as follows: and giving a complete predefined environment set and a complete domain constraint set to construct a complete domain ontology.
As shown in fig. 8, the third category is: direct action on hardware by unpredictable operating condition changes and environmental changes ultimately leads to failure of the drone flight control system. The above-mentioned change direct action is in unmanned aerial vehicle flight control system's hardware component, accumulates along with time, progressively permeates to the inside unit of part, and then influences components and parts or circuit characteristic, and the unusual signal of telecommunication that produces will act on unmanned aerial vehicle flight control system software through soft-hardware interface as software input to lead to unmanned aerial vehicle flight control system software to operate unusually, the reaction is in parts or unmanned aerial vehicle flight control system again, and then causes unmanned aerial vehicle flight control system's global or local trouble.
The third type of historical defect prior data can be expressed as:
scenario of incomplete demand:
scene 3:
the domain constraint k belongs to a set of domain constraints,
sub-scene 3-1:
sub-scene 3-2:
sub-scenes 3-3:
sub-scenes 3-4:
sub-scenes 3-5:
sub-scenes 3-6:
sub-scenes 3-7:
sub-scenes 3-8:
and (3) defect expression: safety issues;
the solution is as follows: and giving a complete predefined environment set, an operation condition set and a domain constraint set to construct a complete domain ontology.
As shown in fig. 8, the fourth category is: direct action on the drone flight control system software by unpredictable changes in operating conditions eventually leads to failure of the drone flight control system. The abnormal operation of the software of the unmanned aerial vehicle flight control system generates an abnormal electric signal through the software and hardware interface, the abnormal electric signal directly acts on an internal unit of a hardware component of the unmanned aerial vehicle flight control system, and further acts on the hardware component of the unmanned aerial vehicle flight control system, so that the global or local fault of the unmanned aerial vehicle flight control system is finally caused.
The fourth type of historical defect prior data may be expressed as:
scenario of incomplete demand:
scene 4:
the domain constraint k belongs to a set of domain constraints,
and (3) defect expression: the safety problem.
The solution is as follows: and giving a complete set of predefined operating conditions and a complete set of domain constraints to construct a complete domain ontology.
Therefore, the computer equipment acquires multiple groups of software requirement historical defect data classified according to the categories. It is understood that each type of historical defect prior data may include multiple sets of software requirement historical defect data, and each set of software requirement historical defect data may include one type of defect scene information, defect performance information, and defect solution information under that type.
And step S420, generating a software requirement defect mode body according to the multiple groups of software requirement historical defect data.
And the computer equipment generates a software requirement defect mode body through a body tool prot g according to the plurality of groups of software requirement historical defect data.
Correspondingly, step S200 includes step S210:
step S210, according to the application scene of the functional demand information, determining non-functional demand information corresponding to the application scene, and acquiring at least one group of historical software demand defect data corresponding to the non-functional demand information from the software demand defect mode body as historical defect prior data.
In this embodiment, after determining the functional requirement information corresponding to the unmanned aerial vehicle flight control system software to be developed, the computer device determines the non-functional requirement information corresponding to the application scene according to the application scene of the functional requirement information, and acquires at least one set of software requirement historical defect data corresponding to the non-functional requirement information from the software requirement defect mode body as historical defect prior data.
As an embodiment, referring to fig. 9, fig. 9 is a schematic diagram of a step of refining step S210 in an embodiment. As shown in fig. 9, step S210 specifically includes step S211 and step S212:
in step S211, an application scenario of the function requirement information is determined.
The application scene of the function demand information can be an application scene of developed unmanned aerial vehicle flight control system software.
Step S212, determining non-functional requirement information matched with the application scene, and acquiring at least one group of software requirement historical defect data corresponding to the non-functional requirement information from the software requirement defect mode body as historical defect prior data.
The computer equipment determines non-functional requirement information matched with an application scene, and acquires one or more groups of software requirement historical defect data corresponding to the non-functional requirement information from the software requirement defect mode body as historical defect prior data. In this embodiment, the non-functional requirement information may be a security requirement in an application scenario, and in other embodiments, the non-functional requirement information may also be other non-functional requirements.
In the embodiment, the matched non-functional requirement information such as the safety requirement is selected and determined for different application scenes, and the historical defect prior data corresponding to the safety requirement is merged into the application requirement model, so that the prior information of the application requirement model is enhanced, and the knowledge of the application requirement model is more complete; and then, the requirement extraction of the unmanned aerial vehicle flight control system software to be developed is carried out based on the application requirement model, so that the error avoiding effect of historical defect prior data can be fully exerted in the requirement extraction process, and the quality and the reliability of the developed unmanned aerial vehicle flight control system software are improved. The accuracy of software demand extraction has been promoted to this embodiment to the quality of the unmanned aerial vehicle flight control system software of development has been promoted.
It should be understood that, although the steps in the above-described flowcharts are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a portion of the steps in the above-described flowcharts may include multiple sub-steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or the stages is not necessarily sequential, but may be performed alternately or alternatingly with other steps or at least a portion of the sub-steps or stages of other steps.
In one embodiment, as shown in fig. 10, there is provided a software requirement extracting apparatus, including:
the determining module 10 is used for determining functional requirement information corresponding to unmanned aerial vehicle flight control system software to be developed;
a first obtaining module 20, configured to obtain, according to the function requirement information, non-function requirement information corresponding to the function requirement information; the non-functional requirement information comprises historical defect prior data;
a construction module 30, configured to construct an application requirement model based on the historical defect prior data; the application demand model is used for demand extraction of the unmanned aerial vehicle flight control system software to be developed; the application requirement model comprises a functional logic use case, and the functional logic use case is used for representing the implementation logic of the function corresponding to the functional requirement information.
Optionally, the building module 30 comprises:
the unmanned aerial vehicle flight control system requirement knowledge body construction sub-module is used for constructing an unmanned aerial vehicle flight control system requirement knowledge body by adopting a body tool based on a Knowledge Aided Design System (KADS); the unmanned aerial vehicle flight control system demand knowledge body comprises an unmanned aerial vehicle flight control system generalization body, a task body, a field body and an application body; the unmanned aerial vehicle flight control system generalization body, the task body, the field body and the application body comprise corresponding concepts and incidence relations among the concepts;
and the application demand model building submodule is used for building the application demand model according to the unmanned aerial vehicle flight control system demand knowledge body and the historical defect prior data.
Optionally, the unmanned aerial vehicle flight control system requirement ontology building sub-module includes:
the first building unit is used for building ontology representation for a plurality of generalization concepts and incidence relations among the generalization concepts of the unmanned aerial vehicle flight control system by adopting the ontology tool based on the KADS to obtain a generalization ontology of the unmanned aerial vehicle flight control system;
the second construction unit is used for extracting tasks corresponding to the unmanned aerial vehicle flight control system software by adopting the body tool according to the generalized body of the unmanned aerial vehicle flight control system and a preset conceptual mapping relation to construct the task body; the task body is used for representing the execution process of executing the demand extraction task;
a third construction unit, configured to establish an ontology representation for a plurality of domain concepts of the domain and an association relationship between the domain concepts by using the ontology tool according to the domain corresponding to the task ontology, so as to obtain the domain ontology; the domain ontology is used for representing knowledge characteristics of the domain corresponding to the task ontology;
and the fourth construction unit is used for constructing the application body by adopting the body tool according to the unmanned aerial vehicle flight control system generalization body, the task body and the field body.
Optionally, the application requirement model building submodule includes:
the fifth construction unit is used for constructing a field demand model according to the field ontology and the task ontology;
and the sixth construction unit is used for constructing the application demand model according to the field demand model, the application ontology and the historical defect prior data.
Optionally, the historical defect prior data includes at least one group of software requirement historical defect data, and each group of software requirement historical defect data at least includes defect scene information and defect solution information; the sixth building element includes:
the first generating subunit is used for generating at least one crosscut use case according to the defect scene information and the defect solution information which are included in the at least one group of software requirement historical defect data; the crosscutting use case comprises implementation logic used for representing non-functional requirements corresponding to the non-functional requirement information; the non-functional requirements comprise safety requirements corresponding to the unmanned aerial vehicle flight control system software;
and the second generating subunit is configured to generate the functional logic use case corresponding to the functional requirement information according to the domain requirement model, the application body, and the crosscut use case, so as to obtain the application requirement model.
Optionally, the apparatus further comprises:
the second acquisition module is used for acquiring multiple groups of software requirement historical defect data;
the generating module is used for generating a software requirement defect mode body according to the plurality of groups of software requirement historical defect data;
correspondingly, the first obtaining module includes:
and the obtaining submodule is used for determining non-functional requirement information corresponding to the application scene according to the application scene of the functional requirement information, and obtaining at least one group of historical software requirement defect data corresponding to the non-functional requirement information from the software requirement defect mode body as the prior historical defect data.
Optionally, the obtaining sub-module includes:
the determining unit is used for determining an application scene of the function requirement information;
and the acquisition unit is used for determining non-functional requirement information matched with the application scene and acquiring at least one group of historical software requirement defect data corresponding to the non-functional requirement information from the software requirement defect mode body as the prior historical defect data.
The software requirement extraction device provided in this embodiment may implement the software requirement extraction method embodiment, and the implementation principle and the technical effect are similar, which are not described herein again. For specific limitations of the software requirement extraction device, reference may be made to the above limitations of the software requirement extraction method, which is not described herein again. The modules in the software requirement extraction device can be wholly or partially realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, there is also provided a computer device as shown in fig. 11, which may be a drone flight controller. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing the software requirement extraction data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a software requirement extraction method.
Those skilled in the art will appreciate that the architecture shown in fig. 11 is a block diagram of only a portion of the architecture associated with the subject application, and is not intended to limit the computing device to which the subject application may be applied, and that a computing device may in particular include more or less components than those shown, or combine certain components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having a computer program stored therein, the processor implementing the following steps when executing the computer program:
determining functional requirement information corresponding to unmanned aerial vehicle flight control system software to be developed;
acquiring non-functional demand information corresponding to the functional demand information according to the functional demand information; the non-functional requirement information comprises historical defect prior data;
constructing an application demand model based on the historical defect prior data; the application demand model is used for demand extraction of the unmanned aerial vehicle flight control system software to be developed; the application requirement model comprises a functional logic use case, and the functional logic use case is used for representing the implementation logic of the function corresponding to the functional requirement information.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, the computer program can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Ramb microsecond direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and bus dynamic RAM (RDRAM).
In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:
determining functional requirement information corresponding to unmanned aerial vehicle flight control system software to be developed;
acquiring non-functional demand information corresponding to the functional demand information according to the functional demand information; the non-functional requirement information comprises historical defect prior data;
constructing an application demand model based on the historical defect prior data; the application demand model is used for demand extraction of the unmanned aerial vehicle flight control system software to be developed; the application requirement model comprises a functional logic use case, and the functional logic use case is used for representing the implementation logic of the function corresponding to the functional requirement information.
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above examples only show some embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.