Demand document analysis method and device, computer equipment and readable storage medium

Abstract

The invention discloses a demand document analysis method and device, computer equipment and a readable storage medium, in a financial scene, demand documents relate to different types of financial businesses, in a medical scene, the demand documents relate to function design of a medical system, and the demand documents relate to different types of financial businesses. According to the method, the problems of low efficiency and incomplete coverage caused by manual evaluation of the demand document can be solved, so that the quality and efficiency of demand document analysis are remarkably improved. The method comprises the following steps: constructing a security demand corpus; generating a training sample based on the security demand corpus, and performing model training on a pre-constructed security demand review model by adopting the training sample to obtain a target review model; inputting the to-be-recognized demand document and the analysis cue word into a target review model; on the basis of the target review model, the analysis cue words are utilized to screen the to-be-analyzed demand points, and a review result of each to-be-analyzed demand point is determined; and aggregating the review result corresponding to each to-be-analyzed demand point to obtain an analysis result corresponding to the to-be-identified demand document.

Description

Technical Field

[0001] The present application relates to the fields of computer technology, financial technology and medical health, and in particular to a method, apparatus, computer equipment and readable storage medium for analyzing requirements documents. Background Art

[0002] As enterprises accelerate their digital transformation, the complexity and scale of requirements documentation during software development have increased significantly. This is especially true in high-security sectors such as finance, government affairs, and healthcare. Requirements documents must simultaneously address business functionality, compliance, and security requirements. For example, financial services must adhere to the relevant regulations of financial regulators to ensure the proper use of funds and risk control. They also require encrypted storage and transmission of transaction data and financial information within supply chain finance systems to prevent data leakage and tampering. Healthcare services must adhere to relevant industry regulations, such as the storage and management of electronic medical records, which must comply with relevant standards to ensure the authenticity, integrity, and security of patient medical data. Furthermore, strict access control mechanisms must be established to ensure that only authorized doctors, patients, and payment processors can access the relevant data.

[0003] In related technologies, traditional requirement document analysis mainly relies on manual review: information security personnel review the business scenarios in the document one by one based on their experience, identify potential security requirements and supplement non-functional descriptions.

[0004] In the process of implementing this application, the applicant discovered that the related technology has at least the following problems:

[0005] Existing technologies rely on manual experience, lack security knowledge, and are unable to dynamically adapt to complex scenarios, resulting in low efficiency in requirement document analysis and incomplete coverage of security requirements, which in turn causes security vulnerabilities and compliance risks after the system is launched. Summary of the Invention

[0006] In view of this, the present application provides a method, apparatus, computer equipment and readable storage medium for analyzing requirements documents. The main purpose is to solve the problem that the existing technology relies on manual experience, lacks security knowledge drive, and cannot dynamically adapt to complex scenarios, resulting in low efficiency in requirements document analysis and incomplete coverage of security requirements, which in turn causes security vulnerabilities and compliance risks after the system is launched.

[0007] According to the first aspect of the present application, a method for analyzing a requirements document is provided, the method comprising:

[0008] Acquire security data from multiple data sources and construct a security requirements corpus based on the security data, wherein the security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and remediation solution fields;

[0009] Generating training samples based on the structured text recorded in the security requirement corpus, and using the training samples to train a pre-built security requirement review model to obtain a target review model;

[0010] In response to a user uploading a requirement document to be identified and an analysis prompt word, the requirement document to be identified and the analysis prompt word are input into the target review model, and the requirement document to be identified is split into a plurality of requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point;

[0011] Based on the target review model, using the analysis prompt words, screening the demand points to be analyzed from all the demand points, and determining the business scenario corresponding to each of the demand points to be analyzed, and determining the review result corresponding to each of the demand points to be analyzed based on the business scenario and the security requirements corpus;

[0012] Aggregate the review results corresponding to each of the demand points to be analyzed to obtain the analysis results corresponding to the demand document to be identified.

[0013] According to a second aspect of the present application, a demand document analysis device is provided, the device comprising:

[0014] An acquisition module, configured to acquire security data from multiple data sources and construct a security requirements corpus based on the security data, wherein the security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenario, risk level, compliance requirements, attack model, historical vulnerability, and repair solution fields;

[0015] A training module, configured to generate training samples based on the structured text recorded in the security requirements corpus, and use the training samples to perform model training on a pre-built security requirements review model to obtain a target review model;

[0016] a splitting module for, in response to a user uploading a requirement document to be identified and an analysis prompt word, inputting the requirement document to be identified and the analysis prompt word into the target review model, and splitting the requirement document to be identified into a plurality of requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point;

[0017] a screening module for screening demand points to be analyzed from all demand points based on the target review model and the analysis prompt words, determining the business scenario corresponding to each demand point to be analyzed, and determining the review result corresponding to each demand point to be analyzed based on the business scenario and the security requirements corpus;

[0018] The output module is used to aggregate the review results corresponding to each of the demand points to be analyzed to obtain the analysis results corresponding to the demand documents to be identified.

[0019] According to a third aspect of the present application, a computer device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the methods described in the first aspect when executing the computer program.

[0020] According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the methods in the first aspect are implemented.

[0021] By means of the above technical solution, the present application provides a method, device, computer equipment and readable storage medium for analyzing requirements documents. The embodiments of the present application realize the automated processing of requirements document analysis by constructing a security requirements corpus and training a target review model, which significantly reduces the time and cost of manual review. In addition, the target review model supports dynamic screening of requirements points to be analyzed based on analysis prompt words provided by the user, and matches business scenarios that are not clearly associated based on similarity calculations. This flexibility enables the solution to adapt to complex requirements scenarios in different industries (such as finance, government affairs, and medical care) and improves generalization capabilities. In summary, the embodiments of the present application solve the problems of low efficiency and incomplete coverage of traditional manual review through automation, structured data-driven and dynamic adaptation technology, significantly improves the quality of requirements document analysis, and provides an efficient tool for security requirements management in complex business scenarios.

[0022] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present application. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0024] Figure 1 A schematic diagram of a method for analyzing a demand document provided in an embodiment of the present application is shown;

[0025] Figure 2 A schematic diagram of a method for analyzing a demand document provided in an embodiment of the present application is shown;

[0026] Figure 3 A schematic diagram of the structure of a demand document analysis device provided in an embodiment of the present application is shown;

[0027] Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0028] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and are not to be construed as limiting the present application.

[0029] Those skilled in the art will understand that, unless otherwise stated, the singular forms "a," "an," "said," and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of this application refers to the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0030] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with their meanings in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0031] Those skilled in the art will appreciate that the term "terminal" as used herein includes both devices that are wireless signal receivers, i.e., devices that only have wireless signal receivers without transmission capabilities, and devices that have receiving and transmitting hardware capable of performing two-way communication over a two-way communication link. Such devices may include: cellular or other communication devices with single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) devices that may combine voice, data processing, fax, and / or data communication capabilities; PDAs (Personal Digital Assistants) that may include a radio frequency receiver, a pager, Internet / Intranet access, a web browser, a notepad, a calendar, and / or a GPS (Global Positioning System) receiver; and conventional laptop and / or palmtop computers or other devices that have and / or include a radio frequency receiver. As used herein, a "terminal" may be portable, transportable, installed in a vehicle (air, sea, and / or land), or adapted and / or configured to operate locally, and / or in a distributed manner, at any other location on Earth and / or in space. As used herein, a "terminal" may also be a communication terminal, an Internet access terminal, or a music / video playback terminal, such as a PDA, an MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or a device such as a smart TV or a set-top box.

[0032] A requirements document is a core document in software development, product design, or project management. It clearly defines the goals, features, constraints, and user needs of a system, product, or project. It serves as a bridge for team communication, ensuring that all participants (e.g., developers, designers, testers, clients, etc.) have a consistent understanding of the requirements and avoiding discrepancies during subsequent development.

[0033] Analysis prompt words are keywords or phrases entered by the user to guide the target review model to screen demand points in specific business scenarios and achieve dynamic focus analysis.

[0034] A requirement document analysis method provided in an embodiment of the present application is applicable to a requirement document analysis system. Users can access the requirement document analysis system through a terminal device and input the requirement document to be identified, so that the system calls the target review model to review the requirement document to be identified. The target review model is an AI model trained based on a large language model (LLM) and is used to automatically analyze requirement documents. Dependency syntactic analysis technology can be used to identify functional verbs in the document, divide logical boundaries, and split the document into independent requirement points. Then, according to the business scenario and security requirement corpus, the requirement points are matched with historical vulnerabilities, compliance requirements, etc. to generate risk review results.

[0035] The present application embodiment provides a method for analyzing demand documents, such as Figure 1 As shown, the method includes:

[0036] S10. Obtain security data from multiple data sources and build a security requirements corpus based on the security data. The security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and repair solution fields.

[0037] Considering that traditional methods for identifying security risks in requirements documents tend to overly rely on the subjective experience of security personnel, resulting in incomplete coverage of security risks, the present embodiment integrates authoritative data such as laws and regulations, attack models, and vulnerability cases to construct an objective security requirements corpus. This security requirements corpus replaces the traditional manual experience-driven review model. In the process of building the security requirements corpus, the system first needs to obtain three types of core security data from heterogeneous data sources: legal and regulatory texts, ATTACK attack models, and security vulnerability cases. For requirements documents in medical scenarios, medical-related laws and regulations such as the "Medical Data Protection Law," "Electronic Medical Record Application Management Specifications," and "Medical Device Network Security Management Measures" can be obtained based on actual conditions. These regulations have clear provisions on the collection, storage, use, and sharing of medical data, as well as the network security of medical devices. Furthermore, considering attack scenarios unique to the medical industry, attacks against medical devices (such as pacemakers and infusion pumps) and attacks on medical information systems (such as hospitals' electronic medical record systems and registration systems) are collected. The ATTACK framework is used to determine possible tactics and techniques. We also collect security vulnerability cases from the medical industry, such as a hospital's electronic medical record system leaking patient data due to untimely patch updates, or a medical device being hacked and treatment parameters being tampered with. For requirements documents in financial scenarios, we can obtain relevant laws and regulations such as the "Measures for the Administration of Data Security of Financial Institutions" and the "Cybersecurity Law (Applicable to the Financial Sector)" based on actual circumstances. These regulations have strict requirements for data security, customer information protection, and transaction compliance for financial institutions. We also consider common attack scenarios in the financial industry, such as phishing attacks against online banking systems and market manipulation attacks against securities trading systems. We refer to the ATTACK framework to identify possible tactics and techniques. We also collect security vulnerability cases from the financial industry, such as a bank's system vulnerability leading to the theft of customer funds, or a securities company's trading system being hacked and tampered with transaction data. It is understood that the system can also obtain other core security data based on actual needs. This application does not specifically limit the types of other core security data. After obtaining security data, the system will perform comprehensive preprocessing on this security data. Specifically, for legal and regulatory texts, the system will perform detailed clause parsing and keyword extraction to obtain a set of compliance requirements. This set clearly defines the legal and regulatory requirements that must be followed in various business scenarios, providing a clear compliance basis for subsequent security reviews. For example, keywords such as "patient data anonymization" and "data access authorization mechanism" were extracted from the Medical Data Protection Act to form a set of compliance requirements. In medical business scenarios, such as telemedicine services, compliance requirements may include the requirement to encrypt the transmission and storage of patients' personally identifiable information to protect patient privacy.Keywords such as "data classification and hierarchical management" and "data backup and recovery" were extracted from the "Measures for the Administration of Data Security in Financial Institutions" to form a set of compliance requirements. In online banking transfer scenarios, compliance requirements may include multiple verifications of customer identities to ensure the security of funds transfers. For the ATTACK attack model, the system performs tactical and technical standardization and business scenario mapping. This standardization standardizes and unifies the various tactics and techniques within the attack model, facilitating system identification and analysis. For example, mapping the "privilege escalation" tactic to a medical information system might manifest as a hacker exploiting a vulnerability to gain administrator privileges and tamper with patient medical records. Business scenario mapping yields an attack-defense correlation table. For example, mapping the "credential theft" tactic to an online banking system might manifest as a hacker obtaining a user's account number and password. This business scenario mapping yields an attack-defense correlation table. Business scenario mapping combines the attack model with actual business scenarios to create an attack-defense correlation table. This correlation table details the potential attack methods and corresponding defense strategies in different business scenarios, providing targeted guidance for subsequent identification of strategies to be supplemented. For security vulnerability cases, the system conducts root cause analysis and extracts structured remediation solutions, generating a vulnerability remediation knowledge base. This knowledge base contains the causes of various security vulnerabilities and proven remediation solutions, providing an effective reference by subsequently identifying strategies for supplementation. For example, in a medical security vulnerability case, a root cause analysis is performed to identify the causes of the vulnerability, such as non-compliant coding or incorrect system configuration. Remediation solutions are then extracted and structured to form a vulnerability remediation knowledge base. Specifically, in a case where a SQL injection vulnerability in a hospital information system led to a data leak, the remediation solution might include strict filtering and validation of all input data and updating the database security configuration. In a financial security vulnerability case, a root cause analysis is performed to identify the causes of the vulnerability, such as flaws in system architecture design and insufficient security awareness. Remediation solutions are then extracted and structured to form a vulnerability remediation knowledge base. For example, in a case where a vulnerability in the password retrieval function of a bank's online banking system led to the theft of customer accounts, the remediation solution might include strengthening the verification mechanism of the password retrieval process, adding verification methods such as SMS verification codes and facial recognition. Finally, the system performs multi-source data fusion and field mapping on the compliance requirements set, attack and defense association table, and vulnerability remediation knowledge base. It's important to note that multi-source data fusion integrates data from different sources, eliminating conflicts and redundancies. Field mapping ensures that relevant fields in different datasets accurately correspond, resulting in multiple structured texts. Each structured text closely corresponds to a specific business scenario, detailing the security requirements, potential attacks, and corresponding defense and remediation measures. By aggregating these multiple structured texts, a security requirements corpus is ultimately formed.

[0038] In summary, the embodiments of the present application provide standardized and scenario-based data support for intelligent demand document analysis through structured integration of multi-source heterogeneous security knowledge, effectively improving the accuracy and comprehensiveness of security risk identification, and providing strong guarantees for the safe operation of business systems.

[0039] S20. Generate training samples based on the structured text recorded in the security requirements corpus, and use the training samples to train a pre-built security requirements review model to obtain a target review model.

[0040] In an embodiment of the present application, the security requirement corpus integrates authoritative data such as laws and regulations, attack models, and vulnerability cases. These structured texts cover a wide range of security knowledge and risk scenarios. Therefore, the system generates training samples based on the structured texts recorded in the security requirement corpus to train the pre-built security requirement review model. By learning these training samples, the security requirement review model can be exposed to a variety of security requirement expressions and actual cases, which in turn helps the model learn comprehensive and systematic security rules and potential risk patterns, and enhance the model's ability to identify and judge various security risks. When faced with unseen requirement documents, the model can also accurately identify the security risks therein, thereby improving the generalization ability of the model. The specific implementation process of generating training samples based on the structured texts recorded in the security requirement corpus and using the training samples to train the pre-built security requirement review model to obtain the target review model is as follows:

[0041] Based on the structured text in the security requirements corpus, the system generates positive and negative requirements for each business scenario, labeling them as risk-free or risk-existing. In actual operation, the system analyzes the compliance requirement fields in the security requirements corpus. For medical scenarios, the system extracts keywords such as "patient data encryption storage" and "medical device access control." Based on medical regulations and standards, it generates positive requirements, such as "hospital information systems must use the AES encryption algorithm to encrypt and store patients' electronic medical records." For financial scenarios, the system extracts keywords such as "financial transaction data encryption transmission" and "customer identity multi-factor authentication." Based on financial regulations and standards, it generates positive requirements, such as "bank online banking systems must use the RSA encryption algorithm to encrypt transaction data during fund transfers." The system also extracts defense measures for medical scenarios based on the attack model fields in the security requirements corpus, such as "preventing medical data tampering." It generates requirements that incorporate active defense logic, such as "hospital information systems perform hash checks on patient data every hour and issue prompt alerts if any inconsistencies occur (defense measures: medical data tampering response strategy). In financial scenarios, defense measures are extracted, such as "preventing financial account theft." Requirements containing proactive defense logic are generated, such as "Bank systems monitor abnormal transaction behavior (such as large-value inter-regional transfers) in real time and promptly freeze accounts if anomalies are detected (Defense measures: countermeasures for financial account theft)." Furthermore, to comprehensively simulate various security scenarios, this step also generates requirements with security flaws. During actual operation, the system can analyze historical vulnerability fields in the security requirements corpus and extract the root causes of vulnerabilities, such as "Financial systems fail to verify the complexity of user login passwords" and "Medical devices fail to update security patches in a timely manner." Requirements with security flaws are constructed, such as "Bank users may use simple numeric combinations as login passwords" and "A certain model of medical equipment has not received security patch updates for an extended period." The system can also process existing compliance requirements, generating non-compliant requirements by deleting or replacing compliance keywords. For example, "Financial data storage encryption" can be changed to "Plaintext storage of bank customer transaction records" and "Plaintext transmission of patient test reports" can be changed to highlight the security risks associated with lack of encryption. Furthermore, since positive demand points represent those without security risks, the system labels them "risk-free" to clarify their safety. Defective demand points, on the other hand, are those with security risks. For these demand points, the system not only labels them "risky" but also details the corresponding pending strategies. These pending strategies are generated based on the content in the remediation solution, attack model, and compliance requirements fields. These pending strategies, as a result of the review, provide specific guidance for subsequent risk remediation.Understandably, the system can also correlate historical vulnerability information corresponding to the demand point. By analyzing similar vulnerabilities in the past, the model can better understand the nature of the risk and its potential impact. Furthermore, the risk point is labeled with a corresponding risk level. Based on factors such as the severity and probability of occurrence, the risk is assessed and classified into different risk levels (high, medium, and low) to facilitate targeted risk management.

[0042] Furthermore, the system randomly identifies at least two of the generated requirements and, using natural language processing techniques, conducts in-depth analysis and integration of these selected requirements, effectively combining them into a requirements document (training sample). This combination is not a simple splicing process, but rather is based on the logical and semantic rules of natural language, ensuring coherence and readability in the requirements document. In actual operation, for medical scenarios, the system rationally combines and arranges the generated requirements according to the medical business scenario. Requirements related to patient information management are grouped into the "Patient Information Management Module" section, for example, grouping requirements such as "Encrypted Storage of Patient Registration Information" and "Control of Patient Information Access Rights" together. To more realistically simulate the complexity of actual requirements documents, requirements from different medical business scenarios are mixed and arranged across scenarios, such as combining requirements for the medical equipment management module and the patient information management module. Some non-security-related or vaguely described requirements are inserted, such as "Adjusting the font size of the hospital registration system interface," which are marked as "Risk-free." "Optimizing medical device performance" is marked as "Requires additional security constraints associated with the associated business scenario." For financial scenarios, the system rationally combines and arranges the generated requirements according to the financial business scenario. The requirements related to financial transactions are grouped into the "Financial Transaction Module" section, such as grouping requirements such as "encrypted transmission of transaction data" and "transaction authority control" together. In order to more realistically simulate the complexity of actual requirement documents, the requirements of different financial business scenarios are also mixed and arranged across scenarios, such as mixing the requirements of the customer information management module and the financial transaction module. Some non-security-related or vaguely described requirements are inserted, such as "adjusting the color of the bank's mobile app interface", which is marked as "risk-free". "Optimizing the response speed of the financial system" is marked as "requires additional security constraints for associated business scenarios". Finally, in order to enable the target review model to accurately split the requirement documents for analysis, when annotating the training samples, the system can also use XML / JSON format to annotate the document structure in detail. The specific annotation content includes the starting signal and logical boundary corresponding to each requirement point, so that each requirement point can be quickly located and identified in the subsequent review process and the requirement document can be divided.

[0043] After the above processing, the fully annotated requirements documents are used as training samples and fed into the pre-built security requirements review model for model training. These training samples contain rich security requirements information and annotation results, providing sufficient and accurate data support for the training of the security requirements review model. This helps the model learn the security characteristics and patterns of different requirements, thereby improving the model's review capabilities and accuracy, ultimately resulting in a high-performance target review model.

[0044] The model includes two core tasks. The first is document segmentation, which involves accurately extracting all requirements from a complete requirements document. This requires the model to identify the start and end points of requirements and clearly separate the different requirements within the document. The second is the review recommendation generation task, which involves performing a security analysis on each segmented requirement and outputting the corresponding review results, including review recommendations and risk levels.

[0045] For the first task, the pre-built security requirements review model uses a pre-training process to learn the semantic boundaries within documents. The model focuses on key information such as functional verbs and logical connectives. For example, the model identifies verbs such as "add" and "support" as the start signals of a requirement point, as these verbs often mark the beginning of a new requirement. Furthermore, the model determines the end boundaries of a requirement point based on periods, semicolons, or paragraph terminators. This allows the model to accurately segment requirements points at a semantic level, improving segmentation accuracy. For long paragraphs containing complex logic, the model uses dependency parsing. Long paragraphs may contain requirements with multiple logical branches. For example, "User login must support function A, while prohibiting operation B" actually contains two independent logic points. Through dependency parsing, the model can split these multi-logically branched requirements into multiple independent requirements points, enabling more precise processing of complex requirements documents.

[0046] For the second task, the model conducts an in-depth security analysis of each identified requirement and outputs corresponding review results, including review recommendations and risk levels. Before conducting the security analysis, the model extracts key features from each requirement. These features include, but are not limited to, keywords, data types, operational behaviors, and involved system components. For example, for the phrase "patients can access other people's medical records without identity verification," the model extracts keywords such as "patient query," "other people's medical records," and "unauthenticated," along with the operational behavior "medical record query." The model learns security rules and policies based on the medical security requirement corpus, identifies the requirement as a security risk based on relevant regulations, and outputs the review recommendation "Add patient identity verification to ensure patients can only access their own medical records," with a high risk rating. For the phrase "customers can modify the mobile phone number associated with their bank account without SMS verification," the model extracts keywords such as "customer modification," "mobile phone number binding," and "no SMS verification," along with the operational behavior "modify mobile phone number binding." It learns security rules and policies based on the corpus of financial security requirements, determines the security risk of this requirement point based on relevant laws and regulations, and outputs the review suggestion "Add SMS verification code verification to ensure the security of customers changing their bound mobile phone numbers," and marks it with a medium risk level. The model learns the security characteristics and patterns of different requirement points from training samples. For each requirement point, the model analyzes its annotation information, including whether there is a risk, the risk level, and the corresponding strategies to be supplemented. By learning from a large number of training samples, the model is able to establish a mapping relationship between the characteristics of the requirement point and the security risk. For example, when the model learns that multiple requirement points containing the "unverified file type" feature have security risks, it will quickly identify potential security risks when encountering new similar requirement points and output corresponding review suggestions.

[0047] Understandably, to further enhance the model's review capabilities, reinforcement learning is employed to optimize the model. During the reinforcement learning process, the model receives rewards or penalties based on the discrepancies between its output review results and the actual annotation results. If the model's review results are accurate—that is, if the review recommendations are reasonable and the risk level is correct—the model receives positive rewards. Conversely, if the review results are inaccurate, the model receives penalties. By continuously adjusting the model's parameters, it can achieve higher rewards based on different requirements, thereby improving the model's review accuracy and reliability.

[0048] During the training process, the performance of the model is evaluated regularly. The model is tested using a reserved test set, with evaluation indicators including the accuracy of review recommendations, the accuracy of risk level judgment, and the recall rate. The model is optimized based on the evaluation results. If the model performs poorly on certain types of demand points, the specific reasons are analyzed, which may be insufficient feature extraction, incomplete rule learning, etc., and then the model parameters are adjusted or the training methods are improved accordingly. For example, if the model makes inaccurate risk level judgments when processing demand points with complex logic, more training samples containing complex logic can be added, or the dependency parsing algorithm can be optimized to improve the model's ability to handle complex requirements. By continuously adjusting the model's parameters and training strategies until the model achieves satisfactory performance indicators on the validation set, it is ensured that the target review model can accurately and efficiently split and review the analysis requirements documents, providing reliable support for actual security requirements review work.

[0049] In summary, by learning from training samples built based on the security requirements corpus, the target review model can conduct a more comprehensive analysis and identification of various possible security risks, reduce the omission of security vulnerabilities, and avoid the interference of subjective factors, thereby more accurately identifying security risks in requirement documents.

[0050] S30. In response to the user uploading the requirement document to be identified and the analysis prompt words, the requirement document to be identified and the analysis prompt words are input into the target review model, and the requirement document to be identified is split into multiple requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point.

[0051] In this embodiment of the present application, users can upload a document of requirements to be identified and analysis prompts based on a terminal device. After the system receives the document of requirements to be identified and analysis prompts uploaded by the user, it will use the target review model to split the document into multiple requirement text blocks corresponding to a single requirement point. The specific operation is as follows:

[0052] To enable the target review model to accurately process the requirements document to be identified, the system, in response to the user uploading the requirements document and analysis prompts, first standardizes the format of the requirements document to be identified, eliminating issues such as formatting irregularities and typesetting differences, ensuring a unified and clear document structure and laying the foundation for subsequent analysis. In medical scenarios, the requirements document to be identified may contain new functional requirements for medical information systems, patient data sharing rules, and so on. The standardized requirements document is then combined with the analysis prompts to form a complete input content, which is then input into the target review model. After receiving the input content, the target review model analyzes the requirements document. Using its semantic recognition mechanism, the model identifies functional verbs in the requirements document and uses the identified functional verbs as the starting signal for the requirement point.

[0053] After accurately identifying the starting signal of a requirement point and determining its logical boundaries, the target review model splits the requirements document according to the logical boundaries corresponding to each requirement point. This splitting operation breaks down the originally complex requirements document into multiple relatively independent requirement text blocks, each of which uniquely corresponds to a requirement point. This splitting method makes subsequent processing of the requirements document more efficient, enabling detailed security analysis, review, and resolution of each individual requirement point.

[0054] S40. Based on the target review model, use the analysis prompt words to screen the demand points to be analyzed from all the demand points, determine the business scenario corresponding to each demand point to be analyzed, and determine the review results corresponding to each demand point to be analyzed based on the business scenario and the security requirement corpus.

[0055] like Figure 2 As shown in the figure, based on the target review model, the system uses analysis prompts to screen the demand points to be analyzed from all demand points, and determines the business scenario corresponding to each demand point to be analyzed, and determines the review result corresponding to each demand point to be analyzed based on the business scenario and security requirement corpus. The specific steps are as follows:

[0056] S41. Match a business scenario to each demand point in the security demand corpus, and associate the demand point with the corresponding business scenario.

[0057] In this step, the system matches business scenarios for each demand point based on the security requirements corpus, and associates the demand point with the corresponding business scenario. Specifically, the target review model will traverse all demand points, and for each demand point, compare its text content with the business scenario description in the security requirements corpus. The comparison process can use a keyword matching method to extract key information from the demand point, such as the business functions involved, operation objects, etc., and search for business scenarios containing this key information in the security requirements corpus. If a matching business scenario is found, an association relationship is established between the demand point and the business scenario, and the relationship is recorded in the associated database. In the medical scenario, the security requirements corpus can include business scenarios such as patient information management, medical equipment access, telemedicine services, electronic medical record systems, and medical insurance reimbursement processes. Based on this corpus, the system's target review model will traverse all demand points. For example, if a requirement is to "ensure the confidentiality of the patient's ID number during transmission," the model will extract the key information "patient ID number" and "transmission process." It will then search the security requirements corpus for business scenarios containing this key information, discover that the "patient information management" business scenario meets the requirements, establish an association between this requirement and the "patient information management" business scenario, and record it in the associated database. In financial scenarios, the security requirements corpus can include business scenarios such as account management, fund transactions, risk management, financial product sales, and customer information protection. For example, if a requirement is to "encrypt and store the customer's bank card number," the target review model will extract the key information "customer bank card number" and "encrypted storage," find the "customer information protection" business scenario in the security requirements corpus to match it, establish an association between this requirement and the "customer information protection" business scenario, and record it in the associated database.

[0058] S42. If there is a demand point that does not match the business scenario, calculate the similarity between the demand point and each business scenario in the security requirement corpus, and associate the business scenario with a higher similarity than other similarities with the demand point.

[0059] In this step, if there are any requirements that fail to match a business scenario via keyword matching, the system will further calculate the similarity between the requirement and each business scenario in the security requirements corpus, and then associate the business scenario with a higher similarity than the others with the requirement. Specifically, for requirements that fail to match a business scenario, the target review model will vectorize the text content of the requirement and the description of each business scenario in the security requirements corpus. Then, using a text similarity calculation algorithm, such as the cosine similarity algorithm, it calculates the cosine similarity between the requirement vector and each business scenario vector. Furthermore, all calculated similarity values ​​are compared, and the business scenario with the highest similarity is selected. This business scenario is then associated with the unmatched requirement, and the association database is updated. For example, if there is a requirement for "Ensuring the stable operation of medical imaging diagnostic software in the cloud" for which keyword matching fails to find a suitable business scenario, the target review model will vectorize the text content of the requirement and the description of each business scenario in the security requirements corpus. Using the cosine similarity algorithm, we calculated the cosine similarity between this demand point vector and business scenario vectors such as "patient information management," "medical equipment access," "telemedicine services," "electronic medical record system," and "medical insurance reimbursement process." After comparison, we found that the "medical equipment access" business scenario had the highest similarity. Therefore, we associated "medical equipment access" with this demand point and updated the association database.

[0060] S43. In combination with the business scenario keywords in the analysis prompt words, a demand point to be analyzed is selected from all demand points, and the business scenario associated with the demand point to be analyzed is matched with the business scenario keywords.

[0061] In this step, the target review model extracts business scenario keywords from the analysis prompt words. In the medical scenario, the business scenario keywords of the analysis prompt words may be "electronic medical record system" and "medical insurance reimbursement process". Next, the association information of all demand points and business scenarios in the associated database is traversed to check whether the business scenario description associated with each demand point contains the business scenario keywords. If it does, the demand point is marked as a demand point to be analyzed, forming a set of demand points to be analyzed. For example, the business scenario keyword of the analysis prompt word is "fund transaction". The target review model traverses the associated database to check whether the business scenario description associated with the demand point contains "fund transaction". If the business scenario associated with a demand point is "fund transaction", it is marked as a demand point to be analyzed, forming a set of demand points to be analyzed.

[0062] S44. For each demand point to be analyzed, according to the business scenario associated with the demand point to be analyzed, determine the structured text corresponding to the business scenario in the security requirement corpus, analyze the demand point to be analyzed based on the structured text, and generate an analysis result.

[0063] Specifically, for each requirement point in the set of requirements to be analyzed, the target review model searches the security requirements corpus for the structured text corresponding to that business scenario, based on its associated business scenario. The model compares and analyzes the content of the requirement point to be analyzed with the structured text, checking whether the requirement point meets the compliance requirements in the structured text, whether there are any risk vulnerabilities, and whether it conforms to the defense logic. The analysis process can use a combination of rule matching and machine learning algorithms. If the requirement point does not meet the compliance requirements in the structured text, has risk vulnerabilities, or does not conform to the defense logic, it is determined to be a defective requirement point. If it meets the compliance requirements, does not have any risk vulnerabilities, and conforms to the defense logic, it is determined to be a positive requirement point, thus generating the analysis results.

[0064] S45. Generate review results corresponding to the demand points to be analyzed based on the analysis results.

[0065] If the analysis results indicate that the target requirement is defective, the system determines the defect cause, the strategy to be supplemented, and the risk level based on the structured text. Ultimately, these factors are aggregated to produce the review result for the target requirement. Specifically, if the target requirement is determined to be defective, the target review model analyzes the structured text again to determine the defect cause. It then searches for corresponding remediation solutions, compliance requirements, and defense logic, and generates the strategy to be supplemented based on the findings. Furthermore, based on pre-defined risk assessment criteria, it determines a risk level (e.g., high, medium, or low). Finally, the defect cause, strategy to be supplemented, and risk level are integrated to form the review result for the target requirement, which is recorded in the review result database. If the analysis results indicate that the target requirement is positive, the target review model directly generates a risk-free review result record and stores it in the review result database, indicating that the target requirement meets the security requirements of the business scenario and poses no security risks.

[0066] For example, if the analysis results determine that a requirement is positive, the target review model generates a risk-free review result record and stores it in the review result database. If a requirement, "Allowing large fund transfers without identity verification," is identified as a defective requirement, the target review model analyzes the structured text corresponding to "Fund Transaction" and determines that the defect is caused by a lack of an authentication mechanism. It then searches for a remediation solution, such as adding multi-factor authentication, and generates a policy to be supplemented. Based on the risk assessment criteria, the risk level is determined to be high. Finally, the defect cause, supplementary policy, and risk level are integrated to form the review result for that requirement and recorded in the review result database.

[0067] S50. Aggregate the review results corresponding to each demand point to be analyzed to obtain the analysis results corresponding to the demand document to be identified.

[0068] To comprehensively assess the security and compliance of the requirement document to be identified, the review results for each requirement point to be analyzed must be integrated and presented in an intuitive manner. Specifically, in this step, the system will sort the review results for each requirement point to be analyzed based on its corresponding risk level, then aggregate the sorted review results to obtain the analysis results for the requirement document to be identified and display them.

[0069] Specifically, the system accurately ranks the review results for each requirement point to be analyzed based on a pre-defined risk level standard. This risk level standard is developed based on a comprehensive consideration of multiple factors, including the security requirements of the business scenario, the potential scope of impact, and the potential losses. The target review model iterates over the review results for all requirement points to be analyzed and ranks them from high to low (or low to high based on actual requirements) based on the risk level information contained within. For example, review results with a "high" risk level are ranked first, those with a "medium" risk level are ranked next, and those with a "low" risk level are ranked last. Next, the ranked review results are integrated to form a comprehensive and systematic analysis of the requirement document to be identified. During the aggregation process, key information from each review result, such as the cause of the defect, the strategy to be supplemented, and the risk level, is retained. At the same time, relevant information is categorized, summarized, and organized to clearly present the security status of the entire requirement document to be identified. Finally, the resulting analysis results of the requirement document to be identified are displayed.

[0070] It should be noted that in healthcare scenarios, risk rating standards comprehensively consider multiple factors, including the business scenario's security requirements, potential impact, and potential losses. For example, business scenarios involving patient safety, such as surgical decision support systems, have extremely high security requirements, the potential impact directly affects patients' lives, and a problem could result in significant losses. Therefore, the corresponding risk level for such scenarios is high. Conversely, non-critical business scenarios, such as internal hospital announcement systems, have relatively low security requirements, a smaller potential impact, and limited potential losses. Therefore, the risk level is low. Business scenarios falling between these two levels, such as electronic medical record query systems, are assigned a medium risk level. In financial scenarios, risk rating standards also incorporate multiple factors. Business scenarios involving large-scale financial transactions and sensitive customer information, such as online banking fund transfers, have extremely high security requirements, the potential impact could affect the financial security of numerous customers, and a problem could result in significant losses. Therefore, the risk level is high. For general financial business report generation needs, which have relatively low security requirements and a potential impact primarily on internal data display and analysis, resulting in relatively small losses, the risk level is set to Low. For intermediate business scenarios, such as financial product recommendation systems, the risk level is set to Medium.

[0071] The method provided in an embodiment of the present application first obtains security data from multiple data sources and constructs a security requirement corpus based on the security data. The security requirement corpus includes multiple structured texts, each of which includes but is not limited to business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and repair solution fields. Furthermore, training samples are generated based on the structured texts recorded in the security requirement corpus, and the pre-built security requirement review model is trained using the training samples to obtain a target review model. Next, in response to the user uploading the requirement document to be identified and the analysis prompt words, the requirement document to be identified and the analysis prompt words are input into the target review model, and the requirement document to be identified is split into multiple requirement text blocks based on the target review model. Subsequently, based on the target review model, the analysis prompt words are used to screen the requirement points to be analyzed from all the requirement points, and the business scenario corresponding to each requirement point to be analyzed is determined, and the review results corresponding to each requirement point to be analyzed are determined based on the business scenario and the security requirement corpus. Finally, the review results corresponding to each requirement point to be analyzed are aggregated to obtain the analysis results corresponding to the requirement document to be identified, and the analysis results are displayed. The embodiments of this application solve the problems of low efficiency and incomplete coverage of traditional manual review through automation, structured data-driven and dynamic adaptation technology, significantly improve the quality and security of requirement document analysis, and provide an efficient tool for security requirement management in complex business scenarios.

[0072] Further, as Figure 1 The specific implementation of the method, the embodiment of the present application provides a demand document analysis device, such as Figure 3 As shown, the system includes: an acquisition module 301, a training module 302, a splitting module 303, a screening module 304, and an output module 305.

[0073] The acquisition module 301 is configured to acquire security data from multiple data sources and construct a security requirements corpus based on the security data. The security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and repair solution fields.

[0074] The training module 302 is configured to generate training samples based on the structured text recorded in the security requirement corpus, and use the training samples to perform model training on a pre-built security requirement review model to obtain a target review model;

[0075] The splitting module 303 is configured to, in response to a user uploading a requirement document to be identified and an analysis prompt word, input the requirement document to be identified and the analysis prompt word into the target review model, and split the requirement document to be identified into a plurality of requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point;

[0076] The screening module 304 is configured to screen the demand points to be analyzed from all demand points based on the target review model and the analysis prompt words, determine the business scenario corresponding to each demand point to be analyzed, and determine the review result corresponding to each demand point to be analyzed based on the business scenario and the security requirements corpus;

[0077] The output module 305 is used to aggregate the review results corresponding to each of the demand points to be analyzed to obtain the analysis results corresponding to the demand documents to be identified.

[0078] In a specific application scenario, the acquisition module 301 is used to acquire security data from multiple data sources, wherein the security data includes legal and regulatory texts, ATTACK attack models, and security vulnerability cases; the legal and regulatory texts are subjected to clause parsing and keyword extraction processing to obtain a compliance requirement set, and the ATTACK attack model is subjected to tactical and technical standardization and business scenario mapping processing to obtain an attack-defense association table, and the security vulnerability cases are subjected to root cause analysis and structured extraction processing of repair solutions to obtain a vulnerability repair knowledge base; the compliance requirement set, the attack-defense association table, and the vulnerability repair knowledge base are subjected to multi-source data fusion and field mapping processing to obtain multiple structured texts, and a business scenario field and a risk level field are added to each structured text, and the multiple structured texts after the fields are added are aggregated to obtain the security requirement corpus, wherein each structured text corresponds to a business scenario.

[0079] In a specific application scenario, the training module 302 is used to generate positive demand points and defect demand points for each business scenario based on the structured text recorded in the security demand corpus, and mark them with risk-free labels and risk-existing labels, wherein the positive demand points are used to indicate demand points that do not have risk loopholes, meet compliance requirements and comply with defense logic, and the defect demand points are used to indicate demand points that have risk loopholes or do not meet compliance requirements or do not comply with defense logic. The defect demand points are also marked with strategies to be supplemented, associated historical vulnerabilities and corresponding risk levels; at least two demand points are randomly determined from all the generated demand points, and based on natural language processing technology, the at least two demand points are combined into a demand document, and the demand point starting boundary and the demand point ending boundary are marked for the demand document; the marked demand document is used as a training sample.

[0080] In a specific application scenario, the splitting module 303 is used to perform format standardization processing on the demand document to be identified uploaded by the user, and jointly input the analysis prompt words and the demand document into the target review model; the functional verbs in the demand document are identified as the starting signals of the demand points through the target review model, and based on the dependency syntactic analysis technology, the sentence trunk structure is constructed to determine the logical boundaries of the demand points; according to the starting signals and logical boundaries corresponding to each demand point, the demand document is split to obtain multiple demand text blocks.

[0081] In a specific application scenario, the screening module 304 is used to match business scenarios for each demand point in the security demand corpus and associate the demand point with the corresponding business scenario; if there is a demand point that does not match the business scenario, the similarity between the demand point and each business scenario in the security demand corpus is calculated, and the business scenario with higher similarity than other similarities is associated with the demand point; in combination with the business scenario keywords in the analysis prompt words, the demand point to be analyzed is selected from all demand points, and the business scenario associated with the demand point to be analyzed is matched with the business scenario keywords; for each demand point to be analyzed, according to the business scenario associated with the demand point to be analyzed, the structured text corresponding to the business scenario is determined in the security demand corpus, the demand point to be analyzed is analyzed based on the structured text, and an analysis result is generated; and a review result corresponding to the corresponding demand point to be analyzed is generated according to the analysis result.

[0082] In a specific application scenario, the screening module 304 is used to determine the defect cause, the strategy to be supplemented and the risk level based on the structured text if the analysis result indicates that the demand point to be analyzed is a defect demand point, aggregate the defect cause, the strategy to be supplemented and the risk level, and obtain the review result corresponding to the demand point to be analyzed; if the analysis result indicates that the demand point to be analyzed is a positive demand point, generate a review result indicating no risk.

[0083] In a specific application scenario, the output module 305 is used to sort the review results of each demand point to be analyzed according to the risk level corresponding to each demand point to be analyzed, aggregate the sorted review results, obtain the analysis results corresponding to the demand document to be identified, and display them.

[0084] The apparatus provided in an embodiment of the present application first acquires security data from multiple data sources and constructs a security requirements corpus based on the security data. The security requirements corpus includes multiple structured texts, each of which includes, but is not limited to, business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and remediation solution fields. Furthermore, training samples are generated based on the structured text recorded in the security requirements corpus, and the training samples are used to train a pre-built security requirements review model to obtain a target review model. Next, in response to a user uploading a requirement document to be identified and analysis prompts, the requirement document to be identified and the analysis prompts are input into the target review model. Based on the target review model, the requirement document to be identified is split into multiple requirement text blocks. Subsequently, based on the target review model, the analysis prompts are used to filter the requirement points to be analyzed from all the requirement points, determine the business scenario corresponding to each requirement point to be analyzed, and determine the review results corresponding to each requirement point to be analyzed based on the business scenario and the security requirements corpus. Finally, the review results corresponding to each requirement point to be analyzed are aggregated to obtain the analysis results corresponding to the requirement document to be identified, and the analysis results are displayed. The embodiments of this application solve the problems of low efficiency and incomplete coverage of traditional manual review through automation, structured data-driven and dynamic adaptation technology, significantly improve the quality and security of requirement document analysis, and provide an efficient tool for security requirement management in complex business scenarios.

[0085] It should be noted that for other corresponding descriptions of the functional units involved in the power distribution network power restoration device provided in the embodiment of the present application, reference can be made to Figure 1 and Figure 2 The corresponding description in will not be repeated here.

[0086] To solve the above technical problems, the embodiment of the present invention also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0087] like Figure 4As shown, a schematic diagram of the internal structure of a computer device. The computer device includes a processor, a non-volatile storage medium, a memory and a network interface connected via a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database and computer-readable instructions, and the database may store a control information sequence. When the computer-readable instructions are executed by the processor, the processor can implement a data relationship reconstruction method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute a data relationship reconstruction method. The network interface of the computer device is used to connect and communicate with the terminal. Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0088] In this embodiment, the processor is used to execute Figure 3 The memory stores the program code and various data required to execute the specific functions of the acquisition module 301, training module 302, splitting module 303, screening module 304, and output module 305. The network interface is used to transmit data between user terminals or servers. The memory in this embodiment stores the program code and data required to execute all submodules in the data relationship reconstruction device. The server can call the server's program code and data to execute the functions of all submodules.

[0089] The present invention also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the data relationship reconstruction method in any of the above embodiments.

[0090] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0091] The present invention also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the data relationship reconstruction method in any of the above embodiments.

[0092] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0093] Those skilled in the art will appreciate that the steps, measures, and schemes in the various operations, methods, and processes discussed in this application may be interchanged, modified, combined, or deleted. Furthermore, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be interchanged, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and schemes in the prior art that are similar to those disclosed in this application may also be interchanged, modified, rearranged, decomposed, combined, or deleted.

[0094] The above description is only part of the implementation methods of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for analyzing a requirements document, characterized in that: include: Acquire security data from multiple data sources and construct a security requirements corpus based on the security data, wherein the security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenarios, risk levels, compliance requirements, attack models, historical vulnerabilities, and remediation solution fields; Generating training samples based on the structured text recorded in the security requirement corpus, and using the training samples to train a pre-built security requirement review model to obtain a target review model; In response to a user uploading a requirement document to be identified and an analysis prompt word, the requirement document to be identified and the analysis prompt word are input into the target review model, and the requirement document to be identified is split into a plurality of requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point; Based on the target review model, using the analysis prompt words, screening the demand points to be analyzed from all the demand points, and determining the business scenario corresponding to each of the demand points to be analyzed, and determining the review result corresponding to each of the demand points to be analyzed based on the business scenario and the security requirements corpus; Aggregate the review results corresponding to each of the demand points to be analyzed to obtain the analysis results corresponding to the demand document to be identified.

2. The method according to claim 1, characterized in that The step of acquiring security data from multiple data sources and constructing a security requirement corpus based on the security data includes: Acquire security data from multiple data sources, including legal and regulatory texts, ATTACK attack models, and security vulnerability cases; Perform clause parsing and keyword extraction on the legal and regulatory texts to obtain a set of compliance requirements, perform tactical and technical standardization and business scenario mapping on the ATTACK attack model to obtain an attack-defense association table, and perform root cause analysis and structured extraction of repair solutions on the security vulnerability cases to obtain a vulnerability repair knowledge base; Multi-source data fusion and field mapping processing are performed on the compliance requirement set, the attack defense association table and the vulnerability repair knowledge base to obtain multiple structured texts, and a business scenario field and a risk level field are added to each of the structured texts. The multiple structured texts after the fields are added are aggregated to obtain the security requirement corpus, wherein each of the structured texts corresponds to a business scenario.

3. The method according to claim 1, characterized in that Generating training samples based on the structured text recorded in the security requirement corpus includes: Based on the structured text recorded in the security requirements corpus, positive demand points and defect demand points are generated for each business scenario, and are marked with risk-free labels and risk-existing labels. The positive demand points are used to indicate demand points that do not have risk vulnerabilities, meet compliance requirements, and conform to defense logic. The defect demand points are used to indicate demand points that have risk vulnerabilities, do not meet compliance requirements, or do not conform to defense logic. The defect demand points are also marked with strategies to be supplemented, associated historical vulnerabilities, and corresponding risk levels. Randomly determine at least two demand points from all generated demand points, combine the at least two demand points into a demand document based on natural language processing technology, and mark the demand point start boundary and the demand point end boundary for the demand document; The annotated requirement documents are used as training samples.

4. The method according to claim 1, wherein In response to a user uploading a requirement document to be identified and an analysis prompt word, the requirement document to be identified and the analysis prompt word are input into the target review model, and the requirement document to be identified is split into multiple requirement text blocks based on the target review model, including: Performing format standardization on the requirement document to be identified uploaded by the user, and inputting the analysis prompt words and the requirement document into the target review model; Identifying functional verbs in the requirement document as starting signals of requirement points through the target review model, and constructing sentence trunk structures based on dependency syntactic analysis technology to determine the logical boundaries of requirement points; The demand document is split according to the starting signal and logical boundary corresponding to each demand point to obtain multiple demand text blocks.

5. The method according to claim 1, wherein The target review model is based on the target review model, and the analysis prompt words are used to screen the demand points to be analyzed from all the demand points, and the business scenario corresponding to each of the demand points to be analyzed is determined, and the review result corresponding to each of the demand points to be analyzed is determined according to the business scenario and the security requirement corpus, including: Matching a business scenario to each requirement point in the security requirement corpus and associating the requirement point with the corresponding business scenario; If there is a demand point that does not match the business scenario, calculate the similarity between the demand point and each business scenario in the security demand corpus, and associate the business scenario with a higher similarity than other similarities with the demand point; In combination with the business scenario keywords in the analysis prompt words, the demand point to be analyzed is selected from all demand points, and the business scenario associated with the demand point to be analyzed matches the business scenario keywords; For each of the demand points to be analyzed, according to the business scenario associated with the demand point to be analyzed, determining a structured text corresponding to the business scenario in the security requirement corpus, analyzing the demand point to be analyzed based on the structured text, and generating an analysis result; Generate the review results corresponding to the corresponding demand points to be analyzed based on the analysis results.

6. The method according to claim 5, characterized in that Generating the review results corresponding to the demand points to be analyzed based on the analysis results includes: If the analysis result indicates that the demand point to be analyzed is a defective demand point, the defect cause, the strategy to be supplemented, and the risk level are determined based on the structured text, and the defect cause, the strategy to be supplemented, and the risk level are aggregated to obtain a review result corresponding to the demand point to be analyzed; If the analysis result indicates that the demand point to be analyzed is a positive demand point, an evaluation result indicating no risk is generated.

7. The method according to claim 1, characterized in that The aggregating the review results corresponding to each demand point to be analyzed to obtain the analysis results corresponding to the demand document to be identified includes: sorting the review results of each demand point to be analyzed according to the risk level corresponding to each demand point to be analyzed, aggregating the sorted review results, obtaining the analysis results corresponding to the demand document to be identified and displaying them.

8. A demand document analysis device, characterized in that: include: An acquisition module, configured to acquire security data from multiple data sources and construct a security requirements corpus based on the security data, wherein the security requirements corpus includes multiple structured texts, each of which includes but is not limited to business scenario, risk level, compliance requirements, attack model, historical vulnerability, and repair solution fields; A training module, configured to generate training samples based on the structured text recorded in the security requirements corpus, and use the training samples to perform model training on a pre-built security requirements review model to obtain a target review model; a splitting module for, in response to a user uploading a requirement document to be identified and an analysis prompt word, inputting the requirement document to be identified and the analysis prompt word into the target review model, and splitting the requirement document to be identified into a plurality of requirement text blocks based on the target review model, wherein each requirement text block corresponds to a requirement point; a screening module for screening demand points to be analyzed from all demand points based on the target review model and the analysis prompt words, determining the business scenario corresponding to each demand point to be analyzed, and determining the review result corresponding to each demand point to be analyzed based on the business scenario and the security requirements corpus; The output module is used to aggregate the review results corresponding to each of the demand points to be analyzed to obtain the analysis results corresponding to the demand documents to be identified.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images