Product demand document analysis method and device, electronic equipment and storage medium

Abstract

The invention discloses a product demand document analysis method and device, electronic equipment and a storage medium. The method comprises the steps that a to-be-analyzed product demand document is acquired, and the content of the to-be-analyzed product demand document is subjected to structured processing; identifying at least one entity object involved in the product demand document; matching operation fault data corresponding to the entity object in a preset database; and generating risk prompt information corresponding to the product demand document based on the operation fault data, and associating the risk prompt information to the product demand document. According to the application, through automatic analysis and association of the content of the product demand document and the operation fault data, potential operation risks can be identified in a demand design or review stage; the efficiency and quality of demand review are improved, and the operation risk after the system is online is reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of product design analysis, and particularly relates to a product requirement document analysis method and device, an electronic device and a storage medium. BACKGROUND

[0002] In the research and development process of software systems and information products, a product requirement document (PRD) is usually used to describe product functions, business processes, system interactions and related constraints, and is a basic file for guiding subsequent design, development and testing work. Since the PRD directly determines the system implementation direction and business logic, the completeness and reasonableness of its content have an important influence on the stable operation of the system, so in the research and development process, the PRD needs to be reviewed for demand design to confirm whether the demand is reasonable and whether it meets the existing system architecture and business rules.

[0003] In practical applications, PRD review relies on manual reading and experience judgment, and the review focus is mainly on function correctness, business process integrity and implementation feasibility. With the expansion of system size and the increase of business logic complexity, the PRD content often involves multiple systems, interfaces and cross-business process coordination, so that potential risks are no longer limited to a single function point, but are more likely to be hidden in system interactions and historical operation constraints.

[0004] At the same time, enterprise information systems have accumulated a large amount of running abnormals, problem handling and optimization experience in the long-term operation process, and this information should have important reference value for subsequent demand design. However, in the existing PRD review process, the above information is usually not systematically introduced into the review process, and the review personnel have difficulty in identifying the potential risk points that may be touched in the demand design in a timely and comprehensive manner, thereby causing some demands to have an adverse effect on the stability of the system or the existing business process after implementation.

[0005] Therefore, how to improve the identification ability of potential system risks in the PRD review stage so that the review process not only focuses on the function description of the demand itself, but also more fully considers the constraints and experience of the system operation level, has become a technical problem to be improved in the existing demand review mechanism. SUMMARY

[0006] Based on this, the present application aims to provide a product requirement document analysis method, device, electronic device and storage medium, which identifies entity objects in the document and associates corresponding fault records, and feeds back the related records to the document page, providing design risk reference for demand review.

[0007] In a first aspect, the present application provides a product requirement document analysis method, comprising:

[0008] Obtain the product requirements document to be analyzed;

[0009] Identify at least one entity object in the product requirements document to be analyzed, and denote it as the document entity object;

[0010] Match runtime failure data corresponding to the document entity object in the preset database;

[0011] Risk warning information is generated based on operational failure data and corresponding to the product requirement document to be analyzed.

[0012] Furthermore, identifying at least one entity object in the product requirements document to be analyzed includes:

[0013] Using a pre-trained entity recognition model as input, the product requirement document to be analyzed is used to identify at least one entity object involved in the product requirement document to be analyzed. The entity object is used to represent at least one of the following: system, function, interface, business process, and data element.

[0014] Furthermore, the runtime fault data matched with the document entity object in the preset database includes:

[0015] Calculate the similarity between the document entity object and the entity objects involved in each running fault data in the preset database, and record it as entity similarity;

[0016] Runtime fault data is matched with document entity objects based on entity similarity.

[0017] Furthermore, matching runtime fault data corresponding to document entity objects in the preset database also includes:

[0018] In the preset database, semantic analysis is used to match the runtime fault data corresponding to the document entity objects, and this data is recorded as the initial fault data.

[0019] Determine the context information of each document entity object in the product requirements document to be analyzed;

[0020] Calculate the correlation between the initial fault data and the document entity object based on the context information corresponding to the document entity object;

[0021] Based on relevance, operational fault data that meets the relevance threshold is retained from the initial fault data.

[0022] Furthermore, the risk warning information generated based on the operational failure data and corresponding to the product requirement document to be analyzed includes:

[0023] Standardize the runtime fault data corresponding to each document entity object to obtain standardized fault data;

[0024] Standardized fault data is linked to the original document carrier of the product requirement document to be analyzed through a preset interface.

[0025] Furthermore, by using pre-defined interfaces to link standardized fault data to the original document carrier of the product requirement document to be analyzed, including:

[0026] Structured comment information is generated based on standardized fault data. The structured comment information is generated according to a preset template and includes one or more of the following: operational fault data, impact information, and suggestion information associated with the product requirement document to be analyzed.

[0027] Structured comments are published to the original document carrier of the product requirements document to be analyzed via the comment feedback interface.

[0028] Furthermore, obtaining the product requirements document to be analyzed includes:

[0029] Obtain the document identifier of the product requirements document;

[0030] Use document identifiers to identify the product requirement documents to be analyzed in the document storage platform;

[0031] The content of the product requirements document to be analyzed is processed into structured text.

[0032] Secondly, the present invention provides a product requirement document analysis device, comprising:

[0033] The document acquisition module is used to acquire product requirement documents to be analyzed.

[0034] The entity recognition module is used to identify at least one entity object in the product requirement document to be analyzed, denoted as the document entity object;

[0035] The data matching module is used to match runtime fault data corresponding to document entity objects in a preset database;

[0036] The risk alert module is used to generate risk alert information corresponding to the product requirement document to be analyzed based on operational failure data.

[0037] Thirdly, the present invention provides an electronic device including a memory storing computer-executable instructions and a processor, wherein when the computer-executable instructions are executed by the processor, the device performs the steps of the product requirements document analysis method provided in the first aspect.

[0038] Fourthly, the present invention provides a readable storage medium storing a computer-executable program that, when executed, can implement the various steps of the product requirements document analysis method provided in the first aspect.

[0039] The present invention has the following beneficial effects:

[0040] This invention proposes a product requirement document analysis method. By automating the parsing and analysis of product requirement documents and introducing entity recognition and fault data matching mechanisms, it accurately associates entity objects such as systems, functions, interfaces, business processes, or data elements involved in the product requirement documents with operational fault data in a pre-set database. This allows for the automatic generation of risk warning information highly relevant to the document content during the requirement review stage. Compared to existing methods relying on manual experience and post-event summaries, this invention effectively reduces the cost of historical fault information retrieval and understanding, reduces misjudgments caused by entity ambiguity or semantic mismatch, and improves the accuracy and coverage of risk identification. A further embodiment standardizes the fault data and links it back to the original product requirement document in the form of structured comments, achieving intuitive presentation and continuous traceability of risk information. This encourages relevant personnel to pay attention to potential risks in a timely manner during the requirement review and design stages, thereby improving the efficiency and quality of product requirement reviews and reducing systemic risks in subsequent development, testing, and operation stages. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0042] Figure 1 Flowchart illustrating the product requirements document analysis method provided in this embodiment of the invention;

[0043] Figure 2 This is a schematic diagram of the product requirement document analysis device provided in an embodiment of the present invention;

[0044] Figure 3 This is an electronic device architecture diagram provided for an embodiment of the present invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] See Figure 1 An embodiment of the present invention provides a product requirements document analysis method, comprising the following steps:

[0047] Step S110. Obtain the product requirements document to be analyzed.

[0048] Specifically, a product requirements document (PQV) is a document that describes the functions and business objectives that a product or system needs to achieve during the planning phase. It typically includes the background of the requirements, business process descriptions, functional requirements, interaction specifications, interface dependencies, and constraints. The PQV supports understanding of product functions and scope by multiple roles, including R&D, testing, and operations. It is a crucial input document in the product design and review process, and therefore has high reference value and stability in the early stages of the product lifecycle.

[0049] In practical applications, product requirement documents are typically stored electronically on a document storage platform, which can be an internal document management system, knowledge base system, or collaboration platform. Product requirement documents are usually managed using a unique document identifier, which may include a page identifier, document number, access path, or a combination thereof, used to uniquely locate the corresponding product requirement document within the document storage platform.

[0050] In this step, the document identifier is used to identify the product requirement document to be analyzed in the document storage platform. Specifically, the system can send a query request containing the document identifier to the document storage platform through a preset interface, and the document storage platform returns the corresponding document content based on the document identifier.

[0051] In a further embodiment, the obtained product requirement document content can be in unstructured or semi-structured text form, such as containing natural language descriptions, heading levels, list information, or nested paragraph structures. To facilitate subsequent entity recognition and semantic analysis of the document content, the product requirement document content is structured. This processing may include: parsing the document's hierarchical structure, mapping different chapters, paragraphs, or fields to predefined data fields; segmenting the text content, removing irrelevant tags or formatting information; and finally generating structured text data in a unified format.

[0052] In a more preferred embodiment, the parsed text data, table data, and chart data are further encapsulated into a standardized structured data format, such as JSON. The JSON data can include document metadata, content type identifiers, structural hierarchy relationships, and corresponding text or numerical content, thereby achieving a unified structured output of product requirement document content. By converting document content in different formats into standard JSON format, a consistent data input interface can be provided for model-based entity recognition, context analysis, and semantic matching in subsequent steps, reducing the impact of different content formats on analysis and processing, and improving the stability and scalability of the document analysis process.

[0053] Step S120. Identify at least one entity object in the product requirement document to be analyzed, and denote it as the document entity object.

[0054] The entity objects identified in this step represent the core business and technical elements involved in the product requirements document. These can include, but are not limited to, systems, functions, interfaces, business processes, and data elements. Essentially, they are a structured expression of content in the requirements text that has clear business semantics or system-specific characteristics. They can be categorized into different types based on their semantic attributes, such as system entities, interface entities, and business process entities. For example, system entities represent the names of business systems or subsystems involved in the product requirements document, such as payment systems, order systems, and logistics systems; interface entities represent the interface or service identifiers involved in inter-system or intra-system call relationships, such as payment interfaces, shipping interfaces, or settlement interfaces; and business process entities represent cross-system or cross-functional business processing flows, such as payment flows, shipping flows, or order processing flows.

[0055] By identifying entity objects in product requirement documents, the requirements described in natural language can be mapped into structured elements with clear semantic orientation, providing a foundation for subsequent matching of operational fault data.

[0056] Specifically, using standardized structured text as input, the text fields, paragraph hierarchy information, and content location information are traversed and analyzed to identify potential entity objects in the document.

[0057] In a further embodiment, the type of entity object can be predefined into multiple categories, such as system entities, functional entities, interface entities, business process entities, and data element entities. For different types of entity objects, their location, chapter, and contextual text content in the product requirements document can be recorded to form a mapping relationship between entity objects and document content. This avoids ambiguity issues caused by relying solely on keyword matching and improves the accuracy of entity recognition results.

[0058] In one implementation, a pre-trained entity recognition model is used to analyze and process the structured text of a document. This pre-trained entity recognition model can be built based on natural language processing technology and trained on corpora containing system names, functional modules, interface identifiers, business process descriptions, or data field descriptions, thereby enabling it to automatically identify entity objects from natural language text. The structured text is input into the entity recognition model, and the model outputs the entity object corresponding to the text fragment and its entity type identifier.

[0059] In another embodiment, for content presented in the form of tables or charts in the product requirements document, entity object recognition can be performed by combining the table structure information and chart semantic information obtained in step S110. For example, field names or chart descriptions in a table can be input as independent text units into the entity recognition model to identify system names, interface identifiers, or data element entities contained therein.

[0060] In some embodiments, to further improve the stability and completeness of entity recognition, post-processing can be performed based on the output of the entity recognition model. For example, multiple recognition results of the same entity object in different text fragments can be merged, and entity objects with the same semantics but different expressions can be normalized to obtain the final document entity object set.

[0061] Step S130. Match the runtime fault data corresponding to the document entity object in the preset database.

[0062] The operational fault data matched in this step are records of various anomalies, errors, or business interruptions generated during the operation of a product or system. This data can come from a unified fault management database, event log system, operations and maintenance platform, or issue tracking system. The content typically includes information such as the time of the fault, the affected system or module, fault description, scope of impact, fault level, handling records, and repair suggestions. Each piece of operational fault data is usually associated with a specific system, interface, or business process and may contain descriptive fields corresponding to the entity object.

[0063] In some embodiments, matching the operational failure data corresponding to the document entity object employs an entity similarity-based matching method. Specifically, using the document entity object as the matching object, entity information involved in each operational failure data is retrieved from a preset database, and the similarity between the document entity object and the entity information involved in the failure data is calculated. The similarity can be calculated based on string matching, text similarity, or semantic vector similarity. By comparing the similarity with a preset threshold, operational failure data with high similarity to the document entity object is filtered out, thereby determining the operational failure data corresponding to the document entity object.

[0064] In other embodiments, the matching of runtime failure data corresponding to document entity objects employs a matching method based on semantic analysis and context relevance. Specifically, a natural language processing model is used to perform semantic analysis on the document entity object and its surrounding text, and semantic matching is performed on the text content of runtime failure data in a preset database to obtain initial failure data semantically related to the document entity object; subsequently, the relevance of the initial failure data is calculated by combining the context information of the document entity object in the product requirement document, and runtime failure data that is highly consistent with the context of the document entity object is retained according to a preset relevance threshold.

[0065] In a more preferred embodiment, the entity similarity-based matching method and the semantic analysis and context-related matching method can be used in combination. The results obtained from the two matching methods can be fused, for example, by using a weighted method or priority rules to filter the matching results, thereby improving the completeness of operational fault data coverage while ensuring matching accuracy. Through this method, stable matching of operational fault data related to document entity objects can be achieved under different business scenarios and different document representation formats.

[0066] Step S140. Generate risk warning information corresponding to the product requirement document to be analyzed based on the operational failure data.

[0067] The risk warning information generated in this step is used to organize and express the operational failure data obtained from the previous steps, so as to intuitively present potential risks to relevant personnel during the product requirement review or design stage. The risk warning information not only reflects the correlation between historical operational failures and current product requirement documents, but also provides targeted risk references and improvement suggestions for requirement design.

[0068] In some embodiments, generating risk alerts based on operational failure data includes standardizing the operational failure data. Specifically, the system uniformly organizes operational failure data from different sources and in different formats, extracting and normalizing fields relevant to risk analysis. For example, information such as failure descriptions, impact on systems or business processes, impact outcomes, and handling recommendations are converted into a unified data structure, thereby obtaining standardized failure data. This standardization process avoids the impact of differences in the representation of different failure records on subsequent analysis and presentation.

[0069] In a further embodiment, structured risk warning content is generated based on the standardized fault data. The structured risk warning content can be generated according to a preset template to uniformly describe historical operational risks related to the product requirement document. The preset template may include one or more of the following: operational fault data associated with the product requirement document, corresponding impact information, and suggested information, thereby ensuring consistency in the content structure and expression of the risk warning information, facilitating understanding and comparison.

[0070] In some embodiments, the generated structured risk warning information is associated with the original document carrier of the product requirement document to be analyzed through a preset interface. Specifically, the structured risk warning information is published as a comment on the document page corresponding to the product requirement document through a comment feedback interface, thus directly linking the risk warning information with the specific requirement content. In this way, relevant personnel can simultaneously obtain the relevant risk warning information when viewing the product requirement document.

[0071] In a further embodiment, while issuing risk warning information, notification operations can also be triggered for preset relevant objects to remind them to pay attention to the risk warning information. These relevant objects may include product managers, requirements reviewers, or technical managers, thereby achieving effective transmission of risk information in the requirements review process and forming a closed-loop mechanism for risk identification and feedback.

[0072] Through the above steps, the automatic generation and correlation feedback of operational failure data and risk warning information are realized, enabling historical operational risks to be intuitively presented and continuously traced at the product requirement document level. This helps to identify potential problems in advance during the requirement design phase and improves the completeness and security of requirement review.

[0073] The disclosed method can be implemented using various types of devices. Therefore, the present invention also discloses an apparatus corresponding to the above method, and specific embodiments are given below for detailed description.

[0074] like Figure 2 As shown, one embodiment of the present invention provides a product requirement document analysis device, comprising:

[0075] Document acquisition module 202 is used to acquire product requirement documents to be analyzed.

[0076] The entity recognition module 204 is used to identify at least one entity object in the product requirement document to be analyzed, denoted as the document entity object;

[0077] Data matching module 206 is used to match runtime fault data corresponding to document entity objects in a preset database;

[0078] The risk warning module 208 is used to generate risk warning information corresponding to the product requirement document to be analyzed based on the operational failure data.

[0079] The device provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0080] The methods and related apparatuses mentioned in the above embodiments are described with reference to the method flowcharts and / or structural diagrams provided in the embodiments of this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 3 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0081] The following embodiments illustrate the application of this method to a computer device. It is understood that the computer device can be any device with computing and processing capabilities, including but not limited to servers or personal laptops. In one embodiment, the computer device can be an application server, which can be a server used to run the application under test.

[0082] See Figure 3This document illustrates a hardware block diagram of an electronic device intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0083] like ​ As shown, the electronic device includes: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0084] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0085] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0086] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0087] The memory stores a program, which the processor can call. The program is used to implement the various processing steps of the aforementioned product requirement document analysis scheme.

[0088] This invention also provides a readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the various processing flows of the product requirement document analysis scheme provided in any possible implementation of the above embodiments and / or in combination with the embodiments.

[0089] The invention has been described in particular detail above with respect to possible scenarios, and those skilled in the art will recognize that the invention can be practiced through other embodiments. Specific naming of components, capitalization of terms, attributes, data structures, or any other programming or structural aspects are not mandatory or important, and the mechanisms or features of implementing the invention may have different names, forms, or procedures. The system can be implemented through a combination of hardware and software (as described), entirely through hardware elements, or entirely through software elements. The specific division of functions among the various system components described herein is merely exemplary and not mandatory; rather, the functions performed by a single system component can be performed by multiple components, or the functions performed by multiple components can be performed by a single component.

[0090] Those skilled in the art should understand that the various steps of the disclosed methods can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using device-executable program code, which can then be stored in a storage device for execution by the computing device. Alternatively, they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, the embodiments disclosed in this invention are not limited to any specific hardware and software combination.

[0091] The programs (also referred to as programs, software, software applications, or code) executable by these computing devices include machine instructions of a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0092] Certain aspects of this invention include the process steps and instructions described herein in algorithmic form. It should be noted that the process steps and instructions of this invention can be implemented in software, firmware, and / or hardware, and when implemented in software, they can be downloaded, stored on various operating systems and operated from said platforms.

[0093] Those skilled in the art will understand that the structures shown in the figures are merely block diagrams of some structures related to the present application and do not constitute a limitation on the terminal device to which the present application is applied. Specific terminal devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0094] In the description of this specification, the use of terms such as "one embodiment," "some embodiments," "example," "specific example," or "possible design," etc., refers to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0095] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A product requirements document analysis method, characterized in that, include: Obtain the product requirements document to be analyzed; Identify at least one entity object in the product requirements document to be analyzed, and denote it as the document entity object; Match runtime failure data corresponding to the document entity object in the preset database; Risk warning information is generated based on operational failure data and corresponding to the product requirement document to be analyzed.

2. The method according to claim 1, characterized in that, The identification of at least one entity object in the product requirement document to be analyzed includes: Using a pre-trained entity recognition model as input, the product requirement document to be analyzed is used to identify at least one entity object involved in the product requirement document to be analyzed. The entity object is used to represent at least one of the following: system, function, interface, business process, and data element.

3. The method according to claim 1, characterized in that, The step of matching runtime fault data corresponding to document entity objects in the preset database includes: Calculate the similarity between the document entity object and the entity objects involved in each running fault data in the preset database, and record it as entity similarity; Runtime fault data is matched with document entity objects based on entity similarity.

4. The method according to claim 1, characterized in that, The step of matching runtime fault data corresponding to document entity objects in the preset database also includes: In the preset database, semantic analysis is used to match the runtime fault data corresponding to the document entity objects, and this data is recorded as the initial fault data. Determine the context information of each document entity object in the product requirements document to be analyzed; Calculate the correlation between the initial fault data and the document entity object based on the context information corresponding to the document entity object; Based on relevance, operational fault data that meets the relevance threshold is retained from the initial fault data.

5. The method according to claim 1, characterized in that, The risk warning information generated based on operational failure data and corresponding to the product requirement document to be analyzed includes: Standardize the runtime fault data corresponding to each document entity object to obtain standardized fault data; Standardized fault data is linked to the original document carrier of the product requirement document to be analyzed through a preset interface.

6. The method according to claim 5, characterized in that, The method of linking standardized fault data to the original document carrier of the product requirement document to be analyzed through a preset interface includes: Structured comment information is generated based on standardized fault data. The structured comment information is generated according to a preset template and includes one or more of the following: operational fault data, impact information, and suggestion information associated with the product requirement document to be analyzed. Structured comments are published to the original document carrier of the product requirements document to be analyzed via the comment feedback interface.

7. The method according to claim 1, characterized in that, The process of obtaining the product requirement document to be analyzed includes: Obtain the document identifier of the product requirements document; Use document identifiers to identify the product requirement documents to be analyzed in the document storage platform; The content of the product requirements document to be analyzed is processed into structured text.

8. A product requirement document analysis device, characterized in that, include: The document acquisition module is used to acquire product requirement documents to be analyzed. The entity recognition module is used to identify at least one entity object in the product requirement document to be analyzed, denoted as the document entity object; The data matching module is used to match runtime fault data corresponding to document entity objects in a preset database; The risk alert module is used to generate risk alert information corresponding to the product requirement document to be analyzed based on operational failure data.

9. An electronic device, characterized in that, The device includes a memory storing computer-executable instructions and a processor, which, when executed by the processor, causes the device to perform the product requirements document analysis method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, It contains a computer-executable program that, when executed, enables the product requirements document analysis method as described in any one of claims 1 to 7.

Images