Machine learning-based interactive design requirement intelligent analysis method and system

Abstract

This invention discloses a machine learning-based intelligent analysis method and system for interaction design requirements, belonging to the field of intelligent analysis technology for interaction design requirements. First, it connects to open interfaces of a requirements survey platform, an interview audio transcription system, a hand-drawn sketch upload port, and an enterprise requirements management system to collect multi-source heterogeneous raw requirements data, including user natural language requirements descriptions, hand-drawn interaction sketches, historical interaction requirements archives, and user feedback work orders. The raw data is then subjected to noise filtering, format normalization, entity extraction, and disambiguation processing to construct an interaction design requirements knowledge graph storing related relationships. The knowledge graph data is converted into feature vectors that integrate semantic and structural features, and input into a pre-trained requirements analysis machine learning model. This invention can cover the processing of various types of unstructured requirements materials, solving the problems of insufficient adaptability and high error rates in existing technologies, and significantly improving the efficiency of requirements analysis.

Description

Technical Field

[0001] This invention relates to the field of intelligent analysis technology for interaction design requirements, and in particular to a method and system for intelligent analysis of interaction design requirements based on machine learning. Background Technology

[0002] Interaction design is a core preliminary step in the development of various digital products, widely covering multiple fields such as consumer internet applications, in-vehicle interaction systems, government service platforms, and industrial control terminals. As product iteration cycles continue to shorten and user needs become increasingly personalized, the sources of requirements are gradually showing multi-source heterogeneous characteristics, encompassing various forms such as natural language interview records, hand-drawn interaction sketches, historical requirement documents, and user feedback work orders. The industry generally has the core demand to improve the efficiency of requirement analysis, reduce the error rate of requirements, and reduce the cost of R&D rework.

[0003] One of the current mainstream requirements analysis solutions is the purely manual analysis model. In this model, product managers and interaction designers manually collect requirements materials from different channels, systematically analyze each requirement, align the requirement logic, verify conflicts, and categorize and archive them to form a structured requirements list. Then, they match reusable interaction design components based on their personal experience. This model is highly adaptable and can cover highly customized niche requirements, and is currently widely used in small and medium-sized R&D teams and digital transformation projects in traditional industries. However, this model has significant drawbacks. The efficiency of requirements analysis is greatly affected by personnel experience and workload; the requirements analysis cycle for large projects can reach several weeks. The process of organizing multi-source heterogeneous data is prone to requirements omissions and ambiguities. Requirement conflict verification relies on manual checking, resulting in a high rate of missed judgments. Furthermore, the matching of reusable components depends entirely on accumulated personal experience, leading to a high rate of repetitive development and high overall R&D costs.

[0004] Another mainstream solution is a rule-matching requirement parsing tool. This mode pre-builds a standardized keyword library and requirement classification rule templates, performs keyword matching only on text-based requirements, and automatically outputs requirement classification tags and a preliminary list. This mode has a fast parsing speed and can significantly improve the processing efficiency of standardized text requirements. It is currently integrated into the internal requirement management platforms of most leading companies. However, this mode only supports structured text data processing and cannot recognize unstructured requirement materials such as hand-drawn sketches and audio-to-speech text. It has poor multi-source data adaptation capabilities, the preset rules cannot cover disambiguation scenarios for ambiguous requirements, the tag misjudgment rate is high, and it does not have built-in requirement conflict verification logic and automatic component matching capabilities. It still requires a lot of manual intervention to complete the subsequent verification and matching work. When new requirement types appear, the rule library needs to be manually updated, resulting in high iteration costs and insufficient adaptation flexibility.

[0005] As the complexity of interaction design requirements continues to increase, neither of the existing two types of solutions can simultaneously meet the comprehensive needs of multi-source heterogeneous data processing, high-accuracy requirement parsing, automatic conflict checking, and automatic matching of reusable components. The industry urgently needs a more efficient and intelligent requirement parsing solution to address the above pain points. Summary of the Invention

[0006] The present invention proposes a machine learning-based intelligent analysis method and system for interaction design requirements, which solves the problems mentioned in the prior art, such as poor multi-source data adaptability, low analysis efficiency, high conflict omission rate, and component matching dependence on manual methods.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a machine learning-based intelligent analysis method for interaction design requirements, comprising the following steps: By connecting to the open interfaces of the requirements survey platform, interview audio transcription system, hand-drawn sketch upload port, and enterprise requirements management system, we can obtain multi-source heterogeneous original datasets corresponding to interaction design requirements. The multi-source heterogeneous original datasets include user natural language requirement descriptions, scanned hand-drawn interaction sketches, archived historical interaction requirements documents, user feedback work orders, and high-fidelity prototype annotation files. The multi-source heterogeneous original dataset is subjected to noise filtering, format normalization, entity extraction, and disambiguation processing in sequence. Redundant, invalid, and duplicate information in the original data is filtered out, and the structured storage format of all data is unified. User roles, functional points, interaction paths, performance indicators, and applicable scenario entities corresponding to the requirements are extracted. Based on the general interaction design terminology library, the synonyms and heteronyms of entities are corrected. An interaction design requirement knowledge graph is constructed, and all requirement entities, entity relationships, and entity constraints are mapped and stored in the interaction design requirement knowledge graph in the format of subject, predicate, and object triples. All triplet data of the interaction design requirement knowledge graph are converted into feature vectors that integrate semantic and structural features. These vectors are then input into a requirement parsing machine learning model that has been pre-trained on a public interaction design requirement dataset of millions of data points. The output is a three-level hierarchical requirement label that conforms to hierarchical subordinate logic. The three-level hierarchical requirement label includes a first-level functional requirement label, a second-level non-functional requirement label, and a third-level interaction scenario requirement label. The second-level non-functional requirement label is subordinate to the corresponding first-level functional requirement label, and the third-level interaction scenario requirement label is subordinate to the corresponding first-level functional requirement label and the second-level non-functional requirement label. All requirements corresponding to the three-level hierarchical requirement tags are checked for three types of conflicts: functional mutual exclusion, resource conflict, and compliance conflict. Based on the preset priority rules that are weighted by user weight, business value, and implementation difficulty, conflicting requirements are adjusted to generate a sorted structured requirement parsing result. The requirement parsing result is matched with the preset interaction design component library based on the semantic similarity of requirement tags and historical reuse rate, and a recommended list of corresponding reusable components sorted by reuse priority is output.

[0008] Furthermore, the preprocessing steps for the multi-source heterogeneous original dataset specifically include: using an improved YOLOv8 object detection algorithm specifically trained for hand-drawn interactive controls for the hand-drawn interactive sketches, extracting interactive control entities, control position attributes, and handwritten text entities, and using a CRNN model to complete the recognition and correction of handwritten text; For natural language requirement descriptions and historical interaction requirement archive documents, the ERNIE 3.0 pre-trained language model is used to complete entity extraction and relation extraction. The entity extraction categories cover four types: user roles, functional requirements, non-functional constraints, and scenario information. The relation extraction categories cover four types: subordinate, trigger, mutual exclusion, and dependency. Based on a general interaction design knowledge base, the extracted entities are disambiguated. The cosine similarity between the extracted entities and standard terms in the knowledge base is calculated. Entities with similarity higher than a preset threshold are mapped to the corresponding standard terms, while those with similarity lower than the threshold are marked as entities to be confirmed and pushed to manual verification.

[0009] Furthermore, the entity nodes of the interaction design requirements knowledge graph include user role nodes, function entry nodes, interaction action nodes, and constraint condition nodes. The attributes of the user role nodes include role type, operating habits, and usage frequency. The attributes of the function entry nodes include entry location, triggering method, and number of associated functions. The attributes of the interaction action nodes include action type, response threshold, and feedback form. The attributes of the constraint condition nodes include constraint type, constraint scope, and effective time. The relationships between entity nodes include subordinate relationships, triggering relationships, and mutually exclusive relationships. Subordinate relationships correspond to "belonging to" or "containing" relationships; triggering relationships correspond to "triggering" or "jumping" relationships; and mutually exclusive relationships correspond to "cannot exist simultaneously" or "mutually exclusive" relationships. The attributes of all relationships include relationship strength, effective scenario, and confidence level. The attributes configured for each entity node include requirement priority, applicable scenario, and compatible terminal type. The requirement priority is automatically determined by the weights output by the pre-trained model. The applicable scenarios cover four categories: mobile, PC, in-vehicle, and large-screen. The compatible terminal types include three categories: all-terminal, specific terminal, and customized terminal.

[0010] Furthermore, the required analysis machine learning model adopts an improved BERT-GCN model. The BERT layer of the improved BERT-GCN model adopts a lightweight DistilBERT structure to reduce the number of parameters and improve inference speed, and the GCN layer adopts a two-layer graph convolution structure to fully extract the first-order and second-order neighborhood association features of the knowledge graph. During the model training stage, the model is fine-tuned using a three-year historical interactive design requirement dataset of the enterprise with annotations. The annotation dimensions cover three categories: entity annotation, relationship annotation, and third-level requirement label annotation. The model's loss function uses cross-entropy loss superimposed with demand hierarchy constraint loss. The cross-entropy loss is used to measure the classification accuracy of the three-level hierarchical demand labels. The demand hierarchy constraint loss is calculated based on the hierarchical mapping matrix of functional demand labels, non-functional demand labels, and interactive scenario demand labels to calculate logical inconsistency loss. The demand hierarchy constraint loss accounts for 15% of the total loss and is used to restrict the hierarchical logical consistency of the three-level hierarchical demand labels.

[0011] Furthermore, the steps for outputting the three-level hierarchical requirement tags specifically include: firstly, outputting the first-level functional requirement tags, simultaneously outputting the core description of the functional requirement, its business segment, and the expected implementation cycle; secondly, outputting the second-level non-functional requirement tags, simultaneously outputting the type of non-functional requirement, which includes performance, adaptation, compliance, and security, as well as the constraint scope of each non-functional requirement; finally, outputting the third-level interaction scenario requirement tags, simultaneously outputting the triggering conditions, preconditions, post-feedback, and user paths involved in the scenario; all non-functional requirement tags and interaction scenario requirement tags are associated with one or more corresponding superior functional requirement tags, and there are no second- or third-level tags without a superior.

[0012] Furthermore, the step of performing conflict verification on all requirements corresponding to the three-level hierarchical requirement tags specifically includes: fusing the semantic features, association features, and attribute features of the requirement entities, calculating the association similarity between different requirement entities, and setting the preset threshold to 0.85. If the association similarity exceeds 0.85 and the two requirement entities have mutually exclusive relationship edges in the knowledge graph, then the corresponding requirement is marked as a conflicting requirement. The preset priority rule calculates the priority score of each requirement by weighting it according to user weight (40%), business value (35%), and implementation difficulty (25%). Conflicting requirements with high scores are retained first, while conflicting requirements with low scores are pushed to the person who submitted the requirement for adjustment. After the adjustment is completed, a conflict check is performed again. The final requirement parsing result is generated after all requirements are free of conflict.

[0013] A machine learning-based intelligent analysis system for interaction design requirements includes: The multi-source data acquisition module connects to the requirements survey platform interface, the hand-drawn sketch upload interface, the enterprise internal requirements management system interface, and the audio transcription interface to obtain multi-source heterogeneous raw datasets corresponding to interaction design requirements. The multi-source heterogeneous raw datasets include user natural language requirement descriptions, hand-drawn interaction sketches, historical interaction requirement archive documents, audio transcription text of requirement interviews, user feedback work orders, and high-fidelity prototype annotation files. The data preprocessing module includes a built-in noise filtering unit, entity extraction unit, ambiguity disambiguation unit, and knowledge graph construction unit. It is used to perform noise filtering, format normalization, requirement entity extraction, and ambiguity disambiguation on multi-source heterogeneous raw datasets. All requirement entities, entity relationships, and entity constraints are mapped and stored in the constructed interaction design requirement knowledge graph in triple format. The interaction design requirement knowledge graph is stored in the graph database Neo4j. The requirement parsing module has a built-in pre-trained requirement parsing machine learning model that supports online incremental iterative updates of the model. The requirement parsing results after each manual verification are automatically added to the fine-tuning dataset to optimize the model. The input is the feature vector obtained by converting the triples of the interaction design requirement knowledge graph, and the output is a three-level hierarchical requirement label that conforms to the hierarchical subordinate logic. The three-level hierarchical requirement label includes functional requirement label, non-functional requirement label, and interaction scenario requirement label in sequence. The requirement verification output module interfaces with an enterprise interaction design component library, which includes general UI components, business-customized components, and industry-specific components. It is used to perform conflict verification on all requirements corresponding to the three-level hierarchical requirement tags, generate a sorted structured requirement parsing result based on preset priority rules, match the requirement parsing result with the preset interaction design component library, and output a recommended list of corresponding reusable components sorted by reuse priority. The recommended list also outputs the reuse count, applicable scenarios, and modification cost information of the components.

[0014] Furthermore, the data preprocessing module also includes a built-in sketch recognition unit. This sketch recognition unit first performs preprocessing operations on the uploaded hand-drawn interactive sketch, including grayscale conversion, binarization, noise reduction, and tilt correction. Edge detection uses the Canny edge detection algorithm to extract the contour features of the interactive controls. Control recognition uses a lightweight YOLOv8 model specifically trained for hand-drawn interactive controls, covering 28 common interactive control categories. Handwritten text extraction uses a CRNN model to recognize and correct the text in the handwritten area. After recognition, the position, type, and associated text of the controls are automatically converted into structured requirement entity data, eliminating the need for manual input of the requirement information corresponding to the sketch.

[0015] Furthermore, the improved BERT-GCN model built into the requirement parsing module includes a text encoding layer, a graph convolutional layer, and a hierarchical classification layer. The text encoding layer adopts the DistilBERT structure to encode the text description of the requirement entity into a 768-dimensional semantic feature vector. The output of the text encoding layer is input to the graph convolutional layer and the hierarchical classification layer, respectively. The graph convolutional layer adopts a two-layer graph convolutional network, which performs neighborhood aggregation on the semantic feature vector based on the adjacency matrix of the knowledge graph to obtain a structural feature vector that integrates the association relationship. The hierarchical classification layer includes a first-level classification head, a second-level classification head, and a third-level classification head. The first-level classification head outputs functional requirement tags. The second-level classification head further classifies and outputs non-functional requirement tags based on the output features of the first-level classification head. The third-level classification head further classifies and outputs interaction scenario requirement tags based on the output features of the first-level and second-level classification heads. The outputs of the three classification heads constrain each other to ensure the correctness of the hierarchical subordinate logic.

[0016] Furthermore, the requirement verification output module also has a built-in conflict early warning unit. When the conflict early warning unit detects a requirement conflict, it first pushes early warning information, including a description of the conflicting requirement, the cause of the conflict, and the business segments involved in the conflict, to the requirement manager and designer. The adjustment suggestion is based on the similarity matching of the historical conflict requirement handling solution library, and outputs the three historical handling solutions with the highest similarity. The solution types include four categories: requirement priority adjustment, requirement merging, requirement splitting, and requirement removal, for users to choose from. The handling solution selected by the user is automatically stored in the handling solution library for matching adjustment suggestions for subsequent conflict requirements, thereby improving the efficiency of conflict handling.

[0017] Compared with existing technologies, the beneficial effects of this invention are: This invention constructs a full-link collection and preprocessing system for multi-source heterogeneous requirement data, combined with a hand-drawn interactive control-specific recognition model, unstructured text entity extraction, and disambiguation mechanism. It uniformly converts requirement materials of different forms into a standardized interactive design requirement knowledge graph, effectively solving the adaptability defects of existing rule-based parsing tools that only support structured text processing and cannot cover unstructured requirements such as hand-drawn sketches and oral interview transcription. The requirement collection process does not require manual sorting, significantly reducing the probability of requirement errors and omissions.

[0018] This invention introduces an improved BERT-GCN requirement parsing model with hierarchical constraint loss, coupled with a requirement conflict verification mechanism that integrates semantic, relational, and attribute features. It outputs three-level hierarchical requirement tags that conform to subordinate logic, and can automatically complete the verification of three types of requirement conflicts: function, resources, and compliance. This effectively solves the shortcomings of manual parsing mode, such as efficiency limitations due to human experience and high rate of missed conflict detection, as well as the high rate of misjudgment of tags and inconsistent hierarchical logic in rule matching mode. It significantly improves the efficiency and accuracy of requirement parsing results.

[0019] This invention uses an automatic semantic similarity matching mechanism between requirement tags and the interaction design component library to output a recommended list of reusable components sorted by reuse priority. This effectively solves the shortcomings of the existing model, which relies on the accumulated experience of designers for component matching and has a high rate of repeated development, and significantly reduces the repeated R&D costs in the interaction design process.

[0020] This solution is suitable for interactive design requirement analysis scenarios across all industries, including internet consumer products, in-vehicle interactive systems, government service platforms, smart home terminals, and industrial control interfaces. It supports flexible adjustment of requirement priority weights, tag systems, and dedicated component libraries based on industry characteristics. It can meet the requirement analysis needs of R&D teams of different sizes without extensive customization and has high promotion and application value. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the overall process of intelligent analysis of interaction design requirements based on machine learning, as proposed in this invention. Figure 2 This is a flowchart of the multi-source heterogeneous data preprocessing and knowledge graph construction process of this invention; Figure 3 This invention provides a flowchart for analyzing the machine learning model processing requirements. Figure 4 This is a flowchart of the requirement conflict verification and component recommendation process for this invention. Figure 5 This is the architecture diagram of the intelligent analysis system for interactive design requirements of this invention. Detailed Implementation

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

[0023] Reference Figures 1 to 5 This invention discloses a machine learning-based intelligent analysis method for interaction design requirements, comprising the following implementation steps: First, multi-source data collection was completed by connecting to the open interfaces of the requirements survey platform, interview audio transcription system, hand-drawn sketch upload port, and enterprise requirements management system. The interface adopts the OAuth2.0 authentication mechanism, the request timeout threshold is set to 30 seconds, and it supports uploading large files larger than 10M in chunks and resuming interrupted uploads. The collected multi-source heterogeneous raw datasets cover five categories: user natural language requirements descriptions, scanned hand-drawn interactive sketches in PNG / JPG / PDF format, historical interactive requirements archive documents in Word / Markdown / Confluence format, user feedback tickets, and high-fidelity prototype annotation files.

[0024] After data collection, the multi-source heterogeneous raw datasets are preprocessed sequentially. The first step involves noise filtering, automatically removing garbled content, duplicate test requests, and blank documents without valid information. The second step is format normalization, converting all text data to UTF-8 encoding and adjusting all image data to 640*640 resolution RGB three-channel images. The third step is entity extraction, matching preset entity rules to extract five types of entities: user roles, functional points, interaction paths, performance indicators, and applicable scenarios. The fourth step is disambiguation, using a general interaction design terminology library to correct for synonyms and homonyms in the extracted entities. For example, the entity "pop-up" described as "non-clickable background close" is mapped to the standard term "modal pop-up," and the entity "pop-up" described as "clickable background close" is mapped to the standard term "non-modal pop-up." After correction, an interaction design requirement knowledge graph is constructed, storing all requirement entities, entity relationships, and entity constraints in a subject-predicate-object triple format in the Neo4j graph database. In version 5.0, typical triplet examples include paid user, submit, refund request, refund request button, trigger, refund pop-up, modal pop-up, mutual exclusion, and non-modal pop-up.

[0025] After preprocessing, all triplet data in the interaction design requirement knowledge graph are converted into feature vectors that integrate semantic and structural features. These vectors are then input into a requirement parsing machine learning model pre-trained on a public interaction design requirement dataset of millions of entries. The output consists of three levels of hierarchical requirement labels that conform to hierarchical logic. The first level consists of functional requirement labels, the second level consists of non-functional requirement labels, and the third level consists of interaction scenario requirement labels. Second-level labels must belong to their corresponding first-level labels, and third-level labels must belong to their corresponding first-level and second-level labels. There are no second-level or third-level labels without a superior. Typical output examples include the first-level label "Order Refund Function", the second-level labels "Page Response Time ≤ 1s" and "Adapted for Android and iOS", and the third-level labels "Sold Order Scenarios" and "Unsold Order Scenarios".

[0026] After the tag output is completed, all requirements corresponding to the three-level hierarchical requirement tags are checked for three types of conflicts: functional mutual exclusion, resource conflict, and compliance conflict. Based on the weighted rule of 40% user weight, 35% business value weight, and 25% implementation difficulty weight, the priority score of each requirement is calculated. Conflicting requirements with high scores are retained first, while conflicting requirements with low scores are pushed to the personnel who submitted the requirements for adjustment. After all requirements pass the verification, a structured requirement parsing result is generated in order of priority. Then, based on the cosine similarity between requirement tags and component tags, a preset interaction design component library is matched, and a recommended list of reusable components in order of reuse priority is output. The recommended list also displays the historical reuse count, adapted scenarios, and estimated modification cost information of the components.

[0027] This invention also discloses a specific implementation scheme for preprocessing multi-source heterogeneous raw datasets: For hand-drawn interactive sketches, an improved YOLOv8 object detection algorithm specifically optimized for hand-drawn interactive controls is used to extract entities. The improvement involves adjusting the input resolution of YOLOv8 to 640*640. 5000 interactive control samples covering different hand-drawn styles are added to the training set, including hand-drawn buttons, input boxes, pop-ups, drop-down menus, etc. The model achieves 98.2% mAP@0.5 on the test set, accurately extracting interactive control entities, control coordinate attributes, and handwritten text regions. Then, a CRNN model is used to complete the recognition and correction of handwritten text. The CRNN model is trained based on 100,000 interactive annotation samples of handwritten Chinese, English, and numbers, achieving a recognition accuracy of 97.5%. For natural language requirement descriptions and archived historical interaction requirements documents, an ERNIE 3.0 pre-trained language model was used to complete entity and relation extraction. The model was fine-tuned on 100,000 annotated interaction requirement texts, achieving an F1 score of 96.8% for entity extraction and 95.3% for relation extraction. The extracted categories covered four types of entities: user roles, functional requirements, non-functional constraints, and scenario information, as well as four types of relations: subordinate, trigger, mutually exclusive, and dependent. In the disambiguation stage, the cosine similarity between the extracted entities and standard terms in the knowledge base was calculated. Similarity scores higher than 0.8 were automatically mapped to the corresponding standard terms, while those lower than 0.8 were marked as entities to be confirmed and pushed to the manual verification queue. The manually verified entity data was automatically added to the training set to achieve iterative optimization of the model.

[0028] This invention also discloses specific construction rules for an interaction design requirements knowledge graph: the entity nodes of the knowledge graph are divided into four categories: user role nodes, function entry nodes, interaction action nodes, and constraint condition nodes. The attributes of user role nodes include role type, operation habits, and usage frequency. The operation habit attribute can be high-frequency operation, low-frequency operation, or elderly user adaptation. The attributes of function entry nodes include entry location, triggering method, and number of associated functions. The triggering method attribute can be click trigger, swipe trigger, or voice trigger. The attributes of interaction action nodes include action type, response threshold, and feedback form. The response threshold attribute can be click response 300ms or swipe response 500ms. The attributes of constraint condition nodes include constraint type, constraint scope, and effective time. The constraint type attribute can be compliance constraint, performance constraint, or security constraint. The edges connecting entity nodes are divided into three categories: subordinate edges, triggering edges, and mutually exclusive edges. Subordinate edges correspond to "belonging to" or "containing" relationships; triggering edges correspond to "triggering" or "jumping" relationships; and mutually exclusive edges correspond to "cannot exist simultaneously" or "mutually exclusive" relationships. The attributes of all edges include relationship strength, effective scenario, and confidence. Relationship strength is a value between 0 and 1, with higher values ​​indicating stronger relationships. Effective scenarios can be mobile, PC, vehicle, or all terminals. Confidence is the confidence score obtained by the model for the relationship.

[0029] This invention also discloses a specific implementation scheme for the requirements parsing machine learning model: The requirements parsing machine learning model adopts an improved BERT-GCN model, wherein the BERT layer adopts a lightweight DistilBERT structure, with only 60% of the parameters of the original BERT, and the inference speed is improved by 70%. The GCN layer adopts a two-layer graph convolution structure, which can fully extract the first-order and second-order neighborhood association features of the knowledge graph. During the model training stage, the model is fine-tuned using a three-year historical interactive design requirements dataset of an enterprise with annotations, covering three categories of annotation dimensions: entity annotation, relationship annotation, and third-level requirement label annotation. The total loss function of the model adopts a combination of cross-entropy loss and requirement hierarchy constraint loss, and the specific formula is as follows: ;in For the total loss, Cross-entropy loss is used to measure the classification accuracy of three-level hierarchical demand labels. The hierarchical constraint coefficient is fixed at 0.15. The hierarchical constraint loss is used to restrict the consistency of the subordinate logic of the three-level hierarchical requirement labels. The calculation formula is as follows:

[0030] in This refers to the number of samples within a batch. For the first Predicted probabilities of two / three level labels The predicted probability of the child label is the parent label corresponding to the label. A loss is incurred when the predicted probability of the child label is higher than that of the parent label. The constraint is that the parent label must be effective simultaneously when the child label is effective. The batch size for model training was set to 32, the initial learning rate to 2e-5, the number of training epochs to 10, the early stopping patience to 3, and the initial weights used were the DistilBERT-base-chinese weights from the HuggingFace open-source library. The GCN layer had an input dimension of 768 and an output dimension of 256. The code snippet for the core loss function is as follows: import torch import torch.nn as nn class HierLoss(nn.Module): def __init__(self, alpha=0.15): super().__init__() self.alpha = alpha self.ce_loss = nn.CrossEntropyLoss() def forward(self, y_pred, y_true, hier_adj): ce = self.ce_loss(y_pred, y_true) parent_pred = torch.matmul(y_pred, hier_adj) hier = torch.mean(torch.relu(y_pred - parent_pred)) return ce + self.alpha * hier This invention also discloses a three-level hierarchical requirement tag output rule: In the output stage, first-level functional requirement tags are output first, simultaneously outputting the core description of the functional requirement, its business segment, and expected implementation cycle. Next, second-level non-functional requirement tags are output, simultaneously outputting the specific type of the non-functional requirement, including performance, adaptation, compliance, and security categories, as well as the constraint scope of each non-functional requirement. Finally, third-level interaction scenario requirement tags are output, simultaneously outputting the triggering conditions, preconditions, post-feedback, and involved user paths of the scenario. All non-functional requirement tags and interaction scenario requirement tags are associated with one or more corresponding parent functional requirement tags. Each tag carries a unique ID, and the association between parent tag IDs and child tag IDs is stored in a preset tag mapping table. The output is displayed in a hierarchical tree structure, facilitating designers to quickly organize the requirement logic.

[0031] This invention also discloses a specific implementation scheme for requirement conflict verification: in the verification stage, the semantic features, relationship features, and attribute features of the requirement entities are integrated to calculate the association similarity between different requirement entities. The formula for calculating the association similarity is as follows: ; in The fixed value is 0.4. The fixed value is 0.3. The fixed value is 0.3. Let cosine similarity be the textual features of two entities. This represents the degree of path overlap between two entities in the knowledge graph. The similarity is calculated as the Jaccard similarity between two entity attributes. The association similarity threshold is set to 0.85. If the association similarity exceeds 0.85 and the two entities have mutually exclusive edges in the knowledge graph, the corresponding requirement is marked as a conflicting requirement. The priority score of conflicting requirements is calculated weighted by user weight, business value, and implementation difficulty. Conflicting requirements with higher scores are retained first, while those with lower scores are pushed to the submitter for adjustment. After adjustment, conflict verification is performed again. The final requirement parsing result is generated after all requirements are free of conflict. The core similarity calculation code snippet is as follows: from sklearn.metrics.pairwise import cosine_similarity def cal_entity_sim(entity1, entity2, beta=0.4, gamma=0.3, delta=0.3): # Calculate semantic similarity sem_sim = cosine_similarity(entity1.emb.reshape(1,-1),entity2.emb.reshape(1,-1))[0][0] # Calculate relation path similarity path1 = set(entity1.get_all_relation_path()) path2 = set(entity2.get_all_relation_path()) rel_sim = len(path1&path2) / len(path1 | path2) if len(path1 |path2) !=0 else 0 # Calculate attribute similarity attr1 = set(entity1.attr.keys()) attr2 = set(entity2.attr.keys()) attr_sim = len(attr1&attr2) / len(attr1 | attr2) if len(attr1 |attr2) !=0 else 0 return beta * sem_sim + gamma * rel_sim + delta * attr_sim This invention also discloses an intelligent analysis system for interaction design requirements based on machine learning, comprising four core modules: a multi-source data acquisition module developed using the Python FastAPI framework, which interfaces with a requirements survey platform, a hand-drawn sketch upload interface, an enterprise internal requirements management system interface, and an audio transcription interface; it supports both full synchronization and incremental synchronization data acquisition modes, with the incremental synchronization frequency configurable to be executed once per hour / day / week; the raw data collected is stored in a distributed object storage service; the data preprocessing module includes a noise filtering unit, an entity extraction unit, an ambiguity disambiguation unit, and a knowledge graph construction unit; all units support parallel processing, with preprocessing time for a single batch of 100 requirements not exceeding 1 minute; the constructed interaction design requirements knowledge graph is stored in the graph database Neo4j, supporting Cypher query, with a single query response time not exceeding 200ms; The requirement analysis module has a built-in pre-trained requirement analysis machine learning model, which is deployed on a GPU cloud server equipped with an NVIDIA T4 graphics card. The inference time for a single requirement is no more than 1 second. It supports online incremental iterative updates and automatically fine-tunes the model every day at midnight using the requirement data that was manually verified the previous day. The fine-tuning learning rate is set to 1e-6 to avoid catastrophic forgetting of the model. The requirement validation output module connects to the enterprise interaction design component library, which includes three categories: general UI components, business-customized components, and industry-specific components. Each component is configured with a standardized tag system. During the matching phase, the cosine similarity between the requirement tag and the component tag is calculated. The top 5 components with the highest similarity are sorted and output according to their reuse priority. The recommendation list synchronously displays the component's historical reuse count, applicable scenarios, and estimated modification cost information.

[0032] This invention also discloses a specific implementation scheme of the sketch recognition unit built into the data preprocessing module: The sketch recognition unit first performs grayscale conversion, Gaussian filtering for noise reduction, and Canny edge detection on the uploaded hand-drawn interactive sketch. The low threshold of Canny edge detection is set to 50, and the high threshold is set to 150. Then, the tilt angle of the straight lines in the sketch is calculated by Hough transform, and tilt correction is performed. After correction, a lightweight YOLOv8 model is used to recognize 28 common interactive controls to obtain the coordinate position and type attributes of the controls. Then, the handwritten text area on the control is cropped, and the handwritten text recognition and correction are completed by the CRNN model. Finally, the position, type, and associated text of the control are automatically converted into structured requirement entity data, without the need for manual input of the requirement information corresponding to the sketch. The recognition accuracy of the hand-drawn sketch reaches more than 96%.

[0033] This invention also discloses the specific structure of the improved BERT-GCN model built into the requirement parsing module: the improved BERT-GCN model includes a text encoding layer, a graph convolutional layer, and a hierarchical classification layer in sequence. The text encoding layer adopts the DistilBERT structure, which encodes the text description of the requirement entity into a 768-dimensional semantic feature vector. The output of the text encoding layer is input to the graph convolutional layer and the hierarchical classification layer respectively. The graph convolutional layer adopts a two-layer graph convolutional network, which performs neighborhood aggregation on the semantic feature vector based on the adjacency matrix of the knowledge graph to obtain a 256-dimensional structural feature vector that integrates the association relationship. The hierarchical classification layer consists of a first-level classification head, a second-level classification head, and a third-level classification head. The first-level classification head has an input dimension of 1024 dimensions, which is the concatenation of semantic feature vectors and structural feature vectors, and an output dimension of 128 functional requirements. The second-level classification head has an input dimension of 1024 dimensions plus 128 dimensions, totaling 1152 dimensions, and an output dimension of 64 non-functional requirements. The third-level classification head has an input dimension of 1152 dimensions plus 64 dimensions, totaling 1216 dimensions, and an output dimension of 256 interactive scenario requirements. The outputs of the three classification heads are validated by a logical verification layer to check the hierarchical relationship. If there is a situation where a child label is effective but the parent label is not, the output results are automatically adjusted to ensure the correctness of the hierarchical logic.

[0034] This invention also discloses a specific implementation scheme for the conflict early warning unit built into the requirement verification output module: When the conflict early warning unit detects a requirement conflict, it actively pushes an early warning message to the system backend of the requirement manager and designer via the WebSocket protocol. The early warning message includes the conflict requirement ID, conflict requirement description, conflict type, and the business segment involved in the conflict. Then, it calls the matching interface of the historical processing solution library and uses a similarity matching algorithm to match similar conflict processing solutions from the past 3 years. It outputs the 3 historical processing solutions with the highest similarity. The solution types include four categories: requirement priority adjustment, requirement merging, requirement splitting, and requirement removal, for users to choose from. The processing solution selected by the user is automatically stored in the historical processing solution library for matching adjustment suggestions for subsequent conflict requirements. The conflict processing efficiency is improved by more than 60%.

[0035] Reference Figure 1 This diagram macroscopically illustrates the complete lifecycle of a machine learning-based intelligent analysis method for interaction design requirements. First, the system acquires multi-source heterogeneous raw datasets from various channels, including natural language descriptions, hand-drawn sketches, and historical archived documents. Then, the system performs deep preprocessing on these raw data, completing entity extraction and semantic disambiguation, and constructing a structured knowledge graph of interaction design requirements. Based on this, the system uses the triplet data from the knowledge graph as input, feeding it into a pre-trained machine learning model for requirement analysis. Through layer-by-layer reasoning, it outputs three-level hierarchical requirement labels: functional, non-functional, and interaction scenario. Finally, the system rigorously checks for conflicts and prioritizes all generated requirements, accurately matching the analysis results with a pre-set interaction design component library, and outputting a highly reusable front-end component recommendation list, achieving automated transformation from vague requirements to standardized components.

[0036] Reference Figure 2This diagram details the processing logic for transforming multi-source heterogeneous raw data into a structured knowledge graph. For input data of different modalities, the system employs differentiated processing pipelines: for hand-drawn interactive sketches, object detection algorithms are used to accurately extract interactive control entities and handwritten text features; for natural language descriptions and historical archived documents, a pre-trained language model is invoked to perform deep entity recognition and relation extraction. After obtaining the initial entities, the system introduces a general interaction design knowledge base for global semantic disambiguation to ensure consistency in requirement definitions. Finally, the system maps the cleaned entities, the relationships between entities, and specific constraints to the knowledge graph. Nodes in the graph cover categories such as user roles, function entry points, and interactive actions, while edges represent complex logical relationships such as subordination, triggering, or mutual exclusion, providing a solid graph-structured data foundation for subsequent machine learning inference.

[0037] Reference Figure 3 This figure reveals the internal computational architecture and hierarchical label output mechanism of the requirement analysis machine learning model. The model employs an improved graph convolutional and pre-trained text encoding fusion network (an improved BERT-GCN model). During the data input phase, the model's text encoding layer first performs high-dimensional feature encoding of the textual semantic information of requirement entities in the knowledge graph; subsequently, the graph convolutional layer deeply intervenes to extract the structural features of the topological relationships between entities in the knowledge graph. During the model training phase, the system uses a historical design requirement dataset for fine-tuning and employs a loss function that combines cross-entropy and requirement hierarchy constraints to ensure the rigor of the model's logic. In the inference output phase, the hierarchical classification layer strictly follows subordinate logic, sequentially outputting first-level functional requirement labels, second-level non-functional requirement labels, and third-level interaction scenario requirement labels, fully replicating the business decomposition logic of interaction design.

[0038] Reference Figure 4 This diagram highlights the execution path of conflict resolution, strategy adjustment, and final component recommendation after requirement analysis. Upon receiving the three-tiered requirement tags, the system first activates the conflict verification engine to accurately calculate the similarity between different requirement entities. When the similarity exceeds a preset safety threshold and a logically mutually exclusive relationship exists between two entities, the system triggers an alarm and marks the corresponding node as a conflicting requirement. For conflicting requirements, the system adaptively adjusts and reorganizes them according to preset business priority rules to ensure the coherence and feasibility of the overall requirement chain. After verification and sorting, the system generates the final requirement analysis result and drives this result to perform multi-dimensional feature retrieval in a preset interaction design component library, ultimately identifying and outputting a standardized, reusable component recommendation list adapted to the current requirement.

[0039] Reference Figure 5This diagram systematically presents the hardware and software system architecture used to implement the aforementioned intelligent parsing method. The system is divided into four core functional modules. The top-level multi-source data acquisition module is responsible for coordinating the access and aggregation of various heterogeneous input sources. The data preprocessing module has a built-in professional sketch recognition unit, which can convert unstructured images into usable entities and complete graph construction. The requirement parsing module, as the decision-making center, encapsulates an improved graph convolutional inference model and is responsible for performing highly complex hierarchical label mapping tasks. The bottom-level requirement verification output module is equipped with a conflict early warning unit, which can not only proactively push early warning information when logical contradictions are detected, but also automatically generate conflict adjustment suggestions based on the experience accumulated from similar historical cases, and finally complete the selection and distribution of target interactive components.

[0040] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A machine learning-based intelligent analysis method for interaction design requirements, characterized in that, Includes the following steps: Obtain multi-source heterogeneous raw datasets corresponding to interaction design requirements. The multi-source heterogeneous raw datasets include user natural language requirement descriptions, hand-drawn interaction sketches, and archived documents of historical interaction requirements. The multi-source heterogeneous original dataset is preprocessed to extract requirement entities, disambiguate, and construct an interaction design requirement knowledge graph. All requirement entities, entity relationships, and entity constraints are mapped to the interaction design requirement knowledge graph. Input the triplet data of the interaction design requirement knowledge graph into the pre-trained requirement parsing machine learning model, and output a three-level hierarchical requirement label, which includes functional requirement label, non-functional requirement label, and interaction scenario requirement label in sequence. Conflict checks are performed on all requirements corresponding to the three-level hierarchical requirement tags. Based on the preset priority rules, the sorted requirement parsing results are generated. The requirement parsing results are matched with the preset interaction design component library, and a recommended list of corresponding reusable components is output.

2. The intelligent analysis method for interaction design requirements based on machine learning according to claim 1, characterized in that, The steps for preprocessing the multi-source heterogeneous original dataset specifically include: using object detection algorithms to extract interactive control entities and handwritten text entities from hand-drawn interactive sketches; using pre-trained language models to extract entities and relationships from natural language requirement descriptions and archived historical interaction requirements documents; and performing disambiguation on the extracted entities based on a general interaction design knowledge base.

3. The intelligent analysis method for interaction design requirements based on machine learning according to claim 1, characterized in that, The entity nodes of the interactive design requirements knowledge graph include user role nodes, function entry nodes, interactive action nodes, and constraint condition nodes. The relationship edges between entity nodes include subordinate relationship edges, trigger relationship edges, and mutual exclusion relationship edges. The attributes configured for each entity node include requirement priority, applicable scenario, and compatible terminal type.

4. The intelligent analysis method for interaction design requirements based on machine learning according to claim 1, characterized in that, The required analysis machine learning model adopts an improved BERT-GCN model. During the model training phase, it is fine-tuned using a labeled historical interaction design requirement dataset. The model's loss function uses cross-entropy loss superimposed with requirement hierarchy constraint loss. The requirement hierarchy constraint loss is used to restrict the logical consistency of the three-level hierarchical requirement labels.

5. The intelligent analysis method for interaction design requirements based on machine learning according to claim 1, characterized in that, The steps for outputting the three-level hierarchical requirement tags specifically include: first, outputting the first-level functional requirement tags to clarify the core functions of the requirement; second, outputting the second-level non-functional requirement tags to clarify the performance, adaptability, and compliance requirements of the requirement; and finally, outputting the third-level interactive scenario requirement tags to clarify the applicable scenarios, triggering conditions, and interaction paths of the requirement.

6. The intelligent analysis method for interaction design requirements based on machine learning according to claim 1, characterized in that, The specific steps for performing conflict verification on all requirements corresponding to the three-level hierarchical requirement tags include: calculating the association similarity between different requirement entities; if the association similarity exceeds a preset threshold and there is a mutual exclusion relationship between the two requirement entities, then the corresponding requirement is marked as a conflict requirement; the conflict requirement is adjusted based on the priority rule before the final requirement parsing result is generated.

7. A machine learning-based intelligent analysis system for interaction design requirements, used to implement the intelligent analysis method for interaction design requirements as described in any one of claims 1-6, characterized in that, include: The multi-source data acquisition module is used to acquire multi-source heterogeneous raw datasets corresponding to interaction design requirements. The multi-source heterogeneous raw datasets include user natural language requirement descriptions, hand-drawn interaction sketches, and archived documents of historical interaction requirements. The data preprocessing module is used to preprocess the multi-source heterogeneous raw dataset, complete the extraction of requirement entities, disambiguation, and construction of an interaction design requirement knowledge graph, mapping all requirement entities, entity relationships, and entity constraints to the interaction design requirement knowledge graph. The requirement parsing module has a built-in pre-trained requirement parsing machine learning model. It is used to input triplet data of the interaction design requirement knowledge graph and output three-level hierarchical requirement labels. The three-level hierarchical requirement labels include functional requirement labels, non-functional requirement labels, and interaction scenario requirement labels in sequence. The requirement validation output module is used to perform conflict validation on all requirements corresponding to the three-level hierarchical requirement tags, generate sorted requirement parsing results based on preset priority rules, match the requirement parsing results with the preset interaction design component library, and output a recommended list of corresponding reusable components.

8. The machine learning-based intelligent analysis system for interaction design requirements as described in claim 7, characterized in that, The data preprocessing module also includes a built-in sketch recognition unit, which is used to perform edge detection, control recognition, and handwritten text extraction on hand-drawn interactive sketches, converting unstructured hand-drawn sketches into structured entity data.

9. The machine learning-based intelligent analysis system for interaction design requirements as described in claim 7, characterized in that, The improved BERT-GCN model built into the requirement parsing module includes a text encoding layer, a graph convolutional layer, and a hierarchical classification layer. The text encoding layer is used to encode the text information of the requirement entity. The graph convolutional layer is used to extract the association structure features of the interaction design requirement knowledge graph. The hierarchical classification layer is used to output three-level hierarchical requirement labels that conform to the subordinate logic.

10. The machine learning-based intelligent analysis system for interaction design requirements according to claim 7, characterized in that, The requirement verification output module also has a built-in conflict warning unit, which is used to push warning information when a requirement conflict is detected, and generate adjustment suggestions for conflict requirements based on the handling schemes of similar historical requirements for users to choose from.

Images