A method and system for evaluating deviation between software requirements and code development

Abstract

The application discloses a kind of deviation degree evaluation method and system between software requirement and code development, it is related to software engineering analysis technical field, including: the chapter title in software requirement specification, table and list item content are matched with functional requirement, according to the matching result, to the corresponding text content, extract the subject and action of function and the object and condition of action, and get requirement function point sentence according to set sentence pattern rule assembly;After extracting syntax unit and function call relationship from code generation, it is matched with the word in the preset code feature library, and the code function point sentence is obtained;According to requirement function point sentence and code function point sentence, calculate deviation degree, combined with preset deviation threshold, obtain evaluation result.Through the difference between code and expected requirement target, objectively evaluate code development deviation degree, solve the problems, such as inefficient collaboration, quality out of control and requirement disconnection, existing in large-scale code development.

Description

Technical Field

[0001] This invention relates to the field of software engineering analysis technology, and in particular to a method and system for evaluating the deviation between software requirements and code development. Background Technology

[0002] As software projects evolve from small to medium-sized monolithic applications to large-scale distributed systems, development teams expand, often involving multiple teams and cross-regional collaboration, leading to an exponential increase in code volume. This results in the following problems:

[0003] (1) Different developers have different understandings of software requirements and design documents, which leads to inconsistencies between the code style and logic implementation and expectations (such as architecture design and module responsibilities).

[0004] (2) Newly joined developers are not familiar with the project’s historical design specifications and are prone to writing code that deviates from the original architectural constraints, such as violating layered design and interface contracts.

[0005] (3) When there is a lack of unified deviation measurement indicators, the team will find it difficult to efficiently align development standards, which will lead to frequent disputes during code review, difficulties in later integration, and increased collaboration costs.

[0006] In software development, changes in software requirements and design iterations are commonplace. However, if code implementation doesn't keep pace, it can lead to a disconnect between code, design, and requirements. For example, a design document might require a module to use an event-driven architecture, but the actual code uses synchronous calls. If this isn't detected in time, it could cause compatibility issues during later expansions. Another example is when software requirements explicitly state that user data must be stored encrypted, but the actual code implementation omits encryption logic, which can lead to compliance risks.

[0007] Currently, the deviation between the project's code output and the software requirements specification relies solely on development testing and manual review. There is a lack of platforms for objective evaluation, and no relevant standards have been established, resulting in a lack of reference value and persuasiveness. Furthermore, with the popularization of software development models such as DevOps (a combination of Development and Operations, a culture and practice that integrates software development (Dev) and IT operations (Ops)), Continuous Integration and Continuous Delivery (CI / CD), software development emphasizes automated testing, rapid iteration, and continuous feedback. Traditional manual code reviews are insufficient to cover all deviations, resulting in low efficiency and high subjectivity.

[0008] In industries with stringent requirements for software security and compliance, such as finance, healthcare, and government, code must conform to industry standards or internal compliance systems. Audits also require proof that the code meets preset standards. Quantitative data on code deviations can serve as objective evidence to reduce audit risks. However, code that deviates from compliance requirements may lead to data leaks, system vulnerabilities, and regulatory penalties. Summary of the Invention

[0009] To address the aforementioned issues, this invention proposes a method and system for evaluating the deviation between software requirements and code development. By quantifying the difference between the code and the expected requirements, the deviation of code development is objectively evaluated, thus resolving problems such as inefficient collaboration, quality control failure, and requirement disconnect in large-scale code development.

[0010] To achieve the above objectives, the present invention adopts the following technical solution:

[0011] In a first aspect, the present invention provides a method for evaluating the deviation between software requirements and code development, comprising:

[0012] The functional requirements are matched to the chapter titles, tables and list items in the software requirements specification. Based on the matching results, the corresponding text content is located, the main body and action of the function, as well as the object and condition of the action, are extracted from the text content, and the required functional point statements are assembled according to the set sentence rules and matching order.

[0013] After extracting syntactic units and function call relationships from the generated code, it is matched with words in a preset code feature library to obtain code function point statements;

[0014] The system matches requirement function point statements with code function point statements to determine whether there are any unimplemented requirement function point statements or undefined additional code function point statements, and calculates the deviation degree. The evaluation result is obtained by comparing the deviation degree with a preset deviation threshold.

[0015] As an alternative implementation method, the required function point statements are assembled according to the sentence structure rules and matching order of subject + action + object, subject + action, condition + subject + action, and action + object.

[0016] As an alternative implementation method, the process of matching the functional requirements of the chapter titles includes: filtering all sub-chapter titles containing preset functional terms under the main chapter title according to preset functional terms, then locating the text content where the filtered sub-chapter titles are located, and identifying functional point elements in the text content where the filtered sub-chapter titles are located according to a preset functional point terminology library.

[0017] As an alternative implementation method, the process of matching functional requirements for table and list items includes: matching table or list items with functional requirements based on preset functional words, and extracting the text content of the table or list items with functional requirements as the text content of the functional point elements to be extracted based on the matching results.

[0018] As an alternative implementation, the syntax unit includes: the name of a function, parameter variables, return value, modifiers and statement blocks; the class name, inheritance relationship and list of methods contained in a class; the statement block includes conditional statements, loop statements and exception handling statements.

[0019] As an alternative implementation, the code feature library includes naming features, syntax features, logical features, and comment features; wherein, naming features are defined as business keywords in function and variable names; syntax features are defined as function parameter types, return values, and modifiers; logical features are defined as operations in code blocks; and comment features are defined as business descriptions in code comments.

[0020] As an optional implementation method, the process of matching requirement function point statements and code function point statements includes: determining whether the functional requirement to which the requirement function point statement belongs has a corresponding syntactic unit in the code function point statement; if so, determining whether the subject, action, object and condition elements in the requirement function point statement match the code function point statement, wherein the similarity is calculated and if the similarity is greater than a set similarity threshold, the match is considered successful.

[0021] If a requirement function point statement fails to match, it means that the requirement function point statement is an additional requirement function point statement defined in the software requirements specification but not present in the code generator. If a code function point statement fails to match, it means that the code function point statement is an additional code function point statement present in the code generator but not defined in the software requirements specification.

[0022] As an alternative implementation, the deviation calculation includes: determining the sum of the number of additional requirement function point statements and the number of additional code function point statements, and the sum of the total number of requirement function point statements and the number of additional code function point statements, with the quotient between the two sums being the deviation; wherein, the number of additional requirement function point statements is the difference between the total number of requirement function point statements and the number of requirement function point statements that have been successfully matched, and the number of additional code function point statements is the difference between the total number of code function point statements and the number of code function point statements that have been successfully matched.

[0023] Secondly, the present invention provides a deviation assessment system between software requirements and code development, comprising:

[0024] The requirements processing module is configured to match the content of chapter titles, tables and list items in the software requirements specification with functional requirements. Based on the matching results, it locates the corresponding text content, extracts the main body and action of the function, as well as the object and condition of the action, and assembles the required functional point statements according to the set sentence rules and matching order.

[0025] The code processing module is configured to extract syntactic units and function call relationships from the generated code, and then match them with words in a preset code feature library to obtain code function point statements;

[0026] The evaluation module is configured to match requirement function point statements with code function point statements, determine whether there are unimplemented requirement function point statements and undefined additional code function point statements, calculate the deviation degree, and obtain the evaluation result based on the comparison between the deviation degree and the preset deviation threshold.

[0027] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0028] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0029] This invention proposes a method and system for evaluating the deviation between software requirements and code development. By quantifying the differences between the code and the expected requirements (such as specifications, design, requirements, and compliance standards), it objectively evaluates the deviation of code development, solving problems such as inefficient collaboration, loss of quality control, and disconnect from requirements in large-scale code development. This facilitates the provision of modification suggestions for the deviation points in the later stages, improves the efficiency of subsequent modifications while providing progress and acceptance standards, and achieves a predictable, controllable, and high-quality software development process, applicable to different stages of the development process.

[0030] This invention objectively measures the difference between code and consensus standards by calculating deviation, reducing implicit disagreements in collaboration. It also adds an evaluation standard to project schedule management, reducing the possibility of manipulation through human evaluation and improving the reliability and trustworthiness of project schedule control. Quantifying deviation allows for the timely detection and remediation of deviation issues, preventing excessive accumulation of technical debt. Furthermore, code deviation can serve as a consistency tracking tool, comparing the code's fit with design documents and requirement use cases to promptly identify deviations between code implementation and requirement objectives, ensuring the development process stays aligned with core requirements.

[0031] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

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

[0033] Figure 1 The flowchart illustrates the deviation assessment method between software requirements and code development provided in Embodiment 1 of the present invention. Detailed Implementation

[0034] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0035] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0036] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. Furthermore, it should be understood that the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0038] Example 1

[0039] This embodiment provides a method for evaluating the deviation between software requirements and code development, such as... Figure 1 As shown, it includes:

[0040] The functional requirements are matched to the chapter titles, tables and list items in the software requirements specification. Based on the matching results, the corresponding text content is located, the main body and action of the function, as well as the object and condition of the action, are extracted from the text content, and the required functional point statements are assembled according to the set sentence rules and matching order.

[0041] After extracting syntactic units and function call relationships from the generated code, it is matched with words in a preset code feature library to obtain code function point statements;

[0042] The system matches requirement function point statements with code function point statements to determine whether there are any unimplemented requirement function point statements or undefined additional code function point statements, and calculates the deviation degree. The evaluation result is obtained by comparing the deviation degree with a preset deviation threshold.

[0043] In this embodiment, by creating unified rules for identifying function points in the Software Requirements Specification (SRS) and code generator, the judgment logic for function points is transformed into an executable set of rules. Through keyword matching, sentence analysis, structure recognition, and other methods, text fragments that conform to the function point definition in the SRS and code generator are accurately extracted.

[0044] The Software Requirements Specification (SRS) is a detailed specification document that defines the functions, performance, and design constraints of a software system. It includes functional requirements, non-functional requirements, user interface design, and other content. It serves as an agreement between users and developers and guides the entire process of software development, testing, and maintenance.

[0045] In this embodiment, the process of extracting the functional point statements in the software requirements specification will be described in detail below.

[0046] (1) Construct a functional point terminology library. The functional point terminology library is the vocabulary foundation of the rule engine. It contains high-frequency core words describing functional points in SRS, and stores them according to element type. It supports dynamic expansion.

[0047] Element types include: subject, object, action, condition, and non-functional point keywords.

[0048] Specifically, the subject is the entity that performs the function, and the object is another entity that is targeted when performing a certain function. They are designed according to general terms and domain-specific terms respectively. General terms include: user, system, administrator, operator, role, third-party service, etc. Taking the e-commerce field as an example, the subject in the e-commerce field can include buyer, seller, customer service, warehouse manager, etc. It is stored in the form of a thesaurus and supports synonym association, such as user = user.

[0049] Actions are the actions performed to achieve a function, and are designed according to both general terms and domain-specific terms. General terms include: query, create, modify, submit, verify, generate, import, export, etc. Taking the e-commerce domain as an example, actions in the e-commerce domain can include placing an order, paying, refunding, shipping, and verifying. They are stored in the form of a verb table, including tense variations, such as modify = modified = modifiable.

[0050] Conditions are the scenarios or constraints required to perform functions, and are designed according to general terms and domain-specific terms respectively. General terms include: when..., if...then..., under..., need..., must..., support..., allow..., etc. Taking the e-commerce domain as an example, conditions in the e-commerce domain include when the order status is pending payment, when the shopping cart is over 200 yuan, when the inventory is insufficient, etc.; they are stored in the form of a condition vocabulary + sentence template.

[0051] Non-functional keywords are designed separately according to general terms and domain-specific terms. General terms include: performance, response time, concurrency, security, compatibility, stability, interface style, etc. Taking the e-commerce field as an example, non-functional keywords in the e-commerce field include payment success rate, logistics timeliness, membership level permissions, etc. They are stored in the form of a negative keyword list for filtering operations.

[0052] It is understandable that the design of specific words for element types such as subject, object, action, condition, and non-functional point keywords can be adaptively expanded according to the actual application field. The words mentioned above are only examples and are not limited to them.

[0053] (2) Create unified rules for identifying function points in the software requirements specification, and obtain the required function point statements based on the unified rules, specifically including:

[0054] (2-1) Design sentence structure rules as the core matching logic. The description of functional points in SRS often follows a fixed sentence structure, specifically including: subject + action + object, subject + action, condition + subject + action, action + object. Therefore, the required functional point statements can be extracted by matching sentence structure rules through regular expressions or syntax templates.

[0055] (2-2) Design structural rules using SRS document characteristics. SRS documents usually have a fixed structure, including chapter titles, tables and list items. By identifying structural features, areas with dense functional points can be located.

[0056] Specifically:

[0057] (a) Chapter title matching.

[0058] The functional requirements of the chapter titles in the software requirements specification are matched. First, chapter titles with functional requirements are matched (such as user management functions, order operation processes, etc.). Then, based on the matching results, the text content corresponding to the chapter titles with functional requirements is located. In this way, the identification of functional elements is performed only in the chapters with functional requirements, reducing interference from irrelevant text.

[0059] The software requirements specification typically consists of modules such as document introduction, requirements background, requirements summary, requirements details, attachments, and adjustment records. Therefore, by using preset functional terms, all sub-section titles containing these terms under the main chapter title can be filtered. Then, the text content of the filtered sub-section titles can be located, and the functional elements within that text content can be identified. For example, filtering all sub-section titles under the main chapter title "Requirements Overview" containing preset functional terms allows for the identification of functional elements within the text content of the filtered sub-section titles.

[0060] (b) Extracting table content.

[0061] Software requirements specifications (SPS) often list functionalities in tabular form (e.g., Function Name | Description | Priority), such as Function Name: User Registration; Description: Users need to fill in their mobile phone number and verify. Therefore, matching functional requirements to the tables in the SPS can be done by first pre-setting functional terms, then matching tables containing those terms, and finally using table parsing tools (such as Python's pandas) to extract the text content from the tables containing functional requirements, or by concatenating the function name and description columns to obtain the text content for the extracted functionalities.

[0062] For example, the requirements overview includes modules such as "Menu Settings," "Filter Conditions," and "Data Retrieval Logic," which use specific tables. Therefore, the functional requirements of these secondary functional modules are matched. If "Menu Settings" is matched, the corresponding table header content will be "Serial Number," "First-Level Menu," "Second-Level Menu," "Third-Level Menu," etc., and the menu requirements will be read respectively. If "Filter Conditions" or "Data Retrieval Logic" is matched, the corresponding table header content will be "Field Name," "Database Table Field," etc., and the content corresponding to each table header will be read respectively.

[0063] For example, in "Menu Settings", the sequence number is 1, the first-level menu is "Account Management", the second-level menu is "Corporate Deposit Account", and the third-level menu is "Corporate Deposit Account Opening". In "Data Retrieval Logic", the sequence number is 1, and the field name is "Account Number".

[0064] (c) List item identification.

[0065] The functional points in the software requirements specification are often presented as ordered lists (such as numbered 1, 2, 3) or unordered lists. Since list items are usually independent functional points, matching the text of list items can improve recognition efficiency.

[0066] Ordered lists are lists with sequentially numbered items, suitable for arranging content where a specific order is required. Unordered lists are collections of list items without a specific order; they are also called item lists. In an unordered list, the items are parallel and have no particular order.

[0067] To match the content of the list items in the software requirements specification with functional requirements, we can first preset functional terms, match the list items with functional requirements based on the preset functional terms, and then use existing parsing tools to extract the text content of the list items with functional requirements based on the matching results, so as to use the text content of the functional points to be extracted.

[0068] (2-3) Based on the words in the preset functional point terminology library, extract the subject and action of the function, as well as the object and condition of the action in the text content, and assemble the required functional point statements according to the set sentence rules and priorities.

[0069] Specifically:

[0070] (a) Text preprocessing: Use text processing tools to extract plain text and remove formatting marks such as font and color.

[0071] (b) Filtering non-functional points: For the preprocessed text content, the filtering rules are used to verify it according to the setting of non-functional point keywords in the preset functional point terminology library. If non-functional keywords are contained, they are marked as non-functional points and removed.

[0072] (c) Rule matching and element extraction: For the preprocessed and non-functional point filtered text content, for each sentence, match according to the sentence pattern rules and matching priority of condition + subject + action, subject + action + object, subject + action, and action + object in sequence;

[0073] If the sentence structure rule is matched, then extract the functional point elements:

[0074] Main body: Extract words from the main elements in the functional point terminology library, such as user and system;

[0075] Object: Extract words from object elements in the function point terminology library;

[0076] Action: Extract words from the action elements in the function point terminology library, such as query and place an order;

[0077] Conditions: Extract descriptive statements from conditional word elements in the function terminology library, such as after 3 failed login attempts or after completing real-name authentication.

[0078] (d) Output the structured requirement function point statements in JSON format.

[0079] For example, for the text content "When the order payment is successful, the system will generate a logistics order and notify the buyer", the subject is the system, the object is the buyer, the action is generate and notify, the condition is when the order payment is successful, the chapter (i.e. the functional requirement module) is order management, the sentence structure rule is condition + subject + action, and the reliability can be preset to 95 points.

[0080] In this embodiment, the process of extracting code function point statements from the code generator based on unified rules will be described in detail below.

[0081] (1) Code analysis: Extracting syntactic units and function call relationships; syntactic units include functions / methods, classes, variables and statement blocks; among them, variables include two parts, one is parameters (function / method variables), and the other is logical variables contained in statement blocks.

[0082] Specifically:

[0083] (1-1) Extract information such as the name, parameters (name + type), return value, modifiers (such as @login_required), and statement blocks of functions / methods as the core carrier for matching functional points.

[0084] (1-2) Extract the class name, inheritance relationship, and list of methods contained in the class to identify the object-oriented functional module (such as the UserService class).

[0085] (1-3) Extract statement blocks containing keywords, including conditional statements (if), loop statements (for), and exception handling statements (try), to analyze the logical branches of functional points (such as exception handling for login failure) and determine logical variables.

[0086] (1-4) Function call relationships, such as method A calling method B. A complete logic or function often starts with a method, such as method A. However, for the sake of reusability and other factors, some common logic is often generated into a separate method B. Thus, to complete a logic, method A needs to call method B.

[0087] (2) A pre-defined code feature library is used to store code features corresponding to different functional points. The feature types include naming features, syntax features, logic features and comment features.

[0088] The naming features are defined as business keywords in function / variable names; taking user login as an example, the functional examples include: function names containing "login", "auth", and "signin"; parameters containing "username" and "password".

[0089] Syntax features are defined as function parameter types, return values, modifiers, etc.; taking user login as an example, functional examples include: parameters containing username / password of type str; returning bool (success / failure); including the @auth_required decorator.

[0090] Logical features are defined as key operations (such as database or API calls) within a code block. Taking user login as an example, functional examples include: calling db.query("select*from user where ..."); and calling the password encryption function encrypt().

[0091] Comment features are defined as business descriptions in code comments; taking user login as an example, functional examples include: function comments containing "user login verification", "check account and password validity", etc.

[0092] It is understandable that the design of specific words for the above-mentioned feature and other element types can be adaptively expanded according to the actual application field. The above words are only examples and are not limited to them.

[0093] (3) Based on the preset code feature library, the extracted syntax units and function call relationships are matched to obtain the code function point statements, so as to clarify the main function and intention of the code.

[0094] (4) Output the structured code function point statements in JSON format.

[0095] For example, regarding the "Authentication Function" in the "User Management Module," the function point is user login, and the specific features include: naming features: "["login", "auth", "signin"]", parameter features: "[{"name": "username", "type": "str"}, {"name": "password", "type": "str"}]", return value features: "["bool", "User"]", logical features: "["db.query(.*user.*)", "encrypt\\(password\\)"]", and comment features: "["Login", "Verification", "Account Password"]".

[0096] In this embodiment, the deviation is calculated based on the required function point statement and the code function point statement, and the evaluation result is obtained by combining the preset threshold.

[0097] Specifically:

[0098] (1) Compare and analyze the requirement function point statement with the code function point statement. First, determine whether the function requirement to which the requirement function point statement belongs has a corresponding syntax unit in the code function point statement, such as the corresponding function, language block, etc. If so, determine whether the subject, action, object, condition and other elements in the requirement function point statement match the code function point statement. The similarity can be calculated by algorithms such as cosine similarity and edit distance. If the similarity is greater than the set similarity threshold, it is considered a successful match, that is, the function point data of the current code analysis is the actual implemented requirement function point.

[0099] If there are unmatched requirement function point statements, it means that the requirement function point statement is an additional requirement function point statement defined in the software requirements specification but not present in the code generator. The number of additional requirement function point statements is the difference between the total number of requirement function point statements and the number of requirement function point statements that have been successfully matched.

[0100] If there are unmatched function point statements, it means that the function point statement is an additional function point statement that exists in the code generator but is not defined in the software requirements specification. The number of additional function point statements is the difference between the total number of function point statements and the number of successfully matched function point statements.

[0101] For example, for the "verify username and password" function mentioned in the requirement function point statement, search in the code function point statement for a corresponding function or code block that implements a similar verification operation. If so, calculate the similarity between the two in terms of operation objects, operation behaviors, etc.

[0102] Therefore, the formula for calculating the deviation is:

[0103] ;

[0104] in, The total number of feature points defined in the software requirements specification, i.e., the total number of feature point statements. This refers to the number of required functional points actually implemented in the code generator, i.e., the number of code functional point statements that have been successfully matched. This refers to the number of unimplemented feature requests, i.e., the number of additional feature requests statements. This refers to the number of additional code function point statements that exist in the code generator but are not defined in the software requirements specification.

[0105] (2) Deviation assessment: Combined with the pre-set deviation threshold, the deviation degree D is assessed. If the deviation degree D is less than the deviation threshold, it is considered that the code implementation deviates significantly from the software requirements specification. Otherwise, it indicates that the code development is normal.

[0106] Example 2

[0107] This embodiment provides a deviation assessment system between software requirements and code development, including:

[0108] The requirements processing module is configured to match the content of chapter titles, tables and list items in the software requirements specification with functional requirements. Based on the matching results, it locates the corresponding text content, extracts the main body and action of the function, as well as the object and condition of the action, and assembles the required functional point statements according to the set sentence rules and matching order.

[0109] The code processing module is configured to extract syntactic units and function call relationships from the generated code, and then match them with words in a preset code feature library to obtain code function point statements;

[0110] The evaluation module is configured to match requirement function point statements with code function point statements, determine whether there are unimplemented requirement function point statements and undefined additional code function point statements, calculate the deviation degree, and obtain the evaluation result based on the comparison between the deviation degree and the preset deviation threshold.

[0111] It should be noted that the above modules correspond to the steps described in Embodiment 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0112] In further embodiments, the following is also provided:

[0113] An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0114] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0115] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0116] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0117] The method in Example 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0118] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0119] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0120] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0121] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0122] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0123] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for evaluating deviation degree between software requirements and code development, characterized by, The method comprises the following steps: The content of the chapter title, table and list item in the software requirement specification is matched with the functional requirement, the corresponding text content is located according to the matching result, the subject and action of the function and the object and condition of the action in the text content are extracted, and the requirement function point sentence is assembled according to the set sentence pattern rule and matching order; The code generation is extracted to obtain the function point sentence of the code, and the function point sentence of the code is matched with the preset code feature library to obtain the code function point sentence; The requirement function point sentence and the code function point sentence are matched to determine whether there is an unimplemented requirement function point sentence and an undefined additional code function point sentence, and the deviation degree is calculated, and the evaluation result is obtained according to the comparison between the deviation degree and the preset deviation threshold; The process of matching the requirement function point sentence and the code function point sentence comprises the following steps: judging whether the functional requirement to which the requirement function point sentence belongs exists in the corresponding syntax unit in the code function point sentence; if yes, judging whether the subject, action, object and condition elements in the requirement function point sentence match the code function point sentence, wherein the similarity is calculated to determine whether the matching is successful, and if the similarity is greater than the set similarity threshold, the matching is considered to be successful; If there is a requirement function point sentence that does not match successfully, it indicates that the requirement function point sentence is an additional requirement function point sentence defined in the software requirement specification but not existing in the code generation; if there is a code function point sentence that does not match successfully, it indicates that the code function point sentence is an additional code function point sentence existing in the code generation but not defined in the software requirement specification; The calculation of the deviation degree comprises the following steps: determining the sum of the number of additional requirement function point sentences and the number of additional code function point sentences, and the sum of the total number of requirement function point sentences and the number of additional code function point sentences, and the quotient of the two sums is the deviation degree; wherein the number of additional requirement function point sentences is the difference between the total number of requirement function point sentences and the number of requirement function point sentences that have matched successfully, and the number of additional code function point sentences is the difference between the total number of code function point sentences and the number of code function point sentences that have matched successfully.

2. The method of claim 1, wherein the software requirement and code development deviation degree is evaluated by: The requirement function point sentence is assembled according to the subject+action+object, subject+action, condition+subject+action and action+object sentence pattern rules and matching orders.

3. The method of claim 1, wherein the software requirement and code development deviation degree is evaluated by: The process of matching the functional requirement of the chapter title comprises the following steps: screening all sub-chapter titles containing the preset function word under the main chapter title according to the preset function word, then locating the text content where the screened sub-chapter title is located, and identifying the function point elements in the text content where the screened sub-chapter title is located according to the preset function point term library.

4. The method of claim 1, wherein the software requirement and code development deviation degree evaluation method is characterized in that, The process of matching the functional requirement of the table and list item comprises the following steps: matching the table or list item with the functional requirement according to the preset function word, and extracting the text content in the table or list item with the functional requirement as the text content of the function point element to be extracted according to the matching result.

5. The method of claim 1, wherein the software requirement and code development deviation degree evaluation method is characterized by, The syntax unit comprises the name, parameter variable, return value, modifier and statement block of a function, the class name, inheritance relationship and method list of a class; and the statement block comprises a conditional statement, a loop statement and an exception handling statement.

6. The method of claim 1, wherein the software requirement and code development deviation degree evaluation method is characterized by, The code feature library comprises naming features, syntax features, logic features and comment features; the naming features are defined as business keywords in function and variable names; the syntax features are defined as function parameter types, return values and modifiers; the logic features are defined as operations in code blocks; and the comment features are defined as business descriptions in code comments.

7. A deviation assessment system between software requirements and code development, characterized in that, The requirement processing module is configured to match the contents of chapter titles, tables and list items in the software requirement specification with functional requirements, locate to corresponding text contents according to the matching results, extract subjects and actions of functions and objects and conditions of the actions in the text contents, and assemble the requirement function point sentences according to set sentence pattern rules and matching orders; The code processing module is configured to match the generated code with words in the preset code feature library after extracting syntax units and function call relationships of the generated code, to obtain code function point sentences; The evaluation module is configured to match the requirement function point sentences and the code function point sentences, judge whether there are unimplemented requirement function point sentences and undefined additional code function point sentences, calculate a deviation degree, and obtain an evaluation result according to a comparison between the deviation degree and a preset deviation threshold; The process of matching the requirement function point sentences and the code function point sentences comprises: judging whether a functional requirement to which the requirement function point sentence belongs exists in a corresponding syntax unit in the code function point sentences; if yes, judging whether elements of subjects, actions, objects and conditions in the requirement function point sentences match the code function point sentences, wherein the matching is determined by calculating a similarity degree, and if the similarity degree is greater than a set similarity threshold, the matching is considered successful; If there are unmatching requirement function point sentences, the unmatching requirement function point sentences are additional requirement function point sentences defined in the software requirement specification but not existing in the generated code; if there are unmatching code function point sentences, the unmatching code function point sentences are additional code function point sentences existing in the generated code but not defined in the software requirement specification; The calculation of the deviation degree comprises: determining a sum of a number of additional requirement function point sentences and a number of additional code function point sentences, and a sum of a total number of requirement function point sentences and the number of additional code function point sentences, and a quotient between the two sums is the deviation degree; wherein the number of additional requirement function point sentences is a difference between the total number of requirement function point sentences and a number of matched requirement function point sentences, and the number of additional code function point sentences is a difference between a total number of code function point sentences and a number of matched code function point sentences. The computer program product comprises a memory and a processor, and computer instructions stored in the memory and run on the processor, and when the computer instructions are run by the processor, the method in any one of claims 1-6 is completed.

8. An electronic device, comprising: ​

Images