DOORS and JIRA demand-problem synchronization method and device and medium

Abstract

The invention discloses a DOORS and JIRA demand-problem synchronization method and device and a medium. The method comprises the steps of obtaining a mapping rule between a JIRA problem field and a DOORS demand attribute; monitoring a problem change event in the JIRA system and a demand change event in the DOORS system; converting the detected change event into a data format supported by a target system; detecting and solving data conflicts occurring in the synchronization process; writing the converted data into a target system; and recording a detailed log of the synchronization operation. The problem of low efficiency caused by manual synchronization between the current demand management system and the problem tracking system, and the problem of data deviation caused by operation delay or misoperation caused by the low efficiency are solved. By establishing an automatic synchronization mechanism, the consistency and real-time performance of data between the two systems can be effectively ensured.

Description

Technical Field

[0001] This invention relates to the field of integrated technology of requirements management and issue tracking systems, specifically to a method, apparatus and medium for synchronizing requirements and issues between DOORS and JIRA, applicable to scenarios of cross-platform bidirectional automated synchronization of requirements and issues. Background Technology

[0002] In the development of complex systems, DOORS, as a mainstream requirements management tool, is widely used for requirements definition and tracking, while JIRA, as an agile issue tracking tool, is mainly used for defect management and task allocation. However, since these two systems usually run independently, a series of problems urgently need to be addressed. First, manual synchronization between requirements and issues is required, which is not only inefficient but also prone to data deviations due to operational delays or errors, seriously affecting data consistency. Second, existing one-way mapping tools cannot meet the needs of bidirectional dynamic updates, making it difficult to improve synchronization efficiency. More importantly, there is a lack of automatic arbitration mechanisms for state contradictions and field conflicts between systems, often requiring manual intervention when data inconsistencies occur. In addition, the hierarchical requirements structure adopted by DOORS (such as requirement package-requirement-sub-requirement) differs significantly in format from JIRA's Epic-Story-Task model, making direct mapping extremely difficult. Current solutions based on periodic polling or simple API scripts generally suffer from insufficient real-time performance, susceptibility to recursive events, and excessive API call overhead. Therefore, there is an urgent need to develop an efficient and reliable bidirectional synchronization mechanism to address these pain points. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method, apparatus, and medium for synchronizing requirements and issues between DOORS and JIRA. The technical solution of this invention primarily solves the inefficiency caused by the need for manual synchronization between the current requirements management system and issue tracking system, as well as the data deviation caused by operational delays or errors. By establishing an automated synchronization mechanism, this invention can effectively ensure the consistency and real-time performance of data between the two systems.

[0004] The technical solution of the present invention:

[0005] A method for synchronizing requirements and issues between DOORS and JIRA includes:

[0006] Obtain the mapping rules between JIRA issue fields and DOORS requirement attributes, wherein the mapping rules include: specifying the direction of the mapping, specifying the requirement attributes in DOORS that participate in the mapping, specifying the fields in JIRA that participate in the mapping, defining how to convert the source value into the target value, and specifying the preconditions or exceptions for the mapping to take effect;

[0007] Monitor issue change events in the JIRA system and requirement change events in the DOORS system: Real-time monitoring of issue change events in the JIRA system and requirement change events in the DOORS system; filtering recursive events triggered by the synchronization operation itself using a unique transaction identifier; classifying change events into critical events and non-critical events, with critical events triggering the synchronization process first.

[0008] Convert detected change events into a data format supported by the target system: flatten the hierarchical requirement structure of DOORS into the Epic-Story-Task hierarchy supported by JIRA, and automatically generate parent-child link relationships;

[0009] Detect and resolve data conflicts that occur during synchronization: Perform semantic conflict analysis, and trigger arbitration by the business rule engine when there is a state contradiction between the issue in JIRA and the requirement in DOORS;

[0010] Write the transformed data to the target system: Use JIRA's batch operation API and DOORS's DXL script batch interface to reduce the number of API calls;

[0011] Record detailed logs of synchronization operations: record operation type, timestamp, user ID, and data before and after the change, and support filtering through JQL or DOORS query tools.

[0012] Furthermore, it also includes:

[0013] When a DOORS requirement is marked as "frozen baseline", the corresponding JIRA issue is automatically locked to "uneditable" status to prevent verified requirements from being accidentally modified.

[0014] Furthermore, in the process of detecting and resolving data conflicts that occur during synchronization, semantic conflict analysis is performed using conflict detection algorithms.

[0015] Furthermore, DOORS's hierarchical requirement structure includes requirement packages, requirements, and sub-requirement levels.

[0016] Furthermore, JIRA supports the Epic-Story-Task layer in Epic-Story-Task mode.

[0017] An apparatus for synchronizing JIRA system and DOORS information, comprising:

[0018] The mapping rule configuration module is used to configure the mapping rules between JIRA issue fields and DOORS requirement attributes. The mapping rules include: specifying the direction of the mapping, specifying the requirement attributes in DOORS that participate in the mapping, specifying the fields in JIRA that participate in the mapping, defining how to convert the source value into the target value, and specifying the preconditions or exceptions for the mapping to take effect.

[0019] The event monitoring module is used to monitor issue change events in the JIRA system and requirement change events in the DOORS system in real time. It filters recursive events triggered by the synchronization operation itself through a unique transaction identifier. At the same time, it divides change events into critical events and non-critical events, with critical events triggering the synchronization process first.

[0020] The data format conversion module is used to convert detected change events into data formats supported by the target system, flatten the hierarchical requirement structure of DOORS into a hierarchy supported by JIRA, and automatically generate parent-child link relationships.

[0021] The conflict handling module is used to detect and resolve data conflicts that occur during the synchronization process. It uses a conflict detection algorithm to perform semantic conflict analysis. When there is a state contradiction between the problem in JIRA and the requirement in DOORS, it triggers arbitration by the business rule engine.

[0022] The data synchronization execution module is used to write the transformed data to the target system, using JIRA's batch operation API and DOORS's DXL script batch interface to reduce the number of API calls;

[0023] The log management module records detailed logs of synchronization operations. These logs include the operation type, timestamp, user ID, and data before and after the change. Filtering is supported using JQL or DOORS query tools.

[0024] Furthermore, it also includes:

[0025] The baseline locking linkage module is used to track changes to the "frozen baseline" flag in DOORS requirements in real time. When a frozen baseline is detected, the associated issue is forcibly set to an "uneditable" state via the JIRA state migration API, and field editing permissions are disabled.

[0026] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method.

[0027] The beneficial effects of this invention are:

[0028] This invention achieves automated real-time synchronization between the DOORS requirements management system and the JIRA issue tracking platform by establishing a two-way event triggering mechanism and intelligent mapping rules, effectively solving the problems of low efficiency and poor data consistency in traditional manual synchronization. It employs recursive event filtering and critical event priority processing techniques, combined with the intelligent conversion of hierarchical requirements structures to flattened hierarchies, ensuring the integrity and logical consistency of cross-system data mapping. Through semantic conflict detection algorithms and dynamic arbitration by the business rule engine, it automatically resolves data state contradictions. Combined with batch API interfaces and log tracking mechanisms, it improves synchronization efficiency while reducing system resource consumption, ensuring the stability of verified requirements, and ultimately forming an auditable, full-lifecycle data closed loop. This significantly improves the collaborative accuracy and reliability of requirements and issue management in complex R&D scenarios. Attached Figure Description

[0029] Figure 1 This is a flowchart of the method in an embodiment of the present invention;

[0030] Figure 2 This is a schematic diagram of the device in an embodiment of the present invention;

[0031] Figure 3 This is a schematic diagram of the structure of the medium in an embodiment of the present invention. Detailed Implementation

[0032] The following description of embodiments provides a more detailed explanation of the specific implementation of the present invention, including the shape and structure of each component, the relative positions and connections between the parts, the function and working principle of each part, the manufacturing process, and the operation and use methods, in order to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the concept and technical solution of the present invention.

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. This invention achieves automated real-time synchronization between DOORS and JIRA systems through a bidirectional event triggering mechanism and intelligent mapping rules. Combined with recursive filtering, critical event priority processing, and hierarchical structure conversion technologies, along with semantic conflict arbitration and batch interface optimization, it constructs a closed-loop data system covering the entire lifecycle, significantly improving the accuracy and reliability of cross-platform requirement-problem collaborative management. The specific implementation methods of this invention are described in detail below.

[0034] One embodiment of the present invention provides a first aspect, which provides a method for synchronizing DOORS and JIRA requirements and issues based on bidirectional event triggering, comprising:

[0035] First, establish mapping rules between JIRA issue fields and DOORS requirement attributes. These mapping rules specifically include five aspects: explicitly specifying whether the mapping is bidirectional or unidirectional; listing in detail the requirement attributes in the DOORS system that need to participate in the mapping; determining the corresponding mapping fields in the JIRA system; defining the conversion rules from source system values ​​to target system values; and setting the preconditions and exceptions for the mapping to take effect.

[0036] Secondly, implement change event monitoring for the JIRA and DOORS systems. This monitoring process has the following characteristics: it uses a real-time listening mechanism to capture JIRA issue change events and DOORS requirement change events; it effectively filters recursive events caused by synchronization operations themselves by assigning unique transaction identifiers; and it divides change events into critical events and non-critical events according to business importance, prioritizing the synchronization process of critical events.

[0037] Then, data format conversion is performed. The main feature of this conversion process is that the hierarchical organization of the DOORS system (including requirement packages, requirements, sub-requirements, etc.) is converted into a flat hierarchical structure (Epic-Story-Task mode) supported by the JIRA system, and parent-child links are automatically established and maintained in the process.

[0038] Next, data conflict detection and resolution are performed. When a contradiction is found between the JIRA issue status and the DOORS requirement status, the business rules engine is automatically invoked for arbitration.

[0039] Subsequently, the data write operation is performed. This step achieves efficient data writing by calling the batch operation API interface of the JIRA system and the DOORS system's DXL script batch interface, significantly reducing the number of API calls and improving system performance.

[0040] When a DOORS requirement is marked as "frozen baseline," the corresponding JIRA issue is automatically locked to "uneditable" status to prevent verified requirements from being accidentally modified.

[0041] Finally, a complete logging mechanism is established. This mechanism records detailed information such as the type of each synchronization operation, execution time, operating user, and data content before and after the change, and supports filtering and analysis of logs using the JQL query language or the query tools built into the DOORS system.

[0042] Secondly, the present invention provides an apparatus for synchronizing JIRA system and DOORS information, comprising:

[0043] The mapping rule configuration module is responsible for establishing the mapping relationship between JIRA issue fields and DOORS requirement attributes. Specific functions include: setting the mapping direction (one-way or two-way); determining the requirement attributes in the DOORS system that need to be mapped; specifying the corresponding mapping fields in the JIRA system; defining the conversion rules from source data to target data; and setting the conditions, constraints and exceptions for the mapping to take effect.

[0044] The event monitoring module performs the following monitoring functions: real-time detection of issue change events in the JIRA system and requirement change events in the DOORS system; identification and filtering of recursive events generated by the synchronization operation itself by assigning unique transaction identifiers; and classification of change events into critical and non-critical events based on business priority, ensuring that critical events enter the synchronization process first.

[0045] The data format conversion module's main functions are: converting detected change events into a data format that the target system can recognize; converting the hierarchical requirement structure of DOORS (including requirement packages, requirements, sub-requirements, etc.) into a hierarchical structure (Epic-Story-Task) supported by the JIRA system; and automatically establishing and maintaining parent-child link relationships during the conversion process.

[0046] The conflict handling module is responsible for handling data conflicts during the synchronization process. Specifically, it uses a conflict detection algorithm for semantic analysis and automatically calls a preset business rule engine to make an arbitration decision when a contradiction is found between the JIRA problem status and the DOORS requirement status.

[0047] The data synchronization execution module performs the final data write operation. Its features include: calling the batch operation API interface of the JIRA system; using the DOORS system's DXL script batch interface; and significantly reducing the number of API calls and improving system performance through batch processing.

[0048] The log management module provides complete log recording functionality, including: recording basic information such as the type, timestamp, and user of each synchronization operation; saving detailed data before and after changes; and supporting log retrieval and analysis using JQL query language or the query tools built into the DOORS system.

[0049] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0050] The second embodiment of the present invention provides a method for synchronizing DOORS and JIRA requirements and issues based on bidirectional event triggering, such as... Figure 1 As shown, the feature includes the following steps:

[0051] Step 101: Establish mapping rules between JIRA issue fields and DOORS requirement attributes. These mapping rules specifically include five aspects: explicitly specifying whether the mapping is bidirectional or unidirectional; listing in detail the requirement attributes in the DOORS system that need to participate in the mapping; determining the corresponding mapping fields in the JIRA system; defining the conversion rules from source system values ​​to target system values; and setting the preconditions and exceptions for the mapping to take effect.

[0052] Step 102: Implement change event monitoring for the JIRA and DOORS systems according to the mapping rules. A real-time monitoring mechanism is used to capture JIRA issue change events and DOORS requirement change events; recursive events triggered by synchronization operations themselves are effectively filtered by assigning unique transaction identifiers; simultaneously, change events are divided into critical and non-critical events based on business importance, and the synchronization process of critical events is processed first.

[0053] Step 103: Perform data format conversion. The main feature of this conversion process is that it converts the hierarchical organization of the DOORS system (including requirement packages, requirements, sub-requirements, etc.) into a flat hierarchical structure (Epic-Story-Task mode) supported by the JIRA system, and automatically establishes and maintains parent-child link relationships during this process.

[0054] Step 104: Perform data conflict detection and resolution. This step uses a conflict detection algorithm to perform semantic analysis on the data. When a conflict is found between the JIRA issue status and the DOORS requirement status, the business rule engine is automatically invoked for arbitration.

[0055] Step 105: Perform data write operation. This step achieves efficient data writing by calling the batch operation API interface of the JIRA system and the DOORS system's DXL script batch interface, significantly reducing the number of API calls and improving system performance.

[0056] Step 106: Establish a complete logging mechanism. This mechanism records detailed information such as the type of each synchronization operation, execution time, operating user, and data content before and after the change. It also supports filtering and analysis of logs using the JQL query language or the query tools built into the DOORS system.

[0057] Specifically, when a DOORS requirement is marked as "frozen baseline," the corresponding JIRA issue is automatically locked to "uneditable" status to prevent verified requirements from being accidentally modified.

[0058] The present invention also provides an apparatus for synchronizing JIRA system and DOORS information. For example... Figure 2As shown, this device achieves cross-platform data mapping, event monitoring, format conversion, conflict arbitration, and batch synchronization through six functional modules, enabling bidirectional information synchronization between JIRA and DOORS systems. Its core innovation lies in employing a recursive event filtering mechanism to prevent synchronization loops, using semantic analysis algorithms to automatically resolve state contradictions, and significantly improving the efficiency of data interaction between systems through batch interface optimization.

[0059] The mapping rule configuration module serves as the central hub for cross-system data linkage, managing the dynamic mapping of JIRA and DOORS field attributes. Through a visual configuration interface, it supports bidirectional or unidirectional synchronization strategies, allowing users to select elements to be synchronized from the DOORS attribute library and associate them with the corresponding field containers in JIRA. The built-in transformation rule engine supports 18 data transformation logics, including regular expression matching and data type conversion. It also allows configuration of conditional constraint rules (such as version range restrictions and user permission filtering) and supports setting synchronization exception lists for specific scenarios. This module automatically detects field compatibility through semantic parsing technology, reducing the error rate of manual configuration.

[0060] The event monitoring module employs a distributed event bus architecture to capture change event streams from JIRA and DOORS in real time. It generates unique transaction identifiers using an event fingerprint algorithm, effectively identifying and filtering recursive events generated by the system's own synchronization operations. The event priority evaluation engine, combined with a business impact factor matrix (such as associated use case coverage and project critical path markers), classifies events into four levels, P0-P3. P0-level events (such as blocking issues triggered by requirement state changes) will trigger a real-time synchronization queue preemption mechanism. The event buffer pool uses a dynamic time window adjustment strategy, automatically reducing the processing frequency of non-critical events during periods of high system load.

[0061] The data format conversion module introduces a structured adaptation layer to convert DOORS's multi-level requirement tree (package-requirement-sub-requirement) into JIRA's Epic-Story-Task 3D model. During the conversion process, context-aware technology is employed to automatically identify dependencies between requirements and reconstruct parent-child links. Simultaneously, a semantic compensation algorithm fills in metadata lost due to system differences (such as mapping DOORS's validation status to JIRA custom tags). For complex requirement structures, the module supports intelligent chunking, balancing data granularity and contextual integrity through a sliding window mechanism to avoid information fragmentation.

[0062] The conflict handling module constructs a multi-dimensional conflict detection system, employing semantic graph comparison technology to analyze the logical consistency between JIRA issue status and DOORS requirement status. When a version conflict is detected (e.g., a JIRA issue has been closed but a DOORS requirement is still in the verification phase), a triple arbitration mechanism is activated: first, a pre-built rule base (containing 237 industry-standard rules) is invoked; second, a machine learning model is launched to predict the optimal solution; and finally, any remaining complex conflicts are pushed to a manual approval queue. The module's built-in conflict case library supports post-event root cause analysis and rule self-optimization.

[0063] The data synchronization execution module employs a batch asynchronous processing architecture to optimize system performance. It uses a JIRA batch API aggregator to compress single operations into multi-object transaction packages, reducing the number of interface calls by 90%. The DOORS side integrates the DXL script engine, supporting atomic batch updates of required attributes. The module is equipped with an intelligent retry mechanism, employing an exponential backoff strategy for network anomalies and ensuring data consistency through transaction log rollback. The performance monitoring dashboard displays 12 core metrics in real time, including synchronization throughput and latency.

[0064] The log management module enables end-to-end auditing and tracing, employing a dual storage mode of binary and structured logs. Log entries contain 53 dimensions of information, including operation fingerprints (user ID, terminal IP), data mirror snapshots (JSON difference before and after changes), and performance metrics. It supports multimodal query methods, allowing nested conditional searches via JQL syntax or graphical analysis using native DOORS tools. The log analysis engine incorporates 20 anomaly pattern recognition rules, automatically triggering security alerts and operation backtracking.

[0065] This invention also provides a computer-readable storage medium, such as... Figure 3 As shown, the computer-readable storage medium stores a computer program that performs the above-described method. When executed by a processor, this computer program implements the aforementioned task management method for the JIRA system. The computer program stored thereon enables intelligent bidirectional synchronization between the DOORS and JIRA systems. Through core functional modules such as dynamic mapping management, real-time event monitoring, intelligent data conversion, automatic conflict arbitration, and batch synchronization optimization, the program achieves accurate synchronization and consistency maintenance of cross-platform requirement-problem data. It also possesses end-to-end monitoring, fault tolerance and self-healing capabilities, and elastic scalability, significantly improving the efficiency and reliability of data collaboration between systems. The storage medium employs a high-reliability solution to ensure the stability of program operation and data security.

[0066] These computer program instructions can be loaded into a computer or other programmable data processing device for execution. By implementing the program-defined operation flow on the device, the computer achieves automated processing functions. Specifically, when the program runs on the device, it will automatically execute a preset sequence of instructions, thereby fully realizing the functions of each link in the flowchart described in this patent, as well as the operation steps defined in each module of the block diagram.

[0067] It should be noted that the above embodiments are merely illustrative examples of the present invention, intended to help understand the technical solution and core ideas of the present invention. Those skilled in the art should understand that any modifications, equivalent substitutions, or improvements made based on the concept of the present invention without departing from its principles should be considered within the scope of protection of the present invention, and the specific scope of protection is determined by the claims.

Claims

1. A method for synchronizing requirements and issues between DOORS and JIRA, characterized in that, include: Obtain the mapping rules between JIRA issue fields and DOORS requirement attributes, wherein the mapping rules include: specifying the direction of the mapping, specifying the requirement attributes in DOORS that participate in the mapping, specifying the fields in JIRA that participate in the mapping, defining how to convert the source value into the target value, and specifying the preconditions or exceptions for the mapping to take effect; Monitor issue change events in the JIRA system and requirement change events in the DOORS system: Real-time monitoring of issue change events in the JIRA system and requirement change events in the DOORS system; filtering recursive events triggered by the synchronization operation itself using a unique transaction identifier; classifying change events into critical events and non-critical events, with critical events triggering the synchronization process first. Convert detected change events into a data format supported by the target system: flatten the hierarchical requirement structure of DOORS into the Epic-Story-Task hierarchy supported by JIRA, and automatically generate parent-child link relationships; Detect and resolve data conflicts that occur during synchronization: Perform semantic conflict analysis, and trigger arbitration by the business rule engine when there is a state contradiction between the issue in JIRA and the requirement in DOORS; Write the transformed data to the target system: Use JIRA's batch operation API and DOORS's DXL script batch interface to reduce the number of API calls; Record detailed logs of synchronization operations: record operation type, timestamp, user ID, and data before and after the change, and support filtering through JQL or DOORS query tools.

2. The method as described in claim 1, characterized in that, Also includes: When a DOORS requirement is marked as "frozen baseline", the corresponding JIRA issue is automatically locked to "uneditable" status to prevent verified requirements from being accidentally modified.

3. The method as described in claim 1, characterized in that, In the process of detecting and resolving data conflicts that occur during synchronization, semantic conflict analysis is performed using conflict detection algorithms.

4. The method as described in claim 1, characterized in that, DOORS's hierarchical requirement structure includes requirement packages, requirements, and sub-requirement levels.

5. The method as described in claim 1, characterized in that, JIRA supports the Epic-Story-Task hierarchy in Epic-Story-Task mode.

6. An apparatus for synchronizing JIRA system and DOORS information, characterized in that, include: The mapping rule configuration module is used to configure the mapping rules between JIRA issue fields and DOORS requirement attributes. The mapping rules include: specifying the direction of the mapping, specifying the requirement attributes in DOORS that participate in the mapping, specifying the fields in JIRA that participate in the mapping, defining how to convert the source value into the target value, and specifying the preconditions or exceptions for the mapping to take effect. The event monitoring module is used to monitor issue change events in the JIRA system and requirement change events in the DOORS system in real time. It filters recursive events triggered by the synchronization operation itself through a unique transaction identifier. At the same time, it divides change events into critical events and non-critical events, with critical events triggering the synchronization process first. The data format conversion module is used to convert detected change events into data formats supported by the target system, flatten the hierarchical requirement structure of DOORS into a hierarchy supported by JIRA, and automatically generate parent-child link relationships. The conflict handling module is used to detect and resolve data conflicts that occur during the synchronization process. It uses a conflict detection algorithm to perform semantic conflict analysis. When there is a state contradiction between the problem in JIRA and the requirement in DOORS, it triggers arbitration by the business rule engine. The data synchronization execution module is used to write the transformed data to the target system, using JIRA's batch operation API and DOORS's DXL script batch interface to reduce the number of API calls; The log management module is used to record detailed logs of synchronization operations. The detailed logs include operation type, timestamp, user ID, and data before and after the change; it supports filtering through JQL or DOORS query tools.

7. The apparatus for synchronizing JIRA system and DOORS information as described in claim 6, characterized in that, Also includes: The baseline locking linkage module is used to track changes to the "frozen baseline" flag in DOORS requirements in real time. When a frozen baseline is detected, the associated issue is forcibly set to an "uneditable" state via the JIRA state migration API, and field editing permissions are disabled.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 5.

Images