Demand entry control method and system

Abstract

The invention relates to a demand entry control method and system. The method comprises the following steps: step S1, demand compilation and structured export; s2, platform entry control is carried out; and S3, performing DOORS entry editing permission control. Through entry-level authority control and a precise change operation mechanism, the problem of data islands is effectively solved, fine processing of a single demand entry is supported, the method has the advantages of improving the fine level of demand management, enhancing the data collaboration capability, optimizing the change control process and the like, the limitation that DOORS data can only be stored in a local server is broken, and the demand management efficiency is improved. An interconnection mechanism between the DOORS client and the product data management platform is established, so that fine control and rapid iterative updating of the demand items are realized, operations such as tree-shaped display, batch signing and auditing, version raising and release freezing of the demand items are supported, and the automation degree and the control efficiency of demand change processing are greatly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of product lifecycle control, and particularly relates to a demand item control method and system. BACKGROUND

[0002] The development of PLM (Product Lifecycle Management) system, especially in the field of aerospace, PLM platform has been widely used, and the technology has become mature.

[0003] Currently, the demand control tool based on DOORS mainly generates text, and the DOORS tool saves the demand items in WORD documents on the data control platform, which plays an important role in sharing data and decision support. However, the change of demand items requires changing the entire document, which does not meet the current control requirements. With the development of technology and the continuous refinement of control, the control mode with text as the carrier cannot meet the current product data control requirements.

[0004] However, the current demand control mode based on DOORS has the following significant defects: On the one hand, demand data is mainly stored in the form of text in the DOORS server end, forming a single storage architecture, which not only increases the risk of data loss or damage, but also hinders the effective transmission of demand information to downstream design, testing and other links, and is difficult to meet the demand of product lifecycle data collaborative management.

[0005] On the other hand, the demand change control still stays at the file level operation level, when the demand item is modified, the entire document must be updated, and the independent processing of single item cannot be realized. This extensive control mode leads to low change efficiency, chaotic version control, and cannot adapt to the increasingly refined demand control requirements. For example, in the DOORS system, the editing permission of demand items is usually controlled in units of documents, lacking access permission setting mechanism for single item, making it easy to appear editing conflict or data covering problem when multiple users collaborate. At the same time, the demand change process lacks systematic change impact analysis and related party identification ability, it is difficult to accurately evaluate the spread range of item modification to downstream links, further increasing the control complexity.

[0006] In summary, the demand data is long-term limited to the single text storage mode of the DOORS server side, forming a highly centralized data island, which not only significantly increases the probability of accidental loss or physical damage of data, but also seriously hinders the real-time flow and dynamic interaction of demand information to the downstream links such as design and testing, resulting in low data collaboration efficiency in each stage of the product life cycle, and it is difficult to build a unified and coherent data management chain. More prominent is that the demand change mechanism still adheres to the file-level operation paradigm. When a single demand item needs to be adjusted, the entire document must be updated, and precise processing of individual items cannot be achieved. This extensive management leads to multiple derivative problems: long change response cycle, difficulty in tracing historical versions, frequent editing conflicts and data coverage in multi-user collaboration scenarios. The root cause is that, at the permission control level, the DOORS system only supports document-level access management, lacking the ability to configure fine-grained permissions for individual demand items, such as differentiating exclusive editing, shared editing, or read-only access, etc., resulting in rigid permission allocation when teams collaborate. At the same time, the change process lacks a systematic correlation impact assessment mechanism. When a specific demand item is modified, it cannot automatically identify its dependency relationship with upstream and downstream items and the potential scope of impact, leading to missed notifications and improper sign-off process design, further amplifying the complexity and uncertainty of change implementation. With the exponential growth of modern product complexity, the industry's demand for fine-grained control of demand items is increasingly prominent, including item-level permission dynamic management, multi-end distributed storage architecture, and closed-loop precise execution of the change process. However, the existing technical framework has obvious gaps in these key dimensions, severely restricting the reliability, flexibility, and overall efficiency of demand control.

[0007] With the increasing complexity of products, the industry's demand for fine-grained control of demand items is increasingly urgent, and the existing technology cannot support fine-grained permission control, multi-end data storage, and precise execution of the change process at the item level, severely restricting the efficiency and reliability of demand control.

[0008] In view of the above problems, the existing technology needs to be improved. SUMMARY

[0009] In view of the above defects of the prior art, the first aspect of the present application provides a demand item control method, comprising the following steps: Step S1: demand preparation and structured export; wherein the demand items are created and the content is prepared in the DOORS system, and the item-level access permissions are set for the demand items; then, the XML generation interface of DOORS is called through the data interaction middleware, and the demand item information is exported to an XML file according to a preset data format, and the XML file is stored in a preset shared resource path; Step S2: platformization entry control; wherein the product data management platform reads and parses the XML file, stores the parsed requirement entry in a tree structure in a requirement entry library, and sets the initial state of the entry to "in work"; Step S3: DOORS entry editing permission control; wherein, through the cooperation of the product data management platform and the data interaction middleware, at least one of the following control operations is performed on the requirement entry in the DOORS system: Data synchronization operation: in response to the synchronization request of the product data management platform, the middleware drives the DOORS system to package and upload the requirement data, and then the platform acquires, parses and online displays the data; Influence analysis operation: in response to the influence analysis request of the product data management platform, the middleware calls the entry influence analysis method of the DOORS system to obtain the association relationship information of the entry, so as to create the countersigning process in the platform; Document publishing operation: in response to the document publishing instruction of the product data management platform, the middleware drives the DOORS system to perform locking operation on all entries of the specified document, and changes its state to "published"; Entry change operation: in response to the entry change process initiated by the product data management platform, the middleware drives the DOORS system to perform locking or unlocking operation on the specific entry, and triggers data synchronization after the change is completed, so that the platform acquires and displays the latest data.

[0010] In the requirement entry control method as described above, optionally, in the step S1, the entry-level access permission includes exclusive editing permission, shared editing permission and read-only access permission, and the corresponding permission control is realized by adding or deleting user accounts in the DOORS entry attribute, thereby supporting the editing and freezing control of a single entry; the content of the XML file at least includes DOORS requirement module name, requirement text and requirement attribute.

[0011] In the requirement entry control method as described above, optionally, the text information of the requirement entry is stored in the XML file; the formula, table and picture rich text information in the requirement entry are stored in the data packet in the form of pictures; the introduced picture name is marked in the XML file.

[0012] In the requirement entry control method as described above, optionally, in the step S2, storing the parsed requirement entry in a tree structure in a requirement entry library includes the following steps: According to the hierarchical relationship between the parsed requirement entries, a tree logical structure corresponding to the hierarchical relationship is constructed in the product data management platform; Attribute information corresponding to the requirement entry is stored and displayed in the node of the tree structure, and the attribute information at least includes basic information of a title, a version, an entry type, an entry state and entry owner information.

[0013] In the requirement entry control method as described above, optionally, in the step S1, the XML generation interface of DOORS is called through the data interaction middleware, specifically as follows: an exportRichTextModule interface provided by the middleware is called.

[0014] In the requirement entry control method as described above, optionally, in the step S1, a unique requirement number reqID is defined for each requirement entry.

[0015] In the requirement entry control method as described above, optionally, in the step S3, the data synchronization operation specifically includes: The product data management platform sends a synchronization request to the middleware; The middleware calls a DOORS synchronization interface; The DOORS system packs requirement data and uploads to a preset shared resource path; The product data management platform obtains the data package, parses the data and stores in the platform database; The product data management platform reads the data package parsing result and performs online display.

[0016] In the requirement entry control method as described above, optionally, in the step S3, the impact analysis operation specifically includes: The product data management platform sends a related party impact analysis request; The middleware parses the platform message to obtain the reqID number of the requirement entry; The middleware calls a moduleImpactAnalysisWithDetail interface; The upper and lower associated team names of the entry are obtained; The product data management platform creates a countersigning object according to the obtained associated team name.

[0017] In the requirement entry control method as described above, optionally, the data interaction middleware is also used for monitoring and recording the instruction execution of the DOORS system, including interface calling, parameter passing and execution result feedback.

[0018] In order to achieve the above purpose, the second aspect of the present application provides a requirement entry control system, wherein the requirement entry control method as described in any one of the first aspects is used, including: a DOORS subsystem, a product data management platform subsystem and a data interaction middleware integrated and running; The DOORS subsystem is a DOORS editing tool deployed on a DOORS server and a user client, and is used to provide creation, editing and entry-level permission control functions of requirement entries; in response to instructions from the data interaction middleware, lock and unlock operations on specific requirement entries are performed; in response to instructions from the data interaction middleware or the local client, a structured data file containing requirement entry information is generated and exported; The product data management platform subsystem is deployed on a product data control server and includes a WEB-side requirement entry display processing module, which is used to read and parse the structured data file, store requirement data in an entry form, and provide tree structure display; provide process control functions of requirement change requests and requirement change notifications; in response to changes in process states, lock or unlock instructions for specific requirement entries are sent to the data interaction middleware; The data interaction middleware, as a bridge connecting the DOORS subsystem and the product data management platform subsystem, is used to receive instructions from the product data management platform subsystem and call corresponding interfaces provided by the DOORS subsystem to perform operations; call interfaces of the DOORS subsystem to drive generation and export of the structured data file; return result states of instruction execution to the product data management platform subsystem.

[0019] The requirement entry control method and system provided by the application effectively solve the data island problem and support fine processing of a single requirement entry through entry-level permission control and precise change operation mechanisms, and have the advantages of improving the fine level of requirement management, enhancing data collaboration capability, optimizing change control processes and the like.

[0020] The concept, specific structure and technical effects of the application will be further described below with reference to the accompanying drawings, so as to fully understand the purposes, features and effects of the application. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 is a flowchart of an embodiment of the requirement entry control method provided by the application; Figure 2 is a schematic diagram of middleware interface calling. DETAILED DESCRIPTION

[0022] In order to make the technical means, creative features, purposes and effects of the application easy to understand, the application will be further described below in combination with specific drawings. However, the application is not limited to the following embodiments.

[0023] It is to be understood that the structures, proportions, sizes, etc. shown in the drawings accompanying the present specification are merely intended to facilitate the understanding of the content disclosed by the present specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present application can be implemented, and therefore do not have technical significance. Any modification of the structure, change of the proportional relationship or adjustment of the size, without affecting the effects that can be achieved by the present application and the purposes that can be achieved, should still fall within the scope of the technical content disclosed by the present application.

[0024] In the traditional requirement control practice, the file-level storage mechanism based on the DOORS tool causes the requirement entry change to update the entire document, resulting in the change granularity cannot be refined to the single entry level. The problem is caused by the requirement data stored in the form of unstructured text on the DOORS server side, which lacks entry-level independent operation capability, so that the change process involves forced locking and synchronization of irrelevant entries, significantly reducing the efficiency of requirement control. At the same time, the single data storage architecture hinders the cross-system transmission of requirement information in each stage of the product life cycle, cannot meet the technical requirements of the PLM platform for multi-end storage and fine control of data, and thus affects the accuracy of requirement changes and the consistency of data between systems.

[0025] For example, in the development process of a certain type of aircraft in the aerospace field, the requirement document contains thousands of interrelated requirement entries. When a certain aerodynamic performance requirement entry needs to be adjusted, the existing control method requires engineers to change the entire requirement document. In this scenario, the file-level change mechanism causes other irrelevant functional requirement entries to be accidentally locked, making it impossible for downstream design teams to access valid data simultaneously, and the change history can only be recorded in the form of the overall version of the document, making it impossible to trace the modification track of a specific entry. The lack of entry-level access rights causes editing conflicts when multiple teams work together, and information gaps occur when requirement data is transmitted between the DOORS server and downstream simulation tools, causing the requirement state to deviate from the actual design state.

[0026] If the above problems are not solved, requirement data control will face the risk of missing entry-level change capability. The requirement change process generates redundant steps due to file-level operations, increasing the likelihood of data inconsistency, which in turn causes a chain of errors in downstream design. The single data storage architecture makes the requirement information vulnerable to loss in the event of system failure, and the lack of entry-level permission control will lead to a loss of control over the change process, affecting the reliability and traceability of the entire product development process, and ultimately hindering the realization of the product life cycle control goal.

[0027] To this end, the present application proposes a requirement entry control method, which, as shown in Figure 1 may specifically include the following steps: Step S1: Requirement compilation and structured export.

[0028] In step S1, the requirement entry is subjected to structure tree creation and content compilation in the DOORS system, and entry-level access permission is set for the requirement entry. Then, the XML generation interface of DOORS is called through the data interaction middleware, and the requirement entry information is exported into an XML file according to a preset data format, and the XML file is stored in a preset shared resource path.

[0029] In this step, a unique requirement number reqID is defined for each requirement entry. The requirement number reqID refers to a unique identifier assigned to each requirement entry, which can be implemented by a numerical sequence, a UUID, or a string generated by a hash algorithm, and the purpose is to ensure that the requirement entry has an irreplaceable identity in the entire control process, facilitating accurate tracking and independent management across systems, and avoiding operation ambiguity caused by repeated or ambiguous identification.

[0030] By defining a unique requirement number reqID for each requirement entry in the initial stage of requirement compilation, the identifier is used to accurately operate a specific entry in the subsequent platformized entry control and DOORS entry editing permission control process; the reqID defined in step S1 is contained in the XML file, stored in the requirement entry library after being parsed by the product data management platform in subsequent step S2, and used as a key parameter to specify the target entry in response to data synchronization, impact analysis, document release, and entry change operations in subsequent step S3, thereby realizing the transition from document-level operation to entry-level operation, and effectively avoiding operation errors caused by ambiguous identification.

[0031] In this embodiment, the XML generation interface of DOORS is called through the data interaction middleware, specifically by calling the exportRichTextModule interface provided by the middleware. The exportRichTextModule interface can be understood as a data interaction middleware designed for rich text content export function module, which can convert elements such as formulas, tables, or pictures into independent resource files or embedded coding formats, thereby ensuring the structural integrity and parseability of complex content in the requirement entry during the export process, and the purpose is to solve the technical limitation that the general interface cannot adapt to diversified rich text elements.

[0032] The scheme can actively identify the rich text content in the requirement entry and perform targeted conversion processing by specifying the call of the exportRichTextModule interface in the requirement preparation and structured export stage, convert the non-text elements into standardized resources that can be referenced by the XML file, while retaining the association between the text information and the resource identifier, thereby ensuring the integrity and consistency of the exported data, and providing a reliable data basis for the subsequent analysis of the XML file by the product data management platform, the construction of the tree-shaped logical structure, and the execution of entry-level permission control.

[0033] In actual application, in some embodiments of the application, specific implementation of entry-level access permission and specification of XML file content are proposed to support fine change control of requirement entries. However, in the implementation process, due to the lack of detailed definition of the permission control mechanism and the lack of explicit specification of the XML data format, it is impossible to realize independent editing and freezing operation of a single entry, and the completeness of the exported data is insufficient, which affects the accuracy during multi-terminal storage and the reliability of subsequent platform analysis.

[0034] To this end, the application further proposes that in step S1, the entry-level access permission can include exclusive editing permission, shared editing permission, and read-only access permission, and the corresponding permission control is realized by adding or deleting user accounts in the DOORS entry attribute, thereby supporting editing and freezing control of a single entry. The content of the XML file at least includes the DOORS requirement module name, the requirement text, and the requirement attribute.

[0035] The entry-level access permission refers to a fine-grained permission control mechanism set for a single requirement entry, and the purpose is to accurately allocate the operation range according to the user role to avoid the defect of change of the entire document in the traditional file-level control. The permission control can be realized by adding or deleting user accounts in the DOORS entry attribute, which can be understood as dynamically adjusting the permission by using the built-in attribute control function of the DOORS system without the intervention of additional tools. The purpose is to ensure that the editing and freezing state of a single entry takes effect immediately, thereby supporting real-time collaboration and isolation requirements during the change process.

[0036] As a specific embodiment, the scheme of the application is implemented as follows: when creating a requirement entry in the DOORS system, the system controller can assign exclusive editing permission to a specific user account in the entry attribute, so that the user can independently edit the entry without affecting the state of other entries; when exporting the XML file, the system automatically generates structured data containing the requirement module name "flight control system", the requirement text "the system should have an automatic driving function", and the requirement attribute "safety level: high". The product data management platform analyzes and stores the data as a tree-shaped structure node according to the above information, and the attribute information is displayed on the platform interface for user viewing.

[0037] Through the above scheme, the present application realizes independent editing and frozen control of a single requirement item, ensures the structured integrity of XML exported data, improves the accuracy of multi-end storage and the reliability of product data management platform analysis, thereby effectively supporting the fine execution of requirement items in the change process.

[0038] Further, in this step, the middleware calls the exportRichTextModule interface to package the requirement file, stores the text information of the requirement item in the XML file, and stores the formula, table, and picture rich text information in the requirement item in the data packet in the form of a picture, and marks the introduced picture name in the XML file.

[0039] Specifically, storing the text information of the requirement item in the XML file means storing the pure text content in a structured tag form, which can be implemented by using a standard XML Schema definition, and the purpose is to avoid redundancy interference through a lightweight data structure and provide an efficient analysis mechanism for the basic attribute management of the requirement item. Storing the formula, table, and picture rich text information in the requirement item in the data packet in the form of a picture can be understood as converting non-text elements into independent image files and encapsulating them, which can be implemented in PNG or JPEG format, and the purpose is to avoid the compatibility limitation of XML parsers on complex formats and prevent file expansion and format distortion. In actual application, marking the introduced picture name in the XML file means embedding a reference identifier for the picture resource in the XML document, which can be implemented by using an img tag or a custom attribute, and the purpose is to establish an association path between the text content and external resources and ensure accurate positioning of resources in the display stage.

[0040] This step separates the processing of text information and rich text information, first stores the text content of the requirement item in the XML file in a structured tag form, efficiently carries pure text data by using the hierarchical advantage of XML; at the same time, converts formula, table, and picture rich text elements into picture format and stores them in an independent data packet, avoiding the structural expansion of the XML file due to the embedding of complex content; finally, establishes a reference relationship by marking the picture name in the XML file, so that corresponding picture resources can be loaded from the data packet according to the reference identifier in the analysis stage, thereby completely restoring the original presentation effect of the requirement item in the platform display, ensuring the integrity and consistency of the data in the export, transmission, and analysis links.

[0041] In the present application, the data interaction middleware is also used for monitoring and recording the instruction execution of the DOORS system, including interface calling, parameter passing, and execution result feedback.

[0042] In practical applications, monitoring and recording instruction execution refers to systematic capture and persistent storage of the interaction process between the middleware and the DOORS system, which can be implemented using a distributed log framework or an event trace mechanism, aiming to build a complete operation trace chain. Among them, interface calling refers to recording the identification information of the specific function interface of the DOORS system triggered by the middleware, which can be registered using the unique name or function code of the interface, aiming to clarify the operation path and system dependency relationship; parameter passing refers to saving the structured content of the input data during instruction execution, which can be stored in the form of key-value pair serialization or binary snapshot, aiming to ensure the accuracy and consistency of data transmission; execution result feedback refers to capturing the state information after the completion of instruction execution, which can be recorded in the form of state code enumeration or result summary, aiming to confirm the operation effectiveness immediately and support exception diagnosis.

[0043] The scheme of the present application implements closed-loop monitoring in the whole cycle of instruction flow through data interaction middleware. When receiving the control instruction of the product data management platform, the interface calling information is first recorded to identify the operation type, then the input data content is captured in the parameter passing stage, and finally the result feedback state is obtained synchronously after the completion of instruction execution. These records are stored in association and form a time-sequenced operation track, so that the trigger condition, execution process and final state of each instruction are completely captured, thereby upgrading the middleware from a simple instruction forwarding channel to a key node with process perception capability, effectively ensuring the visibility and controllability of the operation process.

[0044] As shown in Figure 2 , the data interaction middleware is a bridge connecting DOORS and external platforms, receiving and sending instructions pushed by the data management platform, and calling the interfaces of DOORS according to the instructions, such as data synchronization, entry-level changes, and obtaining entry related parties.

[0045] Step S2: Platformized entry control.

[0046] In step S2, the product data management platform reads and parses the XML file, stores the parsed requirement entry in a tree structure in the requirement entry library, and sets the initial state of the entry to "in work".

[0047] Further, in step S2, storing the parsed requirement entry in a tree structure in the requirement entry library can specifically include the following steps: According to the hierarchical relationship between the parsed demand items, a tree-shaped logical structure corresponding to the hierarchical relationship is constructed in the product data management platform. Among them, the construction of the tree-shaped logical structure means generating a visual tree view according to the hierarchical relationship between the demand items, which can be realized by recursively parsing the parent-child node identifiers in the XML file, and the purpose is to ensure that the logical structure in the product data management platform strictly follows the original hierarchy exported by the DOORS system, avoiding structural deviation.

[0048] The attribute information corresponding to the demand items is stored and displayed in the nodes of the tree structure. Among them, the attribute information can include title, version, item type, item state and item owner information, etc. Storing and displaying attribute information means embedding key metadata in tree nodes, which can dynamically combine title, version, item type, item state and item owner information for presentation, which can be completed through database field mapping or front-end rendering technology in specific implementation, and the purpose is to provide complete context identification for each demand item, support state monitoring and responsibility tracing.

[0049] Specifically, the scheme of the present application works through the dual mechanism of constructing tree-shaped logical structure and storing attribute information: in the data analysis stage, the system dynamically generates a tree view according to the hierarchical relationship implied in the XML file, ensuring that the node topology in the product data management platform is consistent with the original demand structure. In the node control link, the embedding of attribute information makes each demand item have traceable metadata, including real-time state and version history. This operation logic enables the system to accurately identify the dependency relationship between demand items, providing reliable topological basis for change impact analysis, while supporting dynamic tracking of item state, thereby effectively solving the problems of structural distortion and information loss.

[0050] Step S3: DOORS item editing permission control.

[0051] In step S3, through the cooperation of the product data management platform and the data interaction middleware, the following at least one control operation is performed on the demand items in the DOORS system: Data synchronization operation: in response to the synchronization request of the product data management platform, the middleware drives the DOORS system to package demand data and upload, and then the platform obtains, parses and online displays.

[0052] Impact analysis operation: in response to the impact analysis request of the product data management platform, the middleware calls the item impact analysis method of the DOORS system to obtain the correlation relationship information of the item, which is provided for the platform to create the review process.

[0053] Document publishing operation: in response to the document publishing instruction of the product data management platform, the middleware drives the DOORS system to perform a lock operation on all items of the specified document, and changes its state to "published".

[0054] Item change operation: in response to the item change process initiated by the product data management platform, the middleware drives the DOORS system to perform locking or unlocking operation on specific items, and triggers data synchronization after the change is completed, so that the platform obtains and displays the latest data.

[0055] Among them, in the DOORS item editing permission control link, the product data management platform and the data interaction middleware cooperatively perform various control operations. Specifically, when the platform initiates a data synchronization request, the middleware drives the DOORS system to package the required data and upload it to the shared resource path, and the platform immediately obtains, parses and displays the data online, ensuring real-time data consistency; in the impact analysis operation, the middleware calls the item impact analysis method of the DOORS system to obtain the association information of the item, and provides basis for the platform to create the concurrence process; the document release operation is driven by the middleware in response to the platform instruction, and the DOORS system performs locking operation on all items of the specified document, and changes its state to "released"; the item change operation is driven by the middleware in response to the change process initiated by the platform, and the DOORS system performs locking or unlocking operation on specific items, and triggers data synchronization after the change is completed, so that the platform obtains and displays the latest data. For example, in the actual execution of the item change operation, when the product data management platform detects a requirement item modification request, the data interaction middleware immediately drives the DOORS system to lock the specific item to prevent other users from editing at the same time, and after the change is confirmed, the data synchronization mechanism is automatically triggered to return the updated item information to the platform through the XML file, so as to realize the independent processing of a single item without updating the entire document.

[0056] In an optional embodiment, the impact analysis operation can specifically include: The product data management platform sends a related party impact analysis request. The product data management platform initiates an instruction signal for triggering the requirement item association relationship query, which can be realized in the form of a structured data packet containing requirement change context information, aiming to clearly analyze the target and deliver the change background.

[0057] The middleware parses the platform message to obtain the reqID number of the requirement item.

[0058] The middleware calls the moduleImpactAnalysisWithDetail interface, which can be realized by a remote procedure call protocol supporting reqID parameter input, aiming to directly obtain the fine-grained association data of specific items.

[0059] Obtain the upper and lower associated team name of the entry. Among them, the associated team name refers to the development or verification team identifier which has an upper and lower binding relationship with the requirement entry, which can be realized by using the team code or name string in the organization structure database, and the purpose is to realize the accurate mapping of the entry to the team.

[0060] The product data management platform creates a sign object according to the obtained associated team name. Among them, the sign object refers to a set of related parties who need to participate in decision-making in the requirement change process, which can be realized by using the team role template preset in the platform or the dynamically generated approval chain, and the purpose is to ensure that the change influence range is fully covered.

[0061] Specifically, the scheme of the embodiment starts the process by sending a related party impact analysis request by the product data management platform, which carries the context information of the requirement change, providing a clear target for subsequent analysis; the middleware receives the request and parses the reqID number of the requirement entry, uses the unique identifier as the core link to avoid analysis deviation caused by fuzzy entry positioning in traditional document-level operation; when the middleware calls the moduleImpactAnalysisWithDetail interface, the reqID number is passed to the DOORS system as an input parameter, triggering a deep association query for a specific entry, overcoming the defect that the general interface cannot efficiently handle entry-level relationships; the DOORS system returns the upper and lower associated team name of the entry based on the reqID number, realizing fine-grained mapping from the requirement entry to the team entity, avoiding redundant data generated by full-text scanning; the product data management platform automatically creates a sign object according to the obtained associated team name, converts accurate team information into a structured approval process, and ensures that all related parties are systematically included in the decision-making process. The above steps form a closed-loop logic chain, taking the reqID number as the key hub, realizing the whole-link precise control from request triggering to sign creation.

[0062] In an optional embodiment, the data synchronization operation can specifically include: The product data management platform sends a synchronization request to the middleware, i.e. the platform initiates a trigger instruction for data synchronization, which can be realized by using a message queue or a RESTful API mechanism, and the purpose is to ensure the timely start and controllability of the synchronization operation.

[0063] The middleware calls the DOORS synchronization interface. The middleware calls the data synchronization service interface provided by the DOORS system as a standardized communication bridge, which can be realized by using the DOORS native API or the encapsulated adaptive interface, and the purpose is to ensure the accuracy and system compatibility of instruction transmission.

[0064] The DOORS system packages the requirement data and uploads to a preset shared resource path. The preset shared resource path can be a network file system shared directory or a cloud storage bucket path, aiming to provide a unified and reliable data transmission transfer site.

[0065] The product data management platform acquires the data package, parses the data and stores in the platform database. In this step, the platform reads the structured data from the shared path and completes the format conversion and persistence, which can be realized by using an XML parser or a JSON processor, aiming to ensure the integrity conversion and efficient storage of the data.

[0066] The product data management platform reads the data package parsing result and performs online display, presents the parsed structured requirement information to the user interface, which can be realized by using a Web front-end rendering framework, aiming to improve the visualization degree of the requirement state and the user operation convenience.

[0067] In summary, the scheme of the embodiment takes the product data management platform to actively send a synchronization request as the starting point of the process, triggering the data synchronization mechanism. After receiving the request, the middleware calls the DOORS synchronization interface, accurately converts the platform instruction into an executable operation instruction of the DOORS system. The DOORS system responds to the interface call, automatically packages the requirement data and uploads to the preset shared resource path, realizes the safe encapsulation and path standardized transmission of the data. The product data management platform subsequently acquires the data package from the path, performs the parsing operation and stores the result to the platform database, completes the data format conversion and persistence management. Finally, the platform reads the parsing result and performs online display, making the requirement entry state real-time visualized. Each step strictly follows the sequential execution logic, the output of the previous step is taken as the input condition of the subsequent step, forming a closed-loop data flow chain, effectively solving the data inconsistency problem caused by the disconnection of each link in the synchronization process, ensuring the reliability and fine control level of the requirement entry synchronization.

[0068] In order to achieve the above purpose, the application also provides a requirement entry control system, which can specifically include: an integrated DOORS subsystem, a product data management platform subsystem and a data interaction middleware, which are integrated and run through structured data interfaces and permission control interfaces to support the preparation, release and fine change control of requirement entries.

[0069] Specifically, the DOORS subsystem is deployed on the DOORS server and the user client, and is used to perform the creation, editing and entry-level access permission control of the requirement entries.

[0070] As shown in the figure, the DOORS subsystem includes function modules such as creating structure tree, editing requirements, and permission control. A user can create a requirement structure tree and edit the content of a requirement entry in the DOORS client, and realize exclusive editing, shared editing, and read-only access mode through the permission control function. In terms of user group control, the system performs unified identity and permission authentication through the user group AD module. When receiving operation instructions from the data interaction middleware, the DOORS subsystem can perform locking or unlocking operations on the target requirement entry; when receiving export instructions from the data interaction middleware or the local client, an XML format structured data file containing requirement entry information is generated and exported.

[0071] The data interaction middleware is deployed on the DOORS server side, and is a data bridge connecting the DOORS subsystem and the product data management platform subsystem. The middleware includes a data synchronization interface and a permission control interface. The data synchronization interface is used to realize bidirectional synchronization of requirement structure tree and entry data. The permission control interface is used to receive entry freezing or unfreezing instructions issued by the product data management platform, and perform corresponding entry locking or unlocking operations in the DOORS system.

[0072] During system operation, the structured data file exported by the DOORS subsystem (structure tree / entry in the figure) is transmitted to the specified path of the product data management platform via the data interaction middleware; when the product data management platform initiates a freezing or unfreezing request (freeze / unfreeze in the figure), the middleware calls the DOORS interface to perform the corresponding operation, and returns the execution result to the product data management platform subsystem.

[0073] The product data management platform subsystem is deployed on the product data control server, and is used to realize centralized control, state control, and life cycle tracking of requirement entries. The subsystem includes a WEB-side requirement entry display processing module and a plurality of business control modules.

[0074] The requirement entry library is used to receive and parse the structured data transmitted by the data interaction middleware, and store it in the form of entry. The specific implementation has been described in detail above, and will not be repeated here.

[0075] The above describes the preferred embodiments of the present application in detail. It should be understood that those skilled in the art can make many modifications and changes without creative labor according to the concept of the present application. Therefore, any technical solution obtained by logical analysis, reasoning, or limited experiment on the basis of the prior art according to the concept of the present application shall be within the protection scope determined by the claims.

Claims

1. A demand entry control method characterized by comprising: The method comprises the following steps: Step S1: requirement compilation and structured derivation; wherein, the requirement entry is created in a structure tree and the content is compiled in a DOORS system, and entry-level access permission is set for the requirement entry; then, the XML generation interface of DOORS is called through a data interaction middleware, the requirement entry information is derived into an XML file according to a preset data format, and the XML file is stored in a preset shared resource path; Step S2: platformized entry control; wherein, the product data management platform reads and parses the XML file, stores the parsed requirement entry in a tree structure in a requirement entry library, and sets the initial state of the entry as "in work"; Step S3: DOORS entry editing permission control; wherein, at least one of the following control operations is performed on the requirement entry in the DOORS system through the cooperation of the product data management platform and the data interaction middleware: Data synchronization operation: in response to a synchronization request of the product data management platform, the DOORS system is driven by the middleware to package requirement data and upload, and then the platform acquires, parses and online displays; Influence analysis operation: in response to an influence analysis request of the product data management platform, the entry influence analysis method of the DOORS system is called by the middleware to acquire the associated relationship information of the entry, so that the platform creates a countersigning process; Document release operation: in response to a document release instruction of the product data management platform, the middleware drives the DOORS system to perform a locking operation on all entries of the specified document, and changes its state to "released"; Entry change operation: in response to an entry change process initiated by the product data management platform, the middleware drives the DOORS system to perform a locking or unlocking operation on a specific entry, and triggers data synchronization after the change is completed, so that the platform acquires and displays the latest data.

2. The demand entry control method according to claim 1, characterized by, In the step S1, the entry-level access permission includes exclusive editing permission, shared editing permission and read-only access permission, and the corresponding permission control is realized by adding or deleting user accounts in the DOORS entry attribute, thereby supporting the editing and freezing control of a single entry; the content of the XML file at least includes the DOORS requirement module name, the requirement text and the requirement attribute.

3. The demand entry control method according to claim 2, wherein The text information of the requirement entry is stored in the XML file; the formula, table and picture rich text information in the requirement entry are stored in the data packet in the form of pictures; the introduced picture name is marked in the XML file.

4. The demand entry control method of claim 1, wherein In the step S2, storing the parsed requirement entry in a tree structure in a requirement entry library comprises the following steps: According to the hierarchical relationship between the parsed requirement entries, a tree logical structure corresponding to the hierarchical relationship is constructed in the product data management platform; The attribute information corresponding to the requirement entry is stored and displayed in the node of the tree structure, and the attribute information at least includes the title, version, entry type, entry state and entry owner information.

5. The demand entry control method of claim 1, wherein In the step S1, the XML generation interface of DOORS is called through the data interaction middleware, specifically, the exportRichTextModule interface provided by the middleware is called.

6. The demand entry control method of claim 1, wherein In the step S1, a unique requirement number reqID is defined for each requirement entry.

7. The demand entry control method of claim 1, wherein In the step S3, the data synchronization operation specifically includes: The product data management platform sends a synchronization request to the middleware; The middleware calls the DOORS synchronization interface; The DOORS system packs the requirement data and uploads it to a preset shared resource path; The product data management platform obtains the data package, parses the data, and stores them in the platform database; The product data management platform reads the data package parsing result and performs online display.

8. The demand entry control method according to claim 6, wherein In the step S3, the impact analysis operation specifically includes: The product data management platform sends a related party impact analysis request; The middleware parses the platform message to obtain the reqID number of the requirement entry; The middleware calls the moduleImpactAnalysisWithDetail interface; The upper and lower associated team names of the entry are obtained; The product data management platform creates a countersigning object according to the obtained associated team names.

9. The demand entry control method of claim 1, wherein The data interaction middleware is also used to monitor and record the execution of instructions to the DOORS system, including interface calling, parameter passing, and execution result feedback.

10. A demand entry control system characterized by, The requirement entry control method according to any one of claims 1 to 9 is used, including: a DOORS subsystem, a product data management platform subsystem, and a data interaction middleware integratedly running; The DOORS subsystem is a DOORS editing tool deployed on a DOORS server and a user client, and is used to: provide creation, editing, and entry-level permission control functions of requirement entries; in response to instructions from the data interaction middleware, perform locking and unlocking operations on specific requirement entries; in response to instructions from the data interaction middleware or the local client, generate and export structured data files containing requirement entry information; The product data management platform subsystem is deployed on a product data control server and includes a WEB-side requirement entry display processing module, which is used to: read and parse the structured data files to store requirement data in an entry form and provide tree structure display; provide process control functions of requirement change requests and requirement change notifications; in response to changes in process states, send locking or unlocking instructions for specific requirement entries to the data interaction middleware; The data interaction middleware, as a bridge connecting the DOORS subsystem and the product data management platform subsystem, is used to: receive instructions from the product data management platform subsystem and call corresponding interfaces provided by the DOORS subsystem to perform operations; call interfaces of the DOORS subsystem to drive generation and export of the structured data files; return result states of instruction execution to the product data management platform subsystem.

Images