A knowledge mapping system and analysis method for software reliability requirements

Abstract

This invention proposes a knowledge mapping system and analysis method for software reliability requirements, belonging to the field of software reliability requirements analysis. This method constructs a standardized requirements modeling system comprising an external cross-linking interface model, a functional logic model, a functional combination model, and a state scenario model to achieve a formal representation of software requirements. It then decomposes and summarizes individual functional requirements, identifies potential failure modes based on a pre-defined classification and comparison system, and establishes a three-layer mapping system of software functional requirements – failure modes – reliability requirements. This completes the forward derivation and transformation of reliability requirements, outputting standardized analysis results. This invention achieves standardized and traceable processing of software reliability requirements analysis, providing prerequisite input and logical basis for the development of highly reliable software, ensuring system stability and task success.

Description

Technical Field

[0001] This invention belongs to the field of software reliability requirements analysis, specifically relating to a method for software reliability requirements analysis. More specifically, this invention relates to a technical solution that derives software reliability requirements by structurally representing software requirements, identifying potential software failure modes, establishing a correspondence between software requirements and software failure modes, and further deriving software reliability requirements. Background Technology

[0002] With the profound development of informatization and intelligentization, software has become a core component of systems in key fields such as industrial control, rail transportation, and aerospace. The reliability of software directly determines the overall functional completion capability, operational stability, and mission success rate of the system. Failures caused by software defects can directly lead to catastrophic consequences; therefore, ensuring software reliability has become a core aspect of system development.

[0003] Software reliability requirements analysis, as a core preliminary step in software engineering and reliability engineering, aims to identify potential failure risks from software functional requirements early in the software development process. It clarifies the reliability requirements the software must meet in areas such as anomaly handling, fault detection, fault tolerance and recovery, timing constraints, data integrity, and continuous operation capability, providing a core basis for subsequent design, development, testing, and verification. Compared to post-event failure analysis and operational reliability assessment, reliability analysis during the requirements phase emphasizes proactive prevention, enabling early control of software failure risks at the lowest cost. This is a crucial foundation for ensuring highly reliable software operation.

[0004] National military standards such as GJB 450A and GJB 11619.1, as well as the international standard IEC 61508-3, all clearly require that systematic reliability analysis be conducted during the software requirements phase to identify potential failure modes and formulate corresponding reliability requirements. Currently, commonly used software reliability analysis techniques in the industry mainly include Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and Preliminary Hazard Analysis (PHA). Among these, FMEA is the most widely used failure analysis method, its core being the identification of potential system failures and risks through a six-step method for optimization and improvement. However, the application of these techniques in software requirements analysis scenarios still faces many challenges and technological gaps.

[0005] First, traditional analysis methods heavily rely on human experience, making it difficult to guarantee efficiency and consistency. Current software reliability requirements analysis primarily relies on manual reading of requirements documents, expert judgment, and group discussions. On the one hand, requirements documents are often presented in unstructured natural language, are lengthy and logically complex, making the manual extraction of reliability-related key points laborious, inefficient, and prone to missing critical requirements. On the other hand, the quality of analysis is highly dependent on the domain knowledge and engineering experience of the analysts; different personnel may have differing understandings of the same requirement, leading to inconsistent requirements extraction standards and analysis results, making it difficult to meet the standardized requirements of high-reliability software development. With the continuous increase in the complexity of software systems, traditional manual methods are no longer suitable for the rapid iterative development needs of modern software engineering.

[0006] Second, classic reliability analysis techniques have inherent limitations and are insufficiently coupled with software requirements. Existing techniques such as FMEA and FTA are mostly static and unidirectional analysis methods, focusing on identifying common failure phenomena without establishing a deep analytical logic bound to software functional requirements. This makes it impossible to achieve end-to-end tracing from the source of requirements to the consequences of failure. At the same time, existing technologies are difficult to cover failure modes caused by complex dynamic logic such as the combination of software functions, concurrency, timing constraints, and state transitions. The analysis of failure propagation paths has many blind spots and cannot adapt to the reliability analysis needs of highly complex embedded software.

[0007] Third, there is a lack of standardized software requirements modeling systems, resulting in inconsistent analytical foundations. Existing technologies have not formed a standardized requirements modeling system for software reliability analysis, making it impossible to provide a unified formal expression for software's external interface interactions, internal functional logic, multi-functional combination relationships, and full-state operation scenarios. Industry standards such as GJB / Z 102A and GJB / Z 142 only provide general requirements for software reliability design and analysis, without specifying standardized modeling methods for software requirements. This leads to inconsistent analytical inputs across different projects and personnel, resulting in extremely poor comparability and reusability of analysis results.

[0008] Fourth, the lack of a systematic set of analysis rules and requirements mapping relationships leads to poor engineering implementation. Existing national and international standards only provide a macro framework for software reliability analysis, failing to establish a comprehensive and executable system of analysis rules that corresponds one-to-one with software requirements dimensions, resulting in poor engineering operability. Furthermore, existing technologies have not established a standardized mapping chain of "software functional requirements - failure modes - reliability requirements." The generated reliability requirements lack clear logical basis and failure sources, resulting in insufficient traceability and verifiability, making it difficult to directly implement them in subsequent design, development, and testing phases, leading to a disconnect between requirements analysis and engineering implementation.

[0009] Based on this, the core idea of ​​this invention is to introduce a standardized knowledge mapping system and analysis method to solve the problems of non-standard and untraceable software reliability requirement analysis in the development of highly reliable software. Summary of the Invention

[0010] This invention addresses the problems of existing software reliability requirements analysis, such as heavy reliance on human experience, inconsistent analysis results, insufficient coupling with software requirements, lack of standardized modeling systems, and poor engineering applicability. It proposes a knowledge mapping system and analysis method for software reliability requirements. This invention unifies the input basis for software reliability analysis by constructing a standardized requirements modeling system and establishing a derivable three-layer mapping system of "software functional requirements - failure modes - reliability requirements," providing a clear logical basis and traceability chain for generating software reliability requirements.

[0011] The present invention provides a knowledge mapping system and analysis method for software reliability requirements, the implementation steps of which are as follows:

[0012] Step 1: Software Requirements Model Construction. Based on the functional requirements, construct a requirements model, sequentially completing the construction of the external interface model, functional logic model, functional combination model, and state scenario model, thus achieving a formal representation of the software requirements.

[0013] Step Two: Software Functional Requirements Analysis and Failure Mode Matching. Using functional requirements as the core, the functional execution process is broken down, constraints are summarized, and scenarios are analyzed to form a standardized list of individual requirements. Based on a classification and comparison system, a one-to-one correspondence between the requirement model and failure modes is used to match the requirement model with failure modes, identify possible failure modes, and ensure comprehensive analysis coverage.

[0014] Step 3: Constructing the "Functional Requirements - Failure Modes - Reliability Requirements" Mapping System. Based on the knowledge base, requirement model, and requirement summarization results, establish a three-layer mapping system for each requirement to complete failure mode identification, control measure formulation, and reliability requirement transformation.

[0015] Step 4: Output standardized analysis results. This includes a software requirements model set and failure mode and reliability requirements tables / documents.

[0016] In step one, the software requirements model includes an external cross-linking interface model, a functional logic model, a functional combination model, and a state scenario model. These four sub-models complement each other to form a complete structured representation system covering static interfaces and dynamic behaviors, single-function logic and multi-function combinations, and single scenarios to the entire state space.

[0017] The external cross-linking interface model defines the system boundary between the software and the external environment, describes the input and output interface information between the software and external cross-linking entities, and is the core carrier of interface-based failure mode analysis. Its modeling elements include five core elements: external interaction entities, cross-linking input interfaces, cross-linking output interfaces, the software to be analyzed, and annotations. Among these, external cross-linking entities encompass external objects that interact with the software in terms of data and control, such as sensors, actuators, cross-linking systems, operators, and storage devices; interface types cover all types of software interfaces, including discrete quantities, analog quantities, bus data, serial port data, and file interfaces.

[0018] The functional logic model describes the internal execution logic of the software's lowest-level atomic functions, namely, the function's processing of input data, computational logic, control logic, and output operations. It is the core carrier for functional logic-based failure mode analysis. Its modeling elements include functional execution processing units, functional input interaction interfaces, functional output interaction interfaces, execution decision nodes, execution flow paths, execution start nodes, execution end nodes, external interaction entities, and model annotation information. Among these, execution decision nodes include logical execution decision and temporal execution decision, and execution flow paths include sequential execution flow, conditional execution flow, and concurrent execution flow.

[0019] The functional combination model is used to describe the reliability constraints such as hierarchical subordination, concurrent mutual exclusion, and priority scheduling among all functional units of the software, and it fundamentally addresses the blind spot problem in reliability failure mode analysis under multi-functional interactive scenarios. Its modeling elements include software functional interaction units, hierarchical aggregation relationships, interactive reliability constraints, and model annotation identifiers.

[0020] The state scenario model is used to describe various operating states and working modes of the software, the transition conditions and constraints between states, and the association between states and functions and interfaces, covering the failure mode analysis requirements of the entire software operating scenario. Its modeling elements include operating modes and working modes, mode transition conditions, mode start nodes, mode end nodes, mode associated functional units, and model annotation information.

[0021] Step two, the software functional requirements analysis and summarization specifically includes: breaking down a single software functional requirement into three elements: execution, processing, and output, clarifying the input source, processing logic, and output destination; extracting the timing, value, concurrency, and exception constraints of the functional requirements; sorting out the operational scenarios, related interfaces, and state dependencies of the functional requirements; and organizing the decomposition, extraction, and summarization results into a single functional requirement analysis list with a unified format and unified dimensions to eliminate the bias of manual analysis.

[0022] The classification and comparison system corresponds one-to-one with the software functional requirement sub-model and is divided into four categories: external cross-linking interface comparison system, functional logic comparison system, functional combination comparison system, and state scenario comparison system. It is used to determine the software failure modes corresponding to the functional requirements, and then formulate corresponding control measures to determine the software reliability requirements.

[0023] This classification and comparison system is pre-formed based on nine national / international standards through structured analysis and knowledge extraction, and includes a standardized knowledge base for software reliability and a failure mode classification system. The nine national / international standards include: GJB / Z102A-2012 "Guidelines for Security Design of Military Software", GJB / Z 142-2004 "Guidelines for Security Analysis of Military Software", GJB8114-2013 "Safety Subset of C / C++ Language Programming", GJB / Z 102-1997 "Software Reliability and Security Design Criteria", GJB 450A-2004 "General Requirements for Equipment Reliability Operation", GJB / Z 768A-1998 "Guidelines for Fault Tree Analysis", GJB11619.1-2024 "Working Requirements for Quality Characteristics of Military Software - Part 1: Reliability", GJB 11619.2-2024 "Working Requirements for Quality Characteristics of Military Software - Part 2: Security", and IEC 61508-3:2010 "Electrical and Electronic / Programmable Functional Safety Electronic Safety Related Systems - Part 3: Software Requirements".

[0024] In step three, the core logic of the "functional requirements-failure mode-reliability requirements" mapping system is as follows: taking software functional requirements as input, identifying corresponding potential failure modes, and then formulating targeted reliability requirements for each failure mode, forming a derivation chain of "software functional requirements → failure mode → reliability requirements". Each mapping item adopts a unified structured format, and the core fields include: software functional requirements, requirement model elements, failure modes, failure mode descriptions, failure cause analysis, control measures, reliability requirements, and standard basis.

[0025] In step four, the standardized analysis results are output, including a software requirements model set and a failure mode and reliability requirements table document.

[0026] The advantages and positive effects of this invention are as follows: First, it constructs a standardized requirement modeling system, unifying the input basis for software reliability analysis and realizing a complete structured representation of software requirements from static interfaces to dynamic behaviors, from single functions to multi-functional combinations, and from single scenarios to the entire state space. Second, it forms a derivable three-layer mapping system, giving reliability requirements a clear logical basis. Each reliability requirement has a clear source of failure modes and functional requirement basis, solving the problems of unfounded reliability requirements, poor traceability, and insufficient verifiability in traditional methods. Third, it forms a complete closed-loop analysis of "requirement modeling - failure analysis - requirement generation - verification and optimization," which can iteratively optimize software functional requirements through reliability analysis results, achieving continuous improvement in software reliability during the requirement phase, and possessing strong engineering applicability and versatility. Attached Figure Description

[0028] Figure 1 This is a flowchart of the overall software reliability requirements analysis methodology;

[0029] Figure 2 It is a software functional requirements model architecture diagram;

[0030] Figure 3 It is a diagram of the analysis process of the "software functional requirements-failure mode-reliability requirements" mapping system. Detailed Implementation

[0031] The technical solutions in the embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0032] This embodiment takes the user login function module of a university online teaching system as the implementation object, and fully implements the analysis method of the present invention. The scenario is simple and universal, and can fully verify the technical effect and whole process logic of the present invention.

[0033] 1. Target audience and implementation basis

[0034] Target audience: User login module of online teaching system for universities.

[0035] Implementation basis: A knowledge base and failure mode classification system for software reliability based on 9 national / international standards have been pre-built as a basis for analysis and comparison.

[0036] List of functional requirements to be analyzed:

[0037] Requirement 1: The system should support users entering their account and password to complete identity verification and return a success or failure result for login.

[0038] Requirement 2: The system should send a graphic verification code to the user and verify the correctness of the input verification code.

[0039] Requirement 3: The system should record user login logs and support querying and exporting login exception logs.

[0040] Requirement 4: The system should automatically lock the account and prohibit login attempts after a user fails to log in 5 times consecutively.

[0041] 2. Specific Implementation Steps

[0042] Step 1: Construct a software requirements model

[0043] For the above four functional requirements, corresponding software requirement models are constructed one by one, including external cross-linking interface model, functional logic model, functional combination model, and state scenario model.

[0044] Model construction for requirement 1 (identity verification):

[0045] ① External cross-linking interface model: The input interface is account input, password input, and login request; the output interface is the login result return interface; the external entities are end users and user information database.

[0046] ② Functional logic model: The trigger condition is that the user clicks the login button; the processing logic is to receive input → format check → account and password comparison → result return; abnormal scenarios are illegal input, database timeout, and comparison failure.

[0047] ③ Function combination model: The timing constraint is to first verify the input format and then perform a database comparison; the mutual exclusion constraint is to prohibit the execution of this function when the account is locked.

[0048] ④ State Scenario Model: The effective state is not logged in; the output state after execution is login successful / login failed.

[0049] Model construction for requirement 2 (CAPTCHA issuance and verification):

[0050] ① External cross-linking interface model: The input interface is the verification code input and verification code refresh request; the output interface is the verification code image distribution interface and the verification code verification result interface; the external entities are the end user and the verification code generation service.

[0051] ② Functional logic model: The trigger condition is page loading / refresh; the processing logic is to generate a verification code → send an image → receive input → compare and verify → return the result; the abnormal scenarios are verification code expiration, input timeout, and incorrect format.

[0052] ③ Functional combination model: The timing constraint is that the verification code verification takes precedence over the account and password verification; the mutual exclusion constraint is that login verification is prohibited when the verification code expires.

[0053] ⑤ State Scenario Model: The effective state is "not logged in"; the output state after execution is "verification passed" or "verification failed".

[0054] Model construction for requirement 3 (login log recording):

[0055] ① External cross-linking interface model: The input interface is login result feedback and user operation information; the output interface is log query interface and log export interface; the external entities are end users and log storage database.

[0056] ② Functional logic model: The trigger condition is the completion of the login operation; the processing logic is to collect log information → store logs → respond to query / export requests; the abnormal scenarios are log storage failure, query timeout, and export interruption.

[0057] ③ Functional combination model: Concurrency constraints are that logging and login verification are executed asynchronously, without blocking the main process.

[0058] ④ State Scenario Model: The effective state is the full login cycle; the output state after execution is the log stored state.

[0059] Model construction for requirement 4 (account lockout):

[0060] ① External cross-linking interface model: The input interface is the login failure record; the output interface is the account lockout prompt interface and the lockout release interface; the external entities are the end users and the user information database.

[0061] ② Functional logic model: The trigger condition is that the number of consecutive failed login attempts reaches a certain threshold; the processing logic is: counting statistics → triggering lock → restricting login → recording lock information; abnormal scenarios are: counting error, lock failure, and unlocking error.

[0062] ③ Function combination model: Mutual exclusion constraint prohibits all login-related function calls when the system is locked.

[0063] ④ State Scenario Model: The effective state is login failure; the output state after execution is account locked.

[0064] Step 2: Analyze and summarize software functional requirements, and identify corresponding failure modes.

[0065] Each of the four requirements was standardized and summarized, forming an analysis checklist. The following is an excerpt of the core content:

[0066] Requirement 1 Summary: Input is username and password; processing involves format validation and identity verification; output is login result; constraint is username as a 6-20 character alphanumeric combination; scenario is user login.

[0067] Requirement 2 summary: Inputs are verification code input and refresh requests; processing involves generation and verification; output is the verification result; constraint is that the verification code is valid for 5 minutes; scenario is pre-login verification.

[0068] Requirement 3 summary: Inputs are login results and operation information; processing involves recording, storing, and querying; output is log data; constraints are that logs must be immutable and retained for ≥180 days; scenario is the entire login process.

[0069] Requirement 4 Summary: Input is login failure records; processing is counting and locking; output is a lock prompt; constraints are 5 consecutive login failures followed by a 30-minute lock; scenario is abnormal login protection.

[0070] Based on a pre-defined classification and comparison system that corresponds one-to-one with the software functional requirement model (external cross-linking interface comparison system, functional logic comparison system, functional combination comparison system, and state scenario comparison system), the matching and verification are completed to identify the failure mode corresponding to each requirement, ensuring no omissions.

[0071] Step 3: Construct a three-layer mapping system to complete the transformation of reliability requirements.

[0072] This step takes as input a preset domain knowledge base, a software functional requirements model, and a list of individual requirements for analysis. The output is a mapping system library and a set of reliability requirement items. Based on the derivation chain of "software functional requirements - failure modes - reliability requirements," the following four core mapping items are generated, as shown in Tables 1-4.

[0073] Table 1 Mapping Item 1 (Corresponding to Requirement 1: Identity Validation)

[0074] Core fields Field content Single software functional requirement The system should support users entering their username and password to complete identity verification and return a success or failure result for login. Demand Model Elements External cross-linking interface sub-model, account input interface Failure Mode External interface value retrieval failure Failure Mode Description When the account input field receives special characters or excessively long strings, the software lacks filtering and validation logic, leading to SQL injection risks and potential user data leaks. Failure Cause Analysis The requirements did not define the validation criteria for account input, and the functional logic did not cover edge cases such as illegal characters and excessively long text. Control measures Add logic to validate account input, filtering characters and limiting the length of input. Illegal input will be directly blocked without proceeding to the backend database query, and operation logs will be recorded. Reliability requirements The software should validate account input, limiting the input length to 6-20 characters, supporting only combinations of letters and numbers, blocking illegal inputs containing special characters or exceeding the input length limit, with a blocking response time of ≤100ms, and simultaneously logging illegal operations. Standard basis Clause 4.2.3 of GJB / Z 102A-2012 and Clause 7.4.2 of IEC 61508-3:2010

[0075] Table 2 Mapping Item 2 (Corresponding to Requirement 2: Verification Code Issuance and Verification)

[0076] Core fields Field content Single software functional requirement The system should issue a graphical verification code to the user and verify the correctness of the entered verification code. Demand Model Elements External cross-linking interface sub-model, verification code input interface Failure Mode External interface timing failure Failure Mode Description The lack of validity period for verification codes, and their failure to expire after the expiration date, allows them to be reused, posing a security risk. Failure Cause Analysis The requirements do not define a time limit for the CAPTCHA, and do not set a timeout expiration and refresh mechanism. Control measures Added verification code expiration control logic, setting a 5-minute validity period. It automatically expires after the expiration date and supports refreshing. Verification is prohibited after expiration. Reliability requirements The software should set the verification code validity period to 5 minutes, after which it will automatically expire and force a refresh. Expired verification codes will be rejected directly, with a response time of ≤100ms. Standard basis Clause 4.2.3 of GJB / Z 102A-2012 and Clause 7.4.2 of IEC 61508-3:2010

[0077] Table 3 Mapping Entry 3 (Corresponding to Requirement 3: Login Log Recording)

[0078] Core fields Field content Single software functional requirement The system should record user login logs and support querying and exporting login exception logs. Demand Model Elements Functional logic sub-model, log recording function unit Failure Mode Functional logic data processing failure Failure Mode Description Login log storage failed, log data was lost or tampered with, making it impossible to trace login behavior. Failure Cause Analysis The requirements do not define log storage reliability, tamper protection, and abnormal log recording mechanisms. Control measures Added log storage verification, anti-tampering, and exception recovery logic; automatic retry upon storage failure; encrypted and tamper-proof log storage. Reliability requirements The software should ensure 100% storage of login logs, automatically retry 3 times if storage fails, encrypt logs to prevent tampering, and retain them for at least 180 days. Standard basis Clause 4.3.2 of GJB / Z 102A-2012 and Clause 7.5.1 of IEC 61508-3:2010

[0079] Table 4 Mapping Item 4 (Corresponding Requirement 4: Account Lockout)

[0080] Core fields Field content Single software functional requirement The system should automatically lock the account and prevent further login attempts after a user fails to log in five times consecutively. Demand Model Elements Functional sub-model, login failure counting and locking function Failure Mode Function combination mutual exclusion failure Failure Mode Description Even after an account is locked, login attempts can still be made, rendering the locking mechanism ineffective and posing a risk of brute-force attacks. Failure Cause Analysis The requirements did not define mutual exclusion constraints between the locking state and the login function, and no restrictions were placed on function calls. Control measures Add mutual exclusion control logic for locked states, intercept all login requests during the locked period, and output a lock notification. Reliability requirements The software should automatically lock the account after five consecutive failed login attempts, with a lockout period of 30 minutes, during which login functionality should be completely disabled. Standard basis Clause 4.4.1 of GJB / Z 102A-2012 and Clause 7.6.2 of IEC 61508-3:2010

[0081] Step 4: Output standardized analysis results

[0082] Based on the above steps, standardized analysis results are output, including a complete software requirements model set and a "Failure Mode and Reliability Requirements Table Document" integrating all mapping entries. The final output document fragment, shown in Table 5, enables the correlation and traceability of functional requirements, failure modes, and reliability requirements.

[0083] Table 5 Software Reliability Requirements

[0084] Single software functional requirement Demand Model Elements Failure Mode Failure Mode Description Failure Cause Analysis Control measures Reliability requirements The system should support users entering their username and password to complete identity verification. External cross-linking interface sub-model, account input interface External interface value retrieval failure When the account input field receives special characters or excessively long strings, the software lacks filtering and validation logic. The requirement does not define the validity verification requirements for account input. Add logic to validate account input. The software should validate the account input and limit the input length to 6-20 characters. The system should issue a graphical verification code to the user and verify the correctness of the entered verification code. External cross-linking interface sub-model, verification code input interface External interface timing failure The verification code has no validity period limit and does not expire after the timeout. The requirement does not define a time limit for the CAPTCHA. Added verification code validity control logic The software should set the verification code to be valid for 5 minutes. The system should record user login logs and support querying and exporting login exception logs. Functional logic sub-model, log recording function unit Functional logic data processing failure Login log storage failure, log data loss or tampering Undefined requirement for log storage reliability Added log storage verification, anti-tampering, and exception reporting logic. The software should ensure 100% storage of login logs. The system should automatically lock the account and prevent further login attempts after a user fails to log in five times consecutively. Functional sub-model, login failure counting and locking function Function combination mutual exclusion failure You can still attempt to log in even after your account is locked. The requirement does not define a mutual exclusion constraint between the locked state and the login function. Add mutual exclusion control logic for locked states The software should automatically lock the account after five consecutive failed login attempts.

[0085] As can be seen from the above specific implementation methods, the method provided by the present invention constructs a standardized requirements modeling system, unifies the input basis for software reliability analysis, and forms a derivable and traceable three-layer mapping system of "software functional requirements - failure modes - reliability requirements", so that each reliability requirement has a clear logical source, improving the standardization, automation level and engineering implementation capability of software reliability requirements analysis.

Claims

1. A knowledge mapping system and analysis method oriented towards software reliability requirements, characterized in that, To perform software reliability requirements analysis, the following steps are required: Step 1: Software Requirements Model Construction: Build a requirements model for functional requirements, and successively complete the construction of external cross-linking interface model, functional logic model, functional combination model, and state scenario model to realize the formal representation of software requirements; Step 2: Software Functional Requirements Analysis and Failure Mode Matching: Based on functional requirements, complete the decomposition of functional execution process, constraint summarization, and scenario analysis to form a standardized list of single requirements analysis; based on the matching verification of the classification comparison system, adopt the classification comparison system that corresponds one-to-one with the software functional requirements model to match the requirements model with failure modes, identify possible failure modes, and ensure analysis coverage. Step 3: Construction of the "Functional Requirements - Failure Modes - Reliability Requirements" Mapping System: Based on the knowledge base, requirement model, and requirement induction results, a three-layer mapping system for a single requirement is established to complete failure mode identification, control measure formulation, and reliability requirement transformation. The core logic of the three-layer mapping system is: taking software functional requirements as input, identifying the corresponding potential failure modes, and then formulating targeted reliability requirements for each failure mode, forming a derivation chain of "software functional requirements - failure modes - reliability requirements". Step 4: Output standardized analysis results, including software requirements model set and failure mode and reliability requirements table documents.

2. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step one, the external cross-linking interface model is used to define the system boundary between the software and the external environment, describe the input and output interface information between the software and the external cross-linking entity, and is the core carrier of interface-type failure mode analysis. Its modeling elements include five core elements: external interactive entities, cross-linking input interfaces, cross-linking output interfaces, software to be analyzed, and annotations.

3. The knowledge mapping system and analysis method for software reliability requirements according to claim 2, characterized in that, The modeling content of the external cross-linking interface model includes: the name, type, transmission protocol, communication cycle, data format, value range, accuracy requirements, source and destination entities, timing combination and mutual exclusion constraint relationship between interfaces; the fault diagnosis strategy, data verification rules, initialization strategy, safety value strategy, and redundancy voting strategy of the interface; and the fault characteristics, response timing constraints, and physical limit parameters of the external cross-linking entities.

4. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step one, the functional logic model is used to describe the internal execution logic of the lowest-level atomic function of the software, namely the function's processing of input data, calculation logic, control logic and output operation. It is the core carrier of functional logic failure mode analysis. Its modeling elements include functional execution processing units, functional input interaction interfaces, functional output interaction interfaces, execution decision nodes, execution flow paths, execution start nodes, execution end nodes, external interaction entities, and model notes; among them, execution decision nodes include logical execution decision and temporal execution decision, and execution flow paths include sequential execution flow, conditional execution flow, and concurrent execution flow.

5. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step one, the functional combination model is used to describe the hierarchical subordination, concurrent mutual exclusion, and priority scheduling constraint relationships between software functional units, and it is the core solution to the blind spot problem in reliability failure mode analysis under multi-functional interactive scenarios; its modeling elements include software functional interaction units, hierarchical aggregation relationships, interaction constraints, and model annotation identifiers.

6. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step one, the state scenario model is used to describe the various operating states and working modes of the software, the transition conditions and constraints between states, and the association between states and functions and interfaces, covering the failure mode analysis requirements of the entire operating scenario of the software; its modeling elements include operating modes and working modes, mode transition conditions, mode start nodes, mode end nodes, mode associated functional units, and model notes.

7. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step two, the classification comparison system corresponds one-to-one with the software functional requirement sub-model and is divided into four categories: external cross-linking interface comparison system, functional logic comparison system, functional combination comparison system, and state scenario comparison system. These systems are used to determine the software failure modes corresponding to the functional requirements, and then formulate corresponding control measures to determine the software reliability requirements.

8. The knowledge mapping system and analysis method for software reliability requirements according to claim 7, characterized in that, The classification and comparison system is pre-formed based on nine national / international standards through structured analysis and knowledge extraction, and includes a standardized knowledge base for software reliability and a failure mode classification system. The nine national / international standards include: GJB / Z 102A-2012 "Guidelines for Security Design of Military Software", GJB / Z 142-2004 "Guidelines for Security Analysis of Military Software", GJB 8114-2013 "Safety Subset of C / C++ Language Programming", GJB / Z 102-1997 "Software Reliability and Security Design Criteria", GJB 450A-2004 "General Requirements for Equipment Reliability Operation", GJB / Z 768A-1998 "Guidelines for Fault Tree Analysis", GJB 11619.1-2024 "Working Requirements for Quality Characteristics of Military Software - Part 1: Reliability", GJB 11619.2-2024 "Working Requirements for Quality Characteristics of Military Software - Part 2: Security", and IEC 61508-3:2010 "Electrical and Electronic / Programmable Functional Safety Electronic Safety Related Systems - Part 3: Software Requirements".

9. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step two, the software functional requirements analysis and summarization specifically includes: breaking down a single software functional requirement into three elements: execution, processing, and output, clarifying the input source, processing logic, and output destination; extracting the timing, value, concurrency, and exception constraints of the functional requirements; sorting out the operating scenarios, related interfaces, and state dependencies of the functional requirements; and organizing the decomposition, extraction, and summarization results into a single functional requirement analysis list with a unified format and unified dimensions.

10. The knowledge mapping system and analysis method for software reliability requirements according to claim 1, characterized in that, In step three, each mapping entry adopts a unified structured format, and the core fields include: software functional requirements, requirement model elements, failure modes, failure mode descriptions, failure cause analysis, control measures, reliability requirements, and standard basis.

Images