Method and tool for identifying requirement change review range of aero-engine control software

Abstract

The invention relates to the technical field of aero-engine control software verification, and particularly discloses an aero-engine control software demand change review range identification method and tool, and the identification method comprises the steps: identifying all software demands related to an upstream demand with a function substantial change, and taking the software demands as a first software demand review range; identifying all upstream demands related to the software demand with the function essence change, and then identifying all software demands related to all the upstream demands as a second software demand review range; identifying a pure derived demand as a third software demand review range; and combining the first software demand review range, the second software demand review range and the third software demand review range, and performing duplicate removal processing to obtain a final software demand change review range. According to the method, all changed software requirements and possibly influenced software requirements can be guaranteed to be included in the review range, and the risk of requirement problem omission in the review link is effectively inhibited.

Description

Technical Field

[0001] The present invention relates to the technical field of aircraft engine control software verification, and in particular to a method and tool for identifying the scope of aircraft engine control software requirement change review. Background Art

[0002] The control software of aircraft engine digital control systems is safety-critical software. Problems with engine control software may cause aircraft function failure or even result in the destruction of the aircraft and the loss of life. As for the software quality of control software, it is basically impossible to pursue the ultimate correctness of the software. The safety of the software can only be guaranteed through strict development process management. DO-178C is the standard document for the development of airborne software in the civil aviation field. This standard clearly defines the verification objectives of the airborne software requirements process and the requirements for change control of the requirements process. However, there is a lack of engineering-implementable verification solutions for the changed software requirements, which leads to many difficulties in the engineering practice process. Therefore, it is necessary to propose a method for identifying the scope of aircraft engine control software requirement change review that meets the requirements of civil aircraft, and provide practical guidance for the verification activities after the civil aircraft software requirements are changed. Summary of the Invention

[0003] In response to the shortcomings of the existing technology, the present invention provides a method and tool for identifying the scope of review of changes in aircraft engine control software requirements, so as to solve the problem in the existing technology that there is a lack of engineering-implementable verification solutions for the changed software requirements, which leads to numerous difficulties in the engineering practice process.

[0004] As a first aspect of the present invention, a method for identifying the scope of an aircraft engine control software requirement change review is provided. The method for identifying the scope of an aircraft engine control software requirement change review comprises: Step S1: comparing the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminating upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; Step S2: Comparing the baseline before and after the software requirement change in the demand system DOORS to identify all changed software requirement items, and eliminating the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; Step S3: Based on the bidirectional traceability matrix, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope; Step S4: identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope; Step S5: Identify purely derived requirements from the software requirement items that have undergone substantial functional changes, as the third software requirement review scope; Step S6: Merge the first software requirement review scope, the second software requirement review scope, and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain a final software requirement change review scope.

[0005] Furthermore, the comparison of the baseline before and after the change of the upstream demand in the demand system DOORS to identify all changed upstream demand items, and excluding upstream demand items with no substantial functional change from all changed upstream demand items to obtain upstream demand items with substantial functional change, further includes: Use a DXL script to traverse upstream requirements based on their requirement IDs, retrieve the requirement texts in the baselines before and after the change corresponding to the requirement IDs, and identify all upstream requirement items whose requirement texts have been changed. A knowledge base of functional requirements of an aircraft engine control system is established, and a large language model is used to identify and eliminate upstream requirement items with no substantial functional changes from all the changed upstream requirement items based on the functional requirements knowledge base of the aircraft engine control system, so as to obtain upstream requirement items with substantial functional changes.

[0006] Furthermore, the comparison of the baseline before and after the change of the software requirements in the demand system DOORS to identify all changed software requirement items, and excluding the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes, further includes: Use a DXL script to traverse the software requirement based on its requirement ID, retrieve the requirement text in the baseline before and after the change corresponding to the requirement ID, and identify all software requirement items whose requirement text has been changed. An aircraft engine control system software requirement knowledge base is established, and a large language model is used to identify and eliminate software requirement items with no substantial functional changes from all the changed software requirement items based on the aircraft engine control system software requirement knowledge base, so as to obtain software requirement items with substantial functional changes.

[0007] Furthermore, the identification of all software requirement items related to the upstream requirement item with substantial functional changes based on the bidirectional traceability matrix as the first software requirement review scope also includes: Using DXL scripts, based on the bidirectional traceability matrix of software requirements and upstream requirements, and according to the ID of the upstream requirement with substantial functional changes, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope.

[0008] Furthermore, the step of identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope, further includes: Use DXL scripts to identify all upstream requirements related to the software requirement item with a functionally changed substantive change based on the bidirectional traceability matrix between software requirements and upstream requirements and the ID of the software requirement with a functionally changed substantive change. Using a DXL script, based on a bidirectional traceability matrix between the software requirements and upstream requirements, and according to the requirement IDs of all upstream requirements, all software requirement items related to all upstream requirement items are identified as a second software requirement review scope.

[0009] Furthermore, the identification of purely derived requirements from the software requirement items that have undergone substantial functional changes as a third software requirement review scope also includes: All purely derived requirements that have no traceability relationship with upstream requirements are screened out from all the changed software requirement items as the third software requirement review scope.

[0010] As a second aspect of the present invention, a tool for identifying the scope of review of aircraft engine control software requirement changes is provided, comprising: A first baseline comparison module is used to compare the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminate upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; The second baseline comparison module is used to compare the baseline before and after the software requirement changes in the demand system DOORS to identify all changed software requirement items, and eliminate the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; A first software requirement review scope generating module is configured to identify, based on a bidirectional traceability matrix, all software requirement items related to the upstream requirement item with the substantial functional change, as the first software requirement review scope; a second software requirement review scope generating module configured to identify, based on the bidirectional traceability matrix, all upstream requirement items related to the software requirement item with a substantial functional change, and then identify all software requirement items related to all upstream requirement items as the second software requirement review scope; a third software requirement review scope generating module, configured to identify purely derived requirements from the software requirement items that have undergone substantial functional changes, to serve as the third software requirement review scope; The software requirement review scope merging module is used to merge the first software requirement review scope, the second software requirement review scope and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain the final software requirement change review scope.

[0011] The method and tool for identifying the scope of review of changes to aircraft engine control software requirements provided by the present invention have the following beneficial effects: clarifying the engineering acquisition steps for the review scope of software requirement changes, improving the efficiency of identifying the scope of change review, implementing the requirements of DO-178C for software requirement verification activities, and providing practical guidance for verification activities after civil aircraft software requirement changes; by fully identifying the changed and affected requirements, ensuring that the changed software requirements are fully reviewed, and effectively suppressing the risk of missing requirement issues. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present invention, but do not constitute a limitation of the present invention.

[0013] Figure 1 The present invention provides a flow chart of a method for identifying the scope of review of changes to aircraft engine control software requirements.

[0014] Figure 2 A flowchart of a specific implementation method of the method for identifying the scope of review of aircraft engine control software requirement changes provided by the present invention.

[0015] Figure 3 A schematic diagram of the relationship between upstream requirements and software requirements traceability and changes provided by the present invention. DETAILED DESCRIPTION

[0016] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments of the present invention may be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0017] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described 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 making creative efforts should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," and the like in the specification and claims of the present invention and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate for the embodiments of the present invention described herein. In addition, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or apparatuses.

[0019] In this embodiment, a method and tool for identifying the scope of review of aircraft engine control software requirements changes are provided, such as Figure 1 Please also refer to Figure 2 The method for identifying the scope of the aircraft engine control software requirement change review includes: Step S1: comparing the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminating upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; Preferably, the comparing of the baseline before and after the upstream requirements in the requirements system DOORS to identify all changed upstream requirements items, and excluding upstream requirements items with no substantial functional changes from all changed upstream requirements items to obtain upstream requirements items with substantial functional changes, further includes: Use a DXL script to traverse upstream requirements based on their requirement IDs, retrieve the requirement texts in the baselines before and after the change corresponding to the requirement IDs, and identify all upstream requirement items whose requirement texts have been changed. A knowledge base of functional requirements of an aircraft engine control system is established, and a large language model is used to identify and eliminate upstream requirement items with no substantial functional changes from all the changed upstream requirement items based on the functional requirements knowledge base of the aircraft engine control system, so as to obtain upstream requirement items with substantial functional changes.

[0020] In an embodiment of the present invention, a DXL script is used to implement requirement baseline comparison. The DXL script is traversed according to the requirement ID of the upstream requirement, and the requirement text in the baseline before and after the change corresponding to the requirement ID is retrieved. The upstream requirement items whose requirement texts have been changed are identified and output in CSV file format; an aircraft engine control system functional requirement knowledge base is constructed in the Dify platform and a change requirement screening workflow is established. The upstream requirement items with no substantial functional changes are identified and eliminated through a large language model. The output of the change requirement screening workflow in the Dify platform is the requirement items with substantial functional changes in the upstream requirements.

[0021] Step S2: Comparing the baseline before and after the software requirement change in the demand system DOORS to identify all changed software requirement items, and eliminating the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; Preferably, the comparing of the baseline before and after the change of the software requirements in the demand system DOORS to identify all changed software requirement items, and removing the software requirement items without substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes, further includes: Use a DXL script to traverse the software requirement based on its requirement ID, retrieve the requirement text in the baseline before and after the change corresponding to the requirement ID, and identify all software requirement items whose requirement text has been changed. An aircraft engine control system software requirement knowledge base is established, and a large language model is used to identify and eliminate software requirement items with no substantial functional changes from all the changed software requirement items based on the aircraft engine control system software requirement knowledge base, so as to obtain software requirement items with substantial functional changes.

[0022] In an embodiment of the present invention, a DXL script is used to implement requirement baseline comparison. The DXL script is traversed according to the requirement ID of the software requirement, and the requirement text in the baseline before and after the change corresponding to the requirement ID is retrieved. The software requirement items with changed requirement texts are identified and output in CSV file format; an aircraft engine control software functional requirement knowledge base is constructed in the Dify platform and a change requirement screening workflow is established. The software requirement items with no substantial functional changes are identified and eliminated through a large language model. The output of the change requirement screening workflow in the Dify platform is the requirement items with substantial functional changes in the software requirements.

[0023] Step S3: Based on the bidirectional traceability matrix, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope; Preferably, the step of identifying all software requirement items related to the upstream requirement item with substantial functional changes based on the bidirectional traceability matrix as the first software requirement review scope further includes: Using DXL scripts, based on the bidirectional traceability matrix of software requirements and upstream requirements, and according to the ID of the upstream requirement with substantial functional changes, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope.

[0024] In the embodiment of the present invention, Figure 3 As shown, the upstream requirements SSR1, SSR2, SSR3 and SSR5 have changed, and all the software requirements traced back are SRS1, SRS2, SRS3, SRS4, SRS5 and SRS6, that is, the scope of the first software requirement review is SRS1, SRS2, SRS3, SRS4, SRS5 and SRS6.

[0025] Step S4: identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope; Preferably, the step of identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope, further includes: Use DXL scripts to identify all upstream requirements related to the software requirement item with a functionally changed substantive change based on the bidirectional traceability matrix between software requirements and upstream requirements and the ID of the software requirement with a functionally changed substantive change. Using a DXL script, based on a bidirectional traceability matrix between the software requirements and upstream requirements, and according to the requirement IDs of all upstream requirements, all software requirement items related to all upstream requirement items are identified as a second software requirement review scope.

[0026] In the embodiment of the present invention, Figure 3As shown, software requirements SRS1, SRS2, SRS4, SRS6 and SRS8 have changed, and all upstream requirements traced back are SSR1, SSR2, SSR3, SSR4, SSR5 and SSR6. All software requirements related to all upstream requirements (SSR1, SSR2, SSR3, SSR4, SSR5 and SSR6) are SRS1, SRS2, SRS3, SRS4, SRS5, SRS6 and SRS7. That is, the scope of the second software requirement review is SRS1, SRS2, SRS3, SRS4, SRS5, SRS6 and SRS7.

[0027] Step S5: Identify purely derived requirements from the software requirement items that have undergone substantial functional changes, as the third software requirement review scope; Preferably, the step of identifying purely derived requirements from the software requirement items that have undergone substantial functional changes as a third software requirement review scope further includes: All purely derived requirements that have no traceability relationship with upstream requirements are screened out from all the changed software requirement items as the third software requirement review scope.

[0028] In the embodiment of the present invention, Figure 3 As shown, software requirements SRS1, SRS2, SRS4, SRS6 and SRS8 have changed, among which SRS8 is a purely derived requirement, that is, the scope of the third software requirement review is SRS8.

[0029] Step S6: Merge the first software requirement review scope, the second software requirement review scope, and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain a final software requirement change review scope.

[0030] In the embodiment of the present invention, Figure 3 As shown, the final software requirements review scope is SRS1, SRS2, SRS3, SRS4, SRS5, SRS6, SRS7 and SRS8.

[0031] As another embodiment of the present invention, a tool for identifying the scope of review of aircraft engine control software requirement changes is provided, comprising: A first baseline comparison module is used to compare the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminate upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; The second baseline comparison module is used to compare the baseline before and after the software requirement changes in the demand system DOORS to identify all changed software requirement items, and eliminate the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; A first software requirement review scope generating module is configured to identify, based on a bidirectional traceability matrix, all software requirement items related to the upstream requirement item with the substantial functional change, as the first software requirement review scope; a second software requirement review scope generating module configured to identify, based on the bidirectional traceability matrix, all upstream requirement items related to the software requirement item with a substantial functional change, and then identify all software requirement items related to all upstream requirement items as the second software requirement review scope; a third software requirement review scope generating module, configured to identify purely derived requirements from the software requirement items that have undergone substantial functional changes, to serve as the third software requirement review scope; The software requirement review scope merging module is used to merge the first software requirement review scope, the second software requirement review scope and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain the final software requirement change review scope.

[0032] In an embodiment of the present invention, the human-computer interaction interface of the identification tool adopts JavaFx plug-in technology, and a baseline comparison button, a range generation button and a range merge button are designed in the human-computer interaction interface. The baseline comparison button calls the first baseline comparison module to compare the baseline before and after the upstream requirements in the requirements system DOORS to identify all changed upstream requirement items, and eliminate the upstream requirement items with no substantial functional changes from all the changed upstream requirement items to obtain the upstream requirement items with substantial functional changes; the baseline comparison button calls the second baseline comparison module to compare the baseline before and after the software requirements in the requirements system DOORS to identify all changed software requirement items, and eliminate the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; the range generation button calls the first software requirement review range generation module to identify all software requirement items related to the upstream requirement items with substantial functional changes based on the bidirectional traceability matrix. The scope generation button calls the second software requirement review scope generation module, identifies all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifies all software requirement items related to all upstream requirement items as the second software requirement review scope; the scope generation button calls the third software requirement review scope generation module, identifies pure derived requirements from the software requirement item with substantial functional changes as the third software requirement review scope; the scope merge button calls the software requirement review scope merging module, merges the first software requirement review scope, the second software requirement review scope and the third software requirement review scope, and deduplicates the merged software requirement review scope to obtain the final software requirement change review scope.

[0033] The method and tool for identifying the scope of review of changes to aircraft engine control software requirements provided by the present invention involve the verification of change requirements for control software of civil aircraft engine numerical control systems, clarify the engineering acquisition steps for the scope of review of software requirement changes, implement the requirements of DO-178C for software requirement verification activities, and provide practical guidance for verification activities after civil aircraft software requirement changes. By fully identifying the changed and affected requirements, it is ensured that the changed software requirements are fully reviewed, effectively suppressing the risk of missing requirement issues.

[0034] It will be understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present invention, and the present invention is not limited thereto. Those skilled in the art will appreciate that various modifications and improvements can be made without departing from the spirit and substance of the present invention, and such modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A method for identifying the scope of review of aircraft engine control software requirement changes, characterized in that: The method for identifying the scope of the aircraft engine control software requirement change review includes: Step S1: comparing the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminating upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; Step S2: Comparing the baseline before and after the software requirement change in the demand system DOORS to identify all changed software requirement items, and eliminating the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; Step S3: Based on the bidirectional traceability matrix, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope; Step S4: identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope; Step S5: Identify purely derived requirements from the software requirement items that have undergone substantial functional changes, as the third software requirement review scope; Step S6: Merge the first software requirement review scope, the second software requirement review scope, and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain a final software requirement change review scope.

2. The method for identifying the scope of review of aircraft engine control software requirement changes according to claim 1, characterized in that: The method further includes comparing the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminating upstream demand items with no substantial functional changes from all changed upstream demand items to obtain upstream demand items with substantial functional changes. Use a DXL script to traverse upstream requirements based on their requirement IDs, retrieve the requirement texts in the baselines before and after the change corresponding to the requirement IDs, and identify all upstream requirement items whose requirement texts have been changed. A knowledge base of functional requirements of an aircraft engine control system is established, and a large language model is used to identify and eliminate upstream requirement items with no substantial functional changes from all the changed upstream requirement items based on the functional requirements knowledge base of the aircraft engine control system, so as to obtain upstream requirement items with substantial functional changes.

3. The method for identifying the scope of review of aircraft engine control software requirement changes according to claim 1, characterized in that: The comparing of the baseline before and after the change of the software requirement in the demand system DOORS to identify all changed software requirement items, and removing the software requirement items without substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes, further includes: Use a DXL script to traverse the software requirement based on its requirement ID, retrieve the requirement text in the baseline before and after the change corresponding to the requirement ID, and identify all software requirement items whose requirement text has been changed. An aircraft engine control system software requirement knowledge base is established, and a large language model is used to identify and eliminate software requirement items with no substantial functional changes from all the changed software requirement items based on the aircraft engine control system software requirement knowledge base, so as to obtain software requirement items with substantial functional changes.

4. The method for identifying the scope of review of aircraft engine control software requirement changes according to claim 1, characterized in that: The process of identifying all software requirement items related to the upstream requirement item with substantial functional changes based on the bidirectional traceability matrix as the first software requirement review scope also includes: Using DXL scripts, based on the bidirectional traceability matrix of software requirements and upstream requirements, and according to the ID of the upstream requirement with substantial functional changes, all software requirement items related to the upstream requirement item with substantial functional changes are identified as the first software requirement review scope.

5. The method for identifying the scope of review of aircraft engine control software requirement changes according to claim 1, characterized in that: The step of identifying all upstream requirement items related to the software requirement item with substantial functional changes based on the bidirectional traceability matrix, and then identifying all software requirement items related to all upstream requirement items as the second software requirement review scope, further includes: Use DXL scripts to identify all upstream requirements related to the software requirement item with a functionally changed substantive change based on the bidirectional traceability matrix between software requirements and upstream requirements and the ID of the software requirement with a functionally changed substantive change. Using a DXL script, based on a bidirectional traceability matrix between the software requirements and upstream requirements, and according to the requirement IDs of all upstream requirements, all software requirement items related to all upstream requirement items are identified as a second software requirement review scope.

6. The method for identifying the scope of review of aircraft engine control software requirement changes according to claim 1, characterized in that: The identification of purely derived requirements from the software requirement items that have undergone substantial functional changes as part of the third software requirement review scope also includes: All purely derived requirements that have no traceability relationship with upstream requirements are screened out from all the changed software requirement items as the third software requirement review scope.

7. A tool for identifying the scope of review of changes to aircraft engine control software requirements, used to implement the method for identifying the scope of review of changes to aircraft engine control software requirements as claimed in any one of claims 1 to 6, characterized in that: The tools for identifying the scope of the aircraft engine control software requirement change review include: A first baseline comparison module is used to compare the baseline before and after the upstream demand changes in the demand system DOORS to identify all changed upstream demand items, and eliminate upstream demand items with no substantial functional changes from all the changed upstream demand items to obtain upstream demand items with substantial functional changes; The second baseline comparison module is used to compare the baseline before and after the software requirement changes in the demand system DOORS to identify all changed software requirement items, and eliminate the software requirement items with no substantial functional changes from all the changed software requirement items to obtain the software requirement items with substantial functional changes; A first software requirement review scope generating module is configured to identify, based on a bidirectional traceability matrix, all software requirement items related to the upstream requirement item with the substantial functional change, as the first software requirement review scope; a second software requirement review scope generating module configured to identify, based on the bidirectional traceability matrix, all upstream requirement items related to the software requirement item with a substantial functional change, and then identify all software requirement items related to all upstream requirement items as the second software requirement review scope; a third software requirement review scope generating module, configured to identify purely derived requirements from the software requirement items that have undergone substantial functional changes, to serve as the third software requirement review scope; The software requirement review scope merging module is used to merge the first software requirement review scope, the second software requirement review scope and the third software requirement review scope, and perform deduplication processing on the merged software requirement review scope to obtain the final software requirement change review scope.

Images