Airborne software multi-layer demand management method based on capability disassembly

Abstract

The invention relates to the field of demand management, in particular to an airborne software multilayer demand management method based on capability disassembly. A traditional single-layer demand management model is converted into a multi-layer demand management model, a demand engineer disassembles the capability of airborne software based on the demand management model, analyzes, records and changes demand entries in a demand management system, establishes a demand multi-level relationship, manages the delivery process of demands, and improves the demand delivery efficiency. A complete life cycle flow is managed through multi-level demands, and bidirectional verification of demands and delivery is completed.

Description

Technical Field

[0001] The present invention relates to the field of demand management, and in particular to an airborne software multi-layer demand management method based on capability decomposition. Background Art

[0002] At present, the traditional single-layer requirements management model usually mixes all requirements together, lacking a clear hierarchy and structure. This makes it difficult to effectively classify, prioritize and track requirements, increasing the complexity of management. When the number of requirements is large and mixed, the presentation of requirements becomes confusing and difficult to be clearly understood by the project team and users. This may lead to misunderstandings, conflicts and unnecessary rework. Due to the lack of clear hierarchy and structure, changing one requirement may affect other seemingly unrelated requirements, but in fact there are dependencies. This increases the difficulty of change management and may cause project delays or budget overruns. Single-layer requirements management methods usually do not have a clear prioritization mechanism, making it difficult for project teams to determine which requirements are more important and which can be handled later during the development process. This may lead to unreasonable resource allocation and affect the overall progress and quality of the project. Due to the lack of clear classification and priority in the single-layer requirements management model, communication between demand personnel and delivery personnel may also become difficult. Therefore, a more complete multi-layer requirements management method is needed as an alternative. Summary of the invention

[0003] In view of the defects of the traditional single-layer requirement management model, the present invention provides an airborne software multi-layer requirement management method based on capability decomposition, establishes a structured multi-layer requirement model based on software functional objectives, and the requirement engineer decomposes the capabilities of the airborne software based on the multi-level requirement management model, completes the analysis, recording, and modification of requirement items in the requirement management system, manages the delivery process of the requirements, runs through the entire life cycle process of the multi-level requirement management, and completes the two-way verification of requirements and delivery.

[0004] The technical solution of the present invention is a method for multi-layer demand management of airborne software based on capability decomposition, comprising the following steps:

[0005] Step S1: clarify the onboard software functional objectives and establish a structured multi-layer requirement model based on the software functional objectives;

[0006] Step S2: Disassemble the multi-layer requirements and record them in the requirements management system;

[0007] Step S3: The requirements are sent to relevant delivery personnel, who can verify and confirm the requirements and produce delivery results;

[0008] Step S4: Based on the delivery results, the demand personnel completes the two-way verification between demand and delivery by confirming and verifying the consistency between the actual results and the requirements to ensure that the results meet the requirements;

[0009] Preferably, step S1 comprises:

[0010] Step S1.1: By analyzing the airborne software capability items, the airborne software requirement composition structure is preliminarily clarified to form the original airborne software requirements;

[0011] Step S1.2: In-depth analysis of the original requirements of airborne software, planning the management path of airborne software requirements, and building a multi-layer requirement model for airborne software;

[0012] Preferably, step S2 comprises:

[0013] Step S2.1: According to the multi-layer demand model of airborne software, disassemble the initial demand of airborne software, improve the initial demand of airborne software, and clarify relevant information;

[0014] Step S2.2: According to the initial requirements of the airborne software, disassemble the airborne software system requirements, improve the airborne software system requirements, and clarify the relevant information;

[0015] Step S2.3: According to the airborne software system requirements, disassemble the airborne software allocation requirements, improve the airborne software allocation requirements, and clarify relevant information;

[0016] Preferably, step S3 comprises:

[0017] Step S3.1: The requirements are formally issued to the delivery personnel, who will begin to verify and confirm the details of these requirements to ensure accurate understanding and preparation for the relevant tasks;

[0018] Step S3.2: When there is a dispute or change between requirements and deliverables, the relevant parties can initiate a requirements change process to ensure that the project can be executed according to the latest requirements that are agreed by both parties and produce deliverables that meet the requirements;

[0019] Step S3.3: After receiving the requirements, the delivery personnel will first verify and confirm the accuracy, completeness and feasibility of these requirements. Once the requirements are confirmed, the delivery personnel will start the process of implementing the requirements delivery, work according to the established plan, specifications and quality standards, and finally form a delivery result that meets the requirements. This process ensures the consistency between requirements and delivery;

[0020] Step S3.4: These requirements need to be tracked and maintained regularly, including updating the status of requirements (such as completed, in progress, pending review, etc.), handling changes to requirements (such as addition, modification, deletion, etc.), and communicating and collaborating with other team members.

[0021] Preferably, the step S4 comprises:

[0022] Step S4.1: Based on the S3 delivery results, the demand personnel verify the degree of restoration between the results and the requirements. If the results do not match the requirements, the delivery personnel will modify the differences;

[0023] Step S4.2: After the delivery personnel redeliver the results, re-execute step S4;

[0024] Beneficial effects of the present invention:

[0025] The multi-layer requirements management method has shown significant advantages in airborne software development. Clearly defining the functional goals of airborne software and the multi-layer requirements of airborne software helps delivery members to deeply understand the airborne software requirements and focus on achieving these goals, thereby improving the success rate of demand delivery. Through detailed analysis and priority sorting of multi-layer requirements, resources can be allocated more reasonably, resource waste can be avoided, and demand delivery can be ensured to be completed on time and with quality. The multi-layer requirements management method can visualize the relationship between each link in the process of airborne software development from requirements to delivery, providing strong traceability.

[0026] In summary, the multi-layer requirements management approach can provide strong support and guarantee for the development of airborne software by improving delivery success rate, enhancing communication and collaboration, optimizing resource allocation, providing traceability and effective change management.

[0027] In the above scheme, compared with the traditional single-layer requirement management method, the multi-layer requirement management method for airborne software based on capability decomposition provided by the present invention can clearly define the functional objectives of airborne software and the multi-layer requirements of airborne software, which helps delivery members to deeply understand the requirements of airborne software and concentrate on achieving these goals, thereby improving the success rate of requirement delivery. Through detailed analysis and priority sorting of multi-layer requirements, resources can be allocated more reasonably, resource waste can be avoided, and the delivery of requirements can be ensured to be completed on time and with quality. The relationship between each link of the airborne software development process from requirements to delivery can be visualized, providing strong traceability. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0029] Figure 1 It is a schematic diagram of the process of the present invention.

[0030] Figure 2 This is a schematic diagram of the multi-layer requirements of the present invention. DETAILED DESCRIPTION

[0031] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0032] The multi-layer requirement management method for airborne software based on capability decomposition has the following steps:

[0033] Step S1: Clarify the functional objectives of the onboard software, such as data acquisition and processing, flight control, autonomous navigation, communication and data transmission, fault diagnosis and protection, etc.

[0034] Establish a structured multi-layer requirement model based on software functional goals;

[0035] Specifically, step S1 includes:

[0036] Step S1.1: By analyzing the airborne software capability items, the airborne software requirement composition structure is preliminarily clarified to form the original airborne software requirements;

[0037] Step S1.2: In-depth analysis of the original requirements of the airborne software, planning the management path of the airborne software requirements, and building a multi-layer requirement model for the airborne software; detailed description and definition of each functional requirement, including input, output, preconditions, postconditions, etc.

[0038] Step S2: Decompose the multi-layer requirements and enter the decomposed requirements into the requirements management system. When entering, you need to assign a unique identifier to each requirement and record the description, source, priority, status and other information of the requirement in detail. You need to describe the goal, input, output, preconditions and postconditions of each function in detail.

[0039] Specifically, step S2 includes:

[0040] Step S2.1: According to the multi-layer requirement model of airborne software, disassemble the initial requirements of airborne software, improve the initial requirements of airborne software, and clarify the description, source, priority, status, and target, input, output, precondition, postcondition, and abnormal situation of each requirement;

[0041] Step S2.2: Based on the initial requirements of the airborne software, disassemble the airborne software system requirements, improve the airborne software system requirements, and clarify the description, source, priority, status, and goals, inputs, outputs, preconditions, postconditions, and abnormal situations of each requirement;

[0042] Step S2.3: According to the airborne software system requirements, disassemble the airborne software allocation requirements, improve the airborne software allocation requirements, and clarify the description, source, priority, status, and target, input, output, precondition, postcondition, and abnormal situation of each requirement;

[0043] Step S3: The requirements are sent to relevant delivery personnel, who can verify and confirm the requirements and produce delivery results;

[0044] Specifically, step S3 includes:

[0045] Step S3.1: The requirements are formally issued to the delivery personnel, who will begin to verify and confirm the details of these requirements to ensure accurate understanding and preparation for the relevant tasks;

[0046] Step S3.2: When there is a dispute or change between requirements and deliverables, the relevant parties can initiate a requirements change process to ensure that the project can be executed according to the latest requirements that are agreed by both parties and produce deliverables that meet the requirements;

[0047] Step S3.3: After receiving the requirements, the delivery personnel will first verify and confirm the accuracy, completeness and feasibility of these requirements. Once the requirements are confirmed, the delivery personnel will start the process of implementing the requirements delivery, work according to the established plan, specifications and quality standards, and finally form a delivery result that meets the requirements. This process ensures the consistency between requirements and delivery;

[0048] Step S3.4: These requirements need to be tracked and maintained regularly, including updating the status of requirements (such as completed, in progress, pending review, etc.), handling changes to requirements (such as addition, modification, deletion, etc.), and communicating and collaborating with other team members.

[0049] Step S4: Based on the delivery results, the demand personnel completes the two-way verification between demand and delivery by confirming and verifying the consistency between the actual results and the requirements to ensure that the results meet the requirements;

[0050] Specifically, step S4 includes:

[0051] Step S4.1: Based on the S3 delivery results, the demand personnel verify the degree of restoration between the results and the requirements. If the results do not match the requirements, the delivery personnel will modify the differences;

[0052] Step S4.2: After the delivery personnel redeliver the results, re-execute step S4;

[0053] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0054] The above is only a specific embodiment of the present invention, and the present invention is described in detail. The unexplained part is a conventional technology. However, the protection scope of the present invention is not limited to this. Any changes or substitutions that can be easily thought of by any technician familiar with the technical field within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. The protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A multi-layer requirement management method for airborne software based on capability decomposition, characterized in that: The steps include: Step S1: clarify the airborne software functional objectives, and establish a structured multi-layer requirement model based on the airborne software functional objectives; Step S2: Decomposing the demand according to the multi-layer demand model and storing it in the demand management system; Step S3: The requirements are sent to relevant delivery personnel, who implement the requirements and deliver them, generating delivery results; Step S4: Based on the delivery results, the requirements personnel complete the two-way verification between requirements and delivery by confirming and verifying the consistency between the actual results and the requirements to ensure that the results meet the requirements.

2. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 1, characterized in that: The step S1 further comprises: Step S1.1: By analyzing the airborne software capability items, the airborne software requirement composition structure is preliminarily clarified to form the original airborne software requirements; Step S1.2: Analyze the original requirements of the airborne software, plan the management path of the airborne software requirements, and build a multi-layer requirement model for the airborne software.

3. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 2 is characterized in that: The step S2 further comprises: Step S2.1: According to the multi-layer demand model of airborne software, disassemble the initial demand of airborne software, improve the initial demand of airborne software, and clarify relevant information; Step S2.2: According to the initial requirements of the airborne software, disassemble the airborne software system requirements, improve the airborne software system requirements, and clarify the relevant information; Step S2.3: According to the airborne software system requirements, disassemble the airborne software allocation requirements, improve the airborne software allocation requirements, and clarify relevant information.

4. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 1, characterized in that: The step S3 further comprises: Step S3.1: The initial requirements, system requirements and allocation requirements for the onboard software are formally issued to the delivery personnel, who will begin to verify and confirm the details of these requirements to ensure accurate understanding and preparation for the relevant tasks; Step S3.2: When there are disputes or changes in the initial requirements, system requirements and allocation requirements of the airborne software and the delivery, the relevant parties can initiate the requirements change process to ensure that the project can be executed according to the latest and mutually agreed requirements and produce deliverables that meet the requirements; Step S3.3: After receiving the requirements, the delivery personnel will first verify and confirm the accuracy, completeness and feasibility of these requirements; once the requirements are confirmed, the delivery personnel will start the process of implementing the requirements delivery, work according to the established plan, specifications and quality standards, and finally form the delivery results that meet the requirements; this process ensures the consistency between requirements and delivery; Step S3.4: Regularly track and maintain these initial airborne software requirements, system requirements, and assigned requirements: including updating the status of requirements, handling changes to requirements, and communicating and collaborating with other team members.

5. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 4 is characterized in that: In step S3.4, the status of the requirements includes completed status, in progress status and pending review status, and the changes to the requirements include addition, modification and deletion.

6. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 1, characterized in that: The step S4 further comprises: Step S4.1: Based on the S3 delivery results, the demand personnel verify the degree of restoration between the results and the requirements. If the results do not match the requirements, the delivery personnel will modify the differences; Step S4.2: After the delivery personnel redeliver the results, execute step S4 again.

7. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 1 is characterized in that: In the step S1, all possible airborne software stakeholders are considered, and all airborne software functional objectives are identified based on full communication with them.

8. The method for multi-layer demand management of airborne software based on capability decomposition according to claim 3 is characterized in that: The step S2 includes but is not limited to initial requirements, system requirements, and allocation requirements, and supports more levels of demand management.

Images